TBM 257: How to Make the Case for Slowing Down to Speed Up

...when the train is barreling down the tracks

Let’s tackle one of the hardest challenges in product management, management, leadership, and life in general. As always, I don’t write about my full-time job, and any similarities are coincidental and can be chalked up to the basic fact that product is hard. Everywhere.

The age-old question:

How can we make the case for slowing down to speed up when we are already going slow, and when shutting things down and starting over is not an option?

You're bailing water, and somehow, you have to:

1. Keep moving (despite not moving all that fast).

2. Fix the boat.

3. Chart a new, hopefully more effective, course.

In this post, I will give you actionable tips to make the case for slowing down to speed up. To summarize the tips if you are short on time:

1. Value-Driven Focus: Ground your efforts in clear value; assess the value of speeding up. Use core financial metrics to forecast the potential impact of your work, even with ballpark estimates.

2. Leverage Blocked Work: Identify high-impact work blocked by current issues and use it to build urgency and rationale for your efforts.

3. Figure Out Your Accountability Game: Develop a governance strategy that de-risks the effort and shows regular progress. Own it.

4. Test Assumptions: Run experiments to validate key assumptions before pitching your plan. And then continuously de-risk.

5. Identify the Wedge: Find the specific enabling constraints that can unlock progress. Avoid Tetris playing and juggling. Find the approach that cuts through the fog.

6. Pitch the Approach (and the Wedge): Convey not just the value of the work but also how your approach and methodology will contribute to success.

7. Smarter Trade-offs: Be prepared to articulate and defend necessary trade-offs. Own the trade-off narrative before someone owns it for you.

8. Visibility on Main Roadmap: Include your work on the customer-facing roadmap, aligning it with core business priorities.

9. Pragmatic Solutions: Embrace practical, incremental solutions that demonstrate early value, even if they aren’t the ultimate or optimal fix.

10. Put your pride to the side. Yes, people will say they don't trust you. And yes, people will tell you you need to "prove" yourself. That's hard. But if you can put your pride aside and focus on progress, you'll silence the doubters over time.

If you’re game for more, read on.

First, let's dig into this complex problem.

Fuzzy Math

First off, the math is rarely simple. 

If an assembly robot on a factory floor is going 50% slower and making 50% more errors, then there's an exact point at which slowing the line and repairing the robot will make sense. Cut the check! Product work is different. In many situations, we don't know exactly if, how, and when our changes will impact productivity and sustainable outcomes. Delivering the next feature or hitting the current quarter's revenue target is crystal clear and tangible. The promise of eventually moving faster and generating a step-change in better outcomes—not unheard of feats—feels far off and abstract.

We're navigating a plethora of cognitive biases, including the status quo bias, myopia, sunk cost fallacy, action bias, anchoring effect, availability heuristic, etc. And, frankly, in many cases, we are reading the situation perfectly. Satisfying has served humans for a long time. If you've ever watched a big-bang refactoring or platform effort go off the rails, you are likely more skeptical of these projects. They are not a panacea; some businesses lose years of forward momentum when caught in the platform trap.

Default Strategies

When faced with the challenge, teams often default to one of four strategies:

• Let it Burn

• The Juggling Act

• The Process Fix

• Water Bailing Day

The details:

1. Let It Burn (and The Big Fix). Ignore the problem until the only option is a large-scale, high-profile project to fix the issue. The fix will sell itself at this point—no pitch is required. I'll always remember a leader telling me, "The only thing that will persuade people we need to do this is a multi-day outage!" They were right! Pro: Self-selling solution. Con: High risk and high cost.

2. The Juggling Act. The team attempts to invest just enough time to make some progress (or avoid further decay) while simultaneously making progress on "normal" work. Teams often accomplish this through some combination of 1) allocating a certain percentage to the task every sprint/period or 2) allocating a fixed number of team members towards fixing the deeper, long-term issue. The idea here is that you can turn the tide over time without sacrificing other outcomes (too much). Pro: Balanced progress (in theory). Con: Slow resolution and chance problems will worsen faster than you can progress.

3. The Process Fix. Sometimes used with The Juggling Act, teams attempt all sorts of process tweaks to free up additional time and capacity to fit it all in. "Can we cut scope here?" "If we parallelize this and serialize that, can we do A, B, and C?" The basic idea is that there's some optimal way to operate that lets a team take on even more work at any given time. Pro: You may find low-hanging efficiencies. Con: Risks chasing high utilization and making problems worse.

4. Water Bailing Day. A miniature version of Let It Burn. Teams engage in successive, reactive pauses (e.g., "tech debt months," "stability sprint," etc.) and leverage urgency to marshall changes into production. If you've ever been a part of these efforts, you know that mad scramble to get every fix you could think of "on the list" so you can use the air cover to get some things done.

These options translate to our personal lives as well. With many problems, we just wait until they get really bad, at which point we implement the big fix. With other problems, we try to make it all work and gradually dig ourselves out of the hole we're in while trying to keep—usually with a lot of struggle and reduced outcomes—all of our existing responsibilities and commitments. Sometimes, we do this with an expertly balanced schedule ("I'll clean the garage for 15m a day for the next year"), and sometimes we do this with elaborate "life hacking" tactics. 

And other times, we do the reactive juice cleanse—the resilience sprint—and then go back on our merry, or not so merry, way.

The Problem

The challenge with these options is that they all ignore the question of value. 

Why 10%? Why not 30%? 100%? If you slow down by 50%—and this slowdown impacts everything you do—could there be anything more important than addressing that issue, especially considering debt interest compounds? And why do teams beat themselves up over process tweaks, all to eke out tiny improvements, when the elephant is very clearly in the room? 

At least the Let it Burn approach provides a clear, albeit extreme, trigger point for taking action. When the system reaches the point of failure, there is no room for ambiguity regarding priorities. Oddly, despite the risks, this is probably the most strategic of the three options. It's the equivalent of the "humans will human," carbon sequestration, and nuclear fusion response to global warming—not my favorite, but at least definitive. Water Bailing is equally opportunistic but on a smaller scale.

This brings me to observe how teams advocate for these improvement efforts. Either:

1. They are impossibly vague, optimistic about benefits, concerned about, and swamped in the current reality. "We just have to do it!" "We just need to work down the debt!" "Everyone knows we need to refactor this!" "Everyone hates the codebase!" "No high-performing team in the world would EVER work this way!"

2. Or, they vastly undersell the benefits and don't do a great job making an actual pitch with a business rationale. I've observed teams spending crazy amounts of time working around debt fail to mention that time loss—even a swag at the time lost—when they propose working down the debt. Product managers are pitching that six months of building something to close one deal will magically apply to all other customers (a huge stretch). At the same time, developers are cautious to claim even a 5% increase in productivity or throughput and rate of value creation. Instead of people hearing the pitch and saying, "Can we give you MORE money to accelerate that?" the response is typically mild skepticism. 

Impossibly Vague and Optimistic

I appreciate the sentiment around the mix of optimism and "calling out reality" in #1. On some level, teams feel like they shouldn't have to "sell" things that are so obviously making their day-to-day work hard. But unfortunately, you do.

Vastly Undersell the Benefits

#2 is hard due to the abstract, one-removed, indirect nature of value in product development. Product is not like the robot assembly example. But that doesn't make forecasting impossible. What outcomes could the team have produced in the last year if it didn't need to navigate the drag? Where is the qualitative research—the specific daily frustrations, concrete examples of time lost, costly quality issues, etc.? I sense that the people who care enough about these issues often are skeptical of "just guessing," but you don't need to "just guess."

Imagine all the work that goes into making a prioritization justification for a measly product feature. Now compare that to the work that goes into pitching a multi-quarter (or multi-year) "slow down to speed up" effort. The latter can potentially up-level the whole org but is extremely risky. 

Teams spend hours debating the former, hours discussing the latter's architecture, and minutes debating the latter's actual value potential.

..And No Risk Mitigation

An extension of underselling and under-pitching (#2) is that teams can fail to propose any sort of "governance" (for lack of a better word) for the effort. Remember, the competition here is tangible output and near-term revenue. You are proposing a prolonged effort and asking leaders to forego those near-term results for something better in the future. How will you hold yourself accountable for staying on course? What leading indicators will show we're on the right track? How will you de-risk the effort early? How will you SHOW those de-risking efforts are worth it? What are the key risks? This can't be a blank-check game.

For example, a team taking on a big refactoring effort might legitimately need to do a fair amount of work before there are "clear outcomes." But what could they do every week to show incremental progress, even if it is qualitative (e.g., "we increased confidence that _________")? Or if the first task is getting monitoring in place, how many new data points can they view? What are they learning?

Without regularly showing your work and figuring out a structure/game to stay on course, you end up with successive, ungoverned, bigger batch "This Will Fix The Problem Once and For All" efforts that miss the mark and undermine trust in the team. 

It is no wonder that teams end up trying the juggling act (10%), process fixes, or just throwing up their hands and letting it burn down to prove a point. And it is no wonder leaders are skeptical of these types of efforts. Realistically, many of these attempts—no matter what approach you try—fail.

Making the Case

Building on the background above, here are the ten tips I give to product managers, engineering managers, etc., for making the case for slowing to speed up.

Ground the case in value.

You have to ground what you're doing in value. 

The number one thing that makes it difficult to make a case for slowing down to speed up is that people have no concept of what speeding up is worth. Sure, you might be able to ship some features more quickly, but what are those features worth? How are teams contributing to the sustainable and differentiated growth of the company?

 I always ask teams to look at some core financial metrics and then at least try to forecast how those metrics might differ when you do this work versus not doing this work. Engineers, especially, are hesitant to make these types of forecasts because their confidence level is not super high. But even ballpark estimates can help place this initiative in the context of other work. (Sidenote: the cost of hiring new team members because frustrated team members leave is a thing.)

Remember, a lot of feature work is similarly hand-wavy regarding longer-term impact. So, the bar is pretty low, and if you put some thought and care into what you're doing, you'll be surprised at the case you can build. When in doubt, ask yourself, 'What could we do if we were going faster? Or, what could we do if we were improving our decision quality and velocity and acting on those decisions faster?'

Bring some data! I'll always remember asking a senior engineering manager about the expected outcome of a refactoring effort, and they confided that team members were being slowed down 2x in their day-to-day work. I asked why they failed to mention that in their pitch, and the answer was, "Well, we didn't time it exactly, and we don't want people asking us what going 1.2x slower would look like."

Point taken, but come on!

Piggyback off of high-profile (blocked or slowed-down) efforts.

A super effective move is to find work blocked by this problem. What could be unlocked? In a sense, when you can find a dependency, your effort to slow down to speed up literally inherits all the opportunity costs of the work you are unblocking. 

In this case, you can piggyback on this work to build a sense of urgency. If that work is meant to generate a million dollars a month in revenue, and you can decrease the time it takes to finish that work from 12 months to 6 months, the work you're doing is the most important work that could be happening.

Describe how you will de-risk and stay accountable.

Imagine that you are the person funding and budgeting this effort. In no situation would you give a blank check to teams to work endlessly on one of these efforts. You might also realize that trying to get precise estimates and trying to thread the needle will also leave you playing the juggling act or falling into the process trap. Either way, you must develop a sound, appropriate, and context-aware approach to governance.

Basically, how will you keep this on track in an economically viable way?

Put yourself in the shoes of your CFO. Put yourself in the shoes of the people cutting the checks. Then consider the level of rigor you'll need to show your work, show progress, and de-risk when possible. Here, you want to give many opportunities for de-risking and pivoting. How will you hold yourself accountable and keep things on track? 

Design your dashboard FIRST.

Run experiments to address key assumptions.

Consider running experiments to explore what will be required and the progress you might expect before pitching. It's much better to walk into a pitch, describe the problem, define the value that could be unlocked, and then demonstrate that your team has experimented with its form of governance, explored the problem, etc.

I'm amazed at how many teams go in to make a pitch around this type of work, and they've not even tried to test the most basic assumption they're making. Test your assumptions!

Look for the wedge (and reject non-wedges)

I always urge teams to look for the wedge.

 When you're juggling and playing Tetris, you will find yourself navigating a ton of constraints. But when you identify the wedge, suddenly, things become much more feasible. 

An example of a wedge might be the team discovering an approach to refactoring that is much more tangible and will show more immediate results. Another example of a wedge might be a very clear enabling constraint; for example, anytime a team member encounters an instance of the problem, they can spend up to three weeks addressing it.

You'll know you've found the wedge when the team has a collective sense of relief. Similarly, realize when you're ending up with a solution that is not a wedge. You can just feel when an intricate plan will fall apart. It feels like an impossible Tetris game, and somehow, you've made the pieces fit, but you just know that things will fall apart. Trust your instincts there, and make sure you don't fall into that trap.

The wedge (and approach) is an important part of the pitch

Related to the idea of the wedge, realize that how you approach these efforts, how you show your work, and how you will make progress are as much a part of the pitch as the actual value and impact. 

In a sense, you must sell people on the wedge you've found. It may be counterintuitive to them. Their default place might be detailed project plans, estimates, etc. You're walking in there with a proposal that might be better but will seem foreign. So, you will need to take the time to explain how that wedge and enabling constraint will help move the effort forward.

I've found that when teams wrap their heads around the idea that how they approach the work is almost more important than the work, they become very creative in terms of figuring out how to bring everyone along for the journey.

Pick the right tradeoffs.

You're going to have to be smart about describing tradeoffs. 

People outside your team will have many mental models around the levers they can move. They might imagine you can trade off tiny bits of capacity for small progress. They might imagine that you can trade off quality and speed. 

And so what's going to happen is you're going to get a lot of questions from people who want to play the juggling act or tweak your process. You have to anticipate these tradeoff questions and have a persuasive answer that brings people along for the ride. 

So, for example, you might want to stress how continuing to build features on top of the old architecture generally adds a large multiple of work down the road and that the accumulated debt will delay future value out of proportion to the workarounds you're implementing now. Therefore, you're not linearly trading off results now for results later. It's a non-linear relationship. It's your job to frame the game in a way that respects the nature of your work but is also relatable enough to others so that they can wrap their heads around it.

On the "real" roadmap

Work as hard as possible to put this work on the customer-facing roadmap.

There's a strong tendency to want to keep this on a technical roadmap or some kind of parallel roadmap that the engineering team uses. In my experience, this rarely works.

Try to advocate for putting this on a customer-facing roadmap and explain how, ultimately, the work will benefit customers. It's harder but well worth it. Similarly, work through whatever vetting system, prioritization system, or sequencing system your org uses for that customer-facing work. That way, you're talking the same language. The same goes for taking part in all the rituals that the customer-facing teams take part in to get that visibility, to have that accountability, and to stay on people's radar.

Pragmatism FTW

When scoping these efforts, realize that the optimal solution is rarely feasible. You may need to incur some level of waste soon to get early shots of value and demonstrate the value of what you're doing.

This is hard when a lot of architecture and speccing is involved. Building out intermediary solutions and value generators may seem silly, but ultimately, getting people on board and rallying them around the effort will be important. 

This is where a lot of engineering-minded folks trip up. They either blanket defer to the business, letting any claims around short-term work guide what they are doing, or they get extremely stubborn around the solution that needs to be put in place and don't necessarily appreciate the day-to-day challenges of keeping a business moving forward. 

Try to channel your inner pragmatic, entrepreneurial-spirited self here.

Put your pride to the side.

You'll have to put your pride to the side in many cases. If your team has struggled with this for multiple quarters or years and you've lost a bit of trust with your stakeholders, you will be put under a microscope. 

That is going to seem unfair—no way around it. 

You likely have been telling people about this for a while, and now you're getting around to doing something about it, or you're trying again to do something about it, and people are giving you a hard time and talking about trust. They may say, 'Before you do this, you must build trust.' The key point is that you cannot let this get to you. However, you arrived at this point of distrust, and it is now necessary to forge a way forward. If you build up a reactive, defensive stance, it will permeate everything you do. You must seize the current reality and do your best to plot a feasible way forward.

Hopefully, this helps!

We will be covering some of these ideas in the workshop I mentioned at the top of the post. I appreciate all the support I've received over the years as I've tried different approaches to sharing and helping.