In a small engineering organization, it’s not uncommon for software engineers to wear multiple hats. From specifications to design, building, evaluation, deployment, validation, and monitoring, engineers are often required to operate across a range of activities to ensure success. While larger companies may have specialized roles for each of these areas, smaller teams must rely on their engineers to be adaptable and familiar with multiple domains.

However, being a jack of all trades doesn’t mean that a software engineer in a small firm should try to do everything at once. Instead, it’s essential to recognize the limits of one’s knowledge and expertise while striving to learn and grow in the areas that matter most. This means being able to operate effectively in any area with some degree of comfort and familiarity.

It’s crucial to keep in mind that no one can know everything, and that’s okay. Instead of striving for mastery in all areas, small engineering organizations should see the roles as part of a menu of responsibilities for any engineer on the team. There should be clear activity boundaries for given seasons, with expertise being developed in team members or leveraged by partners.

Small teams are common, yet there is often a lack of talk relevant to building and driving them. Embracing the multifaceted nature of the software engineer’s role can provide unique benefits to small organizations, such as the ability to operate across different domains and quickly adapt to changing needs.

You may not be able to have individual masters of software engineering, but in today’s world, that doesn’t mean you can’t produce software with high quality craftsmanship. There can be an emergent manifestation of excellent software from small teams.
The question is how.

To achieve excellent software craftsmanship, small teams need to focus on clear activity boundaries for each team member and the development process. Some parts of the process may demand the entire team’s involvement, whereas others may require solo missions. Take design for example. It may be that during system and service design, several or all team members put their hands in the mix. This can increase overall understanding of goals and reduce problems to team alignment and cohesion. Whereas, in quality assurance each member of the team may be tasked with particular aspects of the testing.

Additionally, small teams need to leverage external partners and tools to augment their skill sets and improve their development process. There are many available resources, such as software development platforms, open-source libraries, and consultancies that can provide specialized knowledge and assistance.

Small teams also need to prioritize continuous learning and growth. Encourage team members to attend conferences, workshops, and training sessions, as well as engage in self-directed learning. This way, the team can continue to build its knowledge base and stay up-to-date with the latest industry trends and best practices.

Finally, small teams should celebrate their successes and recognize the value they bring to the table. Despite limited resources, small teams can still deliver high-quality software that meets customer needs and drives business success.

To end this article, I decided to Google this phrase “the majority of modern software is created by small teams”. I got zero results. Undeterred, I removed the quotes and I stumbled upon this article from twenty-five years ago:
“Less is more”. I won’t restate all of Steve McConnell’s points, but in my own experience with small teams I’ve certainly found the values he expressed to be true. Communication flow is more efficient, strong focus on execution means reduced lag and time loss, and surprisingly, large projects can have a larger error rate.
Small teams can produce high quality software. Engineers on those teams should not let an abundance of titles at large firms distract from their core shared goal: Build great software.