Delegate Design Authority

As we include more of the team in the design process, we must decide how much design authority to keep and how much to delegate. Our goal is to give away as much design authority as possible without putting essential quality attributes at risk or otherwise endangering the architecture. In Management 3.0: Leading Agile Developers, Developing Agile Leaders [App11], Jurgen Appelo describes seven levels of authority. We can use these levels to help us decide how much design authority to keep and what we can leave to the team.

Level 1: Tell

You make the design decision and tell the team what will happen, usually by producing an artifact.

Level 2: Sell

You make the design decision and show the team why it is the right call.

Level 3: Consult

You ask the team for input before making the design decision. Ultimately the decision is still yours.

Level 4: Agree

You collaborate with your team and reach consensus about the design decision as a group. Everyone has an equal voice.

Level 5: Advise

You influence the team by sharing your opinions and insights but let someone else make the design decision.

Level 6: Inquire

You let the team make the design decision and ask them to show why their decision is the right one.

Level 7: Delegate

You leave the design decision to someone else. In this capacity, you might help gather information as a facilitator but someone else is responsible for the decision.

The level of authority you use will vary from decision to decision and team to team. Delegate the right level of design authority for the situation and you’ll increase the team’s confidence, happiness, and agility. Delegate too little design authority and you may undermine trust and make some people feel micromanaged. Delegate too much design authority and you’ll end up with an anxious, unhappy team and a poor design.

In the best case, when you delegate too much design authority to a team that is not ready to handle it you’ll have to try again at a lower authority level. When the team fails under these circumstances, it undermines trust and creates waste through rework, assuming you catch the decision early enough. Although that situation is not ideal, you can still recover. In the worst case, a bad design decision might go unnoticed until it’s too late to recover easily.

Choosing the appropriate level of design authority is not an exact science. It takes some trial and error to figure out how your team likes to operate. The easiest way to check that you’re choosing the best level of authority is to talk it over with your team and decide together.

When to Keep Design Authority

When the risks of failure are high, it’s better to be conservative with how much authority you delegate. Stick to the first three delegation levels when the team is inexperienced. This approach is proven to work and improves your chances of producing a useful design. Unfortunately, the first three delegation levels don’t come with as many bonus multipliers in quality, happiness, speed, and agility.

Simultaneously designing an architecture and skilling up a team is one of the most challenging times to be an architect. You’re under pressure to deliver and unblock development. It’d be so much easier just to design it yourself! In the short term this may be true, but then your team will not grow and you will never be able to delegate design decisions. If you are the only architect on your team, then your skills, knowledge, and time will constraint the types of systems your team designs.

If you are in doubt, keep design authority until an appropriate opportunity presents itself.

Patrick says:

Architect as a Technical Leader

by Patrick Kua, principal technical consultant at ThoughtWorks

An architect’s role is tough. Amongst their many responsibilities, an architect aims to reduce technical risk, plan for future change, and ensure that systems meet their quality attributes. However, for an architect to be truly successful, they also need to act like a technical leader.

Effective architects cannot always rely on their authority to make decisions. In today’s ever-changing technology landscape, it’s impossible for an architect to know all the details about the latest tools and technologies and how to apply them well. Instead, the effective architect must draw upon the wider experience of their development team and organisation. As a technical leader, the architect builds a shared technical vision for the team and focuses on amplifying the effectiveness and growing the skillsets of team members.

If architects are measured by the quality of decisions, they should also be interested in helping developers make better decisions. After all, each line of code represents a choice and, ultimately, each choice is a decision that has been made. The architect can improve developers’ decision making by articulating operational or environmental constraints and agreeing with the team on architectural principles to gently guide future decisions.

Each of these activities—building a technical vision, describing constraints, and applying architectural principles—requires completely different nontechnical skills. These skills, often classified as “soft skills,” are often the hardest to build. To be successful in this role, architects should draw upon deep communication skills such as explaining technical ideas in non-technical terms, using diagrams and models to build a common understanding and telling stories to motivate, excite, and challenge team members. Another essential leadership skill worth developing is the ability to listen. Not only will good listening skills improve the knowledge of the architect, but they will also grow the commitment of the team and organisation to the final technical vision.

Those architects who solely focus on deep technical expertise and owning all technical decisions are destined to build and live in their own ivory tower. You can avoid this situation by developing technical leadership skills and use them to build stronger bridges with the team and the rest of the organisation.

When to Give Away Design Authority

If your team already has some experience, then look for opportunities to consult, decide together, or only share advice before letting others decide. Delegating design authority is of particular importance for decisions that strongly influence the team’s day-to-day-work or for design decisions in which there is passionate interest.

As the team learns more about architecture and as you gain confidence leading the team, incorporate collaborative workshops into your practice. Collaborative group sessions work well when you’re able to agree, advise, inquire, or fully delegate decision making. Your role as a participant will decrease as you give more authority to the team. Instead, you support your team as a knowledgeable facilitator.

Many activities in Part III describe ways to include multiple stakeholders in the decision-making process. Here are a few examples:

• Tell stories with your team and encourage them to tell stories about the architecture too. Check out Anthropomorphize the Architecture and System Metaphor.

• Encourage active participation with collaborative workshops such as Design Studio, Question-Comment-Concern, Risk Storming, and Scenario Walkthroughs.

• Check that the team is engaged and understand what’s happening with an Architecture Briefing or Sanity Check.

• Delegate artifact creation when good examples are available. A few artifacts that are easy to delegate and review include Architecture Decision Records, Architecture Haiku, and Inception Deck.

Get Your Hands Dirty: Delegation Poker

In Managing for Happiness: Games, Tools, and Practices to Motivate Any Team [App16], Jurgen Appelo introduced Delegation Poker, a game you can play with your team to practice choosing a delegation levels. Print or buy Delegation Poker cards from the Management 3.0 website^[25] and play this game with your team. The game’s rules are available on the website.

Here are some things to think about:

• Before playing, each player should write down a few brief case studies related to areas you want to agree on a delegation policy. Try to have at least one case study from each teammate.

• Use the chapters in Part II to guide topic areas. Does the team feel confident in their skills for some topics?

• Are there decisions the team does not feel comfortable owning? Why?

• What areas will benefit most from giving the team more design authority? How can you help your team prepare for the additional responsibility?