Managing Wizards
Operational Notes on the MU Wizard Managers
By: Brian Jones (aka Otter)
Part of the Management Series.
Introduction
This article discusses the issues wizards face in working together to run a MU. It doesn't propose any particular organization structure but instead seeks to describe the strengths and weaknesses in the various standard approaches.
Some Definitions
The people with the privilege to directly affect the DB of a MU regardless of owner are called Wizards in the MUCK community, so that's the term I'm using here. These people are the executive level management with the software-granted power to act unilaterally. One of these people controls the most powerful character (by convention, named One in the MUCK community) and is referred to as the Head-Wiz or Chief. Typically, this is the founder of the game.
There is one level "beyond" the Chief and that's the site administrator. This person owns or controls the computer or account that hosts the MU. This person has direct access to the database files themselves. This person will always be able to do whatever they want. They will be discussed at the end of this article.
Non-wizard staffers of a game are players with limited powers to affect things directly. They have the same management/social issues as a wiz-staff, so what is described in this paper can apply to them as well.
Common Organizational Decisions
The key decision in any Wiz hierarchy is whether there is a Chief or not.
MUs are not created in isolation very often. It's theoretically possible for someone to download the MU software, install it, build the key areas, update all the programs, build the web-site, market, etc., all without having the help of another. It's possible. It's not likely (nor would it be much fun). So, I'm going to ignore the pathological case of a MU with only a single wizard that did literally everything and so can justly take all credit for the entire program.
So, there's a group of people, most likely friends, who start a MU. One of that group takes the initial founding actions of arranging a site, forming the team, pushing and poking and cajoling and supporting the others, and keeping spirits up and people focused until the MU is ready to open. That wizard is usually the one that controls One, and normally becomes the Chief or Head wiz.
This isn't the only model!
It's possible that the password of One is shared and that in fact the wizards form a collective leadership strategy. You'll hear this as Co-Head wiz, or Partnerships. If there's more than two, they might even just be a team or board. The key is, in this organization, there is NOT a single control of the game, but a group that can act.
So, decision one is ...
Single leadership is the most common. It's also the easiest for that leader, because they get whatever they want and win every debate every time. This is also the position of the President of a company that controls 51% of all shares (or of a sole proprietorship).
So long as the single leader is capable and does their job, the MU thrives. There's a clear chain of command at all times. Decisions can be made rapidly (albeit, not necessarily wisely). There is no finger-pointing if a problem occurs, because the one with the authority is also the one with the responsibility.
Let them be incapable or even destructive, and the MU will be harmed or perhaps destroyed. A single leader who gets annoyed and destroys every room or shuts down the server can literally eliminate a MU in seconds. It's easy for a leader to drive players and staffers away, to devastate the social cohesion of the game, and to make it a hell to connect to.
Responsibility is the main reason that people tend to back away from single leadership. The power is great, but it isn't so nice being on the hook for all issues. To share responsibility, to reduce the "burden of command", people seek to take on partners.
Having a collective leadership structure on the other hand divides authority and responsibility to a pair or a group. If a member of the group becomes incapable or dangerous, that member can be removed. This would seem to provide a more secure and predictable form of leadership. You get the discussion to remove rough edges, and the need to achieve consensus means that the actions taken will be more balanced and less extreme. This is equivalent to a publicly traded company's Board of Directors.
This style also has serious drawbacks. Without a clear chain of command, it's very easy for a MU to become a set of fiefdoms, where each member of the leadership team has their own faction. Also, it's very difficult to manage consensus when problems arrive. Committees, by their nature, are fairly conservative (not politically but "slow to make changes"). When Chrysler was in serious trouble it turned to Lee Iacocca and gave him permission to fix things. The board led by granting power and trust, not by direct control. This decision is courageous and difficult to make.
Apple Computer ended up firing their leader (Steve Jobs) not long after the Mac release because he was acting as a single Head wiz with all the negatives and none of the positives. But they brought him back years later (where he is still to this day) because they needed the focus and dynamic control that a single active leader provided. It doubtless helps that he had a chance to mature a bit more...
So, Apple is a good example of a combination of these two. A board of directors that has final power that monitors but doesn't meddle as much with a very charismatic and powerful single leader.
In a MU context, this would be hard to arrange because there isn't the easy monetary measurement standards. But it's something worth considering.
If a collective is chosen, it's very important to document how the collective will function. Votes? Consensus? Unanimity? This documentation allows the collective to function in the face of crisis. Without it, the collective will tend to shatter. There's a reason the military documents in formal procedures everything. It allows the units to maintain cohesion in the face of death and destruction. The collective must determine at the least how to add and remove people from the management team. And they must have some means of ensuring continuity. It's not a real collective if only one person holds the keys to the account and to One, after all.
Regardless of the claims of the membership, if only one person controls the account and has access to One, the system is a single leader system. Because, in the end, that person can't be fired. I see a lot of MUs that claim to have collective management but in fact have a single holder of One's magic password. They are a collective only so long as the Chief permits it. They're a collective in name only. They are a collective that serves "At the discretion of the Chief."
So, when choosing the answer to this crucial fundamental issue, be sure to document clearly what the answer is, and to provide the means to ensure that the choice can be enforced later.
Value of the Team
The team exists to carry out the mission of the MU (whatever that mission may be). If the team can't or won't work together, the team has no value and should be disbanded and a new team formed.
This sounds harsh, and probably is. But the team MUST support the leadership of the game. In a single leader system, this means the team exists at the discretion of the leader. In a collective leadership, the team exists at the support of the collective.
Not all wizards on a wizard team are part of the collective leadership. In a system with six wizards, of whom two are "Co-Head Wiz", the other four wizards serve the two. Serve, not demand.
All staff exists within the context of the leadership. If the leader(s) can't work with someone, they need to be removed. This causes great strife, popularity fights, etc., but if the team doesn't work, the team can't do its job and the MU will suffer regardless.
This is most painful when a collective leadership decides to remove one of the leaders. But the situation remains the same: if the leadership isn't doing its job, the MU isn't being led. The MU can't function well in this capacity.
These are the most unpleasant situations imaginable. They are unpleasant in the real world too; firing is not something most people like.
As a result, the best solution is to do less hiring. Keep the size of the staff (and of any collective leadership group) small. Don't hire until the MU overwhelms the current staff!
Operations Within the Team
Having organized the team and decided on single or collective control is the key decision. Now, the team must be able to function. This section is about how the team operates as a team.
Communication Within the Team
No team is going to function if the members lack the confidence to speak honestly and openly without fear of reprisal in private. There's simply no way for a team to run when fear interferes with the freedom of communication.
So, this topic deals with communication that takes place privately during the meetings of the team. This topic does not talk about the team member's communications outside the team or the public communications the team may have. Public communications will be dealt with next topic.
In a MU, most "meetings" are really just discussions that take place using team-only communication tools, such as "wiz-chat" or wiz-only bulletin board areas. For this topic, I'm going to refer just to the discussion, and not the medium, because the same issues apply regardless.
Speaking before others is difficult for many people; that should simply expire after a period of membership when the novelty wears off. But, when a new team member is inducted, remember that they will likely be hesitant and don't assume it means they agree with what is said or have no view. This is just basic team management, but be sure to welcome the new team members and draw out their positions until they're confident on their own.
Even though the communication is private everyone must understand that it can and will leak out into the real world. There is a very large distinction between private and secret. The discussions among the team are not secret. Privacy means that they are expected to take place in a trusted context. The reader of a private discussion's log must understand that they are seeing people being more open and trusting than in public. A secret communication on the other hand would have "grave damage" if leaked to the public.
The simplest example of private versus secret is this: you want privacy when you use the bathroom. There's no secret there, but you don't expect to be spied on. You want secrecy if you plan to murder someone.
There should be no secrets on a MU; MUs aren't secure, and they shouldn't involve information or actions that will cause grave harm. But, privacy is important to all involved.
So, private discussions among the wizard staff involve the management and administration of the MU itself. They also involve discussions of problem players, of issues that may involve problem players, and possibly issues that may involve legality (such as inappropriate contact with minors or sexual harassment). Mostly, the discussions within the staff will involve less intense things, such as upcoming events or how to solve some technical challenge. In all cases, until the discussions have become published decisions and carried out, they must be treated as provisional.
During the discussions in private many ideas will emerge. Some will be carried out, some won't. When an idea is selected for action then it goes from provisional to accepted. Accepted ideas should then be dealt with from a "how" perspective instead of a "can we or should we" perspective. Even if someone on the staff doesn't think the idea is good, they should cease trying to sink it or snipe at it. Productive discussions can't occur if there's sabotage going on.
It is reasonable for someone that disagrees with an idea to ask not to be involved in carrying it out; depending on the idea, that may be possible. Even if that's done, the person shouldn't publicly attack the idea. We'll discuss this more in the section on public communication.
When there is an inability to come to terms on something within the group then the group needs to use the documented standards described above. If it's a single leader system, the Chief needs to decide. If they're wrong, they're wrong. That's the burden of being Chief. In a collective system, the consensus/vote/whatever rules should be used. Of course, it's always OK to table an issue for later as long as the issue doesn't demand immediate attention! Letting an issue fester though will cause the group to fight amongst itself.
When there's "positions" within the group, such as half the team wants one version of the idea, and half another, and they start arguing as sub-groups, consider having each of the sub-groups do a position paper (or "opinion" in the legal sense) and then re-address the issue after everyone has read all the papers. Do this as a paper (web-page, NOT interactive) so that each party has a chance to write their whole piece, evaluate it, discuss it amongst themselves, and sign their names to it. It's much easier to make something clear when you have unlimited time and space before you have to defend. In the act of writing the paper, often it's wrongness will emerge. In this case, withdraw your position and join the others.
The US Supreme Court works this way and it does work. Only they publish their opposing opinions to the world, which is something I'm hesitant to suggest. But they deal with life and death; we're dealing with MU systems.
Personal attacks within the discussions is always out of place. The general rule: praise in public, criticize in private. Don't say things like, "That's as stupid as all your ideas!" Attack the idea freely, but don't destroy the presenter of it. This is especially true if the presenter is floating it for other players and not personally!
If the team can not manage to discuss things and achieve results, the team really isn't a team and should be disbanded and another formed. That's how important communication is!
Public Communication Between the Team and Players
When the team decides upon an issue (a new idea, a resolution to a problem player, whatever) the team needs to publish this decision to the general player population. Once this is done, the entire team (even those who disagree with it) need to avoid under-cutting the decision.
When all are in agreement, this is easy. When someone disagrees, this isn't. If one morally objects to the decision made, and can't even choose not to speak against it, one should leave the team. A team that makes morally objectionable decisions isn't a place you want to be on anyway!
The more common case is that someone things the idea isn't good. Not that it's evil, but that it's unwise. In this case, the person when asked about by a player can simply say, "That's the policy." They don't have to say, "That's the stupid policy that was created by the other morons on the team."
In point of fact, most ideas aren't worth fighting about. If a team member things the idea is mediocre, they can still promote it and see how it turns out. They can always bring it up again later with specific examples of how it's not working in private with the team.
Thus, the general rule remains, "The whole team should publicly back all decisions made."
What is always destructive is when the players are solicited to back one idea against another before the idea is decided! This can't be stressed enough! It's reasonable to survey the players for positions, but the survey should be issued by the team, not by a single team member meant to trump another!
What this does is causes players to form camps around wizards and then you have the effect of civil war on the game. Do not drag players into wizard disputes. Players deserve a game to have fun, role play, and relax on. The management of the game is not their problem and should not be made their problem.
Player surveys and feedback requests, and public meetings, thus are optional for them. When those sorts of player solicitations are done by the whole team to the players it provides excellent opportunities to tap the many intelligent people who are on your system. When this is done, it establishes an expectation among the players that their statements matter. To solicit them and then ignore the results will cause them to feel slighted (and to in fact be slighted). If you put something to a player vote, be prepared to live with the results.
This is also why it's important that undecided issues not be presented to players. It causes the players to have expectations that may not be met. Unmet expectations causes discontent, which in turn can lead to loss of players and complaints that lead to disharmony among the management team.
Now, some decisions made will be unpopular with the players (remove a popular player for breach of rules and watch the fallout). This leads to serious challenges to the wizards.
If they publish everything they have to justify their action, they may in fact be exposing internal logs, private discussions, and even objectionable material (such as sexually explicit harassing pages). Their case may be made, but they open themselves up to litigation risk and the removal of younger players by parents who see such things as inappropriate to their child.
If they publish nothing and say "Trust us" they may BE trusted or they may be seen as running "secret tribunals" and frighten away players.
If they publish some of the material, edited to remove the worst, they can be accused of falsifying the evidence.
If they publish only the deliberations, with references to the material that is not published, they can at least show they didn't act on whim, but still, the players won't be able to judge for themselves.
In the US courts, this is why all evidence must be presented in open court (unless it's a matter of national security or a few other limited cases like active undercover operations). But we're not a court! We're hosting MU systems!
In the end, I can't give really good advice here. My own tendency is to simply say "They were removed for cause" and refuse to destroy the person's reputation. I remove them, they're gone. Sometimes it works, sometimes it doesn't. In the past, I've found that people were convinced that the person did no harm and was forced to show detailed logs. That got the point across, but it always resulted in very unhappy people. That said, if someone claims I'm lying, I do post logs. If the players don't trust the integrity of the management, the management is not going to be able to do its job at all!
Managing the Database
The MU sits on a large database. Because of this, it is a persistent world. The management of this database has two aspects: the technical side and the social side. The technical side I'm not addressing at all here. I'm only interested in how the database affects the players and management team. In other words, the social side.
Places and Their Importantance
The MUs are made of places where the characters interact. I'm only discussing the public places intended for the game's mission. Many MUs also have "out of character" areas where the genre isn't relevant and people do free-form things. I'm not paying attention to those either.
Players become very attached to where their characters play. Not only to the public places created by (or controlled by) the staff, but also the places they create that are linked to those public places. As a result, the DB rapidly becomes a collection of places with multiple owners.
So, who really owns what goes into the MU?
A player who creates a room (or set of rooms) that becomes popular decides to destroy them and leave. Will they be stopped? If they do it and leave, will the rooms be re-created from backups?
I'm not a lawyer, and I'm not worried about the legal side here. The players, though, are worried (rightly) about what the staff can "do" with their creations.
The real point here is to decide this issue and put it into the system's documents that all players read. If you decide that all creations are subject to staff decisions, then document it that way. The players who can't live with it won't create (or won't stay). But at least there won't be fights over it later.
When the MU grows larger, it's often a good idea to positively delineate staff-managed areas from player-managed areas. On Redwall, for instance, the staff-controlled player Atlas owns the common lands. This way, any staffer knows right away (by doing ex here) if the room is one they have the right to work with directly or not.
This is especially important for wizards because they "can" affect anything! It's very bad manners to use wizard powers to affect the database of objects you don't own or have documented control over. For instance, if a wizard goes into a player-controlled area and sees a typo and fixes it, they just changed someone's object without asking. Granted, you can document that wizards have the freedom to do what they want, but that's pretty heavy-handed. So, it's very helpful for wizards to be able to tell easily "Is this a place I should change or one I should notify someone else to change."
On a minor side-note, should a wizard make a mistake and change something that shouldn't have been, don't crucify the wizard. A simple apology and changing it back should be sufficient. Accidents do happen. Wizards mis-key DB id numbers.
The policies of the game should spell out what is and is not appropriate. They should also specify that when the inappropriate is done, the wizard can and must act to resolve it. If a room is built that is inappropriate (for whatever reason) the wizard should not hesitate to detach (NOT destroy) that room and notify the owner of the issue. If the room or object is egregious then by all means after detaching the object and notifying the owner notify all the rest of the wizards and possibly start more serious proceedings.
The players are grateful when the staff ensures their playground is kept proper. They don't like it when the staff butts in to their affairs on a regular basis. There's a balance, but whatever balance is chosen, document it in the policies so the wizard can say, "Yes, I know this bothers you, but per news rules #8 this needs to change."
This makes the MU run by documented laws instead of a "cult of personality". It also means the wizards who don't have the rules on their side should not act. They might want to propose a rules change (in private, to the staff) but they shouldn't punish a player without being able to list the specific rule violated.
It's possible to write the rules such that "It's a breach if a wizard says so." This at least makes it clear that your wizards have unlimited say and players have no expectation of due process. Think carefully through what you want to allow. Not liking something doesn't mean it's not appropriate!
In-game Software and Programs
Many of the leaders of MUs are not technical people but content people. They have visions of a world and the play within the world. They then rely on some technical programmers to help them achieve this vision. These programmers really aren't often interested in management per-se, but they end up as wizards because the database requires they have W flags to write the needed software.
What you have in this odd case is a person with great power who probably has little or no people experience to warrant it. And this person may want to be more involved in management than the leadership may like, and since there's a W flag, the request will be granted out of simple necessity.
The programs the person creates or installs into the MU should be licensed to the MU. The ownership is with the author of the program (per copyright law if nothing else). But, the MU leadership has a reasonable expectation that if the wizard leaves the programs provided can continue to be used. Thus, the MU admin should make clear to programmers the licenses they expect. In NMC, for instance, the software was put into public domain with GNU license specifically to allow anyone to use it without issues later.
The extreme of open-sourcing all the software isn't needed. It's enough that all the software grant a perpetual irrevocable license to use in this MU.
As a simple practical matter, the location of the programs (physically, where the MUF objects are stored in the MU DB) matters. So, all programs should be stored in a common location and owned by a common wizard for admin purposes. This doesn't interfere with the programmer's life, but it does mean that the programmer won't be seen as the owner of code if someone does ex muf-object. This makes it much easier for teams of programmers to work as well.
Programmers should avoid politics if they claim to be only interested in programming! Wise programmers basically say, "I don't care what you leaders decide, let me know and I'll code it." In this way, they can often survive tumultuous changes in management. If the programmer joins the team actively as management participant, then they need to be willing to take off the technology hat and put on the social awareness hat. They lose their defense of "just being the programmer" and have to behave as a true professional. This is better for them in the real world of course (acting as a proper professional) but many MU programmers I've met over the years are happier hiding out of the way coding.
If you have a non-involved coder then make sure the staff honors that! Don't drag the programmer into internal staff disputes. And don't hold it against a programmer who carries out the coding requested by an unpopular decision. Don't blame the flunky, blame the leadership. This is the only way to keep a non-involved coder on the MU. Coders are very mobile. They're in high demand and are welcome most anywhere.
The Site and the Legal Structure
A MU is just a program. It requires some host to run it. That host must be accessible to all players, and is typically publicly routed on the Internet. The host is called the site.
The site can be any machine that can run the MU software. This used to be restricted to UNIX, but modern MUs run on Windows natively as well. The terminology is slightly different between the two, but I'm going to use UNIX as an example because it's the most common case. Everything said applies to Windows as well, only instead of "shell" the term is "remote desktop connection" or "user account."
In the simplest case, the site is owned by the leader of the MU (or one of them in a collective sense). Often, though, the site ends up hosted by a common provider, through a paid or free account.
Be very wary of "free" MU hosting. It's not unheard of (or uncommon) for a "free" provider to use their direct low-level access to the database to take over a game that they want. When you use a commercial provider, and you exchange money, you have a legal binding contract and they're not going to get involved in your internal affairs.
In either case, the point here is that the person that has access to shell account where the software itself is administrated can do anything they want, including turn the game off, move it somewhere else, destroy it, or take it over. This site must be trustworthy.
If the leader owns or controls the site, the MU isn't going to change leadership through any means not approved by the leader. Period. Even if the One in-game account is hacked, the leader can simply down the software and edit the files to restore One to his or her control. In this way, any MU with a single owner of the account is always a single-leader MU regardless of any claims to the contrary.
If a multi-leader system is to honestly work, the account needs to be controlled by a legal entity (such as a corporation) in which the co-leaders have voting privileges. This is inexpensive, since non-profit corporations typically cost less than $100 to form and under $100/year to run. You don't need to make them tax-exempt charities (which is expensive) to get the legal ownership of the game and account resolved. This also may (MAY) protect the leadership from liability issues with a corporate veil.
While a corporate structure may sound extreme, it is the typical way real-world institutions survive changes of membership over long time-periods.
Whoever runs the site, be sure the MU is backed up regularly with an automatic system. This does not mean "sometimes the Chief kicks off a backup." It means by example "Every night at 2am the MU is backed up by crontab and the files moved off-system." The backups must be automated or they will not happen. Backups seem over-focused on until there's a crash and the MU is lost. With backups, it's a few miserable hours of recovery and re-start, posible re-install of the OS and software (often, only the MU data is saved, not the executables). Without the backup, a loss of disk is the loss of all the work. Perhaps you can rebuild some from saved client logs, but ... most likely not.
The MUs generate logs. These logs can be configured to hold everything done or less. Whatever is chosen, be sure that your players know that the logs exist and on what terms you'll refer to the logs.
Nothing that goes into a MU should be secret: the MU isn't encrypted and you don't want the legal liability of being used to route child porn for instance. So your in-game documents should state that the logs do exist, are backed up, and can be used by law enforcement at the least. This protects you in two ways: by keeping people who would use your game for illegal chat off and by showing due diligence.
The site admin is often the one who will be on the hook, so they will often backup the logs on their own to protect themselves. If they are a commercial service that sells access, however, they do have some protections (yes, protections!) under the DMCA as a common carrier. They should contact their lawyers and draft appropriate terms and file the right documents to enable this.
Choose your site wisely. A good site should be unnoticed. A bad site can destroy your hard work. The site admin is part of your management team whether listed or not. They often don't have or want internal say, but some will. In that case, you can either add them in as a wizard or find a new site.
Created by Otter
Last modified 2006-10-12 06:49 PM
