February 22, 2008
What’s an architect, anyway?
Dietrich Kappe recently posted why he doesn’t hire architects. He argues that architects are a product of large companies.
I tend to agree. Even in organizations with the architect title/role, they should spend at least 50% of their time programming. And engineering managers, 20%.
There are lots of good reasons. Can you really afford to pay somebody a higher salary for producing less? Can somebody who’s not in the trenches really make wise decisions about how to navigate those same trenches? Are people who don’t have to live with the consequences of their decisions really going to make better decisions? Will your organization survive a technical leader whose incentives are often opposite those of the rest of the technical team?
Between the fire-fighting and bug queue management and meetings and long-term plannings and code reviews and test plan reviews and political navigation and coding for multiple projects, you can easily spend 50% of your time just context switching.
You really need somebody who can step back from the fray, and keep steering the team in the right direction. Your team presumably has values (like not working weekends, pushing back against unreasonable pressure to meet unrealistic schedules, gradually reducing the cyclomatic complexity of your code, and so on). If you’re in the thick of it, it’s hard to not compromise, or even forget, those values.
I consider this an organizational optimization problem. How do you distribute the work effectively, so that every person is just below capacity, given that the cost of context switches is relatively high and varies depending on the type of tasks being switched off?