As teams grow, managers invariably start to think about dividing the former team into smaller groups working on specific features or areas, in most cases supported by people or small teams that focus on tooling, infrastructure, and other “meta” tasks that enable engineering.
In some cases, external advisors are brought in to balance the lack of internal expertise on a topic as well.
Usually called architects and regardless of their internal or external origin, these people create prototypes, proof of concepts, and other solutions that are then handed over to product and engineering teams.
This flow is fundamentally broken, and letting architects roam freely can damage both productivity and employee satisfaction in the long run, so let’s explore why that is.
Lack of context
When external people are brought in, they often have a hard time understanding why previous decisions were made. This can go down in two ways: They try to understand how you got to your current situation and gain a deeper understanding, or they decide that it’s not worth their time and follow their own playbook.
For teams, this can lead to uncomfortable meetings where previous progress is steamrolled by a person who isn’t aware of the constraints and tradeoffs made earlier.
Of course, it’s hard to join a team with an existing product, especially if you’re supposed to focus on infrastructure improvements for a team blocked by product work, but I believe that to build and improve on an existing system requires a deep level of understanding that extends past the codebase.
Lack of ownership
When given autonomy, architects can focus on their task at hand, coming up with solutions, building up exclusive knowledge, and making architectural decisions along the way. When the project is more significant, these decisions can influence operations and maintenance for the next years.
When a team receives the deliverable from an architect in a handover process, there is at best an effort to share the essential knowledge, but in the end, the team didn’t have a say in any decisions that preceded the delivery.
This means that people have to take on and maintain a piece of work they ultimately might not agree with on multiple levels, which will cause frustration down the road.
Lack of constraints
Architects are brought in so teams can make use of their expertise, or for a specific improvement task. How they get there is often undefined, though. This can lead to architects choosing their tools of choice, a new tech stack the team hasn’t used before, and other choices sometimes oppose the existing setup.
Once again, after the architect has moved on to a new task, a usually team owns and maintains what they built. Not only do teams have to support new business logic, they might also need to understand a completely different programming language, design paradigms, and mental models.
A big part of the architect’s job is making this knowledge available to the team, but sometimes, that doesn’t happen.
If you find yourself putting out fires in a system you don’t understand, with tools you haven’t chosen, you’re in a much worse place than necessary.
Can architect roles work?
After these pitfalls of architect roles, you might wonder whether it’s even possible to make this setup work. I think that, with a couple of clearly defined rules that are communicated with the architect beforehand, it can work.
Involve the team early on
In the best case, an architect should never work on a task completely on their own. You should always have one person from the team that will own the deliverable present in the learning and decision process so that ownership is shared.
This setup helps with context sharing, as the architect can learn the background of the current product while communicating with the team member, and the team feels like they’ve been heard at the same time.
Share knowledge continuously
Throughout the whole process of ideating and working on the task, the team should receive updates and sessions to share knowledge. This could be synchronous in the form of bi-weekly to monthly meetings, but also asynchronous with videos and discussions.
It’s important that the team receives the time to engage with what the architect is working on. If they’re constantly putting out fires left and right and need to focus on the existing product, they’ll most likely not spend the necessary time early on, which makes it harder when the handover happens.
Create clear boundaries and scopes
Make sure your architect only works on what you want them to do, and clearly define the tools they should be using (if they’re not brought in to build the tools). Choose a stack and technologies your team is familiar with, explain why you made the choice, and stop them from expanding the scope beyond what they should be doing.
The goal of an architect should always be to support a team and goes beyond solving the problem: They must work together closely with the team, understand the context, and communicate with empathy so that a handover doesn’t involve trouble or hard feelings.
Being too lax on constraints and letting architects roam freely without the involvement of the team or knowledge-sharing efforts will most likely end with a huge re-engineering effort because nobody understands what was built or how it works. Your team will probably have hard feelings toward the architect, and that reaction is completely understandable.
The good thing is that it doesn’t have to go down this way if you keep these pitfalls in mind from the beginning.
As an aside, if you feel like this post is a personal attack against certain individuals, I do not want this to be a hit piece but more of a post-mortem to understand how teams can best leverage external expertise and support from architects without the downsides mentioned above.
I’m still not entirely sure as to what the best solution to this problem is, but I believe that collaboration, communication, empathy, and understanding all are crucial to make this work.