Forecast, Plan, Commitment

At some point in your career, someone asked you when something would be done. You gave your best guess based on what you knew at the time. Then that guess showed up in a roadmap, a board presentation, a customer commitment. And when the date slipped (because of course it slipped, you barely understood the problem when you gave the number), you were held accountable for the "miss."

This is what happens when organizations conflate three things that are not the same: a Forecast, a Plan, and a Commitment.

A Forecast is a directional estimate based on current information. It is expected to change as you learn more. A Plan is more refined, reflecting a specific approach and carrying more confidence, but should still not be seen as a promise. A Commitment is what you are actually promising: the result of careful scoping, clear ownership, and real accountability. These three things belong at different points in a project's life, and treating them as interchangeable breaks the system that planning is supposed to create.

The damage shows up in how teams estimate. When every number you give gets treated as a Commitment, you stop giving honest numbers. You pad. You hedge. You refuse to estimate at all until you have more information, which means leadership makes decisions without the signal they need. Or you give a number you know is wrong, because the alternative is a conversation you don't want to have. None of this makes delivery faster or more predictable. It makes it worse.

The fix is shared language. When an organization has a common vocabulary for these three levels of certainty, something changes. A team can say "this is a Forecast" and everyone knows what that means: directional, subject to revision, not a promise. A leader can hold a Commitment with real accountability without accidentally applying that same pressure to an early-stage estimate. The distinction gives teams permission to be honest, and honest estimates are the only ones worth having.

I introduced this framework with a team I led and watched it shift conversations almost immediately. The question stopped being "will you hit the date?" and started being "what kind of signal is this, and what do we need to move it from a Forecast to a Plan?" That's a much more useful conversation.

Slow is Smooth. Smooth is Fast

There's a Navy SEAL training mantra: slow is smooth, smooth is fast. The idea is that under pressure, rushing introduces errors. And errors don't just cost time to fix. They create churn.

Churn is the work that happens because something else went wrong. The feature that has to be rebuilt because the requirements weren't universally defined or understood before development started. The decision that has to be relitigated because it was made on incomplete information. The bug shipped to production that is now blocking three other teams. Every one of those situations started with someone moving faster than they should have, probably because they thought it was the right thing to do. But the time they thought they were saving must be paid back, with interest, in the form of work that has to be done twice.

This is the mechanism behind the mantra. It isn't about being slow for its own sake. It's about recognizing that the shortcuts that feel like speed are often the thing that makes you slower. Skipping the code review because you're behind. Cutting the requirements conversation because you think you already understand the problem. Merging without running the tests because they usually pass. Each of these feels like a reasonable tradeoff in the moment. Each of them is a bet that the error you're risking won't materialize. And when it does, it rarely shows up alone.

Every time I've introduced readiness checklists and reviews into a delivery process, I get the same pushback: these checkpoints are overhead that will slow delivery down. In the end, the reverse is almost always true. By spending time up front discussing and planning, delivery improves. Cycle time is reduced, quality is increased, and timelines are more predictable.

The discipline of going slow is really the discipline of doing things once and doing them right. It means asking the question before you assume the answer. It means taking the extra hour to align before you build for a week. It means treating the review not as a gate but as the thing that keeps the next ten steps from going sideways.

Slow is smooth. Smooth is fast. Not because deliberate movement is faster than urgent movement in any given moment, but because the errors you don't make don't have to be fixed.

Work vs. Meta-Work

Have you ever had a week where you were genuinely busy the entire time and had almost nothing to show for it by Friday?

That's usually not a productivity problem. It's a sequencing problem. The reason it happens is that the Work, the thing that actually creates value, requires space and focus that don't just appear on their own. And when that space isn't protected, you end up spending your time on everything around the Work instead of the Work itself.

I call this the difference between the Work and the Meta Work.

The Work is whatever creates real value: the deliverable, the decision, the insight that didn't exist before. It often requires deep thinking, but depth isn't the point. Output is. And real output rarely happens in ten-minute windows.

Meta Work is the overhead that makes the Work possible: triaging email, organizing your to-do list, deciding what order to do things in. Not the output itself, but what points you toward the right output. It's necessary, but it doesn't require depth.

Conflating the two is how you end up busy all day and behind on everything that actually requires you. An inbox at zero and a well-organized task list feel like progress. And they are, but only if they're clearing the runway for something that needs the full version of your attention.

The solution isn't doing more of either. It's approaching them with different strategies. Meta Work can fit in the gaps: the ten minutes between meetings, the transition time at the start or end of a day. Work needs something different: protected blocks of time, often of at least two hours, claimed on the calendar the same way meetings are. If you don't put it there first, something else will fill it.

There's an AI angle here that I find useful. Meta Work is something I've started to outsource: let Claude triage, prioritize, organize, draft the administrative scaffolding. The Work is where I partner with AI rather than hand things off. The thinking still has to be mine. The research, the structuring, the judgment calls: I'm in the driver's seat, and the AI is in the seat next to me. That line between outsource and partner maps almost exactly onto the line between Meta Work and Work.

Don’t Be a Goldfish

Did you know that goldfish grow to fit the size of their environment? A goldfish in a small bowl stays small. Put it in a pond, and it can grow to be a foot long. Same fish, different container.

Work does the same thing.

Parkinson's Law holds that work expands to fill the time available for its completion. Give a task two hours and it takes two hours. Give it a week and, somehow, it takes a week. We rarely finish early. We find more to do.

This isn't laziness. It's a feature of how we're wired. When there's time left on the clock, it feels wrong not to use it. So we refine. We add. We polish. We revisit decisions we already made. And often, by the end, the thing isn't better. It's just more worked-over.

The trap is subtle because the extra effort feels productive. You're still working. You're still improving things. But past a certain point, each additional hour returns less and less value, and the cost isn't just time. It's the other things that don't get done because you were still polishing the thing that was already good enough.

One of the most effective defenses against this is timeboxing: deciding upfront how much time something gets, and holding that boundary. But even more powerful is defining what Done looks like before you start. In software development, we call these acceptance criteria: the specific, agreed-upon conditions that tell you when something is finished. A well-planned sprint uses both: time-boxed research tasks (spikes) capped by the clock, and implementation tasks (stories) capped by Done. When a team commits to what they can complete in a sprint, they're not just planning work against a calendar. They're creating their own boundaries to prevent endless iteration.

The discipline isn't to work faster. It's to size the container deliberately, define Done before you begin, and when you arrive, evaluate consciously rather than just continuing because there's still time on the clock.

Don't be a goldfish.

1-ear, 2-ear, 3-ear meetings

Not every meeting needs your full attention. Saying that out loud feels a little transgressive, but I think most people already know it's true.

I categorize meetings into three levels of engagement, and I call them 1-ear, 2-ear, and 3-ear.

1-ear means I'm half-present. I'm there in case something goes sideways, but I'm likely also doing other work. One ear open for my name or something that sounds off the rails, but most of my attention on other work. Status updates I've already read. Meetings where I'm a courtesy invite.

2-ear means I'm engaged, but interruptible. I'm tracking the conversation, I'll contribute when relevant, but I might divert my attention briefly if something urgent comes up. Technical discussions, backlog grooming, design reviews: the meetings where I'm a participant, not the driver.

3-ear means I'm fully there. Body, mind, and spirit. No multitasking, no glancing at Slack. 1:1s, retrospectives, difficult conversations. These get my whole self.

The reason this framework matters isn't just personal productivity. It's about shared language. When a team has a common vocabulary for this, you can say "I'm going to 1-ear this meeting" and people know what that means. You can design meeting agendas around it. You can stop performing attentiveness in meetings that don't require it, and actually show up fully in the ones that do.

Since the world shifted to a primarily virtual model 6 years ago, I've observed a particular challenge in virtual meetings: the tool you use to attend is the same tool that interrupts you. Research, including a well-known study out of the University of Essex, has found that in a physical setting, having a phone or other technology in view, even untouched, reduces relationship quality, trust, and empathy during meaningful conversations. Now that most meetings require us to use that technology as the tool of engagement itself, a true 3-ear meeting requires not just presence, but significantly more intentionality.

Planning vs Iteration

Every time I've walked into a quarterly or annual planning cycle, I've heard some version of the same pushback: "We're agile. Don't we only need to plan the current sprint?"

Contrary to that instinct, I've found that the question isn't whether to plan — it's what kind of goal you're planning toward.

The skateboard metaphor is one of the most useful things agile gave us. Instead of building a wheel, then a frame, then an engine, then a car, you build a skateboard: something that works now, even if it isn't the final thing. You iterate from there. Skateboard to scooter to bicycle to motorcycle to car. At every step, you have something functional. At every step, you can course-correct.

It's a good metaphor. For a specific kind of goal.

There are two types of goals here, and the skateboard metaphor only works for one of them. "Go faster" is the first type. Every iteration optimizes for "moves efficiently." The decisions are locally reasonable at each step. You might end up with a car. You might end up with a boat. Both are coherent answers to that question.

But what if your goal is "get to the moon"? That's an entirely different type of goal. You might be able to iterate from a skateboard to a rocket. But without longer-term planning, you're just as likely to end up with a submarine.

Some goals require planning. Not instead of iteration, but to give it direction. A longer-term plan tells you what to optimize for at each sprint, and that's rarely the same thing at every stage. You might be proving a concept in month one and building for reliability in month six. Without that plan, every sprint defaults to optimizing for whatever feels most urgent. Agile is a method for how you build, not a substitute for deciding what you're building or why. "We're agile" is not a strategy. And it's not an excuse for skipping the work of figuring out where you're actually trying to go.

The teams I've seen struggle most with this aren't the ones who iterate too slowly. They're the ones who iterate confidently in the wrong direction, sprint after sprint, because no one ever pointed at the moon.

Effective Retrospectives

Here's a question worth sitting with before your next retrospective: do you know what problem you're actually trying to solve?

Most teams don't. They run a Start/Stop/Continue and walk away with a list of action items that feel productive in the moment and quietly die before the next sprint. Not because the team didn't care, but because they skipped the step that makes any of it stick.

Start/Stop/Continue is a solutions framework. "We should stop doing X" is an answer. But to what question? If the team hasn't agreed on what dysfunction they're actually observing, you can't know whether the fix will work, or even whether you're fixing the right thing. So the same items come back next sprint. And the sprint after. The format doesn't generate new ideas; it generates familiar frustration on a two-week cycle.

Effective retrospective improvement follows a direction. You start with effects: what are we actually observing? Not how do we feel, but what do we see? Where is delivery unpredictable? Where are we working hard but not shipping? Where is trust visibly low? From there, you trace back to causes: what practices, habits, or absence of habits are producing that pattern? Only then do you reach for changes: what would actually move the thing we named?

The framework I use for thinking about software delivery has two categories: Attributes and Tools. Attributes are the observable effects of how a team is working: things like Transparency, Alignment, Focus, Quality. Tools are the levers that produce those effects: ceremonies, processes, practices, norms. Retrospectives are where teams reach for Tools. The problem is they often haven't looked carefully at their Attributes first.

A retrospective structured around this runs three questions in sequence: What Attributes are we seeing? Which Tools are contributing to them? And what Tool changes would actually move an Attribute? Start/Stop/Continue belongs at question three, after the diagnosis, not instead of it.

The teams that improve aren't the ones with the most action items. They're the ones who can name what they're trying to move, and who check after a few sprints whether it moved.

My Eisenhower Matrix

I know I'm overwhelmed when I start living and dying by my to-do list. Over time, I've learned a flat list just doesn't work for me; there are too many variables it can't hold: importance, urgency, dependencies. My solution is an Eisenhower matrix: a 2x2 grid that sorts work along two axes: urgent vs. not urgent, important vs. not important. The four quadrants tell you what to do first, what to schedule, what to delegate, and what to drop.

In the past, I've built versions on a whiteboard and in tools like Mural, Miro, and Figma, each version with its own drawbacks. With my recent partnership with Claude Cowork, it made sense to try building the version I actually wanted inside that tool. The result is a visualization I'm able to iterate on both structurally as well as with the content.

The tool I built colors items by category, so at a glance I can see if I'm behind on items related to setting up my LLC or if I need to schedule an entire day for writing content. Items are manually draggable and Claude can give me feedback on if it thinks that any classification adjustments need to be made. Hovering any sticky lights up its dependencies: what blocks it, and what it blocks. So I never put a decision to be made into the DO FIRST quadrant when it's blocked by multiple dependencies. And the urgency and importance axes are continuous, not binary. Something can be a little important, or moderately urgent. The classic 2x2 removes that nuance.

That last part is what I keep coming back to. We've been using Eisenhower matrices for decades inside the constraints of paper, whiteboards, and template-bound canvas tools. Four quadrants because that's what fit. No dependency lines because the medium couldn't hold them without creating extraneous noise. Now those constraints are gone, and the question changes: what would the tool look like if you could actually build it for the way you think?

That's what Cowork does. It doesn't give you a better template. It gives you the runway to build the tool around your work, instead of forcing your work to fit the tool.

Types of Change

When someone tells me their organization is suffering from "change fatigue," it sparks my curiosity.

In my experience, the term "change" is often a conflation of two very different things, and it's important to distinguish between them:
- Working on new things: adding initiatives, shifting priorities, taking on more.
- New ways of working: changing how your team operates, communicates, plans, and delivers.

Too much of the former exhausts people through volume and context switching. Never being able to fully finish a project because there are new priorities, not having the ability to focus and deliver quality results. This is what drives people to confusion and burnout. The mitigation: ruthless prioritization, protecting focus time, and being honest about what you're asking people to stop doing before you ask them to start something new.

Too much of the latter, done poorly, creates skepticism. You asked people to work differently, it didn't actually make their work easier, and now they don't believe you when you say the next change will. If you're genuinely trying to shift how people work, the most common mistake I see is not allowing the change management curve to settle into a new baseline before layering on the next initiative. Adoption takes time. Integration of new norms takes time. Skipping that step doesn't accelerate transformation. It just creates the conditions for the next round of fatigue.