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.

Everyone Agrees the Problem Is a Person

Everyone Agrees the Problem Is a Person

You have had the meeting. Everyone looked at the status board, saw the same name in the approval column for the fourth week running, and nodded in unison. Marcus is the problem. You sent the reminder. You CCd his manager. You put his name in the weekly update in a color that is not quite red but is not quite not-red. The whole team knows who the bottleneck is. And here is the part nobody says out loud in that meeting. You are pointing at a person because pointing at a person is easier than admitting the process has no rule. A person who takes four days to approve a two-thousand-dollar purchase and four days to approve a two-hundred-thousand-dollar purchase is not doing two different jobs. They are doing the same job in a gap where nobody wrote down where the line is.

The Rule Is Missing, Not the Speed

A bottleneck is a place where work accumulates because the next step has no clear trigger. Think about the last time you approved something in under an hour. The request was specific, the amount was obvious, and the criteria were already in your head. You did not need to think. You just said yes. Now think about the request that sits in Marcus's inbox for four days. It is not that he is slow. It is that the request is asking him to make a judgment call that nobody defined for him. Is this a standard expense or a capital decision? Does this need a second sign-off? What is the threshold where his approval alone is enough? He does not know, and he is not going to guess wrong in front of his manager. So it sits. The person is not the bottleneck. The absence of a written decision rule is the bottleneck. The person is just the most visible object sitting in that gap. And the reason the same person answers in an hour once the rule is written down is not that they suddenly care more. It is that the question they were avoiding has been answered for them.

Why You Keep Pointing at the Person

Because blaming a person gets you a meeting. Blaming a process gets you a conversation about what you actually agreed to, and most leaders do not want that conversation. You can put Marcus on a performance review. You can put his name in a one-on-one. You can escalate to his director. All of those actions have a clear doer and a clear next step. You cannot put no one defined the approval threshold on a performance review. You cannot assign an action item to a missing document. The person is a target. The process is a mirror. And the uncomfortable part is that if you admit the rule is missing, you have to say who was supposed to write it. Usually that is you, or the person one level above you, or the founder who said we will formalize it next quarter. That is three quarters ago. So the person-blame survives because it is the only version of the problem that has a clear owner.

The Part That Does Not Resolve

Here is where it gets messy, and I will not pretend the distinction above is the whole story. Sometimes the person is the problem. Sometimes Marcus is disengaged, or he does not understand the work, or he is using the approval queue as a place to hide from something else. If you only fix the rule, you still have a person who cannot or will not execute. If you only swap the person, the next hire hits the same wall in week three. You need both. The rule and the person. But you cannot see which one is actually missing until you separate them, and most teams never do. They just add another reminder email, another escalation path, another status check, and call it process improvement. The real question was never how do I make Marcus faster. It is who wrote down what good enough looks like, and if the answer is nobody, you have a different problem than the one you walked into that meeting to fix.

You Walked Into a Finished Vote

You Walked Into a Finished Vote

You know the numbers. You can walk into any room and lay out the projects you've shipped, the revenue you've influenced, the problems you've solved that nobody else would have touched. You've rehearsed the narrative. You believe that if you just tell the story well enough, to the right person, at the right moment, the answer will be yes. And here's the part that stings: in most of the organizations I've walked through, the decision about who's next was made six to nine months before the formal conversation ever happened. Not by a committee. Not by a rubric. By a slow accumulation of who got pulled into certain rooms, who got the stretch assignment, who the VP mentioned by name in a Tuesday sync while the rest of the team just got the link to the deck.

The Allocation You Didn't Ask For

The myth is that influence is a presentation. A deliverable. Something you build, polish, and hand over. It isn't. It's a sequence of small allocations that compound before you ever open your mouth. Who cc'd you on the thread. Who asked for your input on the plan versus who just sent you the finished version for awareness. Whether you were in the room when the problem was still fuzzy, or brought in after the shape was already decided. I've watched people spend three months building a business case for a promotion, present it cleanly, and get a warm "let's revisit next quarter." Not because the case was weak. Because the person making the call had already mentally assigned that seat to someone else four months prior. The room isn't neutral. It's pre-loaded, and you walked in expecting a blank slate.

The Part That Doesn't Resolve Cleanly

Here's where it gets uncomfortable. The people who seem to get ahead aren't the ones with the best slide deck. They're the ones who were already operating at the next level in the small, unglamorous moments. The one who reframed the problem in a two-line email before the meeting. The one who spoke up in the cross-functional sync when nobody else would. But even that doesn't guarantee the seat. Because the allocation isn't purely merit-based. It's proximity-based. And proximity is a function of who the leader already trusts, which is a function of history, not performance. So the question that actually matters isn't how to build a better case. It's who you're in the room with, in what capacity, six months from now. And whether you'll recognize that the window is closing before it actually closes.