All Articles

Architect, you need to be in the trenches

Architect, you need to be in the trenches

Architect, you need to be in the trenches.

Software architect, you need to be in the trenches if you want to make good technical decisions.

If you can’t be in the trenches, you need to allow the smart people under you to make important decisions. In fact, you should be actively pulling these decisions and answers up from people under and around you in order to grow the other (senior) engineers on the team. This gives them an opportunity to think about the bigger picture. Beyond that, you have to let smart people make important decisions or they will leave.

My last boss was an architect. He let me make important decisions about the stack. He vetted them and made sure I had thought through everything. He tried to poke holes and find problems. And then he said yes. So I’d go for it. When he left, I was already making the hard decisions, so I was ready and well suited (thanks to him allowing me to push decisions up) to fill his role. I loved my boss and my job because of that. He let me make a difference. He let me have impact by getting out of the way. And what engineer does not want to have impact?

Why do you need to get your hands dirty in order to make good technical decisions?

You cannot make reasonable decisions with new technology and plan for the future, without experimenting. There are just too many unknowns. So you have to try things out. You have to test your many assumptions and there is a tremendous amount of learning that has to take place. Will this work for us? What are the painpoints? How difficult will it be to implement? Is it worth it?

There’s just so much growth and learning, and this sparks other ideas for how the pieces fit together. You cannot skip this step and make wise and informed technology decisions.

That is why somebody who is ideally suited to make stack decisions is low enough to still code every day, and use the stack and is familiar with the problem space and the use cases. But is not so low that they don’t have enough of an architectural view, or is so new that they only care and think about their piece of the stack.

On the other hand, you can’t be so high that you don’t get your hands dirty anymore. An executive who doesn’t get his hands dirty needs to trust the advice of those lower than him, and those who are in the trenches, because you won’t understand the problem and solutions in enough detail. You may be able to rectify that (to some extent) by jumping in and trying to code with the same tools they’re using.

So ideally, stack decisions are pushed UP, by those who are in the middle. Not executives, not entry level, but experienced devs who still code lots in the trenches. They are the leadership in the trenches (the officers if you will). So these will be seniors most likely, and MAYBE architects (if they still code a lot).

You will still make decisions that later turn out to be mistakes. You have to become more comfortable with making these kinds of mistakes, or there will not be progress. All you can do is move forward and make decisions based on the data you have now. Avoid hindsight bias.