Who Makes the Decision?

One of the biggest keys to a well-managed project is proper assignment of responsibility. Having good people on a project is not enough. The project must be correctly organized and managed so that people can succeed. At any moment, each team member should be able to give a clear and unambiguous answer when asked “Who is responsible for X?” or “Who decides what should happen in X scenario?”. If they can’t, the project will be late, over budget, and incongruous.

There are several key factors that influence the success or failure of a project. Most of them are established even before the project begins. One of the most important ones is the decision-making structure. The decision-making structure is setup either implicitly or explicitly before work on the project actually begins.

Some time ago, I led a team of five on a resource constrained project. We worked on a very tight deadline to build and deploy a feature-complete piece of software. The team members varied in skill level. One of the big failures of the project was the amount of time that was wasted in lengthy back-and-forth discussions about design decisions. Some of them were important design decisions, and others were merely stylistic. During the last days of the project, this cost us a fair bit in terms of stretch goals, overall project polish, and added costly rework.

This led to an important project management discovery:

1. All authority and responsibility should be defined up front.

• 1a. No one should have responsibility without authority.
• 1b. No one should have authority without responsibility.

The exact decision-making structure is important, but less important than simply having the process well-defined. There are several basic structures for project decision-making.

Anarchy

Each person is specifically allowed to make whatever decisions they wish.

Pros: No time spent for communication, team members feel empowered, no uncertainty
Cons: Code wars, tougher feature integrations, more work items, Picasso-like final product

Unanimous

All team members must agree with each decision.

Pros: Unified codebase, low error rates, extremely stable cohesive product
Cons: Very costly discussions and deliberations, significantly lower project velocity, project failures are very costly

Democracy

Formal vote. Majority decides.

Pros: Unified codebase, highly-informed team
Cons: Costly synchronization for decisions, insufficient weight to seniority, project failures are harder to troubleshoot

Dictatorship

One person makes all the decisions.

Pros: Unified codebase, efficient decision resolution
Cons: Single point of failure, can create resentment or schisms, misses opportunity for team nurture

Delegated

One person delegates decisions on an issue-to-issue basis

Pros: Utilizes experience, allows emergent expertise
Cons: Potential decision delays

Distributed

Different people are each given complete authority over specific parts of the project.

Pros: Synergistic codebase, efficient decision resolution
Cons: Moderate project risk if a critical part is distributed to the wrong member

Undefined

Part anarchy, part social games, full of uncertainty.

Pros: No time spent for communication
Cons: Higher synchronization costs, disjointed codebase, usually doesn’t result in a finished product

How do you find the right structure for your team?

For any long-term team, you may have to experiment with different decision-making styles and assignments of responsibility. Some people are more comfortable in lead roles. Others are happier without the pressure of responsibility and would rather follow decisions. Stronger-willed individuals thrive with more hierarchical decision-structures. Collaborative teams are happier putting their heads together to discuss and design things in more detail, when there is less time pressure.

For short-term project teams, the organizer should pick the style he thinks will fit the team members best. If you are an organizer, you’ll learn through experience which styles work best. From the short-term projects I’ve run, it seems that Delegated and Distributed decision-making styles work best, especially when some of the team members have worked together on previous projects.

The best decision-makers in any capacity will always take into account the opinions and wisdom of other team members. No sane leader makes unilateral decisions without factoring in the impact of the decision on the team, as well as on the project. Dictatorship may sound like a bad choice, but it might be the ideal choice given the right project scope and people. A good dictator is also a great team player.

Another thing that is useful to consider: the decision-making structure doesn’t need to follow the organization chart. If you work with a corporate team, even a dictatorship might work better if the most senior technical member is the project Architect, instead of the nominal Team Lead. The most important thing is that the team feels confident in the decision-making structure. Project success is something objective and measurable, not something political. Often political structures are at odds with effective delivery strategies.

Summary

All projects are best managed and executed with clearly assigned responsibilities. This always eliminates a key factor of uncertainty, simplifies communication protocols, and increases project cohesion. If you are working on any sort of project, especially one in Agile software development, it is essential that every team member is able to answer the questions “Who is responsible for X?” and “Who decides what should happen in X scenario?”.

Further reading: Yegor256 - What Does a Software Architect Do?