Preface: I’m going to experiment with sharing some cases here. They are always better live, but I inserted a couple of moments for you to think asynchronously. This scenario is based on a blend of real situations, but has been adjusted for learning purposes.
Setup
One of your teams is really struggling with pace and progress against their goals, which is frustrating both the you (CPO) and the CEO. You know everyone on the team is smart and hard working, but it’s very hard to tell what is going on and why. Disturbingly, your most senior product manager is on this team. You ask some questions individually to the PM, the designer, and the lead engineer. This is what you hear…
The PM tells you…
“Things are improving, but it could be better. The team was derailed by having to work on blocking a spam attack from China (which has nothing to do with their OKR). Admittedly, the next phase of the roadmap is very unclear but first I want to ship something and learn.
The engineering lead’s obsession with XP (extreme programming) methods is causing some swirl. I’ve never worked this way and am trying to figure out how to support them.
I’m happy to walk you through our metrics again, but ultimately the team just needs to buckle down. I’d like for upper management to stay clear and give us the autonomy to figure things out ourselves. I’d like to cancel our bi-weekly team update meetings until we get on track, if that’s ok.”
The Designer tells you…
“The team has a good high-level vision, although the engineers don’t all understand our team OKRs. The PM’s domain knowledge is superb and he has a good nose for the metrics. The team knows what to do at any moment but is missing insight into what should be coming next and why. It can feel like a constant scramble, especially for me.
I’ve been frustrated with the lack of polish of the UX going out to customers. I think the engineers have way too low a bar. 1-on-1s with the PM? It’s been a while. We talk at standup and the weekly team planning meeting.”
The Engineering Lead tells you…
“I like our PM and designer a lot. The PM really knows the customer and can take care of the OKR. Sometimes it feels like the backlog is getting empty and those two have to scramble, but it always works itself out.
The team problems are coming from a few areas: the engineers are relatively junior and are adjusting to XP methods; the PM is not familiar with taking big concepts and breaking them into small stories; there is constant scope creep because the PM and designer keep on trying to add more polish to releases when instead we should be learning and iterating; lastly, we’ve got too many distractions tied to engineering ownership of other parts of the code base, like the spam attack.
I’m never entirely sure what the PM is working on, but when we do talk, it’s always clear a lot of work was being done.”
What do you observe?
Before you go on, take a second to write down the things you observe and where you would want to learn more.
.
.
.
.
.
.
.
.
.
.
Here are a few of my observations:
- There’s not enough communication going on — neither inside the team nor outside the team. Disturbingly, the PMs instinct is to hunker down and communicate less, rather than more. Their instinct is also to avoid asking for help, which is often a sign of insecurity not strength.
- The essential triad — the PM, designer, and engineering lead — isn’t partnering enough nor spending enough time with each other. They haven’t built shared values and they aren’t leaning into each other’s areas enough. For example, the engineering lead seems too focused on engineering-only problems, and is danger of becoming an “order taker” (i.e. tell us what to build and we’ll build it). The designer seems too passive about the problems. But ultimately, with my most senior PM on this team, I’d be looking to the PM to pull the crew together and forward, starting with the triad but extending out to everyone.
- The shift to an XP agile methodology has slowed them down as they make the adjustment. From their statements, you don’t know how or why the decision was made, but you can tell that there wasn’t enough training (for anyone on the team), and/or enough external expectation-setting on the impact of a process shift.
- The team hasn’t pushed its planning forward far enough, making things feel like a constant scramble. The PM should be leading this effort, but involving the entire team. The good news is they have both numeric targets and a high-level vision, so creating a team roadmap — even a sketch of one — should be very doable.
- One pattern from the observations so far is a gap between what I would expect from a very senior PM and what is actually happening. However, I’m wondering whether this PM actually knows what is expected of them. Have I, as product leader, made the expectations for different levels of seniority clear? Has the PM been getting direct enough feedback from their manager?
- I bet a lot of you caught the spam attack that derailed the team’s forward progress. They clearly have two conflicting responsibilities: 1. ownership / maintenance of some existing parts of the code base; 2. progress against new OKR goals.
What questions do you have?
As you think about your observations, you should ponder: what else do I need to learn? Did I jump to conclusions and make assumptions, or do I need to ask more questions? Guaranteed there is more to learn and deeper nuance to understand. First on my list would be: “what do the direct managers of these three people think?” although no doubt you already asked that, and got their okay to speak to the parties directly, before you dove in!
What do you do next?
Before you go on, take a second to write down a few of the next steps you would take.
.
.
.
.
.
.
.
.
.
.
Here are some next steps I’d think about:
- I’d want to pull the direct managers of the PM, designer, and engineering lead together to discuss their observations and mine, and to formulate a plan. I’d want them to be giving individual feedback to their reports, but also to select one person (either from this group or someone else) to more actively coach the team until they were out of trouble. This person could also help us diagnose whether this team can be healed or if it needs to be remixed (change up the people in some way).
- Speaking of coaching, if we’re backing their decision to move to XP, I’d try to carve out some budget to get the cross-functional team (not just the engineers) some coaching specifically on this topic.
- If the product organization is missing clear expectations based on seniority (what I call a skills matrix – see here and here), I’d want to fix this ASAP. This would be my failing. Perfect is the enemy of progress here, and I’d involve the broader product team in this effort.
- I’d be talking to whoever was directly managing the PM about the feedback being given. Has it been direct, clear, specific, and actionable? Is the issue that the PM has not been receptive? The answers would dictate the solution, but for sure things need to ratchet up here.
- I also need to get together with the CTO to discuss the conflict between code maintenance and OKRs. Do we need to change how we handle maintenance, or adjust our OKRs? The team cannot solve this — it must be handled at the executive level. The CTO and I have to resolve this together, and if it impacts the OKRs, we need to bring our proposed solution to the CEO.
STEP: a simple framework to think about
As you progress in your career, you go through a simple arc:
- Learn to do your job well
- Learn how to get your squad doing their job well
- Learn how to get your organization doing their job well
- Learn how to get an entire company doing their job well
When you get to thinking about org and company, a simple framing to review as you examine a problem is what I’ll call the STEP framework:
Strategy: do we have a clear, coherent business and product strategy that creates the right decision-making guardrails for the teams?
Targets & Goals: do teams have clear goals that connect to the strategy, and are the goals aligned across teams and functions?
Execution & Decisions: are we executing well across the decisions we are making, the data we are using, how we are communicating, and how we are collaborating?
People & Org: do we have the right people on the bus, are they being managed well, and have we organized ourselves in a way that helps us accomplish our work?
(yes, it really should be STPE but that’s harder to remember)
In the case above, the issues were less about strategy and targets, and far more around execution and people.
Product Case Camp
If you’re senior in product, engineering or design (either at the executive level or working to break into the executive level), and find case-based learning interesting, you should consider Product Case Camp. This is a new program I’m running, where small cohorts will meet for an hour a week, every week, to discuss through complex, realistic scenarios. Topics will cover strategy, team effectiveness, and more. I’ll be leading the sessions personally. In other words, I’ve designed this to be engaging rather than scalable! I’ve just opened up applications and we’ll be kicking off the first cohorts shortly. You can learn more here.
Top image from Logan Fisher on Unsplash