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
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.
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.