One-on-ones are the most expensive recurring investment an engineering manager makes. If you manage a team of seven engineers and meet each for 45 minutes every week, you are spending nearly a full working day every sprint inside these conversations. Done poorly, they degenerate into awkward small talk or a redundant recap of Jira tickets. Done well, they become your most reliable diagnostic tool for team health, individual motivation and organizational drag.
The purpose of a 1:1 isn't to track delivery. You already have standups, sprint boards and pull requests for tracking progress. The 1:1 exists to build the relationship, understand the person and surface the problems that engineers hesitate to raise in group settings. When you change how you approach these conversations, you shift your leadership posture from oversight to support.
The primary trap: Status updates versus real signal
The default failure mode for engineering managers is turning 1:1s into status reports. It feels comfortable because reviewing sprint progress is familiar and low-risk. You ask what someone is working on, they tell you about their current ticket, you discuss a PR comment and thirty minutes disappear without either of you learning anything new.
Consider how easily this trap springs: an engineer mentions they're stuck on an OAuth token refresh issue. Instead of asking why authentication changes have blocked three consecutive sprints, you spend twenty minutes debating token lifespans and reviewing code snippets. You walk away feeling productive because you touched technical details, but you missed the real signal: the identity team has ignored your team's pull request for two weeks, and your engineer is demoralized by cross-team gridlock.
This pattern signals an underlying problem with ownership and accountability. If you need a private meeting to discover whether a feature is on track, your team's everyday delivery visibility is too low. Chasing status updates in 1:1s wastes high-leverage time on information that should already be transparent.
┌───────────────────────────────────────────────────────────┐
│ THE 1:1 SPECTRUM │
├─────────────────────────────┬─────────────────────────────┤
│ LOW LEVERAGE (STATUS SYNC) │ HIGH LEVERAGE (SIGNAL SYNC) │
├─────────────────────────────┼─────────────────────────────┤
│ "Did you finish ticket 402?"│ "What made that ticket drag?"│
│ "What are you doing next?" │ "What drained your energy?" │
│ "When will the PR merge?" │ "Who are you waiting on?" │
│ Manager does 70% of talking │ Engineer does 70% of talking│
│ Focus on tasks and output │ Focus on system and growth │
└─────────────────────────────┴─────────────────────────────┘
The 1:1 belongs primarily to the engineer, not to you. While you protect the recurring time and provide structure, they should drive the agenda. If they come with three topics, start there.
If an engineer says they have nothing to discuss, resist the urge to end the meeting after three minutes. Giving time back sounds polite, but doing it regularly trains engineers to treat 1:1s as disposable check-boxes. Instead, use an empty agenda to step back from sprint mechanics: ask about long-term technical growth, examine the team's review turnaround or explore friction in the testing pipeline.
How to talk: Shifting from interrogation to active listening
How you speak in a 1:1 determines what information reaches you. When managers ask blunt, evaluative questions, engineers instinctively enter self-preservation mode. Questions like "Why didn't this ship on Friday?" or "Why did the test suite fail?" invite defensive explanations rather than honest problem-solving.
To uncover what is really happening, change the posture from evaluation to curiosity:
- Replace "why" with "what" or "how": Instead of asking "Why is this integration taking so long?", ask "What part of this third-party API has surprised you most?" or "How can I help clear that dependency?"
- Embrace comfortable silence: When you ask a thoughtful question, resist the urge to fill the gap after three seconds. Engineers often need five to ten seconds to move past a rehearsed answer and formulate what they actually think.
- Probe the second layer: The first response to "How are things going?" is usually a reflexive "Pretty good." Follow up with a concrete probe: "What went better than expected this week?" or "What felt heavier than it needed to be?"
Active listening also means watching for discrepancies between words and demeanor. If an engineer claims everything is fine but seems unusually withdrawn, acknowledge the observation gently without being accusatory: "You sounded a bit exhausted during yesterday's architectural sync. How are you feeling about the timeline?"
What you are trying to learn: The four essential signals
When you sit down with a direct report, you are running a quiet diagnostic on four distinct areas of your team's operating environment:
1. Systemic friction and hidden drag
Engineers often tolerate absurd levels of day-to-day friction: flaky CI pipelines, slow local builds, ambiguous requirements from product or friction with another platform team. Over time, this friction becomes invisible background noise that quietly saps morale. Your 1:1 is where you surface this drag before it causes burnout.
Ask questions that invite them to critique the environment:
"If you had a magic wand and could delete one recurring step from our deployment or testing workflow tomorrow, which one would you pick?"
2. Energy and intrinsic motivation
Competence isn't the same as engagement. An engineer might be exceptionally good at migrating legacy database schemas while secretly dreading every working hour spent doing it. If you only look at velocity, you will miss the warning signs until they hand in their resignation.
You need to know what energizes each person and what depletes them. Pay attention to the tasks that make their eyes light up and the responsibilities they consistently procrastinate on.
3. Team dynamics and psychological safety
Tension between team members rarely explodes in public channels first. It usually appears as quiet avoidance: avoiding PR reviews from a specific colleague, hesitating to speak up in refinements or privately expressing frustration about architectural disagreements.
In the first 30 days as an engineering manager, building a safe diagnostic channel is essential for surfacing these dynamics. The 1:1 gives engineers a private forum to voice concerns about collaboration before misunderstandings solidify into resentment.
4. Upward feedback on your own leadership
You can't improve if you only evaluate downwards. Ask how your own decisions, communication style and meeting cadence affect their daily focus:
"What is something I did over the last few weeks that helped you, and what is something I did that created confusion or got in your way?"
Be prepared to receive feedback without defending yourself. If you get defensive, you teach the engineer that honesty is dangerous.
Getting to know the person: Working styles, motivation and boundaries
Treating engineers like interchangeable ticket processors is a reliable way to burn out top performers and build fragile software. Every engineer comes with distinct motivations, communication preferences and personal boundaries. Getting to know them doesn't mean prying into their private life; it means understanding how they operate best as a professional.
| Dimension | What You Want to Understand | A Helpful Question to Ask |
|---|---|---|
| Feedback preference | Do they prefer immediate verbal nudges or written notes they can digest first? | "When I share constructive feedback, what format gives you the best space to process it?" |
| Recognition style | Do they appreciate public shout-outs in company demos or quiet private praise? | "When you ship something you're proud of, how do you prefer your impact to be recognized?" |
| Ambition and growth | Do they want deep technical specialization, architecture influence or people leadership? | "Looking ahead six to twelve months, what capabilities do you want to build that our current work isn't touching?" |
| Working cadence | When are their peak hours of concentration, and what shatters their flow state? | "What does your ideal uninterrupted coding block look like during the week?" |
Keep in mind that personal circumstances fluctuate. An engineer with a newborn at home, someone supporting an ill family member or someone relocating across time zones has different emotional bandwidth than someone in a settled routine. Knowing the broader context lets you adjust project expectations with empathy before delivery issues arise.
At the same time, keep clear boundaries. A 1:1 is not amateur therapy. If an engineer is dealing with severe personal distress or mental health challenges, your responsibility isn't to counsel them. Your job is to listen respectfully, adjust workload pressures and connect them to trained professionals through your company's employee assistance program.
Habits that protect the space: Cadence, notes and follow-through
The best conversational posture matters little if your calendar habits suggest 1:1s are optional. How you manage these recurring slots signals whether you prioritize internal people over external emergencies.
Reschedule instead of canceling
Canceling a 1:1 because "neither of us has an agenda" or "a stakeholder meeting came up" sends a damaging signal: internal team members matter less than external emergencies. If an unavoidable conflict arises, reschedule it promptly within the same week rather than dropping it entirely. Consistent presence builds dependability.
Maintain a shared running document
Use a private shared doc for each direct report with date headings. Both you and the engineer should add agenda items throughout the week as thoughts arise. This eliminates the awkward blank stare at the start of the meeting and ensures you address items that matter to both sides.
Avoid the venting vacuum
Listening to frustration about legacy architecture or ambiguous product requirements is essential diagnostic work. But allowing the 1:1 to become an unconstrained venting session week after week creates cynicism rather than progress. Once an engineer has shared their frustration, pivot to action: "What is one technical guardrail or communication boundary we can put in place to reduce this friction?"
Close the loop on commitments
If an engineer asks you to investigate a cross-team dependency, clarify a product requirement or speak with IT about hardware access, write it down and track it. When you fail to follow through on commitments made in a 1:1, you erode trust faster than any missed sprint deadline. Even a quick Slack message stating "I asked the platform lead about that PR queue; they are reviewing it this afternoon" shows that their concerns don't vanish into a managerial void.
Actionable takeaways for your next 1:1
- Audit your talk-time ratio: Aim to speak no more than 30% of the time. If you find yourself lecturing or explaining policy for twenty minutes, stop and ask what they think.
- Banish the Jira board: Close your task tracker before the call starts. Focus on the engineer, their environment and their blockers.
- Ask one diagnostic friction question: Start your next round of syncs by asking what tool, meeting or process created the most unnecessary drag this sprint.
- Contract feedback channels: Clarify how they prefer to receive praise and critique so you can adjust your delivery to their communication style.
- Commit to one concrete follow-up: Before concluding, identify at least one small operational blocker you will remove on their behalf before you meet again.