#34 Break The Silos: Own Software Architecture As a Team

Instead of having the ivory tower of architects dictating decisions, let the entire development team own the architecture of their solutions. This creates an environment where everyone can grow.

Back in 2011 when I started working in tech, many companies had this stupid setup: Architects would sit isolated from developers, like kings in their castles. They would hand down their decisions from above, and developers had to follow them blindly. Want to change something? You had to beg for their blessing first. We called these their "ivory towers" - and yeah, it was as inefficient and frustrating as it sounds.

First issue: When architects sit far from dev teams, they are clueless about real problems. They don't code with the team, so they have no idea what headaches their designs cause in day-to-day work. You need to get your hands dirty to know if something works.

Second: When architects just draw diagrams all day, they get rusty. They lose touch with tools, don't keep up with new programming languages, and basically start to live in their own bubble. Out of touch with tech, stuck in their old ways, and more focused on theory than what actually works.

Third: This setup kills developer growth. When all architecture decisions come from above, we stop caring about system design. We turn into code monkeys, mindlessly producing features without thinking about the bigger picture, and the consequences it has for our business.

Oh man, I had no clue back then how much I would dislike this kind of setup in the future and how hard I would fight it at every company I worked at. But damn, it was worth every battle.

What could it look like? My take as an experienced architect:

The whole development team owns the architecture of their code - period. Whether they are working on a small part (like payments or scheduling) or the whole app if it is smaller.

Don't care if an idea comes from a junior or senior dev. Everyone gets an equal say. But here is the key: the whole team needs to discuss and agree on decisions. No room for egos or "I am the boss" attitudes here. In one of my previous articles, I described how to organize the work within such a team and make meaningful and democratic decisions using a developer carousel.

Some people will argue: "That only works for small companies." BS. While yes, changing from ivory towers takes time (humans hate changing habits, so it is a pain, I agree), it is totally doable if you take it step by step. I have worked at tiny companies and large-scale organizations - this shift can work anywhere but sometimes it will require tons of politics.

When multiple teams work on a large system, one great way to share knowledge and keep architecture in line with business needs is setting up an "architecture guild." As Jakub Nabrdalik puts it:

How the guild works

The guild meets regularly once per 2 weeks, but also has meetings ad-hoc to address urgent issues when they arise. When the guild meets, it discusses the problems and work required, invites all the relevant people (outside of the guild), schedule the necessary research, creates an RFC document to gather all possible input from people with the knowledge on the issue matter, chooses the person responsible for getting the decision done.

Who is responsible

Every 2 weeks one person from the guild is chosen as an acting Speaker of the guild. That person holds personal responsibility, for making sure, that the guild makes the decision in efficient manner. For every issue discussed by the guild, a person responsible will be chosen. If there are no volunteers, the Speaker of the guild is responsible. The Speaker is also on an on-duty of the architecture guild, where she is responsible for answering all the questions from outside of the guild.

Here is my take on organizing a guild: Just read Jakub's repo. The first time I set up a guild, I basically copied his approach word-for-word. Then adjusted it with the next iterations to our needs. Now whenever someone asks me how to do it, I just send them his guide. Important note from me: Anyone can join the guild, no matter of experience. The only rule? You need to actively participate. That's it.

When you let the whole team make architectural decisions, good things happen. No more knowledge trapped with just a few people, everyone owns the architecture, developers grow way faster, and honestly - it is just way more fun to work in this kind of environment.

What do you think of a setup where the entire software development team is involved in architectural decisions? How does it look in your team?