Management is not about being in charge.
We usually associate the term “manager” with people managers. At first glance, a people manager’s job consists of bossing people around – telling them what to do. For example, engineering managers no longer write much code, but rather focus on organizing teams.
But a typical engineering team has a second manager – a product manager. The PM typically lacks formal authority. They are responsible for defining some work that should be done, but can’t actually tell anyone what to do or how to do it.
And yet, the PM is still a manager.
The responsibility of management is not simply making decisions and then passing them on to someone else for execution. The responsibility of management is to create an environment in which decisions can be made and work can happen. A manager does not need hiring and firing authority in order to do that. In fact, John Cutler’s litmus test for what makes a good manager is precisely the reverse – to ask “if your team could choose whether or not to hire you, would they?”
Dimensions of Decision-Making
And yet, the PM needs to make decisions. What’s more, those decisions need to stick. Nothing undermines team confidence like flip-flopping between ideas and making it impossible to plan ahead. This is the real value that a manager provides to the team – the ability to set the course and keep it steady, guiding efforts towards some useful outcome.
But it would be a mistake to model this on one axis, with decisiveness on one side and indecisiveness on the other. There are two components that contribute to the “stickiness” of a decision – direction, and autonomy.
Direction
Imagine your typical product manager. Let’s call them Pip. Pip’s day-to-day involves communicating with the business to keep tabs on the strategy and metrics handed down from more senior management. Pip also takes requests coming in from other stakeholders. Before asking the team to start working, Pip will usually take some time to understand the problems more deeply and figure out what a solution might look like. The fidelity of that solution – informed by Pip’s understanding of the problem and ability to define how to address it – represents the magnitude of the direction that Pip is providing to the team.
Thus, direction flows from the organization, through Pip, into the team. If Pip is providing a low magnitude of direction, they might be creating open-ended backlog tickets, or asking to improve product-level metrics that could be raised through many different kinds of intervention. If Pip is providing a high magnitude of direction, they would write highly detailed specifications and measure success through very specific, feature- or screen-level metrics.
Autonomy
If direction is the fidelity of Pip’s requests to the team, autonomy represents the extent to which the team feels empowered to define their own work. A highly autonomous team can challenge Pip’s requirements and understanding of the problem. A team with low autonomy is compelled to deliver only solutions that the PM has already defined.
Autonomy is a function of the balance between Pip’s team-facing influence and org-facing influence. If Pip’s ability to influence the organization is low, all they can do is take orders from more influential colleagues, and try to fulfill them. If Pip is influential in the organization and can manage stakeholders effectively, they can give the team a high level of autonomy. If Pip trusts in the technical and problem-solving expertise of their team, they can provide air cover against the rest of the org, while the team investigates the problem and potential solutions.
The Four Quadrants
The combination of these two dimensions gives us four possible operating modes.
A skilled PM knows how to shift between them to achieve the current most important goal efficiently. However, each operating mode has a failure mode associated with it, where autonomy and direction are not sufficiently balanced, and the team’s decision-making ability breaks down.
Dithering
A team is operating in the first quadrant if they have no external direction, and no autonomy. All they can do is dither aimlessly. Without either a solid direction to follow or the autonomy to find some way forward themselves, the team has no way to make progress on goals because they don’t have any stable goals in the first place. This usually happens when business leadership has failed to adequately set product goals.
Like the rest of the team, the PM is not contributing a lot to the organization. Pip spends most of their time copying stakeholder requests from emails to tickets. Priority can change at any time, so Pip can’t commit to studying the problem in more detail. Without a good understanding of long-term goals, and lacking any success metrics, Pip’s only real option is to double down on output. Melissa Perri outlines in detail how to escape this “build trap.”
Pip might be stuck in this quadrant if they or their management are afraid of risk. Risk-reducing strategies are key to moving away from this mode of work; teams should focus on increasing the frequency with which they ship, reducing the scope of each release, and gathering metrics from each iteration. If a release fails to deliver on the desired metrics, it’s not a failure, but a sign to try something else. Releases should be treated as experiments, and an experiment can never fail – it merely produces a negative result, which still contributes to the team’s understanding of the problem space.
Delivery
If the org is willing to take some risks, Pip can start placing bets on which solutions might make an impact on important problems. If Pip has not secured much autonomy for the team, but is able to give a high magnitude of direction, it’s easy to make a decision and then stick to it. There is only once decider. The team focused on delivering to the provided specifications without being encouraged to push back or question the effectiveness of the prescribed solution.
This mode of delivery can work if the team is tackling a well-understood problem. If Pip has the necessary domain knowledge, or has help from outside the team, the engineering team will have everything they need in order to execute the plan. This is the working mode most commonly associated with waterfall delivery models, as well as Scrum. If the business relies on consultants and agencies, or is structured around domain-specific silos, this may be the only choice they have.
The results of working this way hinge entirely on how well the problem was actually understood. Often, the answer is “not as well as you thought”. If the team has sufficient autonomy to pivot away from the prescribed solution, they can still deliver some value, regroup, and save the day. It pays to give the experts room to reach the right outcomes, rather than over-prescribe outputs.
But if the PM has not given the team any autonomy at all, and turned them into nothing more than pixel-pushers, then there is no way to alter course. This mode of delivery becomes nothing more than ruinous micro-management. By trusting the specs more than the team, the PM dooms the entire project to failure.
Discovery
PMs often try to avoid the above outcome by making a really, really good plan. A perfect plan that will anticipate every problem. But “perfect” is the worst enemy of “good enough” – and so the chase for the perfect plan usually proves futile. Not in the least, this is because a perfect plan has to involve a very low-level definition of what needs to be built, and few product managers are interested in, or capable of, getting that technical. PMs trying to anticipate risks are better off working with the engineering team and leveraging their technical expertise.
If Pip trusts the team to design a good solution, they only need to provide a small amount of direction. As long as the team understands the objectives of the project, they will be sufficiently empowered to explore many possible options, and iterate towards an outcome that moves the needle in the right direction. This is the mode you would expect to see in Lean teams, or cross-functional teams that have their own embedded designers, user researchers, and so on.
Because this mode of working has very high uncertainty associated with it, Pip needs to give the team a tremendous amount of air cover. If Pip can’t convince stakeholders that research is necessary in order to ultimately deliver better quality outputs, it can spell trouble for the team’s reputation. And without a certain amount of guidance from Pip, the team’s efforts will spin out of alignment and cease to make progress towards the end goal. Frequent iteration and a laser focus on learning are must-haves if you want to operate in the Discovery mode and not wipe out.
Synthesis
Most of the time, Pip will probably have neither the sway to run in an unconstrained Discovery mode for long, nor the time to put together a spec detailed enough to focus exclusively on Delivery. A balance between autonomy and direction will result in a synthesis of the two other modes.
A team in this mode is empowered, but not autonomous. They have the strategic direction they need from Pip, and the freedom to make tactical decisions. The team has an understanding of the most important metrics that the project needs to push, and Pip has engaged the appropriate experts in order to figure out the general shape of a solution that might push those metrics most effectively. This is fairly typical of an organization where Agile is practiced correctly.
But when a strict top-down direction comes up against an empowered team driving a bottom-up initiative, the result can be simply unproductive conflict. PMs facing a deadlock between strategic and tactical needs must tread carefully, or else leave feelings hurt on all sides.
Moving between zones
As a project progresses, conditions around the team’s work will likely change. If the team has been shipping frequently and gathering user feedback, the need for discovery will progressively decrease. Deadlines will loom closer, and transitioning into a delivery-focused mode will help meet them.
But early on in a project, it will usually be more beneficial to do the opposite: secure as much autonomy as possible for the team to get a feel for the problem, explore fruitful directions for solving it, and maybe even push back against the initial definition. Cutting the period of discovery prematurely may significantly limit the impact that the ultimate output will make.
Pavel Samsonov is a Product Designer at Bloomberg Enterprise. Interested in collaboration between human and machine actors, Pavel is currently designing expert user experiences for Data License products across the GUI, API, and Linked Data platform.
You can connect with Pavel via Twitter: @PavelASamsonov
Comments