2026: The Year of Balance

How do you stay steady when you can't make the ground hold still?

I choose a word every year. I like it better than a list of resolutions because it can be both broad and specific. I can come back to it over and over again as a directional intention.

Previous words of the year have been Cultivate, Journey, and Launch. For 2026, I chose Balance.

You see, I spent the second half of 2025 burning the candle at both ends. Moving to NYC, work, theatre, travel, working out. Everything was at 100%, and I could feel myself burning out. Balance meant math to me: pull back to 80% across the board as an act of self-care. A couple of my theatre "kids" actually came over on New Year's Day and decorated my whiteboard with doodles of "2026: The Year of Balance." Those doodles are still there. I've kept them up as a reminder to myself.

Then in March, I left my corporate job and struck out on my own to start a fractional & consulting practice. It was scary and unscripted, and my tidy 80% plan did not account for this sudden change in direction.

While I was in the middle of the tumult, I reached out to my counselor for a few check-in sessions. At the end of our first session, he said, "I know this is hard, but you seem really balanced."

He had no idea that was my word of the year, but his comment totally reframed it.

I had been chasing Balance as distribution: how much of me goes where. He saw steadiness: a core that holds while everything under it shifts. I think of it now like a horseback rider whose torso stays even while their legs and hips move with the horse. Distribution needs circumstances to cooperate. Steadiness comes with you.

The uncertainty hasn't resolved, but I've stopped waiting for the ground to settle before I call myself balanced.

If you're standing on shifting ground right now, you may be steadier than you feel. It took someone else saying it out loud for me to see it in myself.

Raising the Importance Line

A mentee recently asked me for advice on how to be more effective. They have great ideas for how to improve the organization, but they never get to them because they're so bogged down in an endless list of urgent to-dos.

I've coached people (most often Senior Managers and Directors) through this situation countless times. We start by plotting out their current list of tasks, projects, and ideas onto an Eisenhower matrix: Importance vs Urgency. The pattern is almost always the same: Do First (Important & Urgent) is overflowing, everything in it is on fire, and you clear three things just in time for five more to land. Meanwhile those great ideas atrophy in Schedule (Important & Not Urgent), never addressed, always just out of reach.

People in that spot have tried working harder, tackling more in Do First, hoping that they'll clear it out and finally get to Schedule. The result is usually burnout and still not getting to those items. The trick isn't to do more, it's to raise your importance line.

This is the critical thing to remember: The axes on an Eisenhower matrix are continuous, not binary. Something can be a little important, or moderately urgent. So the boundary between Do First (Important & Urgent) and Delegate (Not Important & Urgent) is arbitrarily drawn. You drew it by deciding what to handle yourself and what to delegate. And you can redraw it by delegating more, strategically and a little at a time. Every time you hand off something that used to sit above your line, the line moves up and you have more space for the Schedule work.

In practice: examine the items that are sitting right at your current importance line, or just above it, specifically those on the urgent side. You're looking to identify work that's urgent and important enough to matter and small enough that a mistake won't sink anyone. Pick one of those and delegate it. With support.

The support is essential and can easily be overlooked. You have to stay close enough to catch a problem early and far enough back that the decision is still theirs. Think of it as coaching rather than a test.

Afterward, talk it through together: how it went, what they needed from you, what you'd each do differently. Next time something comes up at that same level of importance, you'll already know whether that person can handle it, and you can hand it over with a lot less hand-holding. Now your importance line has actually moved.

Do this enough times and you both grow. They're handling work that used to need you, which is how they get ready for the next role. And you finally have time for those great ideas to improve the organization.

Hear, Help, Handle

About ten years ago I sat in a new manager training and walked out with three words I've used ever since. They weren't part of the curriculum. They came from another participant, a manager like me, describing how she framed requests with her own team.

Hear, Help, Handle.

I wish I could remember her name. I've been using her framework for a decade and have never been able to credit her properly. Part of why it stuck, I suspect, is where it came from: the most useful thing I took out of that training was something the person sitting next to me was already doing.
It's how I ask people to frame a request when they bring me something. I introduce it in the first 1:1 with every new direct report, because it shapes how we work together from then on.

Hear means no action needed: a status update, or something they need to say out loud to someone with the context to understand it. Sometimes they want to complain, and that's a legitimate use of the time. I'm listening, not solving.

Help means thought partnership. This is where I coach: open-ended questions meant to guide them toward their own answer rather than hand them mine. They still own the problem, and they leave with a path they chose.

Handle means they've reached the end of their rope and need it off their plate. Sometimes that's the right call, and I take it.

What I didn't expect is how often the level gets renegotiated in the conversation, in both directions.

Someone asks me to Handle something and I'll steer us back toward Help, because working it through is what grows them, and taking it off their plate would cost them that. Other times someone brings me a Hear, and because I have context they don't, I know it needs to be a Help, or that it's already been Handled somewhere above us.

The label isn't a contract. It's a starting position that makes the real conversation possible.

It works upward too. I use the same three words with my own managers, and it saves everyone the guessing. It scales past 1:1s as well: a cross-functional team briefing their various leaders together can say which one they're asking for, and the whole room calibrates at once.

Not everything falls neatly into one of the three, and it isn't meant to. It's the foundation you fall back on when you aren't sure what someone needs from you, which is most of the time.

Improving Efficiency through Increased Slack

The instinct when a team is under a time-crunch is to push harder. Fill every hour. This feels like the right move. It is almost always wrong.

What maximizing utilization actually optimizes for is busyness. Everyone looks busy, everyone is busy, and yet things aren't moving. The reason is that utilization and speed are not the same thing. The metric you actually want to improve is cycle time: how long it takes a single piece of work to move from start to done. And cycle time gets destroyed when a system is running at full capacity.

Think about how a CPU behaves. At 80% capacity it runs smoothly — tasks get scheduled, work gets done, the system responds. Push it to 100% and something different happens. It starts context-switching constantly, thrashing between tasks, spending more time managing the load than processing it. Output actually drops. The same dynamic plays out on teams. A team running at full capacity isn't a team running at peak performance. It's a team that has no room to absorb anything.

Here's how it plays out in practice. Every developer is working on something. A high-priority item comes in. It waits, because there's no one to pick it up. Meanwhile, a developer hits a blocker — waiting on a design review, waiting on an API, waiting on a decision. Rather than sitting idle, they pick up something new. Now they're carrying two things. Neither finishes. The in-progress pile grows. The team looks busier than ever and the actual output has slowed to a crawl. Not because people aren't working hard, but because the system is full and nothing can move.

A useful way to picture this: imagine a team passing work to each other like balls. If everyone is already holding a ball, no one can catch a new one. Work stops moving. The solution isn't to throw more balls — it's to make sure someone always has a free hand. That free hand is slack. It looks like unused capacity. It is actually what keeps everything else flowing.

The counterintuitive truth is that a team with slack moves faster than a team running at capacity. Not because they're doing more, but because they can actually finish what they start, absorb the unexpected, and respond when something urgent arrives. Protecting that capacity isn't inefficiency. It's the mechanism that makes the whole system work.

What would it take to protect enough slack that your team could actually respond when something urgent comes in? And how do you make the case for doing less when the pressure is always to do more?

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.