Have you heard of the concept of “bottleneck”? Imagine a typical situation at work with a team of several developers and an architect and/or tech leader.
In a project, as is typical, there are simple tasks and those that are extremely difficult and critical for the entire project. The architect takes on this mega-difficult task and works on it. After all, he is the architect and must do the most difficult things, and if he has an inflated ego, even more so. Who can do it better than him?
With difficult tasks, it is usually the case that they are very difficult (even very very), and it takes a lot of time to complete them. The problem that often arises in the work of an architect is that he cannot devote one hundred percent of his time to these difficult tasks because he also has other responsibilities (often several projects).
This is where the trap of the “bottleneck” appears. Time is passing. Others are waiting for the architect to finish what he started because what he is doing is blocking others. Frustration is growing for everyone and it is getting nervous. This is a situation with a way out. Eventually, it will be done, but why so much stress? Can’t it be done differently?
Trust in the development team
An architect is not part of the team to show off but to help (i.e., not interfere or block work). The evolution from developer to architect is difficult and has several aspects. One of them is:
Being a great programmer and solving the toughest problems doesn’t count anymore. Since you’re an architect, you’re judged on the value (and quality) your team delivers, not on what you can do alone.
In summary, instead of sitting on something for days and nights, the architect becomes a consultant and mentor for their team and helps them develop to deliver a project that meets business requirements and quality attributes.
I won’t go into whether this working model makes sense here because it’s a topic for a separate article, but it’s a common working model found in technology companies.
When the architect trusts the team and creates an environment for them to work in, and the team sees that it really helps, the bottleneck problem disappears, and work becomes more effective and enjoyable.
Does an architect even have a chance to write code?
Architects don’t write code because they deal with other things. Below I will show you how an architect can still have a chance to code without blocking the team.
An architect who doesn’t program loses touch with reality. You cannot allow this to happen.
Proof of concepts
So-called POCs, which means writing code to validate architectural decisions requiring specific code, are ideal for architects to program something. A good approach when creating POCs is ensuring that the code is high quality (production-ready), documented, and covered by tests. Such a POC then brings concrete value to the project.
Fighting technical debt
If there is any technical debt in the project, it is a great area for the architect to take on a specific problem, come up with a solution, and immediately fix it.
Code review
As an architect, I may not write code during a code review, but reviewing someone else’s code is engaging and allows me to be closer to the code and the team.
Pair programming
Programming with someone in a pair allows the architect to program while teaching the other person and showing them their way of working (while also learning something from the other person). It also has the additional benefit of greatly integrating people through teamwork.
Development automation
Creating tools such as CLI that can speed up the work of programmers and make their lives easier is another thing an architect can do.
Summary
Whether the architect is a bottleneck in the team depends mainly on him but also on other factors. One such factor is the availability of tools and technologies that enable faster and more efficient design.
Another important factor is understanding project and business requirements by the entire team, not just the architect. Cooperation between developers and architects can be crucial for project success, as it allows for exchanging knowledge and experience and mutual understanding and trust.
Therefore, it is worth investing in building good relationships among team members and creating conditions for effective work.
Effective Software Architect
Do these things to be an effective software architect:
- Act as a consultant and mentor to the team, helping them develop and deliver projects that meet business and quality requirements.
- Trust the team and create a work environment that allows them to see the benefits of your help.
- Take responsibility for paying off technical debt.
- Conduct regular code reviews.
- Organize pair programming to demonstrate your work style and to integrate the team’s work.
- Create tools to facilitate the work of programmers.
- Verify architectural decisions by writing code.
- Maintain documentation and knowledge flow.
