As software engineers, we often discuss what makes a good engineer and what makes a good team. It’s a topic I’ve been reserved about for various reasons, but as time passes, I realise we need to be more open about these things. Sharing our insights would provide more visibility for businesses and stakeholders who require our services, ultimately leading to better outcomes for everyone involved.
Working across various businesses, I’ve seen different team types. One of the most common is the hero-based team, where one or more engineers are seen as the “know-all” experts. While such leadership is natural, what makes the most significant impact is that “heroes” are mostly unable to share their knowledge for various reasons, whether political or, more often, due to being overloaded with work. This leads to an imbalanced team where the hero’s or heroes’ expertise can’t be leveraged effectively, and the team’s success depends on the availability of these individuals.
Another unbalanced team type is the chaotic development team. Engineers of mixed skill levels frequently take work as individual tasks and don’t communicate well on high-level design or project goals. This often leads to a lack of alignment in code structure, silos formed, and inefficient use of time and resources.
On the other hand, a well-balanced team is built of seasoned engineers and is united by a joint technical background. They understand and are keen to use best practices in development process operations, such as contiguous CI/CD pipelines, infrastructure as code, and ample unit test coverage. They also practice design practices such as domain-driven design and clean architecture in a uniform and easy-to-understand way. What this boils down to, and I see it as a root cause of success – is such teams spend much less time in meetings and calls because they can leverage their shared background and refer to it, much like lawyers refer to precedents in the law practice, to make informed decisions quickly and efficiently.
One incredible issue I’ve observed is that despite these differences, all types of teams can deliver approximately the same amount of functionality in the initial two – three months. However, once the codebase reaches a certain level of maturity, the differences become apparent. Unbalanced teams will inevitably struggle to maintain the codebase or scale the product effectively, while a well-balanced team can easily handle these challenges.
Stakeholders are often unaware of the long-term effects of an unbalanced team or poor technical decisions. Once the investment in the codebase and experts reaches a certain point, changing course can be challenging and costly. I’ve seen a few projects where stakeholders decided to pivot by changing the tech stack because it looked like the initial stack was the culprit. However, in most cases, the underlying issue was an unbalanced team or poor technical practices, which resulted in technical debt and scalability issues.
