The stretch you can't point to

The stretch you can't point to

You worked 72 hours this week. Can you name three things that exist because of it? Take your time.

Picture one week: meetings, messages, a fire at 4 p.m. on Wednesday, a document finished Friday morning. You end it tired in the way that feels like proof you did something.

Now picture the next week. Same 72 hours, same coffee, same tired. This time, though, you can name three outcomes, one system you pushed until it either held or broke, and one win you actually said out loud to another person.

The hours were the same, but only one of those weeks left something behind.

Your manager writes your review from what's on the table. Busy is a feeling, and output is something someone else can see without you explaining it.

And the work that only lived in a conversation nobody wrote down, where does that end up?

The Request That Dies in the Inbox

The Request That Dies in the Inbox

You sent the email at 2:47 on a Tuesday. By Thursday you've refreshed your inbox nine times, drafted a follow-up, and deleted it. It starts to feel like you're asking for a favor.

They aren't ignoring you. They opened it, saw a question, and set it down. Questions take thinking, and they've got forty-six other things asking for the same thinking.

An approver does one of three things with your email: answer it, park it, or forget it. Questions get parked.

Some emails show up with the work already done and only need a yes or a no. That's a different load, and the person on the other end feels it.

If there's no date on it, there's no clock. Sometime loses to everything that has a date.

Meanwhile you turn into the one who chases, typing following up for the third time. It's a small cost per email and a big one across a year.

Then there's the harder case, where you're carrying the decision but not making it. Overstep once and the next request takes twice as long. Some leaders sign without reading, and some change the number. Nobody tells you which kind you've got.

How many requests does it take before you know which one you're writing to?

Your Case Is Already Being Written

Your Case Is Already Being Written

The work's done and the results are in, and it feels like nobody's building your case.

Somebody is, though. It's happening right now in hallways, in chat threads, and in meetings you weren't invited to.

There are really two versions going around. One has specifics: what you did and what it was worth. The other has an adjective. Reliable. Solid.

Adjectives come from memory, and memory shrinks fast. By Thursday, the Tuesday fix is already gone.

Meanwhile the other candidate walks in with a number.

So who's holding the pen on your version?

The Org Chart Keeps Growing. The Work Stays Broken.

The Org Chart Keeps Growing. The Work Stays Broken.

Another headcount request just landed on your desk. Before you sign it, pull up the org chart.

There are usually three handoffs between the request and the result. You hired two people last quarter and the mess is still there, it just has more names attached to it now.

Try timing one task through the process. It's often eleven minutes of real work, nine days to ship, and six approvals in between. For most of those nine days the task is just sitting there unopened.

When the new hire asks which handoff actually matters, they hear that's how we do it, which is really just where the explanation runs out.

So they learn the map by memory: who to ping, which thread to refresh, who answers faster before lunch. Six months later they're fast, but the speed lives in their head, and it walks out the door with them.

Someone built this process and chose every step in it. Old choices can be unmade.

Sometimes the volume really is there and you need the people. Sometimes seven steps could be three. The headcount number looks the same either way.

So who drew this process, and what were they trying to avoid when they did?

The Question Everyone Fumbles the Same Way

The Question Everyone Fumbles the Same Way

Someone at the table asks how you're using AI, and you say you're exploring it. Then everyone else says roughly the same thing.

Pay attention next time it happens. You'll hear we're looking into it, it's on the roadmap, or we're evaluating a few tools. Nobody names a task, and nobody names a number.

Every so often one person sounds different. Their setup usually isn't bigger. Their answer is just smaller and more specific: they draft proposals with it on Monday mornings, prep dropped from four hours to forty minutes, and they still write the opening paragraph by hand.

That's three sentences, and the room goes quiet for a second.

They said those sentences out loud before that meeting. More than once.

So if the question lands on you in ten seconds, what are you going to say?

The happy path is not the process

The happy path is not the process

You built a process. You documented it. You ran it once, twice, maybe three times, and it worked. You feel good about that. You have a SOP, a runbook, a "how we do things" doc that a new hire could theoretically follow. And for the next few weeks, that is true. The process holds. Everything cooperates. The input is what you expected, the people are in their seats, and the step count matches the doc. Then one Tuesday a vendor goes quiet, a team member is out sick, and the volume doubles because the client who was "maybe expanding" is now actually expanding. And the process you built for a world that does not exist is the only thing standing between you and a very expensive phone call.

A process is what happens when things go sideways

Here is the distinction I keep coming back to. A happy path is a sequence of steps that assumes every input arrives on time, every person is available, and every edge case stays on the other side of the fence. A process is what you do when one of those assumptions breaks. Most of the "processes" I have seen in operations, and I have been in enough of them to have an opinion, are happy paths wearing a process label. Twelve steps, zero contingencies. The doc tells you what to do when everything is fine. It does not tell you what to do when the input is double what you planned for, or when the person who owns step four is on a flight to Lisbon and their phone is dead. That is not a process. That is a script for a show with one cast member.

You do not need a simulation suite. You need to find the first thing that breaks

I have watched the same three failure modes show up over and over, and they are not exotic. You run the sequence with one person absent and see where the handoff stalls. You run it with double the input and watch which step starts producing garbage. You pull one step out entirely and see whether the next step even knows what to do. That is the whole conversation. Whatever breaks first is not a bug in the process. It is the design. It is the load-bearing piece you were too polite to question because everyone said it was fine. The fix is usually smaller than the fear, but you will not find it by re-reading the doc. You find it by watching the thing collapse in a controlled way before the client is watching.

The step you removed might have been the one holding everything up

And here is the part that does not resolve cleanly. Sometimes the thing that breaks first is the thing you should have removed. The step that everyone says is important is the one that has been quietly absorbing the slack from three other steps that should be doing their own work. You pull it out, the whole thing lurches, and now you have to decide: was that step load-bearing, or was it a crutch that made the other three steps lazy? I do not have a clean answer for that. I have seen both. The difference between the two is usually visible only after the fact, which is the whole point of doing it before the fact.

Good Work Goes Unnoticed

Good Work Goes Unnoticed

The work is solid. You shipped it, documented it, sent the update. And then silence. The quarterly review comes and your name isn't in the room where the decisions get made. You're not slacking, and you're not even doing bad work. But the mechanism that's supposed to carry your output from your desk to the people who allocate titles and budgets has a gap in it, and your work is falling through. I've seen this in companies from 40-person seed-stage shops to 2,000-person scale-ups. The pattern is identical every time. The work is fine. The plumbing is not.

Three Breaks, None of Them About Effort

There are three places this breaks, and none of them are about effort. The channel: you write your update in the Slack thread for your pod, and the person who sets your comp band is in a different workspace, on a different device, in a different meeting. The framing: you logged it as a task completion when the real story was that onboarding dropped from 11 days to 4. Same work, different weight. One is a line in a ticket log. The other is a number a CFO can drop into a board deck. The connection: you fixed the bug, closed the ticket, moved on, and nobody drew the line from that fix to the churn number the board actually watches. You did the work. The story never got assembled.

The Translation Nobody Owns

Here's the part that stings. None of this is a performance problem. The work was done, the quality was there. What's missing is a translation layer between what you did and what the person above you is trying to solve. You're speaking in the language of execution. They're listening for the language of consequence. And nobody in the org is bridging that gap, because the org was built to measure output, not to narrate impact. You're not invisible because you're bad. You're invisible because the system was never designed to carry signal upward. It was designed to carry tasks downward.

The One That Doesn't Have a Fix

And here's where it gets uncomfortable. Sometimes the work genuinely doesn't connect to a bigger result. You fixed a real problem, but it was a local one. The system absorbed it, the number didn't move, and the work is done and done. In that case, the problem isn't visibility. The problem is scope. You're doing excellent work in a place that doesn't propagate. That's a different conversation, and it's harder to have, because the answer isn't frame it better. It means this work, done perfectly, will never be seen by the people who matter. I keep coming back to that distinction. It's the one nobody in a performance review will name for you.