Delegation

Tue, 22 May 2007 08:14:00 GMT

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.

Coding the Architecture - delegation tag

Delegation