Every ‘Quick Task’ Has a Hidden Price Tag — How to Say Yes Without Falling Behind
Every ‘yes’ has a hidden price tag. That 90-minute interview actually takes half a day. Here's the math nobody does.
Here’s a problem that doesn’t show up in sprint planning: the invisible tax on senior engineers.
You get asked to help. Interviews. Code reviews. “Quick” syncs. Onboarding. Each request sounds small. Each one feels impossible to refuse.
But say yes to everything without accounting for the real cost, and suddenly you’re behind on your actual commitments. Not because you’re slow. Because nobody, including you, counted the hours.
This isn’t about learning to say no. It’s about learning to say yes sustainably. There’s a difference.
As a senior+ engineer, I’ve often been asked to help with interviews—sometimes for other teams that didn’t have the capacity or were being built from scratch. The kind of request that feels impossible to refuse. Of course you help. Hiring matters. You’re a team player.
The Math Nobody Does
When someone asks you to “help with an interview,” what they’re picturing is the interview itself. Ninety minutes, maybe two hours. A calendar block. Done.
Here’s what actually happens:
Before the interview you have to:
Read the candidate’s CV and any prior feedback (20-30 minutes)
Review the role requirements, refresh on what we’re looking for (15-20 minutes)
Prepare questions tailored to this candidate’s background (20-30 minutes)
The interview itself:
The actual conversation (60-90 minutes)
Buffer time for overruns and transitions (15-30 minutes)
After the interview:
Document detailed feedback while it’s fresh (30-45 minutes)
Sync with the hiring manager or director (15-30 minutes)
Possible follow-up discussions with other interviewers (15-30 minutes)
Add it up: 2 to 4 hours per candidate. Not 60-90 minutes. Half a day.
And if there are multiple interviews in your sprint? If you’re doing panel interviews with another engineer? Double it.
Say Yes, Then Make It Visible
Aligning on expectations, estimates, and prioritization matters most. At startups and scaleups, where sprint capacity is already tight, this alignment prevents the slow bleed of unplanned work.
For example, consider this message:
“Hey team, happy to help with interviews. Quick note for planning: please account for 2-4 hours of capacity per interview. That covers prep, the interview itself, documentation, and syncing results. Just want to make sure we’re all on the same page.”
That’s it. No pushback. No refusal. Just visibility.
This single message did three things:
It set expectations. Now everyone knows what the commitment actually is.
It protected your sprint. Your manager can see the real capacity impact.
It helped others. Other engineers in the channel now have language to use themselves.
Making invisible work visible is being professional.
This is VDE Principle #6 in action: reduce friction, eliminate empty rituals. If nobody’s tracking the real cost of these requests, that’s friction. Make it visible.
The Process Questions Nobody Asked
Let’s take this a step further. Assuming you accepted an emerging task such as an interview. You clarified timeframes and everyone is aligned. Great!
At this point, you might start thinking: “How will this play out? What should this process look like?”
If you are uncertain about how to tackle the interview, you should ask follow-up questions:
Do we have a formal interview process documented?
How many people should interview each candidate?
Are we calibrated? Is one interviewer consistently harsher than another?
Who owns the interview scorecard (and evaluation guide, maybe), and when was it last updated?
In most cases you should get enough context to keep pushing your task. Feedback doesn’t have to be ideal; it just has to be good enough.
If the answers are vague, that might tell you: there is no process.
And if there’s no process, someone needs to create one. That someone is usually whoever asks the question — which is why most people don’t ask.
But creating a process is also work. It needs to be scoped, scheduled, and owned. You can’t just absorb it into your existing commitments and hope nobody notices.
So in this case you might decide on something like this:
“If we need to formalize the interview process, that’s probably a dedicated task. Should we create a ticket for it and assign an owner?”
Now it’s visible. Now it’s trackable. Now someone has to make a decision about whether it matters enough to prioritize.
The Four Layers of Value
This situation is a perfect example of VDE Principle #3: evaluate decisions through four layers of value. Every engineering decision affects customers, company, team, and yourself. Here’s how it plays out.
Customer value: If I’m behind schedule because I absorbed unplanned work, my team ships late. That means customers wait for features, or bugs take longer to fix. The impact is indirect but real.
Company value: Hiring is critical. Bad hires can cost six figures when you factor in recruiting, onboarding, lost productivity, and eventual replacement. Helping with interviews is genuinely valuable to the organization.
Team value: As software engineers, our primary commitment is to our team’s sprint, iteration, or whatever floats your boat. If we disappear for half a day every time there’s an ad-hoc task, our team’s commitments slip. That’s a real cost — it just happens to be invisible unless someone makes it visible.
Personal value: If we keep absorbing unplanned work without speaking up, we become engineers who are always behind schedule. Not because we’re slow, but because we said yes to everything without accounting for the true cost. That’s a career problem.
Saying yes to everything feels like being a good team player. But if your yes comes at the cost of your actual commitments, you’re creating problems at all four layers.
At a startup, unplanned work can sink a sprint because you’re already running lean. At a scaleup, it creates coordination chaos across teams and suddenly you’re blocking others. Either way, the cost is real.
The Principle: Sustainable Yes
The skill here isn’t saying no. Saying no is easy, but it burns bridges and makes you look unhelpful.
The skill is saying yes sustainably. Which means:
Say yes, because the work usually does matter. But make the cost visible before you’re underwater, not after. Ask the process questions, because if there’s no process, you’re not the only one struggling. Then let others make the tradeoff with full information, not assumptions.
When you name the cost publicly, you’re being the kind of senior engineer who thinks about systems, not just tasks.
Next time someone asks you for “a quick favor” that isn’t quick, try this:
“Happy to help with [X]. For planning purposes, this typically takes [realistic time estimate] when you include [list the hidden work]. Can we make sure that’s accounted for in this sprint?”
You’re not refusing. You’re being honest about what help actually costs.
That’s how senior engineers protect their capacity without burning bridges.
The Cheat Sheet: What “Quick” Requests Actually Cost
“Help with an interview”
You assume it takes 90 minutes.
It actually takes 2-4 hours:
CV review and prior feedback (20-30 min)
Role requirements and prep (15-20 min)
Tailored question preparation (20-30 min)
The interview itself (60-90 min)
Buffer for overruns and transitions (15-30 min)
Detailed feedback documentation (30-45 min)
Sync with hiring manager (15-30 min)
Follow-up discussions with other interviewers (15-30 min)
“Onboard the new person”
You assume it takes a few pairing sessions.
It actually takes 8-15 hours over 2 weeks:
Environment setup troubleshooting (1-2 hours)
Codebase walkthrough (2-3 hours)
Pairing on first tasks (3-5 hours)
Code review with teaching (2-3 hours)
Answering questions throughout (1-2 hours)
“Quick code review”
You assume it takes 30 minutes.
It actually takes 1-2 hours:
Pull branch and run locally (10-15 min)
Understand context and requirements (15-20 min)
Actual review (20-30 min)
Write constructive feedback (15-20 min)
Follow-up discussion (10-20 min)
Re-review after changes (15-30 min)
“Join this sync meeting”
You assume it takes 30 minutes.
It actually takes 1-1.5 hours:
Pre-read materials (15-20 min)
Actual meeting (30 min)
Context switching overhead (10-15 min)
Action items and follow-up (15-20 min)
“Can you document this?”
You assume it takes an hour.
It actually takes 3-5 hours:
Understand what needs documenting (30-45 min)
Write first draft (1-2 hours)
Add diagrams or examples (30-60 min)
Review and revise for clarity (45-60 min)
Get feedback and update (30-45 min)
“Debug this production issue”
You assume it takes a few minutes.
It actually takes 2-6 hours:
Get access to logs and metrics (15-30 min)
Reproduce the issue (30-60 min)
Trace through the code (45-90 min)
Identify root cause (30-90 min)
Test the fix (30-60 min)
Document for postmortem (30-45 min)
“Spike out this approach”
You assume it takes a couple hours.
It actually takes 1-3 days:
Research existing solutions (1-2 hours)
Prototype implementation (5-10 hours)
Test edge cases (1-2 hours)
Document findings and trade-offs (1 hour)
“Present at the team meeting”
You assume it takes the meeting length.
It actually takes 2-3 hours:
Prepare slides or talking points (45-60 min)
Rehearse if needed (15-30 min)
Actual presentation (30 min)
Q&A and discussion (20-30 min)
Follow-up questions after (15-30 min)
Every “quick” request has hidden work attached. The senior move is knowing what that work is and saying it out loud before you’re buried.
Have you ever counted the real hours on a “quick” request and been surprised? What’s the biggest gap you’ve found between perceived vs. actual time? I’m curious what’s missing from this list.
If this resonated, share it with a fellow engineer who’s drowning in “quick” requests. They’ll thank you. And if you’re not subscribed yet, subscribe now so you don’t miss the next one.