Part 2 – Introduction
Last time, we looked at why the old pattern of business and IT as separate entities is no longer appropriate for organisations today. We saw how separating IT and business leads to inefficiencies and delays in delivering value for business and customers/clients. IT no longer supports the business. IT is the business.
The alternative to separate business, and It structures is to combine the two – take all the technology functions that the business relies on to operate and give control of them directly to the business. What remains – those systems that support the business (payroll/accounting/etc) stay with a much reduced IT department, which reverts to a support function as it was originally intended.
In this article, we are going to look in more detail at how these new business technology functions should be organised. Traditionally, IT departments tend to be organised either functionally – developers in one group, testers in another, BAs in their own group and so on; or organised by system – everyone who works on the accounting system in one group, those working on the website in another.
The Traditional Model
This is mostly historical. Done for the convenience of Managers, who find it easier to manage people with the same basic skill sets (which often match their own skills). Unfortunately, this sort of organisation bears little or no resemblance to the way the organisation needs to deliver customer/client value. To deliver value, you don’t need just developers, or just the website. You need people from many of these functional groups to work together to achieve a result. To get anything done, many groups need to be engaged and coordinated which is tricky because they all have competing schedules and ways of working, so we need project managers and project administrators and a host of support staff on both the business and IT sides to coordinate. I remember being in a meeting at one large organisation to kick off a small project and out of the 9 people in the room, 5 were project managers. We had a Business PM, an IT PM, a PM from the web team, a PM from the services team and a vendor PM. All to manage 4 developers.
Even worse, those functional silos will develop individual processes and procedures that need to be followed to engage with them. In one memorable case, these processes caused a 2 week project to download some usage data files from a third party and analyse them, to extend over 7 months. To start work we needed to engage the team that managed the file transfers – fill in a form, wait for their 2 week response SLA, give them the project brief, wait for a developer to be assigned. Then, once that bit was done we needed to engage the next team in the chain – fill in the form, wait 2 weeks… And so it went for months.
Moving Away From Silos
Clearly, these functional silos are not something we want to repeat for our business technology teams. What we want are teams (and teams of teams) that actually align to the way the organisation delivers value – if the organisation needs the website, business intelligence, service bus and back end systems to deliver value to clients, then get people who know those systems and organise them, so they can deliver together.
Traditionally, this is done through cross-functional teams – small teams with all the skills needed to deliver value. This works really well for less complex organisations, but rapidly fails as ecosystems become more complex. As the complexity of the ecosystem grows, we need people with more and more skills (which are hard to find) or, more usually, more and more people in the team to deliver value end to end.
Scaling to Teams of Teams
For those more complex ecosystems, we need more sophisticated ways of organising our teams. Typically, we start to need cross-functional teams of teams rather than individual cross-functional teams – rather than have all the skills in one team, we have all the skills we need in a group of teams that work together to deliver value.
The Team Topologies1 model is a good way to look at how a cross-functional team of teams operates. The Team Topologies model identifies 4 main types of a team – Stream aligned, Enabling, Complex subsystem and Platform that work together to deliver value.
Stream Aligned Teams
Stream aligned teams are the ones that pick up and deliver customer value. They are aligned to the value stream of the organisation. In a simple organisation, these would be all you need – cross-functional teams with all the skills needed. But as organisations grow in complexity, these stream aligned teams need support from other types of teams.
Complex Subsystem Teams
Complex subsystem teams support the stream aligned teams by owning individual complex subsystems that require deep specialist skills to work on. By establishing complex subsystem teams, you remove the need for every stream aligned team to possess rare and possibly expensive skills. It also reduces the stream aligned team’s cognitive load and allows them to focus on delivering overall value and not worrying about the minutiae of one system.
Platform Teams
Platform teams support platforms (does what it says on the tin) that are used by multiple stream aligned teams. Channels are a classic example of a platform – every team needs to use the website or app to communicate with customers, but it makes little sense to have several web or app developers in every team. So we combine them into one platform team that provides support for the stream aligned teams.
Enabling Teams
Enabling teams (again, does what it says on the tin) enables other teams by providing specific skills or services. Test automation is one example. An enabling team can build the automation frameworks that get used by many other teams. Security or DevOps are others.
Cross-Functional Team of Teams
Using a combination of these team types, you can design a cross-functional team of teams that can deliver value effectively. Be careful though that you don’t make too many complex subsystems, platforms or enabling teams, or else you just re-created the functional silos you had before. That’s easy to do, especially when you have people who are invested in the old system making decisions on what’s a complex subsystem/platform. It is very easy, by applying the same thinking as the old system, to faithfully recreate all the problems of the old system in the new one.
Having an experienced partner when designing these cross-functional teams of teams is extremely helpful. It can help you cut through the old thinking and vested interests to achieve the results you need. The next question is usually – “how do I fund all this?” and if you have a suspicion that the way you funded work in the old system might not be the best way to fund work in the new, you would be correct. We’ll look at that next time.
Read Part 3: Value Stream Based Funding Model
Reference:
