Splitting a Team

As a business expands there comes a time when a development team becomes too large to be functional. The first time this occurs is far more challenging for business as they need to determine the best way to split the team. Should it be split by customer segment, by technology, by feature, or maybe by some other method? Each method of splitting a team has pros and cons, and it’s up to the CTO, Head of IT/Technology or another leadership figure to determine what works best for the team and the organisation.

Before making any decision it is important to consult with the development team to find out what they want and why. It’s also important to keep the development team involved in the decision making process, be transparent with them and to be honest about any changes as the splitting of the team will have a significant impact on the, and if they are not engaged in the process it is far more likely they will become apathetic about their work and role and seek employment elsewhere.

# Splitting by Customer Segment

If the decision is made to split a team by customer segment you will require a truely cross functional team. They will need to be capable of building, modifying and supporting all aspects of the entire system. Inter-team communication is vital to prevent conflicting features and changes, and to ensure that multiple teams are not duplicating functionality.

By splitting your team in this method your sales and support staff will know which technical staff to talk to about any issues or feature requests as they can easily make the decision based on the customer involved. The developers should also be more in tune with the customer requirements as they are focussed on a smaller market segment and over time they can gain a deeper understanding of the customer’s want and needs.

If you split the team in this way you also have the opportunity to embed your sales and support staff in the development team, this means that developers will be able to hear the sales reps taking to customers, when customers have technical questions the sales and support staff will be able to ask a developer directly, customer service levels will increase and the developers will be better able to prioritise tasks that are irritating customers.

This division of teams will also allow developers to work on a variety of different tasks and aspects of the system and should help provide variety of tasks for the developers.

# Splitting by Function

As with splitting the team by customer segment, splitting it by functionality will also require cross functional skill sets. Each team will need the ability to implement complete features and a good understanding of the overall product. The team will maintain responsibility for all aspects of the functionality they deliver.

If a team is split by this method there are a number of technical considerations that need to be adopted. The technical teams should actively work to move toward a loosely coupled micro-service environment to remove dependencies on other teams, they should also adopt this strategy for functions within their own team as their current team may get split again at a later date. The teams should be empowered to choose the technical stack required for each bit of functionality; this will allow them to experiment with newer technologies on smaller functions, and to ensure the more important functions can be maintained easily. The technical team will also need the ability to define and implement their own infrastructure, so some training may be required.

In terms of on-going support, clear divisions should be made so the support and sales staff know which teams are responsible for which functions. Product Owners should exist for each team to ensure the most value is being delivered and they will need to coordinate with each other to ensure the value aligns with the other teams.

This division should allow teams some variety in their work, but will require some context-switching between support work and new features. At some point it is likely that the number of features the team supports means they will be unlikely to produce any significant new functionality.

# Splitting by Technology

Splitting by technology (eg frontend and backend) allows your teams to focus on the specific aspects of the system that they specialise in whilst still maintaining a broad understanding of the overall system. This split will delay the choice of splitting by customer segment, feature or something else, but will not replace the decision. At some point a technology based team will become too large to function as a single team and will need to be split by another method.

If this method of splitting a team is chosen then processes can be implemented to ensure communication standards between the frontend and backend are preplanned and agreed upon. Support and sales staff will need to communicate with a product owner or similar role for all issues so they task coordination between teams can be planned and also so the location of any errors can be determined.

This division of teams will enable developers to maintain an overview of the entire system, focus on the programming language of their choice and to work on a variety of tasks. It will generally increase the lead time for support issues, but (longer term) will result in higher quality code. This will also force the creation of a product owner or similar role to ensure and improvements or new features are coordinated between the technical teams.

# Summary

I’ve tried to avoid any favouritism in this article as to which split I prefer, I believe the all have some positive and negative factors, and if done correctly (with additional groupings across teams) they can all work extremely well.

Many of the start-ups I’ve worked at have opted to split the team by technology, this makes scaling a little easier for the organisation, and delays some of the overheads that can occur in the other methods.

Many Agile organisations have opted for the function or feature based split. This is highly scalable and with the addition of a SIG (special interest group) layer the technology choices can be shared across the whole organisation.

I’m currently writing a much larger piece about splitting an organisation by customer segment. I haven’t seen this implemented in my career so far, but I believe there is some potential in it to provide extremely good customer service.