.png)
Dispatch location disavowed // august 18 2024 // This is for PM leaders VPs CPOs
Product Managers hate micromanagement and complain about it constantly. It kills motivation! It kills creativity! I hear this a lot, and see this a lot.
What happened, I think, is agile. That's usually the form it takes. There is a lot of truth the idea that in the last 10 years, agile enthusiasts have gone absolutely bananas. They believe they have built the "right" meetings and processes to "do agile correctly."
PMs get complainy because they bear the brunt of this 'generosity.' For them, it often gets worse. Businesses and the big world beyond out there? It ain't agile. Most part of this world live in a very regimented, concrete, and deterministic paradigm. Think: GAAP. For PM the so-called agile process gets bolted onto a financialized quarterly planning process. This amps up the complexity. Devs don't really have to really worry about this. Lucky them.
It's all true. PM is a nightmare of meetings and reviews. It's about planning, QBRs, standups, retros, budgets, interlocks, product councils, roadmap and strategy reviews. WE'RE FROM THE EXECUTIVE TEAM AND WE'RE HERE TO HELP!
Justifiably, talk of "empowerment" dominates today's product management discourse. The E-word permeates every discussion about software teams.
But what does empowerment really mean? Giving product teams total freedom? It has the feel of "you are not the boss of me," when literally, in fact, that's the opposite of the situation.
So what to make of all of this? Is empowerment good or bad? Is process good or bad?
The Answer is yes.
The negative case for Empowerment
In current PM discourse, Empowerment is seen as a good thing. So, I won't argue that. What I will argue is the case AGAINST unfettered empowerment. Or, more specifically, why limit empowerment?
Empowerment often means letting product teams make all or most decisions. It's a complaint you hear a lot: leadership, execs, or the CEO are "meddling" with the product. The dreaded "HPPO" problem. Autonomy is the axiom.
Which, to be clear, in some companies, is a horrific cultural problem. There are situations where the leadership team is unrelenting narcissistic bullies. Unfortunately, it happens. I'm not here to whitewash it or apologize for it.
But more commonly, free-floating executive narcissism is not the problem. The problem is, if left alone, PMs and their co-conspirators in Dev and UX would create overly complex products. They would go beyond what's needed for the market.
When product managers get too much room, they start to wander. Without a clear sense of what's important, they chase the wrong ideas. They get bogged down in minor details. They spend too much time on things that don't matter. PMs can OVER conceptualize the problem and then this gives dev license to OVER engineer the solution.
Which all makes sense. Product teams want to create something perfect. They want to be proud of their work and its craftsmanship.
The cracks in the armature usually appear in product or company performance. The company is not meeting goals. The release process is lengthy or stalled. Customers and sales are unhappy.
Which inevitably pendulums back to "process." Sometimes you hear teams say "we need governance" and when you hear PMs say that, you know it's bad.
The positive case for Process
Empowerment is often mistakenly seen as entirely positive, while Process is unfairly viewed as thoroughly negative. Too much process (i.e. too many meetings), or process for the sake of process is all bad.
Bureaucracy kills software just as sure as day becomes night.
But is there a case in favor of process? There is.
The hallmark of process-based approaches is, at its base, still all about time. "Process" easily jumps to "micro-management." If you control my time, you control my work. It's a logical leap.
However, the optimistic case for "process" is that managing time is not about micro-control and micro-decision-making... it is about ATTENTION.
Attention drives results. It's what gets work done. The causal chain is this: control time --> control attention --> control focus.
When team members are focused, they make progress. They fix problems, finish tasks, and create value - all in extreme overdrive. Without attention, without focus, even the best intentions fail.
Post-COVID, calendars reign supreme. Unchecked empowerment breeds misalignment because PMs work in solitude. Interrupted less, PMs drift from organizational goals.
The Answer
Balance. The answer is yes.
Don't focus on managing time (efficiency), and don't focus on managing vision (thought police) ... focus on managing attention.
How do you hold a dandelion? Carefully.
Product teams are fragile. You need time in the day and the week to "system interrupt" and get the team to share. But, not so much time that it hurts their autonomy, work-life balance, or flow.
In practice, this means:
Enough meetings ... to sustain interest, momentum, and quickly resolve problems. Problems should not linger.
Not enough meetings ... to make every decision. It should always feel like you don't have enough time together.
Practical Methods - Try This
Ramp up the cadence
Ramp up the meeting cadence.
Use this new forum as an excuse to have fewer meetings. Aggressively cancel. "Just bring it to the daily"
If you meet on a topic monthly, meet weekly. If you meet weekly, meet daily.
Big meetings are fine, and are fine to (occasionally) miss
If you miss, just come to the next. If you meet a lot, on a high cadence, inevitably people will miss. So what.
Record and transcribe
Nothing lingers
It's ok to go long. Meeting efficiency is not the goal. Solving problems is the goal
"What would stop us from solving this today?"
"Can you bring this answer back to our next meeting?" (i.e. tomorrow)
Show us
In the meeting, show us
Write it down, in the meeting
It's both.
Comments