You’ve probably heard of You Build It You Run It before. It’s an operating model that empowers product teams to own every aspect of digital service management. When done well, it accelerates your time to market, increases your service reliability, and grows a learning culture. There are also some pitfalls, which can drain the confidence of your senior leadership, and ultimately put the success of You Build It You Run It at risk.

In our recent You Build It You Run It playbook, my co-author Steve Smith and I take a deeper look at the embedded specialists pitfall. You can guard against this pitfall, and even escape it if necessary.

Teams of specialists suffer at scale

Steve and I often see organisations with small, central teams of specialists supporting a number of delivery teams. For example, you might have some delivery teams and an application support team dependent upon a small DBA team, for the provisioning of your on-premise relational databases and management of your user data.

You don’t want developers to manage database backups themselves, nor to debug a live database with millions of rows of user data. At the same time, your DBAs can’t transfer their depth of expertise to developers. This means DBA workload will inevitably increase as you add more delivery teams, no matter how skilled your DBAs are. Conflicting prioritisation calls, strained relationships, and a lack of delivery team progress are likely, as well as burnout for your DBAs. 

Steve and I have seen specialists in this situation too many times, in different organisations and in different specialisations. We’ve seen it with DBAs, InfoSec analysts, network admins, and operability engineers (which you might know as DevOps). In addition, the easy answer of recruiting more specialists into the central team doesn’t usually work, because there’s a consistent scarcity of affordable specialists in the marketplace.

The embedded specialists pitfall

You Build It You Run It is an operating model in which product teams build, deploy, operate, and support their own digital services. If your organisation adopts You Build It You Run It and you have multiple product teams constrained by a struggling specialist team, one solution that could be considered is embedding those specialists into the product teams. In other words, if you had 10 product teams and one team of 10 DBAs, you would embed each DBA into one of the 10 product teams.

Steve and I call this the embedded specialists pitfall. It’s the logical extreme of You Build It You Run It, and it’s not a good idea. In theory, embedded specialists will act as first responders, and influence technical quality on product teams via their deep expertise. However, we’ve seen serious problems emerge for embedded specialists:

• Multiple assignments. Your embedded specialists are each assigned to multiple teams, because you have N product teams, less than N specialists available, and recruiting more specialists is difficult. 
• Unpredictable workloads. Your embedded specialists are either bored from a lack of work, or burned out from too much work across multiple product teams.
• Lack of knowledge sharing. Your embedded specialists don’t have opportunities to work together, learn from one another, or even talk to another. They can feel lonely.

Tom Clark spoke at DevOps Enterprise Summit Europe 2019 about how this pitfall affected the ITV Common Platform. ITV tried to embed a platform engineer into each product team, and the engineers suffered from multiple assignments, unpredictable workloads, and a lack of knowledge sharing. This had a direct, negative impact which led to technology stagnation and reduced developer productivity.

So, if the answer isn’t adding more specialists to a central team, or embedding specialists into product teams… what do you do?

Establish specialists as a service

You can achieve a step change in productivity by turning your specialist teams into consumable specialist as a service offerings, and achieving a balance between cross-functional product teams and depth of specialist expertise that’s right for your organisation. Steve and I recommend the following:

1. Offload non-specialist tasks to product teams.
2. Map out specialist tasks and the associated actions. For example, you should offload repeatable, low value tasks to your cloud provider. You should automate repeatable, high value tasks in a deployment pipeline. And retain ad hoc, high value tasks as is. See the table below for more details.
3. Establish low friction, public messaging channels for bi-directional feedback loops, #ask-the-dbas, #ask-network-admins.
4. Create public ticket queues to show planned work and work in progress for specialists.

Specialist tasks can be mapped in terms of repeatability and value-add.

The goal is to remove toil for your specialists, and free them up to concentrate on high value scenarios in which product teams really need their deep expertise. Their expertise is too scarce, and too important, to be wasted on tasks that can be handled by your cloud provider or product teams.

Further reading

To find out more, you can continue our You Build It You Run It pitfalls series:

1. 7 pitfalls to avoid with You Build It You Run It
2. 5 ways to minimise your run costs with You Build It You Run It
3. Why your operations manager shouldn’t be accountable for digital reliability
4. How to manage BAU in product teams
5. 4 ways to remove the treacle in change management
6. Why product teams still need major incident management
7. Stop trying to embed specialists in every product team – you are here!
8. How to avoid developer burnout on call

Our You Build It You Run It page has loads of resources on on-call product teams – case studies, conference talks, in-depth articles, and more. Plus our You Build It You Run It playbook gives you a deep dive into how to make it happen!