It’s Thursday at 2:47 p.m. I know the exact time because I’d just closed my calendar and marked Saturday as “DO NOT TOUCH” in all caps. The Merge Conflicts finally had a slot—a real slot, booked at The Larder, our usual spot that only fits 40 people but smells like old beer and possibility. And after that, I was going to go home, open Cyberpunk 2075, and pretend the next eight hours belonged to nobody but me.
Then Diane from up the VP ladder pinged me.
“Paul—quick favor. The Crestwood client presentation is Monday morning. Their dashboard needs one small tweak to the export function before they see it. Shouldn’t take long. Can you handle?”
I stared at that message for maybe five seconds. Long enough to know I should ask what “small” meant. Long enough to know I should ask what “quick” meant. Not long enough to actually do it.
“Sure,” I typed back. “I’ll get it sorted.”
This is the part where I should tell you I was naive. I wasn’t. I knew better. I’ve been managing this team for four years. I’ve seen “one small tweak” arrive on Monday and metastasize by Friday. But Diane was asking. Diane is a VP. Diane controls my review cycle. And the word “small” has a way of making you feel like you’re being dramatic if you push back.

By Thursday evening, I had forwarded the requirements to Dex. Senior dev, genuinely brilliant, ships code like other people ship complaints. Except when he doesn’t. Dex opened the ticket and immediately responded in Slack: “this export function is a mess. are we actually just patching it or can I do this right?”
I should have said: “We’re patching it Monday morning and that’s it.” What I said was, “How long does doing it right take?”
“Three, maybe four hours,” he said. “If I touch it at all, I’m not shipping it half-assed.”
So Dex started Thursday night. By Friday morning, he’d pulled that thread and found three more threads underneath it, each one in his estimation broken or “architecturally questionable,” which in Dex-speak means he will not rest until it’s perfect. He was already at five hours.
Meanwhile, I’d looped in Marcus to help. Marcus is a junior, smart enough, but he treats code review like it’s a performance evaluation of his entire soul. Every PR he writes comes with apologies. “Sorry for the inefficiency here” and “My bad, I should have thought of this.” Friday afternoon, Marcus finished his piece—the API layer that feeds the export. He shipped it. Forty minutes later, he Slacked me: “Paul, I think I might have broken something.”
Not “I broke something.” Might have broken something. The coward’s hedge. Turns out he had. Nothing catastrophic. But the export was now returning null values on a specific edge case. The kind of thing you’d definitely notice in a demo.
(Somewhere on our internal wiki there is a document a bored intern started two years ago called “Marcus Apologies, Ranked.” I have contributed to it. I am not proud of this. The current #1 entry, undefeated for six months, is: “Sorry, I think I may have accidentally made the button worse but also better? I’ll explain in person because it’s hard over Slack.” It is not hard over Slack. He just didn’t want it in writing.)

“When were you going to tell me?” I asked, not unkindly.
“I was trying to fix it first,” Marcus said. “I’m really sorry. I should have caught it.”
By 6 p.m. Friday, Dex was stuck on something in his refactored section that didn’t play nicely with Marcus’s layer. Neither of them wanted to ship a half-measure. I had a choice: override them both, tell them to ship what they had and we’d patch Monday, or do the integration myself.
I chose the third option, which was the wrong option. I started coding.
At 7:15 p.m., I texted The Merge Conflicts group chat. By 8:30, I texted them again. I did not type “work thing” as the reason, because I already knew that was pathetic.
The Merge Conflicts — Group Chat
Paul, 7:15 PM: Running about 20 late, sorry guys.
Paul, 8:30 PM: Have to bail. Family stuff came up. So sorry.
Drummer: 👎
They didn’t respond with words. Not angry. Worse — a single thumbs-down emoji, which somehow lands harder than a paragraph would have.
At 11 p.m., sitting at my desk in a dark kitchen—I’d stopped going to the office hours ago—the dashboard worked. The export function worked. The edge cases were handled. Dex’s refactor was clean. Nobody had to ship garbage.
I closed the laptop and stared at the wall for a minute. Cyberpunk 2075 was still in its case on my coffee table, exactly 40 hours deep where I’d left it three weeks ago.
The thing that got me wasn’t the missed rehearsal or the unopened game. It was that I’d never actually asked Diane what she meant. Not what “small” meant—whether it was small in scope or small in complexity or small in the sense that “it should be easy if you know the code.” And I’d never said, “Let me check my team’s capacity and get back to you Monday morning.”
“The thing that got me wasn’t the missed rehearsal or the unopened game. It was that I’d never actually asked Diane what she meant.”
Both of those questions would have taken thirty seconds. Both would have been fine. And one of them might have changed everything.

What I Learned
(And What You Can Steal From It)
My mistake wasn’t saying yes. It was saying yes to a feeling instead of a scope. “Quick” isn’t a number. It’s not a unit. It’s what the person asking thinks about their own problem, and it has almost nothing to do with what it’ll cost you to solve it. When Diane said “shouldn’t take long,” she meant it genuinely—from her perspective, changing a single export function sounded small. She wasn’t lying. She just didn’t know what was underneath it. And I didn’t ask her to find out.
If you freelance, you’ve had my exact conversation, just with a client instead of a VP. “Just one small tweak to the homepage.” “Should be quick, right?” “My designer left some files kind of messy, but you’ll figure it out.” Those aren’t scope discussions. They’re the other person thinking out loud about their problem, not describing the actual work. And the fix is the same one I should have used: before you say yes to anything, ask “Is that 20 minutes or 20 hours?” or “What does quick like this actually mean?” Not defensively. Not to be difficult. Just to translate their feeling into a real number. Then you can actually commit to something true.
Here’s what you do this week: The next time someone asks you for something and uses the word “quick” or “small” or “just a,” stop. Say this: “I want to make sure I can actually do this right. Is this a 30-minute fix or are there layers under it?” Make them think for 10 seconds instead of you thinking for 10 hours. You don’t have to say no. But you get to say yes to a real thing instead of a hope.



