The DevOps and shift-left movement, that, in my experience, was at its zenith around 2015-2019, popularised the concept of feature teams fully owning their part of the application.

Typically these teams will have at least one person whose job title is something like 'product manager', 'project manager', 'product owner', 'delivery lead', 'scrum master' or 'team lead'. Note that it's common that these are two roles - and when this happens the split is typically a 'product owner', who is a bit more technical, they're looking at RUM dashboards, interviewing users etc, and from that determining the work to be done, and a 'delivery lead' whose focus is more on timelines, resourcing, dependencies on other teams etc.

Using the scrum model, which nobody seems to talk about any more but was very popular when I started my career in 2013, the 'delivery lead' type role is the role that most closely approximates a 'scrum master' - and two of their key roles are:

• to serve as an arbiter between the developers and the product owner
• to serve as an unblocker for the developers, in terms of getting access to systems/resources, making sure the developers' dependencies are fulfilled etc.

In this later sense the delivery lead is on the side of the developers. The idealised picture of this is that the developers have a clear picture of what they're trying build, and what the problem they are solving (because the product owner has done their job), they've created a plan to get there, and now they can sic the delivery lead onto whatever impediments get in their way. The delivery lead hassles whatever admin needed to approve an access request, runs interference when a different part of the organisation tries to get this team to prioritise their piece of work, and resists external stakeholders expanding the agreed scope of work.

However, what I have seen more commonly is that the delivery lead becomes a cudgel against the developers. The reason this happens I think is obvious - the role of 'delivery lead' involves a good deal of stakeholder managment, with stakeholders outside of the feature team, and often senior stakeholders at that. It's likely a lot better for someone's professional reputation to be that person who can say 'yes' to these external stakeholders, than to resist them. It's likely also better for their own performance appraisal to be seen as someone who can be getting things done, rather than someone who is constantly saying 'no'.

This leaves the developers in a shitty situation - they're being told that the delivery lead is the person that can help them get their job done, while that delivery lead becomes the very source of external pressure.

This is a psychologically unsafe environment for the developer - it might not be wise for the developer to be candid with the delivery lead about their estimates of delivery times and risks, because then the delivery lead becomes the person who is going to take away their wiggle room to accommodate an external request.

Being a software developer is a difficult enough occupation - if a developer doesn't have someone who is serving as their advocate to resist external organisational pressure, then that job falls on the developer's shoulders and occupies mental bandwidth (and time!) that could be better spent actually building products.

Questions? Comments? Criticisms? Get in the comments! 👇