Engineers in async-default cultures tend to know things about how the work actually flows that their managers don't fully internalize. The disconnect is usually quiet — engineers don't push back hard on managerial behavior that doesn't fit async patterns, and managers don't ask whether their behavior fits. Both adapt around the gap. The work suffers, the engineers get frustrated, and the team slowly slides back toward synchronous patterns that the engineers don't enjoy and the manager doesn't realize they're causing.
The eight items below are what we hear from engineers when we ask honestly. None of them is dramatic. All of them matter. If you're a manager in an async-default team, working through this list with your direct reports often surfaces patterns you didn't realize you were creating.
1. Responsiveness expectations matter more than you think
When a manager DMs an engineer and expects fast response, the engineer's deep work is interrupted whether or not they actually respond immediately. The anticipation of a manager DM is enough to fragment focus. Even managers who say "no rush, just when you have time" produce this effect because the engineer doesn't know whether the manager means it. The fix is being explicit: "this can wait until end of day" or "this is urgent, please respond when you can in the next hour" or just batching all your DMs into one daily summary.
2. Reading what's already written matters as much as asking questions
When the manager asks for a status update that's already in the engineer's shift-end record, the engineer learns that the records aren't being read. They then write less complete records, because effort spent writing what won't be read feels wasted. The manager creates the documentation gap they're complaining about by not engaging with what's already documented.
3. Scheduling a meeting is the most expensive way to ask a question
For most questions, async is faster and cheaper. The reflex of "let's hop on a quick call" costs more time than the engineer's actual question deserved. Calls are appropriate for genuinely hard discussions; for clarifying questions, asking in writing is better for everyone.
4. Decisions made in 1:1s feel like backroom deals
When the manager and an engineer align on something in their 1:1 and the engineer then advocates for that direction in team discussions, the rest of the team notices. The decision feels pre-made, the discussion feels theatrical, and trust erodes. If the 1:1 produces a decision the team should be aware of, the manager should surface it themselves rather than letting the engineer carry it into the open as if it originated with them.
5. Real-time feedback is less useful than written feedback
Engineers often want feedback they can think about, not feedback delivered live with the expectation of immediate response. Written feedback can be considered, returned to, and engaged with thoughtfully. Live feedback often produces defensive responses or insincere agreement. The manager who writes feedback gets better engagement than the manager who delivers it in real time.
Put a context layer under your distributed team.
StandIn gives engineers a 60-second wrap at the end of every shift. The next shift wakes up knowing exactly what to pick up — no standup required.
Request early access6. Public praise lands better when specific and earned
Generic "great job team!" in Slack feels hollow and sometimes condescending. Specific, attributed acknowledgment — "the way Alex handled the on-call rotation last week was particularly thoughtful" — feels genuine. Engineers can tell the difference. Manager who shower the team with generic praise are seen as performing managerial behavior rather than actually seeing the team.
7. Hours availability isn't a productivity signal
The engineer who responds to Slack at 11pm is often not the highest performer — they're the engineer who hasn't learned to set boundaries, and they're heading toward burnout. The engineer who only responds during their working hours is often the better performer because they're protecting the focus time that produces good work. Managers who unconsciously reward visible availability are accidentally selecting for burnout-prone engineers.
8. Trust signals come from behavior, not statements
Managers who say "I trust my team" and then ask for daily updates, attend every meeting their reports run, and review every decision are signaling distrust through their actions. Engineers read the actions, not the statements. Demonstrating trust looks like delegating decisions, accepting outputs without verification, and not requesting status when it's already been declared.
The conversation that surfaces these
The eight items above usually don't come up in normal manager-IC interactions because the engineer has to explicitly criticize the manager's behavior to raise them. Most engineers won't do that without being asked. A useful periodic conversation: "What's something I'm doing that's making your work harder? What's something I'm doing that's making it easier?" The honest answers often surface the patterns above.
The manager who hears the feedback and adjusts builds substantially more trust than the manager who didn't have the gap in the first place. Engineers don't expect managers to be perfect; they expect them to be responsive to feedback. The willingness to hear the items above is itself a managerial trait worth developing.
Frequently asked questions
What if engineers won't tell me these things directly?
Make it safe to give the feedback. Most engineers won't volunteer criticism of their manager unsolicited; some will if explicitly asked in a way that signals you actually want to hear it. Anonymous skip-level surveys can also surface patterns. The information is available if you create the conditions for it to flow.
How do you change manager behavior once these patterns are entrenched?
One pattern at a time. Pick the one with the most negative effect, change your behavior visibly, and let the team notice. Trying to change everything at once produces no change at all because the manager can't sustain it. Sequential adjustments compound into real change over a few quarters.
What's the single most important shift for a manager moving to async-default?
Reading what engineers have already declared rather than asking them to declare it again. This single change signals more trust, generates more useful records, and reduces interruption. It's also the change most managers find hardest because asking feels like managing while reading feels passive. The asymmetry is illusory; reading is the more skilled work.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.