Structuring Your Software Engineering Team
How to implement a scalable structure that grows with your startup
From the “Software Engineering Cookbook” series. Today, we will look at how to structure a software engineering team so that it can be scaled effectively as it grows.
Startups are fond of flat structures. I experienced it first hand, and I get it. A flat structure does without the overhead of management and fosters creativity as it invites everyone to participate equally in the creation of the product. As the team grows, however, the risk of people stepping on each other’s feet and pulling in different directions becomes more real, and that is when the structure becomes useful to put some order to the chaos.
The structure is not just about the chain of command and it is definitely not about doing work for the sake of doing work. It is a way to “divide and conquer”, arranging the team into functional units with specific processes, all working in harmony to release software which is reliable, secure and maintainable.
Which is More Promising: Data Science or Software Engineering? | Data Driven Investor
About a month back, while I was sitting at a café and working on developing a website for a client, I found this woman…
Without further ado, let’s look at what it takes to set up a scalable structure for a growing engineering team.
Defining the functional units
The first step in defining a structure is to classify the work done by the team on a day-to-day basis. All the different activities that the team undertakes should be covered, including any support and collaboration work carried out for/with other teams across the company.
An example classification for a typical software product startup could be as follows:
- Product Development: Implementation of the product
- Quality Assurance: Testing the product prior to release
- Release Management: Deploying the software onto Staging and Production systems
- DevOps: Managing the infrastructure of the software in the cloud, and the different release environments
These four categories cover the basics of the team’s operations. Looking at the additional support work the team undertakes, we can also include:
- Security: Ensuring the system and its data are secure
- Third-line Support: Working with customer services to resolve technical issues raised by the customer
- Sales Engineering: Helping Sales with the technical aspects of selling the solution to specific customers
Next, we want to size the effort that goes into each category on a weekly basis. The purpose here is to determine whether there is enough work in each category to grant the creation of a functional unit around it. Categories with little or infrequent work can be considered secondary and can be grouped together.
Given the example above, we can therefore envisage the following units setup:
- Product Development
- Quality and Release: Grouped together due to the number of man hours each requires
- Support: Including Sales Engineering, Third Line Support, and Security
The grouping of Quality Assurance and Release Management is slightly controversial. One could argue that they are big enough to be units in their own right. This is exactly the point of the exercise above. We need to determine what is “big enough” for our team, and group activities together sensibly while keeping in mind that it is OK to revise the functional units over time as the team grows.
Once we have defined the units, we need to assign a lead to each one and build a team under it. Having different leads in charge of different units distributes responsibility throughout the engineering team and ensures that the right amount of focus is put into the various details of the team’s work.
A word on line management
The use of functional units is not necessarily bound to the line management structure of the team. In fact, for all my prior implementations I always kept the underlying teams fluid, encouraging engineers rotation across the units at the conclusion of each sprint. However, also remember that some units are not suitable for rotation due to specialization requirements, although this conversely makes them a great training ground for somebody wanting to expand their skill set.
You can also experiment with rotating the leads, as this allows more people to get familiar with the overall functioning of the team and reduce the “bus factor”. However, this might be just as impractical as rotating the engineers since similar specialization requirements apply.
Setting up the process
A unit does not mean much unless there is a process to regulate its functioning.
A good place to start in defining this process is to take a look at the engineering team’s existing procedures and work with each lead to refine the ones relevant to their unit. As time goes by, the leads will most likely find flaws or exceptions in this initial setup, and this is a good chance for them to define and deploy their own refinements. It is better to start with something simple and work out the details as you go along than trying to define a complex set of rules that forces people to jump through unnecessary hoops to get things done.
As part of the process definition, there are also a couple of additional aspects to take into account:
- Interdependence : The units must operate smoothly with each other. Process integration is an important aspect for the efficient functioning of the team.
- Efficiency: The units should work towards the common goals defined in the team’s KPIs and OKRs. Relevant metrics should be devised to measure the performance of the unit and course-correct where necessary. The process should make it easy to define and collect these metrics.
Units which integrate with other parts of the business, such as Sales Engineering and Third Line Support in the previous examples, might also benefit from the definition of additional procedures to regulate their work and how it might impact the rest of the engineering team. This is especially the case when engineering resources are rotated across different units.
These outward-facing procedures can take different forms depending on the team we are integrating with, from a basic booking system for Sales Engineering to a more thorough ticketing system bound to a Service Level Agreement for Third Line Support.
As the team grows, the unit leads can become managers and further structures can be set up within the units themselves. I am a firm believer in the “maximum 7 direct reports” rule for line management, and the same concept can be applied here: when any unit has more than 7 people in it, it is time to break things down further.
Some units might grow faster than others, as is the case for Product Development in our earlier examples. This means that the restructuring will happen faster in those units, and that is fine. Growth does not need to be symmetric. As engineers get promoted to team lead positions within these units, they are less likely to rotate across the whole team, but that does not mean that rotation should be stopped altogether. In fact, rotation is a good way for new joiners to gain exposure to the different aspects of the team, regardless of its size.
Also, it is important to maintain cohesion as the team grows since each unit is likely to develop its own subculture, especially as rotation diminishes. This can be achieved through weekly sharing sessions where different team members can present their challenges and their solutions to the team at large. These are also helpful for the unit managers to see problems in their process, and help each other finding suitable solutions.
In conclusion, setting up a scalable team structure is not as daunting a task as it seems, as long as we:
Have a good understanding of how the team works
- So that: We can set up sensible functional units
Analyze the team’s operational procedures
- So that: We can refine them on a unit-by-unit context, or even better help the unit leads to do so
Manage growth, refining the structure we have put in place as more people join the team
- So that: The team remains cohesive and focused on the same overarching goals
It is also important not to get too attached to the initial team structure that we have set up. Observation through metrics and anecdotal evidence can help us refine this structure and its processes so that team efficiency can increase over time, even as the team grows.
Additionally, choosing the right leads to implement this plan is crucial to its success. We need to identify the right candidates within the team, those with passion and expertise in the different areas of competency required by the various units, and help them grow into the role of leadership, and eventually manager, of the unit they most resonate with.
Thanks for sticking around till the end of the article. I hope this quick introduction to a team structure based on functional units has been helpful and provided some hints on how to go about scaling your team effectively.
Have you worked on team scaling before? What challenges did you face when setting up the structure? Let me know by responding to this story, I will be more than happy to start (or continue) a conversation on this topic.
Until then, keep on creating great software!