3.3 But they built it incorrectly

As an architect, you may support a few projects yourself, but if you work in a more complex environment, you must know when and how to delegate or transfer projects to other architects or teams. When you delegate a project, you may have done the initial planning and secured the support and resources for the project, but you will not be the one completing it. This process is what we refer to as ‘offshooting’ a project.

As a rule of thumb, you should involve yourself closely in mission-critical projects with high complexity or significant risks. If the other architects or teams are not mature enough, you may have to spare time to spar and guide them. Otherwise, offloading projects to them may fail. Conversely, with mature architects and teams, you can set back and let them take the lead.

To offspring, a project ensures everyone knows the narrative intimately and is aware of the architecture principles, technology selections, development methodologies, etc. Once you know everything under control, you can and should trust others. You should, in general, set up some governance to keep track, especially the projects you offshoot (regular check-ins, milestones, and reviews), and then make sure to stop micromanaging them.

Suppose you hover around a project you were supposed to offshoot and keep micromanaging it. In that case, you will stifle creativity and continuously signal a lack of trust in the other architect’s and team’s abilities. Trust is a cornerstone of effective project management. Micromanaging will demotivate them and prevent them from feeling empowered about themselves being in charge of solving the relevant problems. Remember, especially software developers thrive on solving problems.

There’s another reason to empower others. If you, as an architect or an architecture board, require everything run by you, you will become a bottleneck. It doesn’t seem like an issue if you have just one project to support, but you might have a dozen in the larger environment. You will not be able to respond to all the requests fast enough. The others will be waiting for you, and the development will revolve around your calendar.

Micromanaging will burn out good people. They will resent you and avoid collaborating with you. Burnt out, people will not learn from mistakes, but they will learn from them. If you micromanage a project assigned to others, you rob them of valuable growth experiences. If you are unsure, ask others if you are micromanaging, and listen to them. Total transparency is necessary if you get any signals about this.

Sometimes, when a project proceeds, the team developing a new system will learn something you haven’t thought of. They may pivot, switch a significant technology, or drastically change functional requirements. It’s time to detach your ego. Development is a road, and your specifications were only the initial assumptions done based on the information you had available. Focus on checking the outcomes still look good and that the development team upholds the architectural principles you have agreed upon.

You may feel conflicted about a pivoting project after working with it yourself. But it’s again an opportunity for you to learn. Pivoting is not a failure, but a chance to adapt and improve. Why did they choose a different path? What did you miss? How can I plan better next time? Pivoting is excellent feedback for you as an architect. Trust the process of architecture as an analytical discipline. To gain even more trust from your peers, share your observations with others. “This is what I missed earlier. I will not miss the same thing again.”

But what if you suspect the other architect or team is simply incorrect? It’s time to listen even more carefully to what they say and raise your concerns for a constructive debate. You are not there to overrule anyone. You should persuade someone to look at the whole picture instead of a partial one. If you can’t argue your position sufficiently, think of it this way: Your point probably wasn’t that good, and you should let it go.

When working with other architects, you should allow them to have their responsibilities and decision-making authority. You should provide them with principles of reasoning and guardrails and constantly engage in constructive debates with them. Act as a sounding board, not the wizard in the ivory tower. You should also encourage managed experimentation. When you don’t just know, why not create a ‘Proof of Concept’ (PoC)? And when you learn, make sure everyone around you understands.

As an architect in a leadership role, there’s no room for your hubris and ego. Architecture is a continuous process of learning. You can’t be and should not be the only one doing architecture work. Even if you are the only one with the title architect, others will do most of the work and the learning process. You are there to steer, check, spar, and raise points when necessary. Collaboration is the key. And when others disagree with you, you have to acknowledge you might be wrong.

A side note about technology itself: technology is humble. Usually, the best solutions are the simplest and most pragmatic ones, not the grandiose or overly complex. If you allow any room for hubris, your architecture will fail miserably. Humility is, again, often the key to success, even with technology. As an architect, it’s crucial to remain humble and open to learning, as this is often the key to successful architecture.