Michael Kisilenko recently shared something that caught my attention: "Junior devs' confidence is a renewable but dangerous resource.

And that's exactly why seniors don't answer timeline questions. never.

Their auto-answer: "It depends...", and they're not wrong."

That short post nails a dynamic almost every engineering team has lived through. Juniors want a date. Seniors hesitate. Someone hears "it depends" as avoidance, when it is often the most honest answer available. The problem is not that juniors ask for timelines. The problem is that teams rarely share a common language for uncertainty, and confidence fills the gap.

In this article, I want to expand on Michael's point and make it useful in day-to-day engineering management: why junior confidence can be both fuel and fire, why seniors default to "it depends," and what to say instead so the conversation stays productive.

The hidden economics of confidence

Confidence is a performance multiplier. When a junior developer believes they can solve a problem, they try more options, read more docs, and push through ambiguity. That is the renewable part Michael highlighted: confidence tends to recover quickly after small wins.

The danger is that confidence is also a forecasting tool in disguise. People use it to estimate work, make commitments, and answer timeline questions before they have enough information.

"Confidence" is not the same as "certainty." In software, confidence often comes from familiarity, not from verified constraints.

A junior who has built a CRUD API might confidently say a new feature is "two days" because it resembles something they did before. But the timeline question is rarely about the CRUD part. It is about integration, edge cases, deployment constraints, data migrations, security reviews, stakeholder alignment, and all the things you only learn to fear after you have been burned by them.

Why seniors stop answering timeline questions

When Michael says seniors "don't answer timeline questions. never," it sounds dramatic, but the pattern is real. Senior engineers have learned that a precise date becomes a promise, and promises become blame.

Seniors also know that estimates are not just math. They are a negotiation among:

Scope (what exactly is included)
Unknowns (what we have not discovered yet)
Risk (what might go wrong)
Dependencies (other teams, vendors, approvals)
Quality bar (tests, observability, rollout safety)

So they say "it depends" because, in many cases, it truly does.

"It depends" is often a signal that you are missing a shared definition of the work.

The mistake is stopping there. "It depends" without the dependencies is unhelpful. The senior answer should be: "It depends on X and Y. Here is what we know, what we do not, and what we can do next to tighten the range."

What juniors are really asking when they ask for a date

Most timeline questions are not about curiosity. They are about coordination.

A PM is sequencing a release.
Sales is setting expectations with a customer.
Support is planning for change.
Leadership is managing risk.

A junior developer hears "When will it be done?" and interprets it as "How fast can you code?" A senior hears it as "How much uncertainty exists, and can I responsibly convert it into a commitment?" Both interpretations are reasonable.

The fix is to answer the coordination need without faking certainty.

Replace "it depends" with a clearer estimation conversation

Here are practical ways to keep Michael's honesty while still being useful.

1) Answer with a range, not a point

Point estimates feel decisive and are usually wrong. Ranges acknowledge uncertainty and create space for learning.

Try:

"If the integration is straightforward, 2 to 3 days. If we hit schema issues, 5 to 7 days. I can confirm after a quick spike."

This does two things: it gives a planning signal, and it names the risk.

2) State assumptions explicitly

A timeline without assumptions is a trap. Seniors can teach juniors to attach assumptions every time.

Template:

"Estimate: 3 to 4 days assuming the API supports bulk operations, we do not need a new permission model, and QA bandwidth is available by Thursday."

Now "it depends" becomes a checklist.

3) Use confidence levels like a weather forecast

Forecasting is a skill. Borrow the language of forecasts.

"This is a 40% confidence estimate until we validate the data model. After that, we can raise it to 70%."

Stakeholders may not love uncertainty, but they can work with it if you make it legible.

4) Timebox discovery before committing

A short spike can turn unknowns into knowns. Seniors do this instinctively; juniors often skip it because they want to prove they can deliver fast.

Try:

"Give me half a day to prototype the integration and map edge cases. Then I will update the estimate with fewer unknowns."

This protects the team from accidental overpromising.

5) Break work into slices that can ship

The best antidote to timeline anxiety is incremental delivery.

Instead of "feature done," define slices:

Slice 1: Internal flag-enabled endpoint
Slice 2: UI for internal users
Slice 3: Metrics, alerts, and rollout
Slice 4: General availability

Now you can answer timeline questions with progress milestones, not a single cliff date.

Coaching juniors: keep the renewable part, reduce the danger

Michael's phrase "renewable but dangerous" is a great coaching lens. You do not want to extinguish confidence. You want to attach it to good habits.

Teach them to ask better questions upstream

When a junior is asked "How long will it take?" help them respond with clarifying questions:

"What is the minimum acceptable scope?"
"What risks would change the date the most?"
"Which dependencies are already confirmed?"
"Do we need a staged rollout or can we ship all at once?"

This reframes the conversation from personal speed to project risk.

Model humility without fear

Juniors learn by imitation. If seniors treat uncertainty like weakness, juniors will hide it. If seniors treat uncertainty like data, juniors will share it early.

A useful norm:

"If you are unsure, say what you know, what you do not know, and what you will do next."

Reward accuracy and early warnings, not bravado

Teams often accidentally reward heroic confidence: the person who says "I will do it tonight" gets praise, even if it causes rework later.

Instead, reward:

Clear assumptions
Small, testable slices
Early risk surfacing
Re-estimation when new information appears

That is how you keep confidence renewable without letting it become dangerous.

A senior-friendly script for timeline questions

If you are the senior who defaults to "it depends," here is a practical script that stays honest and still helps planning:

"I can give a range right now, and a tighter estimate after a short discovery step."
"Best case is X days if A and B are true."
"Most likely is Y days."
"Worst case is Z days if we hit C."
"Next step: I will validate A and B by tomorrow 2 pm and update the forecast."

It takes 30 seconds, and it turns "it depends" into leadership.

Closing thought

Michael Kisilenko's post is short because the point is simple: junior confidence is powerful, and timeline questions turn that power into risk if the team does not have a shared way to talk about uncertainty. Seniors are right that "it depends." The next level is to explain what it depends on, turn unknowns into tasks, and give stakeholders a forecast they can use.

This blog post expands on a viral LinkedIn post by Michael Kisilenko, Anyx 👀. View the original LinkedIn post →