Understand what's happening in just enough detail

I briefly mentioned delegation in my post yesterday about authority and I wanted to expand on this further. I talked about delegation in the context of having the authority to make decisions - you don't actually have to make all of the decisions yourself. Other examples of where delegation might be needed include :

  • Design : You've come up with a nice logical architecture that defines a collection of components and their interfaces. Taking these to the next level probably requires some lower level design effort, which you might not have time to do yourself across the entire system.
  • Coding : Unless the system is very small, there's no way you can code it on your own. Furthermore, there's probably little chance of you understanding how the entire system works at the code level.
  • Quality assurance : In a similar way to the code, do you really think you can code review the entire system on your own?

Delegation is an important part of a software architect's role and there's a middle ground somewhere between delegating everything and doing everything yourself. Either way, it's worth pointing out that delegation is different to ignoring/not being interested in what other team members are doing. The key points here are to trust your team, delegate where appropriate and make sure you have a handle on what's happening in, to use an agile term, "just enough" detail.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Re: Delegation

Great point Simon. This falls into the category of making sure we're spending our time on the things that really matter.

In Bredemeyer's "Guiding Principles for Enterprise Architects", he describes the "Minimalist Architecture Principle":

"Essentially, the Minimalist Architecture Principle says 'if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.' This means that architects only make decisions that require the overall perspective and authority that the architect has. If a decision has local impact, then the architect has no need to mess with it. If the decision has broad impact, and the impact has highly strategic consequences, then the decision fits the minimalist architecture criterion."

Of course, we'll want to keep in mind that delegation does not allow us to abdicate.


Re: Delegation

In government, this is known as the principle of subsidiarity: a central authority should have a subsidiary function, performing only those tasks which cannot be performed effectively at a more immediate or local level. So it takes a different, but complementary, viewpoint from the Minimalist Architecture Principle by asking what must be done at a higher level to ensure the effectiveness of local action. That's the flip side: what cannot be delegated. For more, see

Add a comment Send a TrackBack