[MUD-Dev] Team management

[Michael Tresca]

Peter Harkins posted on Tuesday, February 25, 2003 4:41 AM

> Keeping track of wizards is another matter. We've got over a
> dozen, of varying levels of commitment and experience level. The
> hardest thing to know is what they're up to or if they're stuck or
> slacking. We've got a few newbies who sometimes need hand-holding,
> and they'll sometimes be reluctant to ask for help (though we've
> mostly gotten it through to them that we don't think they're dumb
> for asking questions) or they'll get stuck and disheartened
> without us realizing it. A few of the wizards that are experienced
> coders (and I'll admit I fall prey to this vice) are content to
> theorize and plan systems but not implement them.

Well, first things first:

  1) Not everyone should be wizzed.  Why would you want someone who
  is low on the commitment scale?  Coding is something of a job and
  while the results are often fantastic, getting there seems
  suspiciously like work.  Coders must be committed or there's no
  point -- it's a volunteer game, so pay's not the incentive.  If
  you're not committed, then it's difficult to reap the rewards:
  satisfaction of a job well done, seeing it enjoyed by players,
  admiration by other coders, etc.  It's all intangible.

  2) Create a sponsorship program.  On RetroMUD, nobody wizzes
  without playing the game for a substantial period of time.  In
  addition, our more advanced wizards MUST sponsor them.  If you
  can't find someone to sponsor you, then no wizzing.  This also
  means at least one person cares about what the new wiz is doing.
  If the wiz fails, it's embarrassing to the sponsor.

> In a nutshell, we have a hard time knowing what everyone is up to
> and if they need help, a push, or something to do. So, on to how
> we've been keeping track of the team.

  3) Ask.  Once a month, an email goes out to the wizards to see
  what they're up to.  If there's problems, we step in as
  administrators to figure out what's wrong and what needs to be
  fixed.  Tracking everybody individually is definitely challenging,
  so why not the new coders make it easier for you by giving a
  report out?

  4) Wizards should not have total access.  By scaling the coding
  tasks, they feel less overwhelmed and are less likely to start
  blowing your game up by accident (or worse, on purpose).  We make
  it a point of having a trial period of a few months.  New coders
  must produce an area during that time or, failing that, provide a
  date when they think they'll be finished with it.  If they can't
  do that, they get removed.

In my experience, a new wizard's likelihood of success or failure is
determined within a week of their wizzing.

Mike "Talien" Tresca
RetroMUD Administrator
http://www.retromud.org/talien




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev