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.

The Second Job Nobody Approved

 

You took a role. Then somewhere between month two and month six, you started doing the thing that was supposed to be someone else's job. Not because you volunteered. Because the gap was there, the deadline was close, and you were the person in the room. Now you're running two roles and getting evaluated on one. Nobody thanked you. Nobody wrote it down. You just did it. And every quarter review, your performance is measured against the original scope while the second scope quietly eats forty percent of your week.

Complaint or Fact

When people bring this up, they almost always frame it as a complaint. I'm also handling the vendor relationships. I've been picking up the onboarding too. The words also and too do a lot of emotional work. They sound like a request for relief, and the response is almost always thanks for stepping up, followed by nothing changing. The sentence that actually lands in a room is different. It's not a request. It's a fact. I've been covering X in addition to Y, and here is what that has meant for the output of this team. No apology. No I'm sorry to bring this up. Just the operational reality, stated the way you'd state it in a status report to a board.

Why the Frame Changes the Room

A complaint invites a debate. A fact invites a decision. When you put the sentence on the table as a fact, the other person has to respond to the state of the operation, not to your feelings about the state of the operation. That is a different conversation entirely. And it is the one that actually produces a structural change. A new hire. A scope adjustment. A title change. A pay correction. Or it produces a clear, explicit no, that is how it stays. Both outcomes are better than the slow bleed of doing two jobs and being measured on one, because at least one of them forces the organization to look at what it actually has running.

The Part That's Uncomfortable

Here is the part that makes people hesitate. If you name the second role, you can no longer pretend it is temporary. You can't keep saying I'm just filling in until they hire someone. The moment you say it out loud as a fact, you are forced to treat it as a permanent condition of the operation until someone actively changes it. And sometimes that means the second role is the job now. The one that pays better. The one that makes you more valuable. The one nobody wanted to create a position for because doing so would mean admitting the first role was underscoped from the start. Naming it doesn't just make the work visible. It makes the misalignment permanent until someone fixes it. And someone is not you.

Effort vs. Evidence

Effort vs. Evidence

You sit in the quarterly review and you say the thing. You say you were on it all week. You say you put in the hours, you say you handled the mess, you say the word grind like it should do the talking for you. And you watch the person across the table nod slowly, write something down, and move to the next agenda item. They are not being cruel. They are doing the math. And the math says you described a feeling. You did not describe a change.

The two descriptions that survive the page

Here is the split. One person says they spent three weeks rebuilding the onboarding flow. The other says the onboarding flow went from a 14-step process to five steps, and the drop-off at step two went from 40 percent to 11 percent. The first sentence is a claim about time. The second sentence is a record of what moved. You can argue about whether three weeks was enough. You cannot argue about 40 percent versus 11 percent. One of those descriptions lives in a document. The other evaporates the moment the meeting ends.

Why effort is a claim and evidence is a record

Effort is something you did. It is internal. It is the hours, the late nights, the context-switching, the email you sent at 11:47 on a Friday. Nobody can audit it. They can only take your word for it. Evidence is something that happened to the system. The error rate. The cycle time. The number of tickets that stopped coming in. Those are external. They are in the data. They do not require your testimony. And here is the part that stings: the person who names the evidence does not need to be in the room for it to count. The person who names the effort does.

Where it gets uncomfortable

Now, some work genuinely does not produce a clean number. You held the team together through a reorg. You absorbed the chaos so the engineers could ship. You made the call nobody wanted to make at 2 a.m. on a Sunday. That work is real. But it is also the work that is hardest to write down in a way that survives being read by someone who was not in the room. And that is not a small problem. That is the exact gap where good people get passed over for people who are better at naming what changed, even when the change was harder to produce than to describe.