Management and Product Management

Over my past few assignments, I have seen several software teams that are instructed by the management group to be an Agile, Product-Led Team, but are then thwarted by said management. This management is often well intentioned but their activity has an outcome that obstructs the team and prevents their (and the business’s) success. The management often speak about the right things: wanting self-governing teams; optimising for outcomes; and hiring in a manner to “raise the bar”. However, the actions they take undermine all that, creating a disconnect for their team and friction with the management tiers.

Unhelpful management behaviours I have observed include:

  • Managers running scrums and stand-ups
  • Insistence on production of project reports that nobody reads
  • Suppressing team members more capable than the manager at a specialist skill
  • Requiring teams to clock in and out – and following up from the central finance function when a “full day” hasn’t been worked
  • Refusal to spend budget on hardware or software that will clearly enable the team to be more productive


Why doesn’t this help?

Some of this might appear to be good governance – after all, shouldn’t a manager run the stand-ups to ensure that work is progressing to plan?

However, all of these behaviours remove responsibility from the team. The last two, in particular, show a failing to understand how product and development teams work. This isn’t about people wanting special treatment, more about understanding that in these roles a manager is unlikely to govern by authority and simply doing the job better than everyone in the team. Given the variety in roles within a software development or product discovery team, it is unrealistic to expect that a manager can do all roles better than their team. Rather, a manager serves the team well by removing obstacles to effective working and giving the team a steer toward an objective.


Why this happens

Two of the three organisations I reference above have a history of retail or small scale manufacturing. In these areas, store managers progress by knowing every detail that goes on in their store and still being great at doing those jobs – one often sees managers on the shop floor mucking in and visibly taking pride in how their store is presented – and being prepared to contribute to that effort. Similarly, the manager in a small-scale production facility will often design the flow and optimise that; it is the role of the team to follow the guide and not deviate.

In both of these cases, the approach to staffing had not changed much with the transition to the running software teams. While it was acknowledged that teams might have specialists, the concept of self-organising teams was mistrusted and hierarchical control over the team was maintained.

The Cynefin model helps us understand these issues (Greg Brougham gives a great explanation here). The small-scale production facility and retail store reside in the Obvious space. Here we have predictable work, where process can be documented. Reduction of costs is desirable here and a repeatable process helps avoid having to hire skilled workers.

Mapping work to the Cynefin model

However, software development sits somewhere between the Complicated (knowable but a subject matter expert is required) and Complex (safe-to-fail experimentation) domains. Product Management, in particular, fits in the Complex domain, requiring safe-to-fail experimentation to identify what leads to desirable outcomes.

When work is in this domain, it cannot be boiled down to a series of repeatable process steps. There may be no point finishing the day’s eight hours if one’s brain isn’t producing; conversely there will be days where the morning flies by and insistence on the employee taking a 15 minute break would seriously interrupt their productivity (and they won’t thank you for that!).

How Product Teams are typically managed

Equally, when the team takes responsibility for the work they do, they will suggest safety measures far more effective than a manager would suggest. Equally, they might suggest sanctions far beyond what would be appropriate for a manager to do! But the point is that they take this responsibility and keep each other honest. This moves beyond working to a set of rules: the team adopts a culture that actively seeks to add value to the business and users. When managers attempt to take control of this process, they take responsibility away from the teams and the virtuous outcomes are diminished or lost.

Needs of Complex-domain teams

So what does a manager do in this domain? Here, the manager sets the desired outcomes and describes the constraints (legal / ethical / regulatory, etc). The team then seeks to meet those outcomes via user research, testing, MVPs, and so on. Attempting to apply a rigid process, or assign blame based on contractual wrangling runs counter to the behaviour required here.

Applying Obvious-domain rules to Complex-domain teams

This sounds like my organisation…

Firstly, this isn’t a rare problem. I am constantly staggered at how many organisations make good money despite following practices that actively hinder that organisation. And secondly, why would it occur to a business to change management practices for different teams? The typical organisation would reject this as it would cause friction and complications between different departments.

Clearly, I don’t have the answers. However, organisations need to recognise the problems that a one size fits all approach creates. It might seem that treating different teams differently will cause problems – in fact, the opposite feels more likely to be true. Teams need to be managed in a manner suited to the domain in which they reside and management hiring decisions and training needs to reflect this.