I’ve talked a lot about self-managed teams in the past few weeks, and why you might want to use one.  The tricky part is self-managed teams just don’t run themselves.

For those of you who just re-read that previous sentence a few times, let me clarify.

I’ve defined a self-managed team as one that has no clear project leader, where all team members equally contribute to the outcome of the team’s goal.  What I haven’t defined as a self-managed team is a body of people who rely on group consensus to get work done.  Far from it.  In a well-oiled self-managed team, each individual has a clearly defined role as an expert, who brings something unique to the table.  In software development, that might be the difference between the PHP coder and the front-end designer – the former in charge of the code that runs the website while the latter takes care of making it appeal to the end user.  Within an area of expertise, one person is clearly in charge of one set of responsibilities, and vice versa, so that the front-end designer doesn’t tell the PHP coder how to program a new form and the coder doesn’t tell the designer what color to use on the website.

It looks easy, but notice the prerequisite: Clearly defined roles for team members.  In a self-managed team, everyone knows exactly what they are in charge of, and they are allowed to take risks within their areas of expertise.

So where’s the “team” portion of this, you might ask.

Well, just because a teammate has the final say in his area of expertise, doesn’t mean they aren’t evaluated.  The team must decide how to manage evaluation processes.  Whether it be every few months or at certain intervals in a project cycle, the team is responsible for looking at each individual member’s work and giving them both praise and criticism for past performance.  These feedback loops are not only necessary for individual improvement, but for the smooth-running of the entire team, so that each individual is aware of how their work output affects others and they can change behavior accordingly.

Sometimes, though, it’s not enough to wait for an evaluation process to resolve conflict between team members.  For example, the work of the marketer may be in direct conflict with the designer.  In this case, there needs to be some sort of conflict resolution process.  Here, it could be group consensus, a weighted voting system, or the team can even select one team member to make a final call.  However, this person is not a “manager” per se because it’s not their job to make sure everyone gets their work done.  That’s the job of the individual.  They do step in, though, to help make final decisions where there is conflict.

So again, the three basic things a self-managed team needs before it can run smoothly:

• Clearly defined individual roles (with areas of expertise and encouraged risk-taking)
• An evaluation process for individuals as it relates to their work in the team
• A conflict resolution scheme for one-off problems between team members that need to be solved on the fly

I could give you a concrete list of how to go about achieving these points (and I may yet in a later article), but the truth is, it’s often better for the team to decide these loose parameters themselves.  They are the ones, after all, who have to work with each other day in and day out.

And what’s the point of a self-managed team if they can’t decide how to work together?

-Deborah Fike

Share and Enjoy