Today marks the one-year anniversary of me stepping into a formal architecture role from that of a backend developer, and I’d like to reflect a bit on what I’ve learned during that time.

Please bear in mind, I work out of a centralized architecture office - the infamous ivory tower - so these learning are probably mostly relevant in similar organization setups - and you (well, your boss’s boss, probably) should work hard to change it1.

Anyway, I hope it can be useful for someone looking to get into architecture. It’s both easier and harder than it looks.

Good news first…

You don’t have to be the best developer

I held off stepping into such a role, because I was afraid I wasn’t experienced enough. I’ve previously worked with incompetent architects who thought they could tell me how to better build stuff and my respect for them was - how do I put this delicately - easy to miss. I wouldn’t want to be in their shoes!

Well, it’s not about your technical prowess at all, but how you exercise your role. You probably won’t be the smartest person in the room, nor the best coder, nor the one with the best understanding of the systems involved or the business domain, so how you interact with others should be informed by this knowledge.

Regardless of technical competence, those of my colleagues who do best in the long run, are those who approach the task with humility and inclusion, rather than mandating solutions. Descending from your ivory tower with a fully baked solution design in hand, ready to hand over to mindless drones for implementation is a surefire recipe for failure.

Developers are perfectly capable of coming up with a good solution design for the task at hand. They don’t need you for that and by taking it away from them, you not only miss out on their expert knowledge of the systems involved, you risk destroying their intrinsic motivation (autonomy, mastery, purpose), leading to a loss of feeling of ownership and no one caring. That’s dangerous!

But don’t worry…

Your value is not in the technical design

Your value derives from your much broader remit. You probably won’t get deep expertise with a system, but superficial knowledge of many. Where a developer gets knowledge about systems in a depth-first fashion, you get yours breadth-first.

You use this knowledge to open up new possibilities; “Over there, they solve similar challenges to ours like this”, and to avoid building yourselves into a corner; “there’s an initiative on the way to do X. If we make these adjustments, we’ll save ourselves a lot of trouble down the line”.

You’ll be able to bring together the right people from the beginning, see issues cropping up ahead of time, and cut through red tape. That’s the real benefit you bring to a project.

You’ll also be in a unique position to identity recurring pain points. A single team struggling to implement a good logging methodology could point to the team missing some competences and be fixed with training; many teams struggling with the same may indicate a tooling deficit. With proper organizational support, you can use this knowledge to improve delivery across the organization.

Just remember…

You can’t fix organizational issues with technology

This is really just the age-old mantra, “you can’t fix social issues with technology” and it’s just as true inside an organization. Coming from a developer background, I’m biased towards building, and that does not work! My stubbornness means I’ve wasted countless (!) hours trying to tool my way out organizational dysfunction that should be tackled at a higher level but isn’t. Push upwards. Organize. Bring people together. It’s slow, but much less wasteful, and you’ll much quicker get a sense of what’s possible and what’s not with your current leadership.

All of this points to…

Your political skills are more important than your technical skills

Architecture is leadership, team-building, sense-making, facilitating, organizing, coordinating, synthesizing, negotiating, and a tiny bit of tech. All of these are “people skills” that require empathy, humility, confidence, the ability to build trust and a fair deal of salesmanship.

You are probably not prepared - but your technical skills are probably fine.

  1. For more on how you can structure architectural work, I highly recommend Eduardo da Silva excellent post Architecture Topologies & Architecture as Enabling Team bulding on work by Gregor Hohpe. ↩︎