You've Been Doing Two Jobs and Only Naming One

You've Been Doing Two Jobs and Only Naming One

You wake up and your day is already three roles deep before your first meeting. You're the one who closes the deal, fixes the process that broke at 2am, and keeps the vendor relationship from quietly imploding. None of those three things are in your job description. You didn't sign up for them. They just... arrived. I've sat across the table from forty-plus operators in the last few years, and the pattern is almost boring in its consistency. People absorb work by default, not by design. They pick up the second function because nobody else will, or because the gap was there and they were standing next to it. And then six months later, the second job is 30% of their week and nobody in the org chart knows it exists.

The Circled List

Here's the part that surprises most people when I ask them to write down everything they did last week, every single task, and then mark the ones that fall outside their actual title. The list is longer than they think. Not by a little. By a lot. I had a VP of Operations tell me she was spending four hours a week writing the content briefs for a marketing team that didn't exist. Another had become the de facto onboarding lead for a team of twelve, a role that had no owner, no budget, and no name. The work was real. The hours were real. The role was not. And because the role was not named, it had no owner, no scope, and no leverage. It just sat there, getting heavier, while the person carrying it told themselves they were "just being helpful."

Why Nobody Names It

The second job stays invisible because naming it costs something. Name it and you're either asking for a title change, a pay adjustment, or a headcount that the budget doesn't cover. Name it and you're admitting the org has a gap, which means someone else's planning was wrong. So the path of least resistance is to keep doing the work and call it "part of the job." The problem is that "part of the job" is a phrase that expands to fill any container you put it in. It will swallow your weekend. It will swallow your promotion case, because the second job never shows up in a review. It will swallow your authority, because you can't delegate a role that technically doesn't exist. And the quietest cost of all: you start to believe the second job is who you are, not something you're doing. That's the part that's hardest to walk back.

Busy Is the Laziest Excuse You Have

Busy Is the Laziest Excuse You Have

You're in the quarterly review and someone asks what moved forward this month. You open your mouth and the words that come out are that you've been so busy. You say it like it explains something, like it's a full answer. In twenty years of running operations across industries, I've heard that phrase in maybe eight out of ten status meetings. And I can tell you, the people who say it most are rarely the ones producing the most. They're the ones who can't point to a specific thing that got built, shipped, or closed. The room hears effort, and the room does not respect effort. It respects output. And you just gave them nothing to point at.

The Word Does Different Work Than You Think

Here's a distinction that most people never sit with. Busy is a process word. It describes motion, duration, the feeling of time passing. It does not describe a result. A developer who has been busy for three weeks might have the same pull request as one who has been busy for four days. A sales rep who has been busy all quarter might have closed two deals or zero. The word absorbs all the ambiguity and lets you hide behind the hours instead of the artifact. I've watched teams log 40 hours a week and produce a single slide deck, and I've watched others work 20 focused hours and ship a product update that moved revenue. The hours were never the variable. The output was. And busy is the one word that keeps you from having to name it.

Where the Real Problem Actually Lives

And here's the part that makes it worse than a simple bad habit. Sometimes the person is genuinely overloaded, but the system that created that overload is the same system that rewards the phrase because it's the only answer that doesn't expose a gap in planning, delegation, or scope. The excuse isn't just lazy in the moment. It's lazy across quarters. It keeps the real structural problem invisible, and the person saying it knows that. That's why the phrase comes out so fast, so automatic, before they have to think about what actually got done. Here's the edge case that keeps me up at night. What if the person who's genuinely doing the most work is the one who says it least? What if the quiet operator who shipped three things this quarter never opens their mouth in the meeting, and the one who did nothing but schedule calls gets the nod? The system rewards the performance of effort, and the person who actually produced is the one who looks most replaceable in the room.

Your Approver Is Not the Bottleneck. Your Ask Is.

Your Approver Is Not the Bottleneck. Your Ask Is.

You send the request on Monday. You check your inbox Tuesday, Wednesday, Thursday. By Friday you've rewritten it three times, added context, attached the spreadsheet, and still nothing. You tell yourself it's the other person. They're slow, disorganized, don't care. And maybe they do. But here's what I keep watching happen: the same approver who gives a yes in four hours on one request stalls two weeks on another. Same inbox, same week. The variable that changed was not the approver. It was the ask.

The Ask Does the Work You Refuse to Do

There's a distinction that most people never make because making it feels like admitting you're the problem. A request that says I need your approval on the vendor contract is not a request. It is a homework assignment handed to the person with the most leverage in the room. You've asked them to open the document, figure out what the numbers mean, decide what level of spend they're comfortable with, and then make a call. That's four separate cognitive tasks wrapped in one sentence. A request that names the dollar figure, the scope, the only change from last year, and the deadline is a different animal entirely. The second one doesn't require the approver to think. It requires them to decide. Those are not the same labor.

The One That Still Stalls

Here's where it gets uncomfortable. Sometimes you write the clean ask. You pre-frame the decision, name the number, the scope, the deadline. And it still sits. That's not a failure of your ask. That's a signal about what the approver is actually managing. They're not processing your request. They're managing their own risk, their own political exposure, their own uncertainty about whether a yes on your thing creates a precedent they can't walk back. You can't fix that with a better sentence. You can only see it for what it is and stop blaming your own grammar for someone else's fear.

Nobody Wins the Room Alone

Nobody Wins the Room Alone

You walk into that conversation with a rehearsed narrative. You know the number you want. You know the three or four wins you are going to lead with. You are counting on the next twenty minutes to do what six months of work should have done. And here is the thing you notice when you watch the people who actually get the number they wanted. They did not do that. They walked in with a file. Not a deck. Not a pitch. A file. Deliverables logged in the week they shipped. Scope changes documented the day they happened. The comp conversation was a checkbox, not a trial.

The Room Confirms. It Does Not Build.

The distinction that matters is this. The room is not where your case gets built. It is where it gets confirmed. There is a difference between a person who says they handled the migration and the vendor negotiation and the team restructuring, and a person who points at the migration ticket, the vendor contract with the clauses they flagged, the headcount sheet showing the three roles they absorbed before backfilling. The first one is a memory. The second one is a record. And the committee sitting across from you is not deciding based on charm. They are deciding based on what they can point to in six months when the next cycle comes around and someone asks why that person got that number.

The Cost Is Not This Year. It Is the Year After.

Here is the part that does not resolve cleanly. The person who did all of it and never wrote it down is not a bad operator. They were too busy doing the work to build the case for the work. And the system that punishes them for that is the same system that expects them to produce, from memory, a complete accounting of eighteen months of output in a twenty-minute window. You cannot build that file retroactively. You can only build the next one. And the cost of not having it is not the number you miss this cycle. It is that the committee starts remembering you as the person who asked for more, instead of the person whose file made the ask obvious. And that memory is harder to overwrite than you think.

The headcount request that came back no

The headcount request that came back no

Eight people. Seventy percent of delivery targets. The team leader walked into a planning meeting with a slide that said request: two additional FTEs. The answer was no. Budget cycle. Headcount freeze. Whatever the reason, the conversation ended there. The team leader said they needed more bodies and everyone nodded. The spreadsheet got another line item. The output did not change. Three months later, the same team was still at seventy percent, and the headcount request was sitting in a revisit-next-quarter pile.

The steps nobody could justify

Then a new ops lead sat down and traced what actually happened between a request hitting the queue and a deliverable going out the door. Two approval steps sat in the middle of the process. One was a manager sign-off on a form. Six months of data. 100% approval rate, every single month. The other was a quality review pass that flagged the same three items every week, every time. Those two steps added four and a half days to cycle time. The team was not slow because they were small. They were slow because every single deliverable had to clear two gates that no one in the room could explain anymore.

What changed when the steps went

They removed both. Not swapped them for a lighter version. Removed. The manager sign-off became a weekly batched review, post-hoc. The quality check became a three-item checklist the maker ran before hitting submit. Same eight people. Same targets. Cycle time went from eleven days to seven. Nobody left. Nobody got a raise. The friction just stopped being there. And the team stopped asking for more people because the asking had stopped making sense.

The distinction that matters in a budget review

Here is what is hard to say out loud in a planning meeting. When you ask for more people, you are asking for more hands on the task. When you cut a step, you are removing the thing that was in the way of the hands you already have. Those are different requests. One is a resource question. The other is a design question. And the design question is the one where the answer is already sitting in the workflow, waiting for someone to look at the data instead of the headcount number. The resource question takes a quarter, a CFO's mood, and a full budget cycle. I keep wondering which one most teams are actually stuck in. Because from the outside, the frustration looks identical. Same energy in the room. Same we-need-more-people energy at the whiteboard. And the answer determines whether the next quarter looks like this one or not.

The question that makes you freeze

The question that makes you freeze

You are in the review. Everything went fine for twenty minutes. Then they ask how you are using AI in your work, and your mouth opens and nothing comes out that sounds like a person who actually does the job. You think about saying I use it for research and drafting, and you can already hear how that sounds. Like a weather app. Like using AI the way you use a calculator. The uncomfortable part is that most of the people in that room are in the same position. They were nudged to use AI in a Slack message, tried a chatbot twice, and now they are supposed to perform fluency on demand. The question is not testing your knowledge of models. It is testing whether you can name a specific thing you did differently because of a tool, and whether you can measure the difference. Most people cannot, and the silence does the talking for them.

The thing nobody tells you about that question

Here is the thing nobody tells you about that question. It is not about AI. It is about whether you can separate three things you have been doing in one undifferentiated blob. The problem you were solving. The process you built or changed. The measurable shift that followed. When you cannot separate those, you sound like someone describing a vibe. Saying I use AI to be more efficient is the operational equivalent of saying I am a team player. It means nothing because it has no before, no after, no specific mechanism. The people who answer well are not the ones who use the most tools. They are the ones who can point at one workflow and say, here is what was broken, here is what I changed, here is what the number did. That is an operator answer, not an AI answer.

The question that keeps coming

And here is where it gets annoying, because the question will keep coming. Not just in reviews. In standups. In client calls. In the quick update email where someone asks how the new tool is working. You will be in a room where someone asks a junior what their AI workflow is, and the junior gives you the same blob answer, and the whole table goes quiet. The people who can separate the three parts do not just sound better. They sound like the person the question was really aimed at. And the people who cannot? They start to sound like the people the question was designed to sort out. That is the part that should keep you up at night. Not that you do not know the answer. That you cannot yet tell which side of that sort you are on.

The Last Thing That Broke Is Not the Next Thing That Will

The Last Thing That Broke Is Not the Next Thing That Will

You built the process. It worked for eighteen months. Then the order volume doubled, or the team grew from six to fourteen, and suddenly the thing that was smooth is grinding. You fix the handoff that dropped two invoices last Thursday. You patch the approval chain that has been sitting in someone's inbox for three days. You write a new email template because the tool integration quietly stopped syncing. Each fix feels good. Each fix is the last one you will make on that specific Tuesday. The next break is somewhere else. And you do not know where yet.

One Pressure Point, Five Faces

Here is the thing most operators miss until it costs them a quarter. Those five failure points, handoffs, exceptions, approvals, tooling, communication, are not five separate problems. They are one pressure point showing up in sequence. Volume is the load, your process is the structure, and the structure has one weak member that everything else was bracing for. When the load shifts, that member shows first. But it was never the only weak one. It was just the one closest to the load path. You are not fixing your system. You are watching it fail in order and naming each failure a new problem.

The Habit Wearing the Costume

The question that actually matters is not what broke. It is what is load-bearing right now that you have been treating as decorative. The approval step that works because there are only four people who need to sign off. The handoff that holds because the same two people do it every morning. The exception path that is a single email to a person who remembers the context. None of those are systems. They are habits wearing the costume of systems, and habits do not scale. They get slower, then they get skipped, then they get blamed on whoever was supposed to follow them. The one that takes your quarter is not the one that broke last month. It is the one where two of the others intersect under a load condition you have not hit yet, and you will not see it coming because it has not broken yet.