A Career Altering Experience

One of the most formative experiences in my career was working for a leader who did the hard work to shape a couple of workstreams, assign owners, and, most importantly, push us hard to build good habits and tempo. It wasn’t easy, by any means. We operated this way for a full year, and the results were incredible (and personally very rewarding).

And I’m not the only person who feels that way. Whenever I chat and catch up with my old team members, inevitably someone will say something like, “Hey, is it just me, or was working with [leader] one of the best experiences of your career?” and someone will chime in, “Yes!”

(Note: Thanks from all of us.)

That year still shapes how I try to approach things today.

I Didn’t Fully Appreciate…

I say try, because it is hard. I never fully appreciated at the time how hard it was, especially when it comes to:

• The advocacy they must have been doing behind the scenes to defend how we were working, and to advocate for our work when it didn’t produce immediate results

• The patience to keep modeling good habits and to coach us back into a zone when things diverged.

• At the time, I did not realize how much of that shaping was discovery work. The lanes were not obvious upfront. They were co-designed with the team, argued over, tested, and revised. It was messier than it looked from the outside.

So importantly, they let us be the heroes in our own stories, instead of pulling all the air out of the room and making it more about them (they certainly could have, and a lot of the credit would have been warranted).

It Is Hard

A lot of leaders start the quarter or year strong, like New Year’s resolutions. It lasts a couple of weeks, and then things drift. Mental models diverge. People avoid the hard conversations and elephants in the room that have gradually bubbled up and accumulated. Or they freak out and make an ad hoc stab at reining things in (”Oh no, it is mid-quarter, we need a plan!”).

I’ve certainly let this happen at times. I’m not immune. Keeping a team “working small and thinking big,” moving that rolling cone of uncertainty down the tracks, is hard. You are constantly needing to course correct (without over-correcting and trying to steer against the drift). You need to sense and respond to the current terrain, while keeping future paths in soft focus.

More Details

I remember asking them at a time, filled with early-career naiveté, something like, “Is this a framework, or something?” Paraphrasing from what I remember:

No, just stuff I picked up along the way. It really is about the lanes, though. You have to break down the right lanes.

They can’t be too vague, but they can’t be too specific. Ideally, they are relatively independent. They should last a while, but you need to be willing to reshape the lanes or make the hard decision to retire one or pause it. They need owners as well—one or just a couple. Once you’ve got the lanes sorted out, it is really about the right habits. What are you going to do this week to move things forward? What happened last week? What are your near-term goals? Longer-term goals? What are your KPIs, and what can you realistically move? What’s getting in the way? It is pretty simple, actually. Most important: talking about it as a team or team of teams. Making decisions together.

We ran the whole thing out of a single doc. Every week, the team would copy forward last week’s lanes and a couple of the columns, then add some stuff. It was terribly manual, but I think that was the point. Manually pulling it together forced you to think about it, and then talking about it together helped you calibrate, decide, and leverage the hive mind.

What I also did not appreciate then was that arriving at the lanes was itself part of the practice. It was collaborative, iterative, and sometimes frustrating. The first version was never the right version. The learning happened in the arguing, the reframing, and the small adjustments over time.

Wait, Everyone Does That!

In my current role, I meet with hundreds of teams and companies to explore exactly how they work, and have collected hundreds of versions and variations of this type of doc. I see how common it is. Back when I first experienced this, I was too green to know how relatively “standard” the idea was, but also how hard in practice it can be to mobilize humans to “stick with” the program and not break the chain, and let the whole thing slip into a performative (or zombie) process. It is like we invent all sorts of reasonable excuses for why it doesn’t make sense, or why it’s OK to try it and stop.

I let this leader and some of the teammates read this post, and pass along any comments, and the leader in question added a comment here:

Tell people that even we slipped into that, when I lost influence with X, and I kind of gave up on my own promotion. I also knew things were winding down, and I was psyched that we’d all find new and exciting things to do. While I would say I’m pretty good at getting this going, I’ve also failed to get it going.

Another ex-team member who has gone on to awesome things added a reminder that:

As you get more senior, the lanes get broader, and your distance from the lanes where things are actually happening gets further. The skills partially translate, but it becomes more about leading people who lead people who lead lanes. But you can’t lose your ability to relate to the people in the thick of it, and operate and understand at that level. Plus, you realize that not all lanes are created equal. You’d never approach a 0/1 effort with 0/1-like lanes the same way as you run something later on.

There are so many ways to pretend you’re doing this, pretend you’re making progress, pretend you’re “aligned,” and pretend your lanes are coherent. It is also so easy to prematurely converge and put some things out there because you just want planning to go away so that you can go back to the real work. Operating under the radar can sometimes feel safer and more productive.

Frameworks…

Another observation is that many frameworks and practices flirt with the core principles here—work small and think big, ownership, shaping the lanes, balancing stability and meaningful levels of detail, etc.—but they pretend things are a lot more stable and repeatable than they really are in practice.

You can’t break everything into clean tickets. Goals don’t always neatly align with quarters. There are tons of work, goal, milestone, problem, solution, opportunity, blah blah blah shapes to deal with, and like the quote above, no way you’d treat them all the same way. It saddens me that so much of the spirit of Agile, which I find very consistent with these ideas, became “training-wheel-ified.” All the important and hard stuff got replaced by quirky little frameworks, named practices, named roles, etc., under the banner of teaching and somehow solving the “predictability” challenge with “the business” vs. doing the really important (and hard) things.

You can put whatever label on what you’re doing, but at the end of the day (as dumb and cliche as it sounds), it is about what you do, what you change, what happens, and what you learn.

Lanes Of Lanes

I spent the last couple of days working with an inspiring team at a big enterprise. Thanks if you’re reading! It was an incredible experience.

One thing that struck me was this fascinating mix of various cascades and mental models for “laddering,” and then the fractal concept of lanes repeating over and over. Some lanes were more project-like, program-like, or product-like. Some were wider and narrower, risk profiles all over the place, but that was where the real work was happening. What’s the context, what is the intent, what are we doing now and next, a softer focus on later, and what routines do we have in place to calibrate what everyone is sensing?

That continuous activity at multiple levels of the org is what gives you that ability to sense what is “actually happening.”

We see this in how customers use Dotwork as well. There are standard, as a leader proudly explained, “boring” OSes, and really cool, quirky OSes, but the magic is in the routines and sensemaking. The goal isn’t the perfect rollup. It is the right resolution for the right discussion, and it allows jumping up and down in elevations when needed to find the lanes in question. “Layers” of a value pyramid are less objects that “roll up” than they are frames, lanes, and perspectives.

The Here And Now

I wanted to end on a more philosophical note.

Looking back on this experience was a good reminder that this is tough stuff. It is human stuff. We can hold ourselves accountable for shaping the “right” lanes that are somewhat durable yet spiky and strategic, but then also surrender ourselves to the idea that, especially if things are working, all lanes change and eventually go away. We have the agency to spend our time doing things with intention and a nice balance of urgency and thoughtfulness. Still, we can surrender to the rolling cone of uncertainty and the beauty of the different futures that might emerge.

Finally, the opportunity to be with a group of people and get into the zone like this is not a given. Sometimes it can feel fleeting and out of reach during our careers. But when you have the opportunity, and you can help foster that opportunity, then seize it!

Basics

So how do you “do” this lanes thing? I’m sure you’ve already been doing something like this, but at the risk of not explaining it:

1. Define a small set of lanes (3-5)

Not too many. Just the main drivers and levers that seem capable of moving things forward. Spend time agreeing on the shape of each lane, including risk profile, complexity, experimentation friendliness, and the kinds of practices it likely needs. Look for lanes that are stable enough to get into a groove, but not so rigid that they cannot evolve when reality shifts. Depending on your role you might be defining these at different “levels”.

2. Write a short intent for each lane.

One or two lines. Direction, not work. Something that conveys strategy and purpose without turning the lane into a task list. The detailed work lives elsewhere inside the lane, where actions and changes get tracked week to week. This separation helps avoid confusing motion with direction. Remember, you’ll be returning to this every week for a while (hopefully), so make it good.

3. Put real ownership on the lanes.

Usually one to three people. If there are multiple owners, they need to commit to genuine co-ownership, not ceremonial representation.

4. Bling out the lanes with just enough information to reason well.

Clear near-term work. Metrics that can be influenced in the near term. More directional, lagging signals, such as goals, risks, and current value. Always include what is being done this period, along with what was carried over. Over time, this becomes less about documentation and more about learning to see drift early.

5. Keep the lanes in one shared place and copy them forward each cycle.

No clean slate (unless you are a completely new team). The migration itself becomes part of calibration. Carrying things forward forces attention on what changed, what stalled, and what disappeared—keeping history available matters more than most expect.

6. Review frequently and plan deeper resets less often.

Weekly or biweekly touchpoints keep things honest. Occasional deeper reviews create space to see lanes in the context of bigger lanes, re-check assumptions, and reset if needed. Periods of divergence and convergence are normal. The shape of lanes and ways of working should not be expected to remain constant. When drift appears, do not wait for the big reset. Adjust in the moment.

7. Work with a depth of field mindset.

Hard focus on what must move now. Soft focus on what lies ahead. Awareness of the rolling cone of uncertainty helps guide tradeoffs. Some lanes are project-shaped. Others are more open-ended. Both are valid as long as each lane continues to earn its place.

8. Refactor, pivot, or retire lanes as part of ongoing practice.

Some lanes stay stable for a long time. Others change shape as understanding deepens. The point is to keep adjusting so the lanes remain useful.

Before I jump in, I wanted to say thank you for encouraging me to keep writing. I published my first post on Medium just over a decade ago. TBM has been going since January 2020. Because of the writing, I’ve had the opportunity to interact with so many interesting people around the world. Hopefully, the writing continues to be helpful in some way.

I was in a discussion recently about Strategic Portfolio Management (SPM), and I asked what turned out to be a surprisingly uncomfortable question: if the people responsible for strategic portfolio management cannot design the organization, shape the strategy itself, or make actual prioritization decisions, what are they actually managing?

Why aren’t leaders managing the portfolio?

Does this just reinforce the business/tech divide?

The response made sense:

“So I don’t see SPM as ‘managing the portfolio’ in the financial sense. It’s more like maintaining the map: clarifying where resources are going, where bets are accumulating, and where the system is overcommitted, and then creating the conditions for leadership to intervene if they choose to.”

But the question stuck with me.

It sent me down a path of reexamining how we talk about portfolio management in software product organizations, and whether the metaphors and assumptions we rely on still hold. Portfolio management language carries a set of hidden assumptions. It assumes assets can be compared, traded, rebalanced, and adjusted without fundamentally changing the system that holds them. In finance, this is often true. In software and technology, it rarely is.

To understand why Strategic Portfolio Management so often feels awkward or incomplete in technology organizations, we need to start with two basic concepts from finance: liquidity and fungibility.

Liquidity and Fungibility

For portfolios of assets, we use the terms liquidity and fungibility to describe how easily assets can be converted into cash without materially affecting their price, and how easily investments can be exchanged for one another or rebalanced across the portfolio.

• Liquidity = ease of converting to cash

• Fungibility = ease of substituting or reallocating value across assets

Liquidity and fungibility exist on a spectrum, not as binary properties. Consider the range between large-cap equities and vineyards.

• Publicly traded large-cap equities (e.g., S&P 500 stocks) are highly liquid and highly fungible, unless your employer, your lawyer, or the SEC has other ideas this quarter.

• Real estate is less liquid and fungible, but you can still sell a unit, change tenants, refinance, or hand the keys to a property manager without redesigning the asset.

• A consumer goods brand portfolio sits somewhere in the middle of the liquidity–fungibility spectrum. After launch, brands and SKUs can be scaled up or down, divested, licensed, reformulated, or sunset. Capital and attention can be reallocated with meaningful (but not instantaneous) effects. Brands aren’t fungible, but they are modular enough to rebalance over time.

• With a vineyard, any rebalancing of the vineyard portfolio involves multi-year, largely irreversible changes to the land, vines, labor model, and production cycle.

These concepts—liquidity and fungibility—will come in handy as we try to wrap our heads around strategic portfolio management in software and technology.

Two Strands

There are really two historical strands feeding into what we now call Strategic Portfolio Management, and each makes specific assumptions about liquidity and fungibility.

First, there is the strand that emerged from centralized IT.

In this model, a single IT organization served demand from across the enterprise, built systems on behalf of the business, and then ran those systems over long horizons. Portfolio management here focused on intake, prioritization, funding, sequencing, and load management within a shared, constrained delivery function.

Assumptions: Systems are bought, configured, run for long periods, and replaceable. Improvements are capitalizable, while “running” the system is treated as an operating expense. IT labor is largely fungible and can be reassigned across initiatives.

Second, there is the strand that emerged from manufacturing and consumer goods.

Here, portfolio thinking was applied to brands, products, and SKUs: deciding what to launch, scale, sustain, reformulate, or retire. These portfolios assumed partially modular assets, recognizable lifecycle stages, and the ability to reallocate capital and attention over time without fundamentally redesigning the organization.

Assumptions: Products and brands are modular assets with lifecycles. Investment can be reallocated over time through capital, capacity, and marketing decisions.

The trouble starts when these assumptions are applied wholesale to software-centric, team-centric, and platform-based organizations, where rebalancing is far more path-dependent than either lineage anticipated.

Lean Portfolio Management

Imagine you are a self-respecting lean aficionado who observes the mess caused by the centralized IT model. “This is madness!” The system is overloaded. Things take years to reach customers. You have dependencies everywhere. There’s no rhyme or reason for how people are organized. The business is frustrated as hell and considering outsourcing everything. There’s no FLOW. The company just lobs projects over the wall, and the poor teams are swamped.

What do you do?

• You make the work visible.

• You limit WIP so things can actually finish.

• You stabilize teams instead of constantly reshuffling people.

• You organize around value rather than around functions.

• You try to shorten feedback loops.

You restore flow. But flow alone is not a strategy.

OK! So what do you do next? Time to get strategic.

Instead of thinking about projects, initiatives, or programs, you start linking them to company strategy. You frame decisions on where that flow goes, to strategic decisions and investments.

If project managers manage the delivery of discrete pieces of work, program managers manage the coordination of related work and dependencies, and project/program portfolio managers manage the selection and sequencing of initiatives, then, by extension, strategic portfolio management involves deciding which strategic investments are allowed to consume the organization’s limited flow.

But note that this is still based on some underlying assumptions:

1. Flow can be deliberately redirected without fundamentally reshaping teams, systems, or architecture.

2. Strategic investments are substitutable, so increasing one and decreasing another is a meaningful move.

3. Capacity is universally reclaimable, and stopping work reliably frees it for reuse elsewhere.

4. Rebalancing is reversible, rather than locking in long-lived consequences.

5. Strategy can be expressed primarily through allocation, not through organizational and product design.

Lean Portfolio Management clearly starts down the path of acknowledging low fungibility and limited liquidity. By stabilizing teams, funding long-lived value streams, limiting WIP, and bringing work to teams instead of moving people to work, it implicitly rejects the idea that labor and teams are easily interchangeable.

In that sense, it makes a real break from the centralized IT model.

Where it stops short is in what it still treats as liquid. Rather than assuming people can be reshuffled, it assumes that flow can be redirected. Strategic change is framed as reallocating capacity, funding, or initiative mix within stable structures. LPM moves fungibility out of people and into flow, but flow itself is far less liquid than the portfolio metaphor suggests.

“Product” Portfolios

In technology product-centric organizations, you don’t hear about “portfolios” as much, even when there are lots of products or lots of product areas, product groups, and product teams. Why?

In technology product-centric organizations, products quickly become entangled with teams, architecture, data, operations, and customer workflows. The product is a long-lived socio-technical system. Shifting investment is slow and risky, and stopping a product rarely frees capacity in a clean, reversible way.

This doesn’t mean, of course, that finance and executives in software and technology companies aren’t making portfolio-level decisions. They absolutely are. They invest more in some product areas, put others on ice, stop funding certain bets, start new ones, and sometimes reorganize to align teams with strategy better.

The difference is where that work lives.

In product-centric software companies, these decisions are not handled by a separate “tech” PMO or portfolio function acting as a buffer between the business and “delivery.” They are part and parcel of product leadership itself, and they sit directly with the executive team. The people deciding strategy are also accountable for how teams, products, and systems evolve. In other words, there is no clean separation between “the business” and “technology.” The portfolio is not something managed between the two. It is the business.

Strategic investment decisions exist, but they are embedded in product leadership and organizational design rather than abstracted into a standalone portfolio layer. Portfolio metaphors imply a level of liquidity and fungibility that simply isn’t there. What looks like portfolio management is, in reality, continuous product stewardship and executive judgment about where to place and sustain long-term bets.

The job of leaders IS implicitly portfolio management.

Note: This isn’t to suggest that so-called “mature” technology product-centric organizations are somehow immune to dysfunction. They aren’t. Underinvestment in platforms is common, everything gets labeled a “product” even when it clearly isn’t, critical work gets starved while flashier bets are overfunded, and the result can be a real mess. The point isn’t that these organizations have figured it all out, but that where the decisions are made is different. In “mature” product-centric software companies, portfolio-level decisions sit with product leadership and the executive team, alongside responsibility for organizational design, hiring, and long-term technical stewardship. Strategy, structure, and execution evolve together, for better or worse.

Strategic Portfolio Management

This brings us to the central idea.

Classic technology PMO and Strategic Portfolio Management functions are primarily concerned with understanding the corporate strategy, and deciding and reporting on how focus and capacity are allocated against it. Their job is to interpret strategic intent, translate it into investment themes or initiatives, and manage the distribution of the limited flow.

But when Strategic Portfolio Management stops being a buffer function within technology and instead becomes an explicit responsibility of leadership, its shape fundamentally changes. The primary levers are no longer just prioritization and allocation. They become organizational design, budgeting horizons, hiring and succession, team topology, and, when necessary, re-orgs. Portfolio decisions shift from routing work through a system to reshaping the system itself.

At that point, strategy, organization, and execution are inseparable, and portfolio management is no longer about aligning to strategy, but about actively co-creating it through structural choices.

Questions To Consider

• What is the true unit of allocation in our organization: projects, flow, teams, or long-lived systems?

• When we “stop” an initiative, what actually gets freed up, and what remains permanently entangled?

• How reversible are our strategic decisions in practice, not in theory?

• Where do we still assume fungibility that does not actually exist, whether in people, teams, platforms, or domains?

• Are our portfolio decisions primarily about reallocating work, or about reshaping the organization that does the work?

• Who truly owns portfolio decisions today: a PMO, a technology function, or the executive team, and what levers do they actually control?

• How often does changing strategic direction require organizational redesign rather than reprioritization?

• What parts of our “portfolio” are effectively vineyards, even if we talk about them like stocks?

• Where does portfolio management end and leadership responsibility begin, and are we clear about that boundary?

• If portfolio management disappeared tomorrow, would strategy execution collapse, or would it simply move back to where it arguably belongs?

Happy 2026, and thank you for reading the newsletter!

I’ve been thinking a lot about prioritization lately. I work at a startup where every second feels like a prioritization decision. There simply aren’t enough seconds in the day, and there’s an endless list of “should-haves” and “musts.” One thing I try to remind myself is that it isn’t about making perfect decisions, but about making marginally better, “good enough” decisions that help us move forward and avoid major crevasses.

To that end, I put together this list of prioritization anti-patterns and traps to watch out for. If we can detect and filter out a meaningful percentage of the duds and traps, it can make a big difference.

• Burning Down the House

• Too Much Time on My Hands

• Everybody Wants to Rule the World

• Just Enough Is Never Enough

• Running on Empty

• Dreamer

• Slow Ride

• Someday Never Comes

• The Logical Song

• Takin’ Care of Business

1. Burning Down the House

“I know none of this is strategic, but if we don’t deal with it right now customers are going to feel it. Let’s just get through this sprint and we’ll talk about the bigger stuff next quarter.”

Never finding a way to pull out of the high-urgency, low-to-medium-value zone. The company is always in full reactive mode, pulled by urgent things that would cause pain for customers and that would have material impact, but that ultimately aren’t big game changers. These often fit into the “table stakes” category.

The key point is that, in most cases, you can’t ignore these things. You have to do something. If you didn’t, it would be painful. But when you spend all of your time doing these things, you aren’t doing the work needed to avoid these problems cropping up in the first place, and you aren’t doing the work that meaningfully protects the growth of the business. The challenge is to do just enough to make the problems go away, while also figuring out how to make the investments that buy you breathing room or fund expansion in more sustainable ways.

Do This Now: Carve out a fixed slice of capacity (even 10–20%) that is explicitly protected from reactive work and can only be used on prevention, thorny problems, or leverage-building. Treat any exception as an escalation-worthy event.

2. Too Much Time on My Hands

“It wasn’t a failure exactly. We just… kept refining it. By the time we shipped, the moment had kind of passed.”

Medium-urgency, medium-value work where the team fails to find the 20/80, the 20% of effort that produces 80% of the results. They spend far longer than they need to, while avoiding early de-risking, early learning, and early value opportunities. This is the “middling” stuff. You sort of forget about it a couple of months later, or maybe only remember the first few early wins.

Looking back, you say things like, “I wouldn’t call it a miss, but we ended up polishing this way too much,” or “We took too long to get something into the hands of customers.” “It was OK, but in many ways it was more trouble than it was worth,” or “Looking back, the real value was in [some small aspect of the work], not necessarily all that stuff we did with the other 80%.” This is the type of work that expands to fill the available space. If you set a quarterly goal, somehow the work is wrapping up with a couple of days left in the quarter.

Do This Now: Force an early cut: define the smallest version that would let you learn something real in the next 2–4 weeks, and commit to shipping that no matter how uncomfortable it feels.

3. Everybody Wants to Rule the World

“Everyone agrees this is the top priority. That said, no one can really drop what they’re already committed to.”

High-value, high-urgency work. Everyone agrees there’s a real time element here, a window of opportunity to seize, and high confidence in the value. In many companies this ends up on something like the “CEO 10” because it’s high-profile.

Everyone understands how critical it is, or so you think. But the message doesn’t reach everyone. Teams are still juggling that work with other work. Different VPs are balancing their local priorities against the priority of the big thing. Everyone is down in the weeds worrying about overly precise estimates here and there, while senior leaders are wondering if “anyone got the memo about how important this is.” “We keep talking about how much of a priority this is, yet somehow I’m not sensing that we’re taking it seriously.”

At the core, leadership isn’t actually carving out the focus the effort requires. In fact, they’re tacitly encouraging practices that break it into small pieces and cause teams to lose sight of the big picture.

Do This Now: Pick one thing teams are explicitly allowed to drop in service of the priority, and say it out loud. If nothing can be dropped, the priority isn’t real.

4. Just Enough Is Never Enough

“We shipped it, which is good. But yeah, if we’d had a bit more time, it probably would have actually mattered.”

Perpetually doing “the bare minimum” and missing opportunities to capture the actual value. Teams either ship quickly and move on, or take a long time to ship and are forced to move on. They get something promising out there, but only capture 20% of the value. In a sense, with 20% more work they could have captured 80% more value, but the team was under too much pressure to move on.

Sometimes this is because everything takes so long that no one has any appetite to iterate. If they had de-risked and gotten something out earlier, they would have had more legroom. In other cases, teams are moving reasonably quickly. They’re skilled at “working small,” but no one is allowed to really “think big” and keep the effort going.

A variant of this is shipping things that are almost there, but never really tying up the loose ends with support, documentation, capturing early win stories, and so on. It isn’t always about pressure to move on, but rather a habit of not really closing the loop. The trouble, of course, is that this is a counterbalancing instinct to the 80/20 problem. Some teams spend forever polishing. Other teams never polish. The features end up with no paint and no sealant.

Do This Now: Before shipping, list the 1–2 follow-on investments that would unlock disproportionate value if the initial release works. Pre-authorize one of them so the team doesn’t have to “re-pitch” momentum.

5. Running on Empty

“We’re close. We’ve been close for a while. It’s just more complicated than we expected, and it’s hard to say what ‘done’ even means anymore.”

Death marches where no one seems able to explain why things are taking so long. They’re aimed at something valuable and urgent, but as time passes, the window of opportunity starts to close and the value proposition or potential ROI gently slips away. One defining trait is that there’s no obvious way to say, “Hey, we’re off track here.” These efforts often involve highly specialized technical puzzles and a lot of pride. No one wants to admit they’ve gotten stuck in a quagmire.

There are periodic “summits” to understand the state of things, but a couple of weeks later everything is somehow back to normal. Leadership teams often bring in an outsider to help wrap their head around it, and the results are similarly unsatisfying: another summit, the outsider sharing their findings, a new “solid plan” emerging, and so on.

Another key element is that these efforts tend to defy adding more people. When asked, “Can we add people to speed this up?” the answer is a confident “no” (for good reasons, in most cases). From a prioritization standpoint, these efforts become permanent fixtures on the roadmap. Other, more urgent things crop up, creating interruptions, but they 1) don’t take up enough capacity to really put pressure on people, 2) are often foundational problems that need to be fixed, and 3) slow everyone else down, even though no one can quite do anything about it.

Do This Now: Introduce a clear “off-track” signal: a date, learning milestone, or decision checkpoint where continuing requires an explicit recommit. If you can’t define that signal, you’re already stuck.

6. Dreamer

“Leadership really believes in this, so we’re protected. We’ll worry about how it fits with the rest of the company later.”

“Innovation” efforts that are lower urgency but high value. Choosing to nurture this work is often the right move. If you didn’t, you’d risk living entirely in the high-urgency, reactive, optimization domain. The CEO wants to see progress on X, so you see progress on X, and the team checks the box.

A couple of problems tend to show up.

One is that the organization tries to treat “innovation” as a project. There are no real opportunities to learn. There are no opportunities to relax governance rules, compliance, and so on. In other words, none of the ingredients for creativity exist. The teams simply aren’t given enough room to operate.

The flip side, of course, is the opposite failure mode: there are no enabling constraints. There’s no pressure to ship and learn. Teams build a bridge to nowhere, basking in the protection of senior leadership. There are also no real efforts to integrate the idea across the organization or to test the ability to scale it, which means the work “finishes” only when it hits the wall of reality (for example, “How will we support this?” or “How will we sell this?”).

Do This Now: Add one enabling constraint: a deadline to ship something real, a forced integration with an existing team, or a concrete scaling question that must be answered. Creativity needs forcing functions.

7. Slow Ride

“Yeah, it’s annoying, but everyone’s learned the workaround. It’s not blocking us — it just makes everything take longer.”

Imagine if Slack or GitHub went down once a day for a couple of hours. It would be the end of the world. Yet there are often areas of friction inside companies that impact everyone and slow everything down, and they get relegated to “tech initiatives.”

From a cost-of-delay standpoint, this work should effectively inherit the opportunity cost of everything it impacts. If the waste were visible, there would be an immediate meeting of senior leadership, maybe even the board. But because the impact is less visible, “qualitative,” mitigated by workarounds, and because a few high-profile teams are lucky enough to avoid the dependency and still produce results, these efforts get framed as lower urgency and lower value. It’s death by a thousand cuts. Nothing so severe that people quit or walk out, but cumulatively it has a massive impact.

Do This Now: Quantify the drag. Pick one workflow or dependency and measure how much time it adds per week across teams. Put that number in front of leadership and reframe the work as cost-of-delay, not “tech cleanup.”

8. Someday Never Comes

“We all know this would be huge. We just don’t have a clear enough solution yet to really start.”

The “shoulda but can’t” trap. If you ran a poll across the company, there would be strong consensus around an opportunity that could change the shape of the business. The problem is that no one can come up with a “solution” that feels high-confidence enough. “Everyone knows this would change the game, but we’re not sure how it would work.” Instead of thinking probabilistically, “OK, we’ll probably fail at a lot of things, but we’ll learn and gradually move the needle,” the organization treats this area as a far-off, aspirational opportunity that will be figured out “later,” once the higher-confidence work has been knocked out. The problem is that “later” never becomes today.

At Dotwork, we sometimes call these “forever problems,” because there’s undeniable value in solving them, but fear of lower probabilities seeps in. The result is that companies only approach these areas through walled-garden “moonshots,” rather than integrating them into a portfolio approach across teams. In reality, all teams should be thinking about how to assemble a balanced portfolio of risk, with some longer bets mixed in. When there’s a strong focus on “can’t,” leaders should spend real time figuring out how to remove the implicit or explicit blockers.

Do This Now: Run one low-cost experiment designed only to reduce uncertainty, not to “solve” the problem. Make learning the goal, not success, and explicitly budget for failure.

9. The Logical Song

“This one feels risky, so let’s focus on the thing we’re more confident in, even if we won’t really know until the end.”

Spinning up prioritization frameworks that include “confidence” for things like value and urgency, while missing the potential cost of increasing that confidence. Imagine an effort that’s genuinely open-ended. You’re not sure yet. It could be a game changer. It could land somewhere modest. But the cost of increasing certainty is low, and the path to learning is clear. Now contrast that with a high-confidence, middling effort where the assumptions are hard to test. You only really know when you get to the “end.” What gets missed is that confidence is not free. We need to take into account how easy it is to learn, to increase confidence, to reduce risk, and to collapse uncertainty early, not just how confident we feel at a single point in time.

Do This Now: Add a column to your prioritization that asks: “How cheaply can we increase confidence?” Favor work where learning is fast and reversible, even if initial confidence is low.

10. Takin’ Care of Business

“We didn’t really have anything small and useful lined up, so when we got blocked we just kind of… made something up. It kept people busy, but looking back, none of it actually mattered.”

Prioritization Tetris. This is only marginally related to prioritization, but many teams “pack” their timeboxes, quarterly goals, and plans based on the premise that, if the stars align, they’ll get everything done. Prioritization becomes an input into the madness.

The anti-pattern is not having a set of very small-batch items at the ready, and not making sure that work is generally accepted as moving some needle. Without this, teams end up inventing work on the spot, without much thinking behind it. Meanwhile, they could be “mopping up” slack in higher-leverage ways. The core point is twofold: loading teams up through prioritization is counterproductive, and if you intentionally give yourself more slack and flexibility, make sure you have small-batch work ready to go.

Do This Now: Build and maintain a small-batch “pull queue” of universally accepted, low-risk, needle-moving work. Make it visible and legit, so blocked teams don’t invent work just to stay busy.

Some prioritization related posts:

TBM 245: The Magic Prioritization Trick

John Cutler

·

September 30, 2023

Read full story

TBM 374: Strategy & Urgency

John Cutler

·

August 24, 2025

Read full story

TBM 351: The 4 Prioritization Jobs (And Why It Matters)

John Cutler

·

April 15, 2025

Read full story

TBM 384: Prioritization Starts With Strategic Prioritization

John Cutler

·

October 21, 2025

Read full story

I was recently talking with a CPO who asked their roughly 200-team (~2000-person) organization to put together a short biweekly report, made up of a direct update from every team, that they could scan.

There had been a surprising amount of pushback. Not because the report was difficult to produce, since most teams were already doing the underlying update work for internal team reasons, but because, for many people, it signaled micromanagement.

​“It sends the message that we don’t trust the teams.”

“It undermines empowerment.”

“We should only do this if leadership plans to act on the information.”

“It goes around managers and directors who need to add context.”

​I could sympathize with the team’s concerns. If the intent was to avoid real conversations, then the pushback was warranted. If the report were used to nitpick details or hound middle managers, that would also be a problem. But none of that was actually being proposed. Honestly, the CPO’s request felt reasonable to me, at least as described.

“For me, this is a form of me showing respect for our teams,” the CPO said. “I can only have so many direct conversations, and I don’t want to walk into those based on second-hand information or outdated context. This keeps me up to speed so that when I do talk with teams, the conversation is actually useful. It’s not a replacement for that at all. And it is not a replacement for me talking with my direct reports and skip levels.”

​What was really being resisted (I think) was the idea that a senior leader might stay continuously exposed to the messy reality of the organization without first having it filtered, summarized, and made safe. That was the big fear, and something I hear over and over. Teams are used to this kind of information being misused, and to having to gloss over reality when broadcasting updates upward.

​This got me thinking about Drucker and mission command. At what point did staying close to frontline reality stop being a leadership responsibility and become seen as micromanagement? What would be so wrong with a CPO maintaining a direct line of sight into the work?

​MBO and Mission Command

When Peter Drucker originally described management by objectives (MBO), the overlap with mission command was real:

1. Focus on outcomes, not tasks

2. Clear intent instead of micromanagement

3. Decentralized execution

4. Trust that people closest to the work decide how

5. Judgment over compliance. Objectives guide thinking, not replace it

Drucker’s original conception of MBO was closer to mission command than many later interpretations suggest. He described objectives as “direction,” emphasized decentralization as a way to extend leadership responsibility (rather than to shirk it), and grounded management in judgement.

​In its best form, MBO said:​

“Here’s what matters. You figure out how.”

“Leaders set intent, not instructions.”

“Judgment lives closest to the work.”

That’s very mission-command-adjacent.

​But in practice, and in direct opposition to Drucker’s teaching, MBO diverged from mission command. The language of objectives stuck around, while other ideas drifted.

• In mission command, intent is meant to be directional, and success is contextual. Judgement remains at the forefront. In MBO, targets often become contracts. Missing the number is considered a failure, regardless of the context. Chasing performative contracts and stale commitments devalues real judgment.

• In mission command, leaders are expected to remain continuously exposed to unfolding reality. Feedback is frequent and direct, and is used to tune intent in real time. Escalation in mission command is routine, expected, and safe. It’s not reserved for emergencies. In MBO, leaders often engage with results at review time or when something “big” has gone wrong and an escalation occurs. Teams are implicitly encouraged to handle complexity locally and escalate only when they can no longer cope.

• In mission command, accountability is grounded in trust and judgment. In MBO, it often turns into a reporting exercise. Teams learn to manage optics and explanations instead of sharing reality early and often.

Drucker himself later warned that MBO “works—if you know the objectives,” noting that most organizations mistake false certainty for clarity (HBR, 1955).

​In Tech…

In tech, we throw around words like “empowerment” and “agency,” but they’re framed primarily in terms of individual autonomy within a theoretically meritocratic system, not in terms of shared doctrine, operating mechanisms, or collective discipline. The implicit promise is that if you hire smart people and apply just enough management to let the nerds do their work, good outcomes will naturally follow. It’s a decidedly anti-process, anti-mechanism stance. It assumes judgment is hired for or “earned” through experience, rather than trained, reinforced, and protected over time.

​What’s striking is that many tech companies are a bit all over the place.

They espouse empowerment, ownership, and accountability, but don’t have time for practice, or “work around the work.” They ask for loyalty, yet people are often in and out before they really need to own the results of their work. They talk about “relentlessly experimenting on behalf of our customers,” but fail to turn that spirit inwards. They frown on anything that smacks of politics, bureaucracy, or process, but simultaneously rely on rigid filtering and implicit rules about escalation that make it unsafe to surface problems early.

You’ll often find companies with five to seven layers of management, but none of the cultural reinforcement those layers assume. The structure is there; the doctrine isn’t. You can’t expect judgment-based leadership to emerge in environments optimized for churn.

​Warranted?

Considering all of this, maybe the team’s pushback was warranted. They were correctly sensing that, in most tech organizations, the conditions for this kind of exposure simply aren’t in place. Without shared doctrine, safe escalation, etc., direct visibility feels like a threat.

​But that’s the more interesting question, isn’t it?

​What if those conditions could be put in place?

​What if staying close to messy reality wasn’t something leaders had to apologize for, and teams didn’t have to defend themselves against, but a shared responsibility supported by real mechanisms, rituals, and trust?

​

Nearing the big 400! As always thank you for your support. 🙏

A subscriber wrote me yesterday:

John, your recent posts have been too academic for my taste. Give me something actionable! Something I can use?

OK! And I need your help. 5 minutes max. Help me help you.

1. Below is an activity you can run with your team to spark a conversation about the “shape” of an initiative. Expect divergence. Expect debate. Expect conclusions like, “Wow, we’d better put in some work to understand that better.” I’ve had good luck with these questions, but they can be always be improved (see #2).

2. I’d really appreciate it if you could take the survey yourself (using a company initiative, from your perspective), so that I can improve the design of the activity.

3. Once I get feedback, I’ll roll it into the Prioritizer app somehow.

Help John Improve This

How to run the activity

1. Pick an initiative or a small set of initiatives.

2. Set ground rules. No judgment. Divergence is expected and useful.

3. Have each participant answer the questions independently (for each initiative).

4. Compare results side by side.

5. Discuss differences, surprises, and areas of ambiguity.

6. Decide what needs clarification, alignment, or further discovery.

How many teams need to be involved to make meaningful progress on this initiative?

1. One team working independently

2. One primary team with occasional input from others

3. A few teams involved with limited coordination

4. Multiple teams actively coordinating on shared work

5. Many teams tightly coupled and coordinating continuously

For how long do we expect this initiative to require sustained, active attention?

1. A short burst of focused work (1–3 weeks)

2. A sustained push over a few months (1–3 months)

3. Ongoing work across multiple quarters (1–3 quarters)

4. Long-running work over multiple years (1–3 years)

5. Enduring work with no clear end in sight (3+ years)

How does this initiative deliver value over time as work progresses?

1. Value is captured quickly and largely complete early

2. Value is captured early, with smaller gains from continued work

3. Value increases steadily as work progresses

4. Value is mostly realized later, after sustained investment

5. Value is largely delayed until a significant future point

Where does the greatest uncertainty affecting this initiative lie?

• Getting known work done reliably, including coordination and throughput

• Having or building the necessary skills, systems, or technology

• Finding the right approach or design to pursue

• Achieving the intended outcomes or impact

• Confirming this is the right problem or strategic focus

How early and often can this initiative be de-risked through incremental progress?

• Many opportunities to de-risk early and pivot freely

• Regular opportunities to test assumptions and adjust direction

• Some opportunities to learn and reduce risk along the way

• Limited opportunities to de-risk until later stages

• Most de-risking only happens near the end

How constrained is the environment this initiative will operate within?

• Clear goals, few meaningful constraints, and many degrees of freedom

• Mostly clear goals with some constraints, but room to maneuver

• Mixed clarity and constraints that require active tradeoffs

• Diffuse or competing goals with many constraints to navigate

• Unclear goals and tightly limiting constraints with little room to adapt

How sensitive is the value of this initiative to delays?

• Value drops sharply with even small delays

• Value declines noticeably as delays accumulate

• Value is somewhat affected by timing, but not critically

• Value is mostly resilient to delays

• Value remains largely intact even if delayed significantly

What best characterizes how we should approach this initiative?

• Mission-critical intervention. High urgency and high value. Leadership actively protects and unblocks.

• Urgent containment. High urgency with limited upside. Do the minimum to resolve the immediate issue.

• Careful optimization. Moderate urgency and value. Improve deliberately without over-investing.

• Future-oriented investment. High potential value, low urgency. Progress steadily with visible learning.

• Slack cleanup. Low urgency and low value. Address opportunistically and stop when returns diminish.

What discovery or research approach best fits this initiative?

• Whole-team discovery. The full team starts together and learns in real time.

• Core-team discovery. A small cross-functional group leads discovery, with frequent team involvement.

• Staged discovery. Initial research happens first, followed by broader team engagement.

• Focused pre-discovery. A small group does most research ahead of delivery work.

• Solo or specialist research. An individual or specialist explores well in advance of the effort.

Where does the primary decision authority for this initiative sit?

• Decisions are fully owned and resolved within a single team

• Decisions are mostly team-owned, with occasional external input

• Decisions require alignment across multiple teams or peers

• Decisions depend on approval or direction from leadership outside the teams

• Decisions sit largely outside the team and require senior or external authority

How aligned are we on the answers above and what they imply for how we proceed?

• Strong alignment. We share a clear view and can move forward confidently

• General alignment with a few open questions to resolve

• Partial alignment. Key differences need discussion before proceeding

• Low alignment. Conflicting views would lead to inconsistent execution

• No alignment. We need deliberate convergence before taking action