Ask and Sync Often — Underestimate the Boss's Memory, Don't Overestimate Their Intuition

• Opening: The Day I Wasted Two Weeks
• The Core Insight: The Person Who Gave the Work Knows the Direction
  • Bias 1: Overestimating the boss's memory
  • Bias 2: Overestimating the boss's intuition
• The Value of Regular Alignment: An Anchor Against Drift
• The Benefit of Sharing: A Deal With Nothing to Lose
• The Art of Asking: How to Ask Smartly
  • 1. Distinguish closed questions from open ones
  • 2. Don't ask empty-handed
  • 3. The 5-minute and 30-minute rules
  • 4. Self-check before asking
  • 5. If it can be async, ask async
• Expectation Management: Confirm What Was Agreed
  • When receiving work: say it back
  • During: surface your assumptions
• A Case: Sample Dialogues
  • The moment of receiving work
  • Mid-progress check
• Pitfalls: Guard Against Over-Reporting
  • Pitfall 1: Interrupting too often
  • Pitfall 2: Responsibility-dumping questions
  • Pitfall 3: Sharing for the sake of sharing
  • Pitfall 4: Loss of autonomy
• Make Active Use of the One-on-One
• Sync in Remote and Async Environments
• Frequently Asked Questions (FAQ)
• When You Don't Know What to Ask: Growing the Sense of Alignment
• The Frequency of Sharing Depends on the Stage
• Trust Grows From Alignment
• Practice: Building a Sync Routine
  • 1. Kickoff sync
  • 2. Regular check-in
  • 3. Set a stuck threshold
  • 4. Light async updates
  • Sync practice checklist
• The Cost of Postponing the Question
• Closing: Together Right Beats Alone Fast
• References

Opening: The Day I Wasted Two Weeks

Early in my career, I wanted to be "the person who just gets it done." When handed work, I wanted to dig in alone to the very end, never asking, and surprise everyone with a finished result. So once I took on a two-week task and barely reported during that time. I was afraid that if I asked midway, people would think, "Can't they even do this much alone?"

Two weeks later, I proudly brought in the result. And my team lead's first words: "Huh? This wasn't the direction we wanted."

What I had built was well-made, but wrong. I had interpreted the requirements my own way, and that interpretation had been off from the start. If I had asked even once on the third day, "I'm going this way, is that right?", I would have lost three days instead of two weeks.

Something hit me that day. Whether what I'm doing is right is best known by the person who assigned it. I am the expert on "how," but the expert on "what and why" is the person who defined the work. Running alone for a long time looks cool, but running cool in the wrong direction just gets you far away fast.

This goes beyond the simple advice "ask often." It is about why regular sync is an expression of competence, and how to ask smartly.

The Core Insight: The Person Who Gave the Work Knows the Direction

There are two cognitive biases to address here. Both are traps that make us run alone.

Bias 1: Overestimating the boss's memory

We commonly assume the boss vividly remembers the work I was given. "They mentioned it last time, so surely they know." But reality differs. The boss is handling ten other things besides me at once, and the context of the moment they gave me the work fades quickly from their head.

That task, which is 100% of my life, is just one of twenty things the boss dealt with that day. So the assumption "of course they'll remember" is dangerous. It's safer to assume the opposite. Underestimate the boss's memory. That is, assume the boss has forgotten, and share while re-surfacing the context. Reminding them, "That task you gave me last week, here's how it's going," is not nagging but consideration.

Bias 2: Overestimating the boss's intuition

Another assumption is the belief that the boss will know "by intuition" how things are going. "They'll notice if I'm stuck," "They'll ask first if there's a problem." But there is no telepathy. The boss cannot know what I haven't reported.

In particular, the trap of reading no news as good news is common. If I'm quiet, the boss thinks "it must be going well," not "are they perhaps stuck?" So silence often sends the false signal of "no problem."

Underestimate the boss's memory, and don't overestimate the boss's intuition. Filling that gap is precisely your sharing.

Combining these two biases, the conclusion is one. Don't expect the boss to remember on their own and notice on their own. Alignment is something I must actively create. And the core of that alignment is confirming "whether the direction I'm going is right," and that answer lies with the person who defined the work.

The Value of Regular Alignment: An Anchor Against Drift

Let me call going off direction "drift." Just as a ship drifts off course bit by bit, pushed by currents, work too moves bit by bit away from the original intent over time.

The frightening thing about drift is that it compounds. A one-degree difference on the first day is negligible. But left unattended, the farther you go, the more the destination diverges from intent.

Drift and Alignment

intended direction
─────────────────────────────────→ goal
 \
  \  drift (not syncing often)
   \
    \
     \___________________ arrive at the wrong place

intended direction
──+───+───+───+───+──────────────→ goal
  ^   ^   ^   ^   ^
  course corrected each time by regular sync

Regular sync is the anchor that catches this drift. The more often you check, the smaller the divergence is when you catch and fix it. The cost of alignment gets cheaper the smaller and more frequent it is, and more expensive the more you defer and batch it. Exactly like that two-week loss in the opening.

There is the same philosophy here as why agile development uses short iteration cycles (sprints) and daily standups. The reason a long waterfall approach is risky is that you discover the direction was wrong only at the end. Check often in short cycles, and even when wrong, you're wrong small and correct fast. The same principle applies to an individual's way of working.

The Benefit of Sharing: A Deal With Nothing to Lose

Sharing and asking often can feel like a loss. "Am I just being a bother?" "Won't I look incompetent?" But weighing cost and benefit, sharing is a deal with almost nothing to lose.

To address a common misunderstanding: the idea that asking often is a sign of incompetence. The truth is the opposite. A smart question is a sign of competence. "I want to confirm the direction is right" is the attitude of a professional who doesn't want to waste time. Conversely, bringing in a result that wasted two weeks is what really looks incompetent.

Another benefit is "visibility of contribution." Working quietly alone means your effort and thought process are invisible to everyone. Only the result is evaluated. But sharing the process makes visible what difficulties you faced and how you got through them. This is not self-PR but legitimate visibility. Invisible work easily becomes work that never happened.

The Art of Asking: How to Ask Smartly

"Ask often" is not "ask anything and everything." There's an art to asking. A smart question saves the other person's time while getting you exactly the answer you need.

1. Distinguish closed questions from open ones

Direction checks are best as closed questions. Rather than "How should I do this?", giving concrete options like "I'm leaning toward A, but there's also option B. Is A right?" lets the other person answer quickly, close to yes/no.

2. Don't ask empty-handed

The worst question is "How do I do this?" The best question is "I tried this and got stuck here. My thinking is A, how do you see it?" When you ask with your own hypothesis, the other person doesn't need to explain from scratch; they just verify your hypothesis.

3. The 5-minute and 30-minute rules

A useful rule of thumb when unsure whether to ask. For a minor block, first try on your own briefly (say, 15-30 minutes). If there's no progress past that, holding on alone any longer is a waste. Build the habit of weighing the time spent struggling alone against the cost of asking.

4. Self-check before asking

Things to ask yourself before a good question.

• Is this answer already in the docs or code?
• Have I organized what I tried?
• Have I made my hypothesis clear?
• Have I shaped it into a form easy to answer?

5. If it can be async, ask async

Leave non-urgent questions as messages. The other person can answer when convenient, and the answer stays as a record. Pull them in directly only when immediate conversation is truly needed.

Expectation Management: Confirm What Was Agreed

The essence of syncing often is "expectation management." Most conflict and disappointment come not from lack of ability but from mismatched expectations. I'm building A while the other person expected B.

The key moments to align expectations are at the start of work and during it.

When receiving work: say it back

When handed work, restate it in your own words to confirm. "As I understand it, I should build X in the Y way up to Z, right? When's the deadline?" This one confirmation catches the initial misunderstanding. People interpret what they hear in their own way, and unless you verify that interpretation out loud, you can't discover the divergence.

In particular, make these clear.

• What is "done" (the definition of done)
• By when (deadline and priority)
• What level of quality/scope (quick and rough vs. perfect)
• Whom it's for (the final reader/user)

During: surface your assumptions

Surface the decisions and assumptions you make while working. Sharing "for the part not specified in the requirements, I'm assuming this and proceeding" lets the other person correct it if the assumption is wrong. Assumptions held in silence are the most dangerous.

There's an old wisdom in expectation management: "under-promise, over-deliver." Honestly promise what you can do, and deliver more when possible. Better to make a promise you'll keep and build trust than to make one you can't keep and disappoint.

A Case: Sample Dialogues

Let's see the abstract principle as concrete dialogue.

The moment of receiving work

A poor example Boss: "Please improve the search feature this time." Me: "Sure, got it." (Inside: How am I supposed to improve search? Let me just try something.)

A good example Boss: "Please improve the search feature this time." Me: "Sure. Just to confirm, is the biggest pain right now speed or accuracy? And does it need to be done within this sprint, or is it a goal for the next release?" Boss: "Speed is the problem. I'd like a first improvement within this sprint." Me: "Got it. Then, prioritizing speed, I'll do the indexing improvement this sprint and leave accuracy for next. I'll show you the mid-point direction in about three days."

Mid-progress check

"Sharing a mid-point update on the search work. I changed the indexing approach to A and response time dropped by half. But as I went, I see a trade-off where accuracy drops slightly. Since you said speed first, shall I keep going this way, or do we need to maintain accuracy at a certain level too?"

This one short share preempts a grilling days later of "Why did accuracy drop?" Surfacing the trade-off instead of deciding it alone — that is mature sync.

Pitfalls: Guard Against Over-Reporting

I've emphasized sharing often, but everything has its balance. If under-sharing breeds drift, over-sharing breeds other problems.

Pitfall 1: Interrupting too often

Asking trivial things every five minutes constantly breaks the other person's focus. Especially for someone in deep work, frequent interruption is a big cost. You need the discernment to batch questions or leave async what can be left async.

Pitfall 2: Responsibility-dumping questions

Repeating only "How do I do this?" without thinking for yourself is not alignment but offloading decisions. A question has value on the premise that "I have thought." Repeating questions with no hypothesis of your own erodes trust.

Pitfall 3: Sharing for the sake of sharing

A report for the sake of reporting, an update to fill a format, is noise. Contentless reports like "Worked hard again today" actually bury the truly important signal. Sharing has value when it affects the other's decision or confirms direction.

Pitfall 4: Loss of autonomy

Trying to get everything confirmed stunts the ability to judge and take responsibility yourself. The more senior you become, the more important the judgment of what to decide alone and what to confirm. You need the discernment to decide small things yourself and confirm large, hard-to-reverse decisions.

The question for finding balance is this. "If this decision is wrong, is the cost of reversing it high?" The higher the cost and the more direction-related, the more you confirm; the smaller and more easily reversible, the more you decide yourself. Amazon's Jeff Bezos's distinction between "reversible decisions (two-way door)" and "irreversible decisions (one-way door)" is useful here.

Make Active Use of the One-on-One

Many companies have a regular one-on-one meeting with your boss. Yet many people let this time pass passively, just answering what the boss asks and ending there. This is a big waste. The one-on-one is not the boss's time but yours.

Intel's legendary CEO Andy Grove, in High Output Management (1983), stressed that the one-on-one should be led by the subordinate. He called it the "subordinate's meeting." Ideally, the subordinate prepares the agenda and the subordinate drives it.

Here's how to use the one-on-one well.

• Prepare the agenda in advance. "This time I'd like to discuss these three things."
• Do your direction checks here. Instead of interrupting with trivial things day to day, batch them and align in the one-on-one.
• Align expectations. Explicitly ask "Am I doing well?" and "Are my priorities right?"
• Ask for feedback. "Is there something I could do better?"

The one-on-one is a regular safety net that prevents that "two-week misstep" from the opening. If there is a place to align direction even once a week, drift never exceeds a week's worth.

Sync in Remote and Async Environments

Distributed teams, working from home, different time zones. In the modern workplace, casually asking the person next to you happens less and less. The more physically apart you are, the more intentional sync must be.

The biggest trap of a remote environment is "drifting quietly in isolation." In an office you can walk by and ask "How's that going?", but remotely such accidental alignment disappears. So active sharing becomes far more important than in an office.

The practice of sync in remote and async environments looks like this.

• Leave progress in writing. Make it visible before being asked. A short update in a public channel makes invisible work visible.
• Break the assumption that "no news is good news." Silence is more dangerous remotely. Say it's going well even when it is.
• Async by default, sync as the exception. Non-urgent things by message, only what needs fast agreement by call.
• Respect time zones and write clearly. Ask with enough context so the other person can understand alone, even while not awake.

What people who are trusted remotely have in common is "working visibly." Not flashy result announcements, but the accumulation of steady, transparent small shares.

Frequently Asked Questions (FAQ)

When You Don't Know What to Ask: Growing the Sense of Alignment

There's a point where the advice "ask often" gets stuck. "I don't even know what to ask." Especially as a new hire, you often fall into a state of not even knowing what you don't know (unknown unknowns). At such times, vaguely asking "Is it going well?" makes for an empty conversation.

The sense of alignment — the ability to know "what to confirm right now" — can be cultivated. There are a few clues.

• Check your assumptions. While working, there are points you glossed over with "this is surely the case." Those assumptions are exactly the candidates to confirm. What you thought obvious is most often wrong.
• Find the forks. The moments while working when you split between "go A or go B." If that choice drives the direction, it's a candidate to confirm.
• Weigh the cost of reversal. The harder it is to undo if this decision is wrong, the more it's worth confirming in advance.
• Look at the silent areas. Parts you filled in arbitrarily because the requirements didn't specify. Those blanks are the danger zone.

In the two-week case from the opening, what I missed was exactly "the assumption that I interpreted the requirements my own way." Had I confirmed that assumption out loud just once, everything would have been different. The heart of the sense of alignment is, in the end, "consciously pulling out the assumptions I made unconsciously."

This sense grows with experience. At first you flounder, not knowing what to ask, but after experiencing drift a few times, "ah, this is the kind of point I should have confirmed" becomes second nature. So don't fear the awkward early questions. They are the tuition for cultivating the sense of alignment.

As a practical tip, before starting work, write down "three assumptions I'm currently making." For example, "this feature is used only by logged-in users," "the data doesn't need to be real-time," "I'll reuse the existing API." Just showing this list of assumptions to your boss or a colleague once surfaces half of the hidden divergences. The moment you write assumptions down, what was obvious in your head finally becomes a verifiable proposition.

The art of alignment is not knowing the answers well, but knowing well what you don't know.

The Frequency of Sharing Depends on the Stage

"Sync often" doesn't mean "report at the same frequency always." Good sharing adjusts frequency to the stage and risk of the work. Reporting at the same intensity every moment becomes excessive; staying silent every moment becomes drift.

A rough guide is this.

• Start stage: align densely. This is when direction is easiest to go off, so confirm often early. Show a small piece of the first output early and get feedback.
• Stable stage: align loosely. Once the direction is fixed and you're cruising, there's no need to interrupt often. A light progress share is enough.
• Fork/risk stage: dense again. At an important decision point or when a risk signal appears, raise the frequency immediately.

The core principle is "more often when uncertainty is high, less often when it's low." Uncertainty should determine the frequency of alignment, not habit or formality. Adjusting this way avoids the trap of over-reporting and reduces the risk of drift.

One more thing: sharing has "push" and "pull." Push is me notifying first; pull is making it available for the other person to look up when they need it. Push the important and urgent directly, and leave reference-level progress as pull (in a shared document or board) so the other person can check it themselves when they want. Mixing these two appropriately greatly raises the efficiency of sharing.

Trust Grows From Alignment

The biggest reward of syncing often is, in fact, "trust." And trust returns as autonomy. This looks counterintuitive. How does the person who confirms often gain greater autonomy?

The mechanism is this. When I share progress transparently and predictably, the boss perceives me as "a person I can hand things to with peace of mind." Someone who delivers bad news early and confirms first when the direction might go off. There's no reason to micromanage such a person. Instead, the trust builds that "this person aligns well on their own, so I can hand them something bigger."

Conversely, the person who runs alone without sharing paradoxically invites more interference. The boss grows anxious because progress is invisible, and when anxious, keeps looking in. Silence invites micromanagement. If you want autonomy, you must first give transparency.

There's an important shift here. Sync is not "asking for permission" but "building trust." It's not asking to offload every decision, but showing "here's where I'm going and the judgment I made." As such sharing accumulates, the boss confirms less and less and delegates more and more.

The virtuous cycle of trust works like this.

In the end, the paradox that "asking often" leads to "being interfered with less." This is the greatest gift alignment gives.

Practice: Building a Sync Routine

A routine for making frequent sync a habit rather than a matter of willpower.

1. Kickoff sync

When you receive new work, do a 5-minute alignment before starting. Restate your understanding in your own words and confirm the definition of done, deadline, and priority.

2. Regular check-in

Schedule mid-point check-ins in proportion to the length of the work. For a two-week task, confirm direction at least once every three days. Drop the temptation of "quietly build it all and reveal it as a surprise."

3. Set a stuck threshold

Decide in advance an upper limit on the time to hold on alone. Past that time, organize your hypothesis and ask.

4. Light async updates

Habituate one- or two-line progress shares rather than grand reports. Like "X done, on Y now, decision needed on Z."

Sync practice checklist

• When receiving work, did I confirm by restating in my own words?
• Did I clarify the definition of done and the deadline?
• On work that could drift, did I confirm early?
• When stuck, did I ask within the threshold I set?
• When asking, did I present my hypothesis along with it?
• Did I surface trade-offs instead of deciding them alone?
• Am I bothering the other person with over-reporting?

The Cost of Postponing the Question

Finally, I want to point to the real cost of postponing the question. We often put it off with "let me try a bit more, then ask." The reason for that delay is usually pride. We don't want to admit we don't know, we want to be seen solving it alone, and we hesitate for fear of interrupting.

But the cost of delay grows over time. First, you go deeper in the wrong direction, making it harder to undo. Second, the later you ask, the more likely you get the reaction "why didn't you ask earlier?", which actually makes you look more incompetent. Third, the stress and blockage built up during that time spoil your other work too.

The two weeks in the opening were exactly the result of this delay. Asking on the third day would have cost three days, but postponing out of pride lost two weeks. The cost of the postponed pride was far greater than the awkwardness of asking early.

Remember. Asking early is not exposing weakness but the strength of saving time. The awkwardness is five minutes, but the cost of delay is several days. Put the two on a scale, and the answer is always clear.

Closing: Together Right Beats Alone Fast

Return to those wasted two weeks. The me back then wanted to be "the person who just gets it done," but what I actually did was "run fast alone in the wrong direction." The real "person who just gets it done" was not someone who doesn't ask, but someone who knows when and what to ask.

Syncing often is not dependence. It is alignment. If I am the expert on "how," the person who defined the direction is the expert on "what and why." Meshing those two expertises often is the essence of collaboration.

Underestimate the boss's memory (assume they've forgotten and re-surface the context), and don't overestimate the boss's intuition (there is no telepathy, so share actively). The small shares that fill the gap between them prevent two-week missteps, build trust, and ultimately produce better results.

Reduce it all to one sentence and it is this. Alignment is a strength, not a weakness. Asking is not because you fall short but the smartest way to save time and build trust. And that smartness is cultivated by practice — what to ask and when, what to decide alone and what to confirm; that sense grows through the awkward early questions.

Going right together beats going fast alone. That goes farther.

References

• Larson, W. An Elegant Puzzle: Systems of Engineering Management (2019) and lethain.com (https://lethain.com).
• Grove, A. (1983). High Output Management. Random House. (One-on-ones and alignment)
• Beck, K. et al. (2001). Manifesto for Agile Software Development (https://agilemanifesto.org).
• Bezos, J. Amazon Shareholder Letter (2015) — two-way door decisions (https://www.aboutamazon.com).
• Harvard Business Review, "What Great Managers Do" (https://hbr.org).
• Clear, J. on feedback loops (https://jamesclear.com).