Here's a topic to get some discussion rolling in this forum. What are the different styles of hierarchy you've come across in MUDs and their admin staff? What are some that you've found to be the most effective?

It's fairly common sensical to assume that the level of complexity in a chain of command would increase with the size of the staff, but there can be variances in style even for a smaller team. For example, if MUD is just starting up with the owner and a couple others, the owner could be the sole wielder of power and act as taskmaster, or everyone could operate as equals and co-founders.

In larger MUDs, the tradition is often to have a head administrator/implementor, a head coder (could be the same person), and a head builder or area/project leads. This is probably good for keeping a staff organized and on-task, yet I've also seen successful MUDs that have just a head admin and everyone else on an equal footing, where game decisions are generally made in a more democratic manner.

Largely I think how viable a particular style of hierarchy is depends on the individual personalities of a team and its leaders. A "democratic" system would be difficult to achieve without trustworthy and cooperative staff members. Likewise, a highly structured system would stagnate without motivated (and motivating) heads to push new projects to completion.

Holy carp! Talk about a controversial beginning! Well, I love it though and that's exactly the kind of question that draws meaningful, intelligent discussion and "opinion."

I've got to step back though and see how the responses come in while I formulate a few cogent replies myself. There's a plethora of viewpoints that range from 'Deming' styles on the personnel side through Oligarchy, Monarchy and outright dictatorships on the political side of things.

Having gone from a nonhierarchical mud to a hierarchical one, I think you make some good points. The nonhierarchical system seemed more casual and welcoming to new players. The founder had the reigns on coding, but he counted on cooperation from a small and highly dedicated staff to build concensus on everything else.

The nonhierarchical mud was successful in this case because:

1. the mud was small.
2. the advancement of the players depended on role-playing more than on item aquisition. That minimized the potential for corruption, either from players or staff, since very little could be accomplished without a community of witnesses. On the other hand, since this mud was all about plot, even the newest imms had tremendous power, through their rp interactions with players, to shape the ongoing story.

I've come to appreciate the value of a hierarchical system for larger muds, but the devil is in the details. The more power you put in the hands of the top staff, the more the mud lives or dies with their integrity and leadership skills.

A "democratic" system would be difficult to achieve without trustworthy and cooperative staff members.

In October 2000 I put together the first design draft for a mud, and emailed it to two friends of mine. We were good friends in real life, and all had years of experience developing and running muds, but we could not agree on what made a good mud! By March 2001 we still couldn't even agree on the basic design (with not a single line of code in sight), and the points we had finalised were compromises that none of us found particularly appealing. Suffice to say that we lost interest, and the design was scrapped.

So I would say that as well as trust and cooperation, a shared vision is also something that is absolutely critical if the staff are developing a mud in a 'democratic' way. Unfortunately this is extremely difficult to achieve, as there will always be disagreements on one point or another. Therefore I think it's better to have one admin with the power to make final decisions in any particular area - either one admin with the final say on everything, or dividing it up so that one admin has the final say on building, another has the final say on coding, etc.

So I would say that as well as trust and cooperation, a shared vision is also something that is absolutely critical if the staff are developing a mud in a 'democratic' way. Unfortunately this is extremely difficult to achieve, as there will always be disagreements on one point or another. Therefore I think it's better to have one admin with the power to make final decisions in any particular area - either one admin with the final say on everything, or dividing it up so that one admin has the final say on building, another has the final say on coding, etc.

I agree completely with that. I would say further that if you want a truely democratic system, you have to have it in place from the very start. I think that the moment you start working on your game, it becomes YOUR game, and no amount of power sharing that comes later will ever change that.

This is based on opinion and observation, not on any direct experience.

The most beneficial mudwise of doing it would be to have the lead admin (owner/whatever) , Head Builder, and Head Coder. They form the high council or whatever. Then you break it down into specific areas of specilization. Your coding group. The Head Coder works as CIO, and runs the coding department. The head builder works as lead for her department. And the Admin can run the Roleplaying/Game-enhancement/Enforcers group.

The key here, I think is to distribute amongst the wizards a sense, that there is no one over them who is responsible for things, but it's a different department that's responsibile for things. When you have 9 levels of Wizards, the buck'll be passed. It's Middle Management Mud style! So I think that by giving ownership to the people who can handle the ownership (got a feature you want added? Talk to Coder. Got a typo in a room? Talk to Builder. Got a problem with another player? Talk to an Admin Assistant.

We have what I'll call a concentric-groups approach. There's a head admin who has the final say, is pretty well-respected by everybody, and who mostly only steps in to stop people from doing horribly unbalancing things and to stop fights. There's a group of about 4 more admins who decides (usually by unanimous agreement) serious admin issues like when someone needs to be kicked out; around that is a group of about 10 who decide by vote when to promote people in the admin hierarchy, and outside that is the full group of admins, builders, etc. who decide all other mud issues by chaotic discussion: they more-or-less have a veto of game changes and can suggest ideas. We don't really have a split of "Alice is a coder, Bob is a builder", wizards are wizards and they just need to do something.

The coders are all in at least circle-of-10, mostly because we don't give anyone access to the code until we have some level of trust. We have an in-game scripting language that is good enough for a lot of coding-type-things, everybody has access to that. People advance through the hierarchy by contributing (time, not money), either by building, adminning, running quests, or doing something else for the game like running the website.

Throughout my experience on a variety of MU* administrative teams, I've found that hierarchies are nearly always more productive, stable and sound. They also run the risk of totalitarian despotism, however, and require the key administrators to not only be visionaries but also talented managers and executives.

As many MU* administrators, particularly the novice or inexperienced, have had the majority of their MU* experience as players, the majority of staff hierarchies that I've seen are similar to player hierarchies - a number of hegemonic levels that staff members advance through based on the number of projects they've taken up and completed. (Eg. After building three areas, a Prospective Builder is promoted to Builder). This, as far as I've seen, does not work well, and often leads to bruised egos and egoist powerplays.

So while I suggest a hierarchical structure, I also stress the important of keeping things as simple and community-based as is possible. Having an administrative head for each major department (building, coding, roleplaying/story creation) can assist in staff structure, but dividing it into further stratas is a dangerous strategy.

While I've seen the model suggested by KaVir, and seen it work extremely well, I've had incredible success in my current and past projects with a binary division at the top of the hierarchy.

My current project, despite being in its infancy, works under the following model:

Executive Development Director - Essentially the CEO, directs the development and design, maintains the server, establishes the ethics and rules, is the final authority on all staff/player administration and code implementation.

Executive Creative Director - Directs the implementation of theme, world, storyline, roleplaying, building and in-game atmosphere. Presides over non-coded implementations and day-to-day staff and player administration.

The seperation into such a duality allows for brainstorming and compromise while offering a 'buck-stops-here' executive leadership that is essential. Traithe and I have been able to pull this off based on a mutual respect and trust in the other's capabilities - as such, we've been able to move quickly toward the pursuit of a joint-vision while adapting our ideas toward compromises we're both happy with.

In the future, we'll most likely be adding directors of various staff spheres (eg. Director of Building) who will act as administrative foremen under the respective executive architect. The majority of staff members, however, will most likely be engaged in a plethora of activities - from building to roleplay administration to player assistance - with the relevant directors approving and monitoring projects to ensure cohesiveness. I believe that any further stratification - having a group of 'builders' and a group of 'roleplay administrators' for example would be counter-productive. We'll see how it goes.

We use multiple levels of hierarchy (10), grouped into 3 major tiers. Avatars are new to the staff, and have minimal access to immcommands and internal information. Immortals are the bulk of the staff, and Implementors manage the staff and have the final say on design/etc. issues.

One thing we do that most games don't is that we try to cross-train all members of the staff- we don't have 'builder' positions, for example. Everyone who has earned at least the Immortal tier knows how to build, run quests, handle a religion, run a mortal cabal, design, and enforce the rules. Coding is probably the only exception, and is done largely by Implementors, although some jobs are "farmed out" to Immortals with appropriate background and interest.

This cross-training has given us a lot of cohesion-- there aren't "camps" of builders vs. quest people, or whatever, because everyone has had to walk in each other's moccassins for a while. Also, it means hybrid projects (i.e., alter this area, have your cabal kick off a quest around it, then have it culminate in a global quest when the new area is ready to be switched in) can be handled by one person.

I think any kind of hierarchy is just a power trip and will eventually lead to corruption... besides no MUD should ever have the amount of staff with different roles to require any kind of structured hierarchy anyway.

In MUDs only one person has real power, the coder- everything else is just perceived power, in the words of the great philosopher "they are guarding all the doors, they are holding all the keys". Even builders must work under the constraints the coder grants them.

And perceived power is very dangerous because most of the time feeling inadequate at not having any real power will make one strive to gain more and more perceived power which results in corruption. This is just what I have seen, but I have strong empirical evidence.

If the coder is not the owner of the mud then that coder is granting control to the owner and they can be perceived as a single totalitarian dictator. That's one rank. Most of the time some powertripping owner will put his coder a step below on some artificial hierarchy but who is he kidding- I have been in this situation and find it very funny when the owner says, 'ok now set me to level 105 and you to level 104'... yeh sure thing boss

Everyone else has a position of perceived power granted to them by the dictator(s). So I think you should just set up a series of classes that separate the immortal commands into groups that perform a certain function. All the builder commands to a builder class, all the rpcontrol commands to the rpimm class, etc... however many roles you have on your mud. Then assign these classes to your staff as required by their function. These classes should not be mutually exclusive but instead build on each other so that the dictator is a member of all the classes and so has access to all commands.

Now you have owner(s) and staff, and no distinction between each member of the staff. Communism wins again!

I think any kind of hierarchy is just a power trip and will eventually lead to corruption...

I think that really depends on the individuals in question - there'll only be as much corruption as the top admin allows.

Quote:

besides no MUD should ever have the amount of staff with different roles to require any kind of structured hierarchy anyway.

You'd be surprised - most mud admin have real lives as well, so if you want staff on most of the time to help people then you might find yourself needing several staff members. And the larger your playerbase, the more important this is likely to become.

Quote:

In MUDs only one person has real power, the coder- everything else is just perceived power, in the words of the great philosopher "they are guarding all the doors, they are holding all the keys". Even builders must work under the constraints the coder grants them.

Well by the same logic the coder works under the constraints that the machine owner grants them. And the machine owner works under the contraints that their ISP grants them. And the ISP works under the constraints that the electricity companies grant them. And so on...

Besides which, what's the worst a coder can do? Delete the source code? Fill it with backdoors? Delete the pfiles? If the mud owner has kept backups then it shouldn't be more than a setback - certainly no worse than a hacker can do, and I'm sure you wouldn't suggest that hackers have the real power?

Wouldn't I . But seriously you made a bit of a leap there, I was talking about strictly within the MUD environment. All power within the mud is controlled by the coder do you dispute this?

er... maybe I should define my use of the word- by power I mean the ability to affect, and to not be affected by, the environment, in this case the environment is the mud (not the machine, not the network, not the power grid, not the shadow government, etc...)

If the coder displeases the owner than the coder can be fired and then the next coder has all the power, I don't mean to imply that the coder himself has the power it is the position and the capabilities of that position that has it.

My main point here is that hierarchies don't make sense in an environment where only one person has any real power.

KaVir wrote:

I think that really depends on the individuals in question - there'll only be as much corruption as the top admin allows.

But why does it need to depend on the individuals in question? I'm naivly looking for the perfect solution not a system of checks and balances (balances move and sway and eventualy come to equilibrium, a perfect solution is always perfect), and I'm assuming corruption comes from a position of perceived power- therfore in my mind by eliminating such positions you eliminate corruption. I may not be right... but thats what makes the conversation interesting

KaVir wrote:

if you want staff on most of the time to help people then you might find yourself needing several staff members

I said staff with different roles, a 100 person staff will still have what... 4 roles? coder, builder, rpimm, greeter (5 if you include owner as a separate role) but I dont see why newbie greeters have to be part of the staff. Slap a fancy title and a newbiepack command on a few high level players that play at different time intervals and you have your greeters. Restrict the term staff to mean those that can directly affect the game's content. I still don't see a reason why some hierarchy needs to be imposed.

Wouldn't I . But seriously you made a bit of a leap there, I was talking about strictly within the MUD environment. All power within the mud is controlled by the coder do you dispute this?

If proper source control policies are in place, I absolutely would dispute this. It happens that most MUDs don't have anything like that, but there's no reason you can't require an approval process for any patch to the mud. Of course if whoever is running the show is not qualified to review for quality, a programmer could slip in backdoors and such, but in terms of actual features and so forth, it's certainly possible. Perhaps you're thinking of some other notion of power - what sort of power exactly does the coder have that others don't? Sure, the server can't do anything that's not supported by its code, but significantly generic servers exist that put a lot of that power in the hands of builders.

Cornelius wrote:

But why does it need to depend on the individuals in question? I'm naivly looking for the perfect solution not a system of checks and balances (balances move and sway and eventualy come to equilibrium, a perfect solution is always perfect), and I'm assuming corruption comes from a position of perceived power- therfore in my mind by eliminating such positions you eliminate corruption. I may not be right... but thats what makes the conversation interesting Twisted Evil

Well, the perfect solution is to have perfect staff who never do anything bad and always get along. Good luck with that one. I think as team size grows, the need for some kind of hierarchy increases. Not necessarily deep like a lot of muds have, but at least some kind of structure to keep everyone on track and organized.

Cornelius wrote:

I dont see why newbie greeters have to be part of the staff.

I was unaware that such a practice existed. There are newbie greeters?

It's not really a useful way of looking at it, that "the coder has all the real power". There's a sort of power that the coder has, inserting back-doors etc., but if he's exercising that sort of power then the mud is in a lot of trouble.

Maybe you mean he has power because if some builder wants a special feature he has to come ask the coder, but the coder rarely decides to go ask a builder to build a special area, so it looks like the dependency all points one way. But really, the builder can probably get by without the feature; he doesn't absolutely require the coder's help to contribute to the mud.

If the mud admin is set up to have one specific person ultimately responsible for each decision, it doesn't make any sense for the coder to make the decisions regarding aspects of the game that he doesn't pay close attention to, like consistency in building. Possibly the coder doesn't even want to pay so much attention to the building that he can make informed decisions there. Also, it's hard to make good game balance decisions if you don't spend a lot of time playing the mud, and a coder may not want to do that either - I know I don't.