If you have a thought that you can’t shake for too many days, you have to stir it. Here’s mine: Why am I at odds with Software Architects?
I don’t mean that there shouldn’t be people whose strong suit is designing - architecting? - complex software systems. That’s obviously necessary. I mean moving that to its own, dedicated role.
Two important caveats - the first is that I’m looking at this from a leadership perspective, and secondly, my own background in engineering strongly shapes and influences how I look at that.
What are the very essential tasks and duties of a software engineer?
Writing code is essential - no one argues that. So that means opening an IDE and creating, modifying, deleting files. Also running some sort of program to check if it actually works, committing changes and making sure they actually make it into some bigger product.
But writing code is only one part of the job. It’s also understanding the problem that is supposed to be solved, it’s working out the pros and cons of various solutions. It’s making a plan and then, using various means, one of it being code, to actually solve the problem it all began with.
That’s obviously a simplification, and the real process is much more nuanced - and it’s not just a single person who is involved there, but a team of engineers getting some work done. And that’s what I’d refer to as a pretty perfect setup - a self-contained team that owns the whole story, from understanding a problem to actually rolling out a working solution. In the ideal setup, the team owns the whole pie—from understanding the problem to delivering the solution.
Here’s where the idea of a software architect complicates the whole dynamic. But before I go and be all grumpy and let you read it, let’s define two different archetypes of software architects, and I’m only really at odds with one of them.
Software architects are mission experts when it comes to understanding, planning and designing software systems that are composed of multiple components. The distinction to software engineers is usually that software architects don’t build those systems - they are more on the designing side of things.
There’s two distinct archetypes:
- The influencing architect - works with teams across an organisation and tries to understand their challenges, helping them to make the best decisions, balancing short and long term needs.
- The deciding architect - also interacts with teams across an organisation, but uses the information to make decisions and communicate and explain those decisions to the teams.
The deciding architect carries a strong hierarchical signal - anyone who can do something that a team can’t do is more powerful. Even if that’s only being able to decide about how a system should be built.
To make it specific, if you’re in an organisation where someone tells you to use microservices - and you’ll have to implement something with that, that’s an issue. If your team decides on using microservices - and lives with the consequences - that’s fine. You reap what you sow. But you shouldn’t reap what someone else sowed.
While there are some upsides on having architects that make decisions – depending on your organisations design, those might even be strong ones – I’m looking at two major turn offs.
The first is that it encourages a learned helplessness - any decision above the organisations threshold for involving an architect is usually handled by those - the team and the engineers in it don’t even have to start thinking about it. It’s something someone else decides. This hampers individual growth, it impairs team growth and also leads to worse systems. What does that look like in a day to day? Instead of just deciding on an issue, there’s two decisions to make: Is this something for the architect? And if the answer is yes, the architect will have to first gather context and make a decision on the original issue. This is slow, it’s costly and most of all - does it really lead to better outcomes? Of course it doesn’t, at least if your teams amount to anything more than pairs of moving hands, typing things on a keyboard.
There’s an implicit notion of hierarchy in having an architect that monopolises decision making on system design topics – and that comes with all consequences of any other hierarchy, the worst being that there’s not many incentives to challenging whatever an authority tells you. While debates about a technical decision within a team can be annoying – they often lead to better outcomes. If someone else simply decides for you, with them having the authority to do so, even with eventually overriding the team, why bother?
And that brings me to the second problem: Dilution of ownership. In an ideal world the team owns the execution from start to finish - it’s clear where to go if something doesn’t work. Having only the tiniest part of that ownership outside of the team dilutes this notion of strong ownership. And when something breaks, who do you go to? The team? The architect? This is inviting finger pointing.
The big question is of course, how do you design healthy organisations that still tap into the experience of high-yield individuals that work horizontally to support many teams? The crucial thing here is that you want those folks flying around consulting - help teams improve their decision making. But you don’t want to make their decisions for them. This is also why being an architect shouldn’t be attached to any formal authority - if you think a team is making a big mistake, escalate through normal leadership channels, not simply override what they are doing.
As my rule of thumb - knowledge should flow from top-down, decision bottom up. If you can’t get teams to make decisions, don’t start making decisions for them - teach them how to make their own.
Decisions are part of the work. Don’t outsource them — build the muscle. Teach a man how to fish, if you remember.