The proponents of DevOps (myself included) usually bring forward arguments that evolve around breaking silos: “You build it, you run it”. This, according to the philosophy, leads to deliverables that take operational concerns into account, more automation and less finger-pointing.
Many of these same arguments could also be applied to some of the other organisational fault lines: “You ask for a feature, you build it”. Or “you build it, you sell it”. Why have responsibility hybrids of this kind not taken off in the same way that the DevOps movement has?
Before looking at the problems with this kind of thinking, let’s consider where the hybridisation has already taken hold in engineering and why we find it valuable.
It used to be commonplace to have a separate QA team charged with testing a software release before it was allowed out of the gates. Today it is more common for teams to integrate QA as part of the development process. The upsides are that flaws are detected earlier, automation is more common and the expensive hand-off to a gatekeeper is avoided leading to more frequent releases.
Similarly, it is more and more an accepted pattern to shift left on security, meaning that a product should not got through an approval process with a dedicated InfoSec team as the guards but instead include security concerns upstream. The InfoSec specialists become coaches rather than gatekeepers.
The relationship between development and operations used to complicated, caricatured by the phrase “works on my machine”. The rise of DevOps has mitigated that: In many teams, developers are now responsible for operating the systems they built. Feeling the pain of operational work is a good motivator to make systems stable and observable. Furthermore, many routine tasks can be automated.
I would thus summarise the promises of shifting more and more things into the developer team as follows:
- Giving developers access to the necessary competencies (QA, security, operations) leads to better deliverables that already integrate these concerns.
- Avoiding a hand-off with a gatekeeper leads to shorter cycle times and fewer misunderstandings.
- As developers are interested in automating repetitive tasks, it is assumed that some of the original work can be automated away over time.
So, as we are already heaping responsibilities on the development teams, why don’t we keep going? Why not extend that the same logic to other roles involved in product development? Why not shift left product management for example?
The first two benefits certainly still apply: A development team that takes over product management responsibilities should have better awareness of the problem space they are dealing with, leading to a result that better solves the actual needs and avoiding a hand-off.
On the other hand, product management may not provide a lot of automation potential compared to the other examples cited above. Therefore we would probably expect less of a gain from the left shift in this area.
There is also something to be said about having only one person responsible for important product decisions: If everyone is responsible, nobody is. Who would be the point of contact? Furthermore, product decisions should probably be embedded in a larger strategy meaning that there needs to be some form of exchange beyond the team. However, we should not forget that engineering teams also somehow manage to create a dynamic in which technical decisions are taken efficiently. Some teams have a TechLead, an individual that has the last word on technical decisions, without the expectation that they necessarily do all of the research alone. The PM in a cross-functional team could play a similar role.
An important reason why this is not common, is likely that the competencies required for QA, operations and security are closer to the skills and mindset of the average developer and that hence these things simply mix better.
Lastly, we should not forget that the overall capacity of an engineering team has a limit somewhere, we cannot integrate an entire organisation into one single team. Then again, there are small garage startups with minuscule teams that still achieve impressive things working fully end-to-end.
Keeping all of these caveats in mind: In the spirit of creating cross-functional teams with as much end-to-end responsibility as possible, I think that it does make sense to reflect on the partitioning of tasks. I don’t think we will subsume the PM role into the engineering team any time soon. But maybe, we can still encourage individuals that like to have a foot in both worlds to be part of the team and create a bridge to at least reap some of the benefits.
The Solution Space 
Leave a Reply