In my previous article, I wrote about some of the misconceptions with “agile” that I see in organisations. This article will focus on one of them specifically – the common (mis)understanding that agile—and more recently lean start-up methods—are seen as operational and tactical, rather than strategic. Where does the confusion comes from? In particular, I want to acknowledge the role that the person who leads the project operations plays in realising the product vision and creating a context for the team to succeed. That person could be a Scrum Master, or an Agile Project Manager, or a Delivery Manager, depending on the context.
Just as product teams require a product strategy that fits the product vision, those teams also require a fitting operational strategy to support the vision. And that’s where I see the role of the person who leads the product operations to be crucial. I also see a trend these days with some organisations effectively making the role redundant or aiming to dismantle it in the name of perceived autonomy for the team. At the same time they are creating extra responsibilities for the Development Managers and Product Managers. More often than not, this comes at a high cost.
Of course, there are valid reasons why an organisation might want to dismantle a role. If the project managers are not reasonably technical or business-savvy, then they are usually not helpful to the organisation. Even if they are technical and business savvy, the organisation may still prefer not to have them – usually because they have behaviours and attitudes stemming from old waterfall project management styles that the rest of the team don’t find helpful.
However, if your product operations discipline is strong, then that is a key competitive advantage for your company. It’s what differentiates highly successful companies like eBay, Spotify, Facebook, the BBC (and Clearleft) from companies who merge this role with the responsibilities of other functions on the team. It may be the difference between a great product and a terrible one. Or the difference between getting the business partnerships the company needs to reach its customers, and getting lost in obscurity. Or the difference between getting the product out when it needs to be, and getting stuck in perpetual delays.
In many companies, the senior Development, Product or Design person on a team is also responsible for some or all of the project management. In my opinion, these jobs are different enough that, in all but small teams, separate people are needed for the separate roles. While it's great to encourage more people to develop an understanding across different organisational disciplines (i.e. developing T-shaped skills), there are a number of important trade-offs and risks to consider when making a decision to permanently reallocate responsibilities for project management to other roles.
Capabilities
The first consideration is the operational maturity of the team. Does the team or the person in charge of project operations have the skills to create a fitting operational strategy for the project and execute on it successfully? Are they merely led by their vision and principles without consideration for the wider impact on the team? If the answer to the latter is yes, this should be a red alarm for your process. Both lean and agile offer up a set of great guiding principles, but on their own, those are not sufficient to support delivery on project objectives.
The biggest issue with blindly following values and principles is the importance of context and specifics. Take ‘experimentation’ for example. ‘Experimentation’ is a principle that I advocate. But for some teams the cost of following that principle (or any other nice-sounding principle) could, for instance, be too much for the business to bare. Teams don’t always appreciate this consideration, especially in organisations that have jumped on the agile, cross-functional, collaborative team bandwagon.
Words like ‘experimentation’ have intrinsically positive connotations. By implication, anything to be experimented with seems by that very fact worth experimenting with. But that doesn’t make sense. Experimentation could easily be used in this context to further a small conservative agenda. A small group gains strength, and inordinate energy is sapped from the larger business and directed towards protecting the group’s interest. My point is: agile and lean principles are great guides, but one shouldn’t make decisions solely on the basis of principles and values. The messy realities of business also matter.
The role of the person leading project operations is to extrapolate from the politics and personal agendas involved in the typical business issue — and guided by good (lean and agile) values and principles — to create a fitting operational strategy. This means weighing out a variety of considerations, in terms of cost for the business; the short and long-term impact on the team, and many others.
Cost of opportunity
Merging too many disparate responsibilities under one umbrella also comes at a high cost of opportunity. For example, if you ask a senior developer to be a dev ambassador, a people manager and a project manager, something’s going to give. And that something is usually the area they are least interested or competent in. The result is a range of crucial, but deprioritised activities which undermine the success of the overall initiative. Even if the person responsible for multiple unconnected activities is relatively competent in all disciplines, it takes their focus away from their core speciality. So while it may seem like giving more responsibility and autonomy to a team will enable them to be more self-sufficient, it may actually be crippling their ability to perform at their best.
Personal interests, competencies and motivations.
While it's good to be T-shaped, one shouldn’t underestimate the importance of personal interests, competencies and motivations. The cost of merging too many disparate responsibilities under one role can be substantial. As pressure continues mounting up on individuals to perform to heightened expectations out of touch with their capabilities and interests, the results are less than favourable. Sooner or later, this is going to affect the bottom line of the company. Or worse - people are going to leave for jobs that fulfil their personal goals and career development better.
Clear thinking
One of the merits of having a dedicated operational person on the team is the clear focus on results. As is the case with most things in product and project management, everything boils down to trade-offs. Cross-functional teams, in particular, are highly complex, so you need someone on the team who is impartial to occupational biases to put those trade-offs into context and drive decisions. This is where the agile project manager must communicate the sense of urgency; clearly frame the problem; have rational and transparent reasoning, and make decisions based on data. Strong operations leads know that this begins with measurement. In the absence of any data, decisions are easily swayed by personal opinions and bias.
Business impact
One of the characteristics of a strong project management function is the ability to simultaneously impact decision-making that actually helps to move the needle in the long run, and also to secure some early wins through early and rapid iterations of work. And all this needs to be done in a way that mitigates risk for your normal business operations.
While the focus for other leaders may be on the design, tech or product direction, the focus for the operations lead remains on improving the process and the result.
Putting the project management responsibilities on non-specialists causes big problems for the success of a team and the wider organisation. In my opinion, companies, and especially mid to large size ones, should proactively seek to create environments which are conducive to high performance. Establishing a strong project operations discipline is a core characteristic of high performance culture, as demonstrated by many organisations which leverage this skillset well. If you are serious about creating a high performance culture, then you should start taking operations seriously at all levels of abstraction — sprint, project, program, product, or business.
The absence of dedicated operational strategy is itself a strategy, just a very bad one. And this hurts the organisation.
