Hey, Let's Embed an SRE in that Dev Team!
I see it often. The thinking goes like this: we don’t have enough budget to put an SRE (security person, QA engineer, etc.) on every team, so instead, we will embed engineers onto a team for a short period, or more often, embed them onto several teams. The reasoning behind it is understandable, seductive even: getting most of the benefit of a fully staffed team at a fraction of the cost.
It’s a practice shrouded in both promise and peril. While it can foster collaboration and bridge gaps, it often backfires, leaving a lasting negative impact on both the engineer and the teams they’re embedded in.
A Story
I encountered an engineer, let’s call him Alex, who was embedded in four teams simultaneously. Despite his unwavering dedication, Alex was perpetually caught in a tug-of-war between the four teams vying for his attention. Every time he chose to work for one team, the other three would be left hanging . No matter which team he chose to work for that week, someone would be disappointed. He was guaranteed to always lose. This took an immense psychological toll on Alex and the teams were lucky if they got one quarter of what they’d hoped for.
The Right Way
There are unintended consequences in this practice of embedding engineers. When an engineer is spread too thin across multiple teams, their contributions become fragmented and often fail to impact the overall progress of any team. The engineer’s time and focus are divided, leaving their ability to deeply contribute to any one team diminished. Additionally, the embedded engineer often finds themselves navigating conflicting priorities and agendas, creating a sense of unease and frustration. If they are in the critical path for delivery, they become a blocker. No matter how many nights and weekends the engineer works, there is no escape.
There are times when embedding an engineer with a team are clearly necessary, but as a partner, not a team member. The key lies in ensuring that the work completed by the embedded engineer is clearly documented and integrated into the backlog of the team they are being loaned out from.
This ensures that the benefits of their contributions are maximized and not hidden in the backlog of the teams in which they are embedded. This gives the loaning team an opportunity to look for systemic fixes that can be developed that will reduce or eliminate the need for embedding in the first place. In the DevOps movement, we call this “shifting left”. It also gives an opportunity for the manager of the loaning team to monitor the workload and morale of the embedded engineer instead of hoping this will be done by one of the for other teams. If those teams are not getting what they need, they will have the opportunity to bring those concerns to someone who can actually do something about it, rather than the embedded engineer.
While embedding engineers can be a valuable tool in certain circumstances, it should be carefully considered. The potential downsides far outweigh the benefits if not implemented thoughtfully. If an engineer is assigned to multiple teams, it’s crucial to ensure that they are not put in impossible situations where the potential benefits of their contributions are lost to the wider organization . By prioritizing the wellbeing of engineers and ensuring that their work is integrated effectively, embedding can become a powerful force for improvement.