I've Been Doing This for Years, Why Does It Feel Like Starting Over?

It is a strange feeling to have spent over a decade working in software and suddenly feel like a beginner again. This past week, I started a new role as a Director of Engineering focused on system architecture. I've worked with many system architects and I've architected many systems myself, but I've never held the title before. This new role is going to stretch my experience beyond anything I've done before. Only being a week in, I still have lots of context to gather, but I also am developing a sense of how to maximize my impact.

As I start thinking about how to be successful in this role, one thing keeps standing out to me: architecture is just a state of the world, and the world changes all the time.

Of course, having a scalable, modular, decoupled system is important. But it isn't as important as the processes and decisions that lead to that architecture. If I can help build systems and processes that consistently produce better architectural decisions, I can have an impact that lasts much longer than any individual architecture.

The temptation to act

My instinct is to act. I want to move as soon as I have direction. The hard thing about being in this new role is learning to slow down and wait. Coming into a new organization, it is very tempting to see all the systems and processes that I want to improve but before any changes are made, it is critical I understand why they came to be. Making changes without understanding them is dooming yourself to repeat history. There is information to be learned from how things came to be.

I think it is important to question the things I'm seeing and not just accept them. But it would also be foolish to change them without understanding them. For example, when I encounter a recurring meeting that seems unstructured, my instinct is to eliminate it. But before I do, I want to understand how that meeting evolved. Maybe it was very useful in the past. Maybe it just needs some tweaks to become useful again. Or maybe it is misguided. The key is in getting the context before making a decision.

Similarly, there are many technical decisions that have been made that don't yet seem intuitive to me. Why was this technology picked and not another? Why does this component exist? Why was the system designed this way?

Again, it would be all too simple to redesign these systems in the name of modernization, but why? Why did these come to be in the first place? Was it a conscious decision or a natural evolution? And if it wasn't a conscious decision, why not? Are the right systems in place to have a feedback loop to learn and adapt? Was there a planning process that is missing? It can be more impactful to understand the systems that lead to these decisions and change those systems than to simply fix the technical problems themselves.

Influence without authority

Throughout my leadership journey, I've strived to lead my teams with reason and debate rather than by the org chart and rank. When I needed to get one of my teams to perform a particular task, I would explain the reason and help them buy into the decision themselves so that they had agency, instead of me telling them to do it. In my new role, that style of leadership will serve me well, but it will also be put to the test.

As an architect, I will be working across multiple teams, but none of them will report to me. The breadth of influence will need to be wider than any role I've previously held, while simultaneously having less direct authority than I've had in a long time. This will require me to lead with influence.

Setting constraints, but not dictating designs

One of the easiest ways to get teams to buy into a design is to let it be their design. I don't need to design every system, but I know that there are boundaries and limits to what we should tolerate for "good design".

This is probably the biggest shift in how I need to think about architecture. My job isn't to be the person with the best architectural answers. It's to create an environment where the organization can consistently arrive at good answers, even when I'm not in the room.

By agreeing with teams up front what the guidelines and constraints are for good design, I'm creating the conditions for good decisions to be made rather than making every decision myself. This serves 2 purposes: it allows teams to move independently without making my work their bottleneck; and it lets teams grow their architectural capabilities so that they are consciously deciding how they will build their systems.

My role becomes reviewing and ensuring that the design they produce will achieve the non-functional requirements of a production system and will be easy to evolve in the future, while being the simplest solution to meet the business need. I should participate in the ideation process when my experience can add value, but I shouldn't need to be the person driving every design.

Fostering a culture of open debate

Trust is earned through actions, not given by a role or title. The best way to earn trust with teams working on architecture is to foster a culture that enables them to have a voice. In order to influence the architectural decisions that the organization is making, I have to be willing to bring my evidence to an open forum and be willing to listen to other points of view.

Fostering a culture of open debate allows everyone to bring their ideas to the table and debate the merits. For it to be successful, the discussion has to revolve around facts, assumptions, and the technical tradeoffs between different options. It is important that the debate never drift into a debate of intelligence or stature. Architectural debates can become incredibly political because architecture is tied to expertise and status. If the most senior person speaks last, everyone may simply converge on their opinion. If the loudest engineer wins, you have the same problem. The quality of an argument matters more than the seniority of the person making it.

If done correctly, this will allow all participants to grow by seeing different points of view on issues and letting a decision be made on merit, not just because it was the latest industry trend.

Having architectural champions

The last strategy to build influence is to leverage the networks that already exist. Have you seen the shirtless dancer leadership movement?

Derek Sivers demonstrates that you don't create organizational change by being the person who has the best idea. You create it by creating other people who believe in the idea enough to carry it forward.

To establish a culture where architectural thinking is shared across engineering, others need to buy in and champion it. It starts by finding individuals that are passionate about making things better and making a change and then praising and elevating them for doing so. They become leaders of the movement themselves, not just followers. The mission becomes helping them build influence so that architecture doesn't just remain an activity, it becomes the culture.

Improving as I go

I'm only a week into this role, so I don't know yet which of these ideas will hold up. That's probably the point. My first responsibility isn't to arrive with all the answers. It's to ask better questions, gather enough context to understand the system, and help the people around me make better decisions. As the story unfolds, I'll write more about it here.