Stop buying specialists and start delivering outcomes

Building a multidisciplinary team allows the members to wear multiple hats, and swap hats based on need, they can focus on what matters, delivering user value.  

Hiring or contracting specialists for specific team roles such as QA, Testers or DevOps Engineers and Developers who specialise on specific technologies, can lead to problems as your team focus becomes delivering outputs. They might deliver a lot more, and add value to your team if you don’t stick them in a box.

To explore this topic we’ll look at the following example teams, Team A and Team B. 

Team A has:

• Backend Developer
• Frontend Developer
• Tester
• User Researcher 
• Product Manager
• Delivery Manager

Team B has:

• Three Developers
• User Researcher
• Product Manager
• Delivery Manager

Team A consists of 3 specialists: Backend developer, Frontend developer and a tester. Whereas, in Team B we have 3 developers who are able to work on all aspects of the system. In our hypothetical scenario we have a backlog of issues and we’ve done a discovery of work and we know what we think we should be building to enable the citizens to achieve their goal. So, we start to get to work. 

In both team A and B everything is looking good. The teams are communicating and collaborating well, there’s a good split of work between the team members.

We’re 2 sprints in and we’ve developed some functionality and are able to test the real application with users. We get some initial user feedback and it transpires that one of our assumptions is wrong and we need to pivot. We initially started our service with simple business logic and it needs to be expanded for the user to fulfil their goal. We identify that our backend application powering our service needs to be a lot more complex than once thought. 

Team B is able to respond to this with no issue as our developers are able to work on all aspects of our service. As Team B has no tester the team identify that they need to do some manual Quality Assurance to ensure they’ve understood the complex business rules before getting feedback from the users. As the developers don’t have a tester in their team, they ask the product manager and one of the developers who hasn’t worked on the feature to test it themselves. Everything works out as they’re able to split all the work and react to other important feedback from users. 

Team A is struggling. We’ve only got one person who’s working on the backend application. The frontend developer isn’t confident enough to work in an area they’re not familiar with, and has no interest in that area. On top of this, they’re also facing pressure that the team has to deliver. The backend developer now feels like they need to rush to deliver and start taking shortcuts. They stop writing comprehensive tests and throw that responsibility over the fence for the tester to pick up. This slows the backend developer’s feedback loop. Instead of knowing some code that they wrote isn’t correct at the time of writing, it’s now taking days to get that same feedback. The frontend developer is now waiting for the backend application to be complete. They’re looking for things to do, but they’re happy that it’s not their fault that the team’s velocity has decreased. 

Passing whole responsibilities to individuals within the team rather than owning the responsibilities as a team can lead to toxic behaviours like blame culture. Team A’s developers are now focusing on output they can control rather than the whole journey. An example of this can be seen when a team with specialists have tickets in their backlog that are very system based and technical focused. Compared with Team B’s tickets that are user story focused that focus on an outcome that requires changes to one or more systems.

I’ve created my example to emphasise how easily focusing on output can negatively influence different parts of the delivery process. Like where the frontend developer and tester can use their specialisms as a way of avoiding to help solve the problem. It’s important to note that a team shape like Team B would not always succeed when things start going wrong. You’d still need to ensure your team is aligned around outcomes they need/want to deliver.

Focusing on what outcomes we’re delivering and enabling the team to share the responsibility of all aspects of delivery, we build a shared drive to deliver. Having a team of generalists, they are more likely to self-organise around the work and look for support from each other. However, if you do have specialists, having a strong product manager/delivery manager to keep the focus on delivering the outcome as specifying that direction is key. Close attention is required for making sure the specialists are focusing on achieving outcomes. 

Sometimes we do need specialists to solve well understood specific problems with well defined outcomes. For example, Team B is looking at integrating their new system with a specific legacy application. However, none of the team are familiar with this technology, and they have a deadline to deliver a Minimal Viable Product. Here, it makes sense to bring in a specialist who can help upskill the team to enable them to have the knowledge to progress quickly. What we don’t want to happen here is the whole responsibility of integrating the systems together to lie solely with this specialist person, siloing a critical path of the service. 

Your team should not generally be built around specialisms, it’s all too easy to amplify toxic behaviours and encourage those behaviours within a team. Specialists are more likely to work within their area of expertise and start creating other issues like gaps of knowledge, silos, blockers and half finished solutions. Team B would work together to solve problems, allowing them to share knowledge as they go and ensure everyone has the same level of understanding. However, within Team A specific system knowledge would only exist in specific individuals. This opens up other problems, such as if a team member is not available this would impact the ability for the team to deliver, effectively blocking the whole team.

Sometimes our users do not have a choice whether or not they want to use the service we build. We should be doing our best to ensure that we’re building software that delivers actual value by focusing on outcomes rather than output.

About the Author