Running Effective One-on-Ones: A Comprehensive Guide for Technical Leaders
Table of Contents
- Introduction
- 1. Core Principles: Why One-on-Ones Matter
- 2. Practical Frameworks: How to Run Great One-on-Ones
- 3. Common Mistakes: What to Avoid and Why
- Mistake #1: Using One-on-Ones for Status Updates
- Mistake #2: Doing All the Talking
- Mistake #3: Canceling or Rescheduling Frequently
- Mistake #4: Not Taking Notes or Following Up
- Mistake #5: Avoiding Difficult Conversations
- Mistake #6: Making It About You
- Mistake #7: Trying to Fix Everything
- Mistake #8: Skipping One-on-Ones with Senior Engineers
- 4. Real Scenarios: Good vs. Bad Examples
- 5. Practice Exercises: Developing This Skill
- 6. Key Takeaways: What to Remember
- Appendix: Templates and Checklists
- Interview Practice
Introduction
One-on-ones are the single most powerful tool in your leadership toolkit. They’re not status updates or task tracking sessions—they’re strategic investments in your team members’ growth, engagement, and performance. For technical leaders transitioning from individual contributor roles, mastering one-on-ones represents a fundamental shift: from optimizing code to optimizing people.
This guide will help you build a deep, practical understanding of how to run one-on-ones that genuinely matter—meetings that your team members look forward to rather than endure.
1. Core Principles: Why One-on-Ones Matter
The Purpose of One-on-Ones
One-on-ones serve three primary purposes that interlock to create effective leadership:
Building Trust and Relationship
Trust is the foundation of all effective leadership. In distributed systems, you need reliable connections between services. In leadership, you need reliable connections between people. One-on-ones create the dedicated space where trust forms. When someone knows they have your undivided attention regularly, they’re more likely to share early warning signs of problems, admit struggles, and be honest about their aspirations.
Career Development and Growth
Engineers don’t leave jobs—they leave managers who don’t invest in their growth. One-on-ones are where you understand each person’s unique career trajectory and help them progress. This isn’t about generic advice; it’s about knowing that Sarah wants to move into architecture, that Michael is interested in mentoring but hasn’t had the opportunity, or that Priya feels stuck doing maintenance work when she wants to build new features.
Aligning Individual Goals with Team Objectives
The best outcomes happen when individual motivation aligns with business needs. One-on-ones are where you connect the dots: “I know you want to learn more about distributed systems. The new payment service we’re building would be a great opportunity—what do you think?” This alignment turns abstract company goals into personally meaningful work.
Why This Matters More Than You Think
Consider your own experience. Think about the best manager you’ve had—someone who genuinely helped you grow. Chances are, they ran effective one-on-ones. Now think about your worst manager. They probably either skipped one-on-ones entirely or treated them as status update meetings.
The data backs this up: regular, high-quality one-on-ones are one of the strongest predictors of team retention and performance. But most importantly, they’re where you actually do the work of leadership. Everything else—sprint planning, architecture reviews, incident response—those are management activities. One-on-ones are where you lead.
The Mindset Shift
As a technical lead, you’re used to solving problems. In one-on-ones, your job isn’t to solve—it’s to enable the other person to solve. This is uncomfortable at first. Someone shares a challenge, and every instinct screams to jump in with a solution. Resist. Your role is to ask questions, provide context, and help them develop their own problem-solving capacity.
Think of it like code review. You could just rewrite someone’s code, but that doesn’t help them learn. Instead, you ask questions: “What happens if this service is down?” “How does this scale?” “What alternatives did you consider?” One-on-ones are similar—you’re helping someone review their own career, challenges, and growth.
2. Practical Frameworks: How to Run Great One-on-Ones
The Foundation: Logistics That Show You Care
Consistency is Non-Negotiable
Schedule one-on-ones weekly for 30 minutes (or biweekly for 45-60 minutes if your team is large). Put them in your calendar as recurring events and treat them as the highest priority. Canceling a one-on-one sends a clear message: “You’re not important.” Emergencies happen, but reschedule immediately—don’t just cancel.
For a distributed team across Vietnam, India, and the US (like in your Tricentis experience), this means sometimes taking calls at inconvenient hours. That’s the job. If you’re in Vietnam and your US team member’s only reasonable time is 9 PM your time, that’s when you meet.
Environment Matters
If in-person: find a private space, not a conference room with glass walls where everyone can see. Get out of the office if possible—a walk or coffee shop changes the dynamic.
If remote: video on, notifications off, close Slack. The engineer on the other end can tell when you’re multitasking. They can see your eyes moving to your second monitor. Don’t.
The Shared Document
Create a shared document (Google Doc or Notion) for each person. This becomes the running record of your one-on-ones. The format:
# One-on-Ones: [Name]
## [Date]
### Their Topics
-
### My Topics
-
### Action Items
- [ ] [Owner] - [Action]
### Notes
-
## [Previous Date]
...Share edit access. This makes it their meeting, not yours. They can add topics ahead of time. You can too, but their topics go first.
The Structure: Three Phases
Phase 1: Their Agenda (60% of time)
Start with “What’s on your mind?” or “What do you want to talk about today?” Then be quiet. Actually quiet. Count to five in your head if you need to.
Their topics come first. Always. Even if you have something urgent, their topics take priority. Why? Because this is the only meeting in their week that’s entirely about them. Everything else is about the project, the sprint, the incident, the deadline. This one meeting is theirs.
Listen for three levels:
- Surface level: The explicit topic they raise
- Emotional level: How they feel about it (frustrated, excited, worried, proud)
- Pattern level: Is this a one-time issue or part of a recurring theme?
For example, if someone says “The deployment process is really slow,” the surface issue is deployment speed. But if you listen deeper, you might hear frustration about lack of ownership, or worry about how this makes them look to the client, or excitement about fixing infrastructure problems. Each of these suggests a different conversation.
Phase 2: Your Agenda (25% of time)
After their topics, transition: “I had a couple things I wanted to discuss—is now a good time?”
Your topics might include:
- Feedback on recent work (both positive and constructive)
- Context they need about company or team direction
- Opportunities you’ve identified for their growth
- Heads-up about upcoming challenges
Keep this crisp. Don’t turn their meeting into your status update session.
Phase 3: Long-term Focus (15% of time)
Every few meetings (at least monthly), explicitly discuss:
- Career progression: “Where do you want to be in a year? In three years?”
- Skill development: “What skills do you want to build? How can I help?”
- Job satisfaction: “On a scale of 1-10, how happy are you? What would make it a 10?”
Don’t save these for annual reviews. Career conversations should be ongoing, incremental, and normal.
The Question Framework: Coaching Not Directing
The quality of your questions determines the quality of the conversation. Here are frameworks for different situations:
For Problems or Challenges:
- “Help me understand the situation—what’s happening?”
- “How is this affecting you / the team / the project?”
- “What have you already tried?”
- “What options are you considering?”
- “What would you do if you were making this decision?”
- “How can I help?”
Notice: you’re not jumping to solutions. You’re helping them think through it. Even if you already know the answer, asking these questions builds their judgment.
For Career Development:
- “What parts of your work energize you? What drains you?”
- “If you could change one thing about your role, what would it be?”
- “What skills do you want to build in the next 6 months?”
- “Who in the company/industry do you admire? What do they do that you’d like to do?”
- “What’s one thing I could do to better support your growth?”
For Giving Context: When you need to share information, frame it as context, not orders:
- “Let me share some background on why we’re making this decision…”
- “I want to give you visibility into what’s happening at the company level…”
- “Here’s what I’m seeing that you might not have perspective on…”
This helps them understand the “why” behind decisions, which develops their strategic thinking.
The Balance: Different Conversations for Different Levels
Your approach should flex based on the engineer’s experience level (drawing from your experience mentoring engineers at different levels):
Junior Engineers (0-3 years)
- Focus: 60% skill development, 30% confidence building, 10% career planning
- They need structure and guidance. Be more directive.
- Regular check-ins: “Are you feeling stuck on anything?”
- Celebrate small wins loudly
- Help them understand what “good” looks like
Mid-level Engineers (3-7 years)
- Focus: 40% skill development, 40% ownership/impact, 20% career planning
- They need challenges and autonomy. Be more coaching.
- Questions like: “What would you do?” “How would you approach this?”
- Help them see the bigger picture
- Push them to take initiative
Senior+ Engineers (7+ years)
- Focus: 20% skill development, 30% organizational impact, 50% career/leadership
- They need vision and leverage. Be more collaborative.
- Treat them as thought partners: “What do you think about this direction?”
- Discuss team/org challenges, not just their work
- Help them mentor others and shape culture
The Feedback Loop: Making It Continuous
One-on-ones are perfect for regular feedback—both giving and receiving. Don’t wait for formal reviews.
Giving Feedback in One-on-Ones: Use the SBI model (Situation-Behavior-Impact):
- Situation: “In yesterday’s architecture review…”
- Behavior: “…when you proposed the new caching approach…”
- Impact: “…it really helped the team see a path forward. That kind of technical leadership is exactly what we need.”
Or for constructive feedback:
- Situation: “In the last sprint planning…”
- Behavior: “…when you disagreed with the estimate…”
- Impact: “…it came across as dismissive of the team’s input. I want to make sure everyone feels heard.”
Keep feedback recent (within a week), specific (not “you need to communicate better”), and balanced (don’t make the whole meeting about problems).
Receiving Feedback in One-on-Ones: Ask directly:
- “What’s one thing I could do differently to support you better?”
- “Is there anything I’m doing that’s getting in your way?”
- “How am I doing as your manager?”
When they give feedback, don’t defend. Say “thank you for telling me that” and really listen. Then follow up on it. This builds trust faster than almost anything else.
The Long Game: Patterns Over Time
Keep notes in your shared doc. After 6 months, patterns emerge:
- Does someone always bring up the same type of problem? That suggests a systemic issue.
- Has someone’s energy level changed? That’s an early warning sign.
- Are they asking about growth opportunities more frequently? They might be getting ready to leave—address it now.
Review your notes quarterly and ask yourself: “Is this person growing? Are they engaged? Are there themes I need to address?”
3. Common Mistakes: What to Avoid and Why
Mistake #1: Using One-on-Ones for Status Updates
What it looks like: “So, how’s the payment service migration going? And the OData implementation? What about the Cosmos DB performance issues?”
Why it’s wrong: You’ve just turned the only meeting that’s about them into another meeting about the work. Status updates belong in standup, Slack, or JIRA. One-on-ones are for the stuff that doesn’t fit anywhere else: career growth, interpersonal challenges, organizational concerns, big-picture thinking.
What to do instead: If work topics come up, go deeper than status: “How do you feel about the migration? What are you learning? What’s frustrating you about it? Is this the kind of work you want to be doing?”
Mistake #2: Doing All the Talking
What it looks like: You spend 25 minutes explaining the new architecture direction, the org changes, and your concerns about the upcoming deadline. Your engineer nods along. The meeting ends. They haven’t said more than a few sentences.
Why it’s wrong: This is broadcasting, not conversation. You’ve learned nothing about what’s going on with them. They’ve had no opportunity to raise concerns, ask for help, or share ideas.
What to do instead: Track the talking ratio. Aim for them talking 70% of the time, you talking 30%. If you’re talking more, you’re doing it wrong. Use questions to draw them out. Get comfortable with silence—people need time to think.
Mistake #3: Canceling or Rescheduling Frequently
What it looks like: “Sorry, I need to push our one-on-one—there’s an urgent client call.” This happens two out of four times per month.
Why it’s wrong: You’ve just signaled that they’re not a priority. Urgent client calls will happen. But if you consistently prioritize everything else over one-on-ones, your team learns that you don’t really value them. Trust erodes. They stop preparing. They start looking for new jobs.
What to do instead: Protect these meetings religiously. If you absolutely must reschedule, do it yourself immediately and explain why: “I’m sorry—there’s a production incident that requires my attention right now. Can we move to tomorrow at 2 PM? This is important to me, and I want to make sure we have the time.” Then actually do it.
Mistake #4: Not Taking Notes or Following Up
What it looks like: You have a great conversation. They mention they want to learn more about Kubernetes. Three months later, they bring it up again: “Remember when I said I wanted to learn K8s? That hasn’t happened.” You have no recollection.
Why it’s wrong: Without notes and follow-through, conversations evaporate. The engineer feels unheard. Your promises (“I’ll look into that training budget” or “Let me think about how to get you on that project”) become meaningless.
What to do instead: Take notes during or immediately after the meeting. Capture action items with owners. Review your notes before the next one-on-one. Follow up on commitments. If you said you’d do something and haven’t, be honest: “I said I’d check on the conference budget—I haven’t yet, but I’ll have an answer by Friday.”
Mistake #5: Avoiding Difficult Conversations
What it looks like: You know Sarah is underperforming on the reporting component. You know Michael has been short with teammates in code reviews. You know Priya seems disengaged lately. But bringing it up feels awkward, so you stick to safe topics.
Why it’s wrong: Avoiding difficult conversations doesn’t make problems go away—it makes them worse. The performance issue becomes a termination. The interpersonal friction becomes a team conflict. The disengagement becomes a resignation. You’ve failed them by not addressing it early.
What to do instead: Lean into the discomfort. These conversations are part of your job. Use the frameworks: “I want to talk about something I’ve noticed…” Be direct, be kind, be specific. Most people appreciate honesty delivered with care. And catching issues early means they’re easier to fix.
Mistake #6: Making It About You
What it looks like: Your engineer shares a challenge with a difficult stakeholder. You respond: “Oh yeah, I had this situation once where…” and spend 10 minutes telling your story.
Why it’s wrong: You’ve just made their problem about you. Instead of feeling heard, they’re now listening to your story. This happens especially to technical leaders who are used to sharing their experience. Your war stories have value, but not at the expense of their airtime.
What to do instead: Share experiences briefly and only when relevant: “I’ve been in a similar situation. What helped me was X. Would that work for you, or is your situation different?” Then hand the conversation back to them.
Mistake #7: Trying to “Fix” Everything
What it looks like: Your engineer shares three frustrations: the deployment process is slow, the codebase has too much tech debt, and they’re having trouble getting time with the product owner. You immediately start problem-solving: “Okay, I’ll talk to DevOps about deployments, I’ll schedule tech debt time next sprint, and I’ll set up a meeting with the PO.”
Why it’s wrong: Sometimes people just need to vent. Sometimes they want to solve it themselves but need to talk through it. By immediately jumping to solutions, you’ve taken away their agency and possibly missed what they actually needed.
What to do instead: Ask: “What do you need from me on this? Do you want my help solving it, or did you just need to talk through it?” Respect their answer. Coaching someone to solve their own problems is often more valuable than solving it for them.
Mistake #8: Skipping One-on-Ones with Senior Engineers
What it looks like: You figure your staff engineer doesn’t need as much attention. They’re self-sufficient. So you skip their one-on-ones when you’re busy, or you keep them short.
Why it’s wrong: Senior engineers need one-on-ones differently, but they still need them. They’re often dealing with more complex organizational challenges, thinking about bigger career decisions, or considering offers from other companies. The absence of one-on-ones signals you don’t value their development.
What to do instead: Senior engineers’ one-on-ones might focus more on organizational strategy, mentorship challenges, or career direction. But they still need the dedicated time. If anything, the conversations are more valuable because their decisions have bigger impact.
4. Real Scenarios: Good vs. Bad Examples
Scenario A: The Struggling Junior Engineer
Context: You’re leading a team at Aperia Solutions. A junior engineer, Tom, has been missing deadlines on his microservice component. You notice in code reviews that he’s not applying the patterns you’ve discussed.
❌ Bad Approach:
You: "Tom, we need to talk about the payment service component. You're behind schedule,
and the code quality isn't where it needs to be. What's going on?"
Tom: "I've been trying, but there's a lot to figure out."
You: "Well, we have deadlines. You need to ask for help when you're stuck. Let me know
if you need anything. But we need this done by Friday."Why it’s bad: You’ve made it about the deadline, not about Tom’s growth. You haven’t uncovered the actual problem. You’ve offered generic “ask for help” without understanding what help he needs. He leaves feeling blamed and unsupported.
✅ Good Approach:
You: "Tom, I want to talk about the payment service component. I've noticed you've been
working on it for a while, and from the code reviews, it seems like you might be
stuck. Help me understand what's happening."
Tom: "I'm trying to figure out how to structure the domain models, but I'm not sure
I'm doing it right."
You: "Okay, so it's the domain modeling specifically. What's making that hard?"
Tom: "I've read about DDD, but I don't know how to apply it to this service. Every time
I start, I second-guess myself and refactor."
You: "Got it. So you understand the concepts but struggle with the application. That's
really common. Here's what I'm thinking: what if we pair on this tomorrow morning?
I'll help you think through the domain model, and we can establish some patterns
you can follow. Would that be helpful?"
Tom: "Yes, that would really help."
You: "Great. After we pair, I want you to apply the same pattern to one more service
on your own, and we'll review it together. The goal is to build your confidence in
these decisions. Sound good?"Why it’s good: You’ve uncovered the real issue (application of concepts, not understanding). You’ve offered specific help (pairing), and you’ve created a learning path (apply pattern, review together). Tom leaves with a plan and support.
Scenario B: The Engineer Who Wants a Promotion
Context: At CoverGo, a mid-level engineer, Maria, has been hinting she wants to move to senior level. She’s been with the team for two years and is doing solid work on the Claims service.
❌ Bad Approach:
Maria: "I've been thinking about my career growth. What would it take to get to senior?"
You: "Keep doing good work. We'll see what opens up."
Maria: "But what specifically should I focus on?"
You: "Just keep improving. When the time is right, we'll talk about it."Why it’s bad: You’ve been completely vague. Maria has no clarity on what “good work” means at the next level. She doesn’t know if it’s 6 months away or 3 years away. She doesn’t know what specific skills to develop. This is how you lose good people.
✅ Good Approach:
Maria: "I've been thinking about my career growth. What would it take to get to senior?"
You: "That's great that you're thinking about this. Let me ask first—what does 'senior'
mean to you? What do you want to be doing differently?"
Maria: "I want to lead bigger projects and mentor others."
You: "Okay, so technical leadership and people development. Those are exactly the right
areas. Here's how I think about the senior level: it's not just about coding
better—it's about multiplying your impact through others and making good decisions
with ambiguity. Let me be specific about what I see as gaps right now.
For technical leadership: You do great work on defined features, but I haven't
seen you drive a full project from ambiguous requirements to delivery. That's a
key senior skill.
For mentoring: You're helpful in code reviews, but that's reactive. Senior
engineers proactively mentor—they identify where someone needs help and create
opportunities for growth.
Here's what I'm thinking: The new reporting component we're building is complex
and ambiguous—perfect for you to lead. And we're hiring two junior engineers next
quarter. What if you took on formal mentorship for one of them?"
Maria: "That sounds good. What would success look like?"
You: "For the reporting component: You define the technical approach, coordinate with
other teams, and deliver it with minimal guidance from me. For mentorship: Your
mentee shows visible growth after 3 months—maybe they're submitting cleaner PRs,
asking better questions, or solving problems more independently.
Let's check in on this monthly. If you're executing on both well, we can talk
about promotion in 6 months. Does that timeline feel right to you?"Why it’s good: You’ve made the criteria concrete. Maria knows exactly what skills to develop and has specific opportunities to demonstrate them. She has a timeline. She has a way to measure success. She leaves energized, not frustrated.
Scenario C: The Performance Issue
Context: At YOLA, an engineer, David, has been delivering work that requires significant rework. Other engineers are starting to complain. You need to address it.
❌ Bad Approach:
You: "David, I need to talk to you about your code quality. The team has been spending
a lot of time fixing issues in your code. You need to be more careful."
David: "I'm doing my best. Maybe the requirements aren't clear."
You: "The requirements are fine. Everyone else understands them. You need to step up."Why it’s bad: You’ve attacked his competence without specificity. You’ve dismissed his concern about requirements. You’ve compared him unfavorably to teammates. This conversation ends in defensiveness, not improvement. He might disengage or leave.
✅ Good Approach:
You: "David, I want to talk about something I've noticed over the last few sprints. I've
seen a pattern where your pull requests are requiring significant rework after
initial review. For example, last week's authentication feature had issues with
error handling that weren't caught until QA. The week before, the data validation
logic needed to be redone. I'm concerned because I know you're capable of better
work—I've seen it. So I want to understand what's happening. What are you seeing?"
David: "Honestly, I feel like I'm always rushing. By the time I understand the
requirements, I don't have much time left in the sprint."
You: "Okay, so timing and requirements clarity. Tell me more about the requirements
piece."
David: "When I get a ticket, it's often high-level. I make assumptions about what's
needed, but then it turns out I was wrong."
You: "That's useful to know. So you're getting to code too quickly without fully
understanding the problem. Here's what I'm thinking: first, when you get a new
ticket, before writing any code, let's have a quick 15-minute conversation where
you walk me through your understanding and approach. That way we can catch gaps
early.
Second, I want you to start writing a brief technical design doc for any feature—
even small ones. Nothing formal, just: what's the problem, what's your approach,
what are the edge cases. Share it in Slack before coding. This forces you to think
through it.
Third, let's look at your work in progress mid-sprint, not just at PR time. If
something's going off track, we'll catch it earlier.
How does that sound?"
David: "That makes sense. I think that would help."
You: "Good. Let's try this for the next two sprints. I'm confident this will improve
things. But I also need to be clear: the current quality level isn't sustainable.
If we don't see improvement after we implement these changes, we'll need to have
a more serious conversation about fit. I want to help you succeed, but I also need
to protect the team's velocity and morale. Does that make sense?"Why it’s good: You’ve been specific about the problem with examples. You’ve listened to his perspective. You’ve created a concrete improvement plan. You’ve been clear about consequences while also being supportive. David leaves knowing what’s expected and how to succeed.
Scenario D: The Disengaged High Performer
Context: At Tricentis, your best engineer, Anita, has been quieter than usual. She’s still delivering, but the energy is gone. She used to volunteer for complex work; now she just does what’s assigned.
❌ Bad Approach:
You: "Anita, is everything okay? You seem less engaged lately."
Anita: "I'm fine. Just busy."
You: "Okay, good. Let me know if you need anything."Why it’s bad: You’ve accepted a surface-level answer to a potentially serious problem. You haven’t created safety for her to open up. You’ve missed a chance to understand what’s really happening.
✅ Good Approach:
You: "Anita, I want to check in with you about something I've noticed. Over the last
month or so, you seem different. You're still doing great work—that's not the
concern. But I remember a few months ago, you were really excited about the BI
pipeline architecture, and you were the first to volunteer for the Qlik
integration challenges. Lately, you're quieter in meetings, and I haven't seen
that same energy. I'm wondering what's changed. And before you say 'nothing'—it's
okay if something is going on. This is a safe space to talk about it."
Anita: [pause] "Honestly... I don't know if I'm growing here anymore."
You: "Okay, tell me more about that. What does growth look like for you?"
Anita: "I feel like I'm doing the same type of work over and over. Data pipelines,
integrations, optimizations. I'm good at it, but I'm not learning."
You: "So you're feeling stagnant. What would make you feel like you're growing?"
Anita: "I want to work on something newer—maybe distributed systems, or machine learning
infrastructure. Something that challenges me differently."
You: "That makes a lot of sense. And I should have asked about this sooner. Here's what
I'm thinking: we have the RPA project coming up—it's a different problem space
with interesting distributed systems challenges. Would that interest you? I can't
promise it's machine learning, but it's definitely outside your current work."
Anita: "Yeah, that could be interesting."
You: "Okay. Let's do this: I'll get you on that project. But I also want to think longer
term. If the work here can't provide the growth you need, I want to know that
honestly. I'd rather help you find the right role—even if it's not on this
team—than have you quietly disengage. Can you commit to keeping this conversation
going? If you're still feeling stuck in a few months, let's talk about it?"
Anita: "I can do that. Thanks for bringing it up."Why it’s good: You’ve named the specific change you observed. You created safety for honesty. You listened without defensiveness. You offered a concrete opportunity while also acknowledging you might not be able to meet all her needs. Anita leaves feeling seen and supported.
5. Practice Exercises: Developing This Skill
Exercise 1: Self-Audit Your Current One-on-Ones
If you’re already running one-on-ones, audit them honestly:
- Consistency Check
- Review the last 3 months. What percentage of scheduled one-on-ones actually happened?
- If it’s below 80%, you have a consistency problem. Fix this first.
- Talk Ratio Analysis
- In your next three one-on-ones, track who talks more.
- Set a timer: every 5 minutes, note who was talking more in that segment.
- Target: they should talk 60-70% of the time.
- Topic Analysis
- Review your notes from the last 5 one-on-ones.
- Categorize topics: Status Updates, Career Development, Feedback, Personal Challenges, Team Dynamics, Other.
- If more than 30% is Status Updates, you’re using the time wrong.
- Follow-Through Check
- List all action items from your last 10 one-on-ones.
- How many did you actually complete? If it’s below 70%, you’re eroding trust.
Exercise 2: Question Practice
Good questions are skills you develop. Practice these:
Week 1: The Open Question
In every one-on-one, start with a completely open question and then stay silent for at least 10 seconds. Options:
- “What’s on your mind?”
- “What’s been going well? What’s been hard?”
- “If you could change one thing this week, what would it be?”
Track your discomfort with the silence. That discomfort is you learning to create space.
Week 2: The Follow-Up
When someone gives you an answer, practice digging deeper:
- “Tell me more about that.”
- “How did that make you feel?”
- “What else?”
Goal: ask at least two follow-up questions before you say anything substantive.
Week 3: The Coaching Question
When someone brings you a problem, resist solving it. Instead:
- “What have you already tried?”
- “What options are you considering?”
- “If you were making this decision, what would you do?”
Week 4: The Growth Question
Dedicate time in each one-on-one to long-term development:
- “What’s one skill you want to build this quarter?”
- “What energizes you about your work? What drains you?”
- “Where do you want to be in a year?”
Exercise 3: Feedback Role-Play
Practice giving feedback (both positive and constructive) using the SBI model:
Setup:
Think of three real situations from your recent experience:
- Something a team member did well
- Something that was problematic but minor
- Something that was a significant issue
Practice:
Write out the feedback using SBI:
- Situation: When/where did this happen?
- Behavior: What exactly did they do/say?
- Impact: What was the effect?
Example from your Aperia Solutions experience:
- Situation: “In yesterday’s architecture review for the port management service…”
- Behavior: “…when you pushed back on the proposed database schema…”
- Impact: “…it helped us identify a critical data integrity issue before we built it. That kind of critical thinking is exactly what we need from senior engineers.”
Practice delivering these out loud. Record yourself if possible. Does it sound natural? Specific? Kind but clear?
Exercise 4: The Hard Conversation Prep
Think of a difficult conversation you’ve been avoiding (performance issue, behavior problem, someone who seems disengaged). Prepare for it:
- Write down:
- What specific behavior have you observed?
- What is the impact of this behavior?
- What outcome do you want from the conversation?
- Script your opening:
- Make it direct but kind
- Focus on behavior, not character
- Express your intent to help
- Anticipate responses:
- What if they get defensive?
- What if they cry?
- What if they disagree with your observation?
- Plan your support:
- What specific help can you offer?
- What resources can you provide?
- What is your follow-up plan?
Then have the conversation. Don’t wait.
Exercise 5: Note-Taking System
If you’re not taking good notes, start now:
- Create the template (shown earlier in section 2)
- During/after the meeting, capture:
- Key topics discussed
- Action items (with owner and deadline)
- Career insights or patterns you notice
- Any commitments you made
- Before each one-on-one, review:
- Last meeting’s notes
- Outstanding action items
- Long-term themes
- Quarterly review:
- Read through all notes for each person
- Identify patterns
- Ask yourself: “Is this person growing? Are they engaged? What themes keep coming up?”
Exercise 6: Empathy Building
One-on-ones require genuine empathy. Practice this:
The Perspective Shift Exercise:
For each person on your team, write answers to:
- What do they care most about in their career?
- What are they probably worried about that they haven’t told you?
- What would make them consider leaving?
- What energizes them about their work?
- What frustrates them?
Don’t guess wildly—base this on what you’ve observed and what they’ve told you. Then, in your next one-on-one, validate your assumptions by asking about them.
Exercise 7: The Growth Plan Workshop
Pick one team member. Create a 6-month growth plan:
- Current State: What are they doing now? What are they good at?
- Desired State: Where do they want to be in 6 months? (If you don’t know, ask them.)
- Gap Analysis: What skills/experiences separate current from desired state?
- Opportunities: What projects/tasks/learning can bridge that gap?
- Support: What resources, time, or guidance do you need to provide?
- Milestones: What would success look like at 1 month, 3 months, 6 months?
Discuss this plan in your next one-on-one. Iterate on it together.
6. Key Takeaways: What to Remember
The Non-Negotiables
- Consistency is everything. One-on-ones only work if they happen regularly. Protect this time.
- Their agenda, not yours. This meeting belongs to them. Their topics come first.
- Listen more than you talk. Target: 70% them, 30% you.
- Coach, don’t solve. Your job is to help them develop judgment, not to solve all their problems.
- Take notes and follow through. Words without action erode trust faster than silence.
- Different levels need different approaches. Junior engineers need structure; senior engineers need strategic partnership.
- Address issues early. Avoiding difficult conversations doesn’t make them go away—it makes them worse.
The Mindset
One-on-ones are not overhead—they’re the core of your job. You can write brilliant architecture documents, run flawless sprint planning, and deliver perfect code reviews. But if you’re not investing in your people through quality one-on-ones, you’re not leading.
Think of it as building a high-performance distributed system. Each one-on-one is like establishing a reliable connection between nodes. Without these connections, the system fails. With them, it scales beautifully.
The Long-Term View
Great one-on-ones compound over time. After six months of consistent, high-quality one-on-ones:
- Trust is deep enough that people tell you about problems early
- You understand each person well enough to match them with the right opportunities
- They feel invested in because you’ve demonstrated consistent care
- Career development is continuous, not an annual review surprise
- Your team’s engagement and retention are higher
The engineers you lead will remember great one-on-ones long after they forget your technical decisions.
Your Action Plan
Starting now:
This Week:
- If you don’t have one-on-ones scheduled, set up recurring meetings with everyone you lead
- Create the shared doc template for each person
- Review your calendar—are these meetings actually happening?
This Month:
- Audit your current one-on-ones using Exercise 1
- Practice the question frameworks in Exercise 2
- Have at least one career development conversation with each person
This Quarter:
- Establish a consistent rhythm and format for your one-on-ones
- Get feedback: ask each person, “How can I make our one-on-ones more valuable for you?”
- Address at least one difficult conversation you’ve been avoiding
- Create growth plans (Exercise 7) for each team member
Long-Term:
- Make one-on-ones a core part of your leadership practice
- Continuously improve: try new questions, approaches, formats
- Pay attention to what works with different people and adapt
- Reflect quarterly: are your people growing? Are they engaged?
The Ultimate Test
Here’s how you know your one-on-ones are working:
- Your team members rarely cancel; they value the time
- People bring meaningful topics, not just status updates
- Hard conversations happen, but they’re productive
- You can describe each person’s career goals and current challenges
- Your team’s retention is high
- When people do leave, they thank you for your support in their growth
One-on-ones are where leadership actually happens. Everything else is management. Master this skill, and you’ll be the leader people choose to follow.
Appendix: Templates and Checklists
One-on-One Meeting Template
# One-on-Ones: [Name]
Role: [Current Role]
Started: [Date]
## Career Goals
- Short-term (6 months):
- Long-term (2-3 years):
- Current development focus:
---
## [Date: YYYY-MM-DD]
### Their Topics
-
-
### My Topics
-
-
### Action Items
- [ ] [Name] - [Action] - Due: [Date]
- [ ] [Your Name] - [Action] - Due: [Date]
### Notes
-
-
### Energy Check
On a scale of 1-10, how happy are you with your work right now? [ ]
What would make it higher?
---
## [Previous dates continue below...]Pre-Meeting Checklist
Before each one-on-one, check:
- [ ] Review notes from last meeting
- [ ] Check status of action items
- [ ] Review any recent work/code from this person
- [ ] Identify any feedback (positive or constructive) to share
- [ ] Note any team/company context they need
- [ ] Block calendar and turn off notifications
- [ ] Set mental intention: this time is for them
Monthly Deep Dive Questions
Pick 1-2 of these to ask each month:
Career & Growth:
- “On a scale of 1-10, how challenged do you feel by your work? What would make it higher?”
- “What skills do you want to build this quarter?”
- “Who in the company/industry do you admire? What do they do that you’d like to do?”
- “What’s one thing I could do to better support your growth?”
Job Satisfaction:
- “What parts of your work energize you? What drains you?”
- “If you could change one thing about your role, what would it be?”
- “How do you feel about the team right now? The company?”
- “What’s something you wish you had more time for?”
Relationship & Feedback:
- “How am I doing as your manager? What could I do differently?”
- “Is there anything I’m doing that’s getting in your way?”
- “Do you feel heard and supported by me?”
- “What’s one thing the team does well? One thing we could improve?”
Quarterly Review Questions
Every 3 months, ask yourself about each person:
- Growth: Has this person developed new skills or taken on new challenges?
- Engagement: Do they seem energized and engaged, or just going through the motions?
- Performance: Are they meeting expectations? Exceeding them? Falling short?
- Relationships: How are their relationships with teammates and stakeholders?
- Career trajectory: Are they on track for their goals? Do I know what those goals are?
- Risk: Is there any risk of this person leaving? Why?
- Support: What additional support do they need from me?
Feedback Framework Quick Reference
SBI Model (Situation-Behavior-Impact):
- Situation: “In [specific context/time]…”
- Behavior: “When you [specific action]…”
- Impact: “It [specific result/effect].”
Positive Example: “In yesterday’s architecture review, when you proposed the caching strategy, it helped the team see a clear path forward. That’s exactly the kind of technical leadership we need.”
Constructive Example: “In last week’s sprint planning, when you dismissed the team’s estimates, several people felt unheard. I want to make sure everyone’s input is valued.”
Key Rules:
- Recent (within a week)
- Specific (not “you need to communicate better”)
- Behavioral (what they did, not who they are)
- Balanced (both positive and constructive)
- Actionable (they can change it)
Remember: One-on-ones are not a task to complete—they’re an investment in people. The quality of these conversations directly determines the quality of your leadership.
Interview Practice: Running Effective One-on-Ones
Q1: "What is your approach to structuring one-on-ones and what makes them effective rather than just routine check-ins?"
Why interviewers ask this Many managers run one-on-ones as status updates — missing their real value. Interviewers want to see whether you understand the purpose deeply and have a practice that reflects that understanding.
Sample Answer
I think of one-on-ones as the primary place where I do leadership — not where I receive reports. The distinction matters because it changes what you do in the meeting. A one-on-one structured as a status update is about information flow to me. A one-on-one structured as a coaching and support conversation is about what the engineer needs from me. My default structure has three parts: first, I ask what's on their mind — I let them lead, not me. This surfaces what they're actually thinking about rather than what I've prepared to discuss. Second, if there's nothing urgent from them, I ask coaching questions: What's going well? What feels stuck? What would make this week better? Third, I bring my own items — context to share, observations, feedback, things I need from them. I keep my items for the end because if I lead with mine, we spend the whole time on my agenda and I never learn what's real on their end. The most important discipline is being consistent. Engineers who trust that their one-on-one will happen reliably and will be a safe space for honesty will bring real things to it. Engineers who've had one-on-ones canceled frequently bring nothing.
Q2: "How do you adapt your one-on-one approach for different types of engineers — junior, senior, struggling, high performers?"
Why interviewers ask this Good one-on-ones aren't uniform. Interviewers want to see whether you read each person and adjust accordingly — and whether you understand that different career stages need fundamentally different conversations.
Sample Answer
With junior engineers, one-on-ones are heavily coaching-oriented — I ask a lot of questions about how they're learning, what's confusing, what they need to grow faster. I pay close attention to their confidence levels and make sure they understand the broader context of the work they're doing. With senior engineers, I spend more time on strategic alignment — their perspective on the team's direction, friction points they're seeing, ideas they want to develop. I try to treat them as peers in the conversation, not as people I'm managing. For struggling engineers, the one-on-one becomes the primary coaching touchpoint — I'm explicit about the gap I see, I ask what support they need, and I track whether the situation is changing. I try to make sure the conversation doesn't feel like surveillance but does feel like someone who cares about their success paying close attention. For disengaged high performers — a particularly important case — I focus on understanding what's drawing them toward disengagement. Often the issue is boredom, lack of challenge, or feeling like their work isn't visible. The one-on-one is where that signal surfaces first, if I'm asking the right questions. One-size-fits-all one-on-ones are one of the most common leadership mistakes I see.
Q3: "How do you use one-on-ones to give feedback regularly rather than saving it for performance reviews?"
Why interviewers ask this Continuous feedback is more effective than annual reviews — but it requires discipline and a communication climate where feedback is normalized. Interviewers want to see whether you've built that practice.
Sample Answer
I have a simple rule: no surprises at review time. If I can't say in a performance review that the person has already heard this feedback before, I haven't done my job. That means specific, timely feedback is a regular part of every one-on-one cycle — not a separate event. Practically, I look for feedback opportunities between one-on-ones so I have something concrete for each meeting. Positive feedback goes in quickly — I don't save appreciation for one-on-ones, I give it as close to the moment as possible. Developmental feedback that's concrete and specific also comes up promptly: "In the design review this week, I noticed X. I wanted to share what I observed and how you might handle that differently." What I've found is that engineers who get regular honest feedback trust the environment more than those who only hear critical things at formal review moments. They can also absorb and act on feedback better when it's specific and recent rather than summarized and stale. I also invite them to give me feedback: "Is there something I could be doing differently that would help you more?" That models the behavior and often leads to genuinely useful information.
Q4: "What do you do when an engineer consistently doesn't bring anything to your one-on-ones or gives only surface-level answers?"
Why interviewers ask this Disengaged or closed engineers are a challenge in one-on-ones. Interviewers want to see whether you notice this pattern and respond intentionally rather than concluding everything is fine.
Sample Answer
I take shallow one-on-ones as a signal about the environment, not just about the person. If someone is consistently giving me surface answers, one of several things is happening: they don't trust that the space is safe for honesty, they don't think it will lead to anything useful, or they've never had a manager who modeled what a real one-on-one conversation looks like. My first response is to change what I bring. Instead of open questions that can be answered shallowly, I bring something specific from my observations: "I noticed this week that you seemed less engaged in the architecture discussion than usual. I wanted to check in on that directly." That specific observation is harder to deflect than "how are you doing?" I also sometimes name the pattern directly: "I feel like we've been staying on the surface in our one-on-ones. I want to make this more useful for you — is there something that would make it feel safer to bring real things here?" That meta-conversation sometimes unlocks something. And I'm patient — trust is built slowly. Consistency over several months of reliably showing up, listening, and acting on what I hear is often what eventually changes the dynamic.
Q5: "How do you use one-on-ones to identify and address flight risk in engineers you want to retain?"
Why interviewers ask this Retaining talent is a leadership responsibility, and one-on-ones are realistically the best early-warning system. Interviewers want to see whether you're attuned to disengagement signals before they become exit conversations.
Sample Answer
The signals I watch for: declining quality of responses in one-on-ones, loss of initiative on work that used to energize them, vague or short answers where they used to be expansive, and any increase in interest in external opportunities or comparison of company practices to other places. When I see a cluster of these, I have a direct and transparent conversation: "I've noticed a shift in your engagement over the last few weeks. I want to be honest — I'd rather understand what's going on now than lose you to a reason I didn't know about." Most engineers appreciate that directness if it comes from genuine respect rather than panic. The answers I hear most often are: the work isn't challenging anymore, they feel their growth has stalled, they feel invisible to the organization, or something structural in the team is frustrating them. Each has a response. Sometimes the response is changing their work scope; sometimes it's making their career path more concrete; sometimes it's changing reporting relationships; sometimes it's that I can't solve what's bothering them and they're right to move on. The honest conversation is better than late-stage retention offers that communicate I didn't notice until they'd already decided.
Q6: "How do you turn a one-on-one into a coaching conversation rather than a reporting session?"
Why interviewers ask this This is a technique and philosophy question. Interviewers want to see whether you have specific conversational practices that shift the dynamic toward development rather than status reporting.
Sample Answer
The primary tool is the type of question you ask. Reporting questions — "Where is that feature? Did you finish the PR?" — pull toward status. Coaching questions — "What's the hardest part of this feature for you right now?", "How are you thinking about the trade-off between X and Y?", "What would you do differently if you were starting this again?" — pull toward reflection and learning. I consciously avoid asking about deliverable status in one-on-ones — I have other mechanisms for that. Status updates belong in standups or async tools. One-on-ones are too rare and too valuable to use for information I can get elsewhere. I also coach on what I observe in the broader environment, not just what they bring to me. "I watched how you handled a difficult conversation in the team meeting last week. I'd like to talk about that — what was your thinking in the moment?" That brings real situations into coaching rather than keeping it abstract. Finally, I try to end each one-on-one with a forward commitment: "What's the one thing you want to focus on before we talk next week?" That closes the loop and gives continuity to the development conversation across multiple sessions rather than treating each meeting as isolated.
Q7: "How do you maximize the value of one-on-ones when you're time-constrained or managing a large team?"
Why interviewers ask this At scale, one-on-one time compresses. Interviewers want to see whether you have practices for maintaining quality at higher volume — not just meeting the calendar obligation.
Sample Answer
The first thing I protect is consistency over frequency. A reliable thirty-minute meeting every two weeks is more valuable than an occasional hour-long meeting when schedules align. Consistency is more important to trust than duration. When I have a larger team, I triage intentionally: who needs most of my one-on-one investment right now? New team members, people in difficult situations, and people at inflection points in their growth or career all warrant more frequent or longer meetings. Stable, high-performing engineers in steady state might be fine bi-weekly or monthly. I also use async context-building to make the live time more valuable. I maintain running notes and track themes across one-on-ones so I'm not starting cold every meeting. Walking in knowing "last week they mentioned a blocker in a collaboration with team X — I should ask about that" is better than starting blank. What I don't do is cancel. Canceling a one-on-one sends a clear signal about priority. I'd rather shorten a meeting to fifteen minutes than cancel it. And I periodically ask engineers explicitly: "Is this meeting valuable to you? What would make it more useful?" That keeps it from becoming a ritual that exists because it's scheduled rather than because it's serving both of us.
Interview Practice: Running Effective One-on-Ones
Q1: "What is your approach to structuring one-on-ones and what makes them effective rather than just routine check-ins?"
Why interviewers ask this Many managers run one-on-ones as status updates — missing their real value. Interviewers want to see whether you understand the purpose deeply and have a practice that reflects that understanding.
Sample Answer
I think of one-on-ones as the primary place where I do leadership — not where I receive reports. The distinction matters because it changes what you do in the meeting. A one-on-one structured as a status update is about information flow to me. A one-on-one structured as a coaching and support conversation is about what the engineer needs from me. My default structure has three parts: first, I ask what's on their mind — I let them lead, not me. This surfaces what they're actually thinking about rather than what I've prepared to discuss. Second, if there's nothing urgent from them, I ask coaching questions: What's going well? What feels stuck? What would make this week better? Third, I bring my own items — context to share, observations, feedback, things I need from them. I keep my items for the end because if I lead with mine, we spend the whole time on my agenda and I never learn what's real on their end. The most important discipline is being consistent. Engineers who trust that their one-on-one will happen reliably and will be a safe space for honesty will bring real things to it. Engineers who've had one-on-ones canceled frequently bring nothing.
Q2: "How do you adapt your one-on-one approach for different types of engineers — junior, senior, struggling, high performers?"
Why interviewers ask this Good one-on-ones aren't uniform. Interviewers want to see whether you read each person and adjust accordingly — and whether you understand that different career stages need fundamentally different conversations.
Sample Answer
With junior engineers, one-on-ones are heavily coaching-oriented — I ask a lot of questions about how they're learning, what's confusing, what they need to grow faster. I pay close attention to their confidence levels and make sure they understand the broader context of the work they're doing. With senior engineers, I spend more time on strategic alignment — their perspective on the team's direction, friction points they're seeing, ideas they want to develop. I try to treat them as peers in the conversation, not as people I'm managing. For struggling engineers, the one-on-one becomes the primary coaching touchpoint — I'm explicit about the gap I see, I ask what support they need, and I track whether the situation is changing. I try to make sure the conversation doesn't feel like surveillance but does feel like someone who cares about their success paying close attention. For disengaged high performers — a particularly important case — I focus on understanding what's drawing them toward disengagement. Often the issue is boredom, lack of challenge, or feeling like their work isn't visible. The one-on-one is where that signal surfaces first, if I'm asking the right questions. One-size-fits-all one-on-ones are one of the most common leadership mistakes I see.
Q3: "How do you use one-on-ones to give feedback regularly rather than saving it for performance reviews?"
Why interviewers ask this Continuous feedback is more effective than annual reviews — but it requires discipline and a communication climate where feedback is normalized. Interviewers want to see whether you've built that practice.
Sample Answer
I have a simple rule: no surprises at review time. If I can't say in a performance review that the person has already heard this feedback before, I haven't done my job. That means specific, timely feedback is a regular part of every one-on-one cycle — not a separate event. Practically, I look for feedback opportunities between one-on-ones so I have something concrete for each meeting. Positive feedback goes in quickly — I don't save appreciation for one-on-ones, I give it as close to the moment as possible. Developmental feedback that's concrete and specific also comes up promptly: "In the design review this week, I noticed X. I wanted to share what I observed and how you might handle that differently." What I've found is that engineers who get regular honest feedback trust the environment more than those who only hear critical things at formal review moments. They can also absorb and act on feedback better when it's specific and recent rather than summarized and stale. I also invite them to give me feedback: "Is there something I could be doing differently that would help you more?" That models the behavior and often leads to genuinely useful information.
Q4: "What do you do when an engineer consistently doesn't bring anything to your one-on-ones or gives only surface-level answers?"
Why interviewers ask this Disengaged or closed engineers are a challenge in one-on-ones. Interviewers want to see whether you notice this pattern and respond intentionally rather than concluding everything is fine.
Sample Answer
I take shallow one-on-ones as a signal about the environment, not just about the person. If someone is consistently giving me surface answers, one of several things is happening: they don't trust that the space is safe for honesty, they don't think it will lead to anything useful, or they've never had a manager who modeled what a real one-on-one conversation looks like. My first response is to change what I bring. Instead of open questions that can be answered shallowly, I bring something specific from my observations: "I noticed this week that you seemed less engaged in the architecture discussion than usual. I wanted to check in on that directly." That specific observation is harder to deflect than "how are you doing?" I also sometimes name the pattern directly: "I feel like we've been staying on the surface in our one-on-ones. I want to make this more useful for you — is there something that would make it feel safer to bring real things here?" That meta-conversation sometimes unlocks something. And I'm patient — trust is built slowly. Consistency over several months of reliably showing up, listening, and acting on what I hear is often what eventually changes the dynamic.
Q5: "How do you use one-on-ones to identify and address flight risk in engineers you want to retain?"
Why interviewers ask this Retaining talent is a leadership responsibility, and one-on-ones are realistically the best early-warning system. Interviewers want to see whether you're attuned to disengagement signals before they become exit conversations.
Sample Answer
The signals I watch for: declining quality of responses in one-on-ones, loss of initiative on work that used to energize them, vague or short answers where they used to be expansive, and any increase in interest in external opportunities or comparison of company practices to other places. When I see a cluster of these, I have a direct and transparent conversation: "I've noticed a shift in your engagement over the last few weeks. I want to be honest — I'd rather understand what's going on now than lose you to a reason I didn't know about." Most engineers appreciate that directness if it comes from genuine respect rather than panic. The answers I hear most often are: the work isn't challenging anymore, they feel their growth has stalled, they feel invisible to the organization, or something structural in the team is frustrating them. Each has a response. Sometimes the response is changing their work scope; sometimes it's making their career path more concrete; sometimes it's changing reporting relationships; sometimes it's that I can't solve what's bothering them and they're right to move on. The honest conversation is better than late-stage retention offers that communicate I didn't notice until they'd already decided.
Q6: "How do you turn a one-on-one into a coaching conversation rather than a reporting session?"
Why interviewers ask this This is a technique and philosophy question. Interviewers want to see whether you have specific conversational practices that shift the dynamic toward development rather than status reporting.
Sample Answer
The primary tool is the type of question you ask. Reporting questions — "Where is that feature? Did you finish the PR?" — pull toward status. Coaching questions — "What's the hardest part of this feature for you right now?", "How are you thinking about the trade-off between X and Y?", "What would you do differently if you were starting this again?" — pull toward reflection and learning. I consciously avoid asking about deliverable status in one-on-ones — I have other mechanisms for that. Status updates belong in standups or async tools. One-on-ones are too rare and too valuable to use for information I can get elsewhere. I also coach on what I observe in the broader environment, not just what they bring to me. "I watched how you handled a difficult conversation in the team meeting last week. I'd like to talk about that — what was your thinking in the moment?" That brings real situations into coaching rather than keeping it abstract. Finally, I try to end each one-on-one with a forward commitment: "What's the one thing you want to focus on before we talk next week?" That closes the loop and gives continuity to the development conversation across multiple sessions rather than treating each meeting as isolated.
Q7: "How do you maximize the value of one-on-ones when you're time-constrained or managing a large team?"
Why interviewers ask this At scale, one-on-one time compresses. Interviewers want to see whether you have practices for maintaining quality at higher volume — not just meeting the calendar obligation.
Sample Answer
The first thing I protect is consistency over frequency. A reliable thirty-minute meeting every two weeks is more valuable than an occasional hour-long meeting when schedules align. Consistency is more important to trust than duration. When I have a larger team, I triage intentionally: who needs most of my one-on-one investment right now? New team members, people in difficult situations, and people at inflection points in their growth or career all warrant more frequent or longer meetings. Stable, high-performing engineers in steady state might be fine bi-weekly or monthly. I also use async context-building to make the live time more valuable. I maintain running notes and track themes across one-on-ones so I'm not starting cold every meeting. Walking in knowing "last week they mentioned a blocker in a collaboration with team X — I should ask about that" is better than starting blank. What I don't do is cancel. Canceling a one-on-one sends a clear signal about priority. I'd rather shorten a meeting to fifteen minutes than cancel it. And I periodically ask engineers explicitly: "Is this meeting valuable to you? What would make it more useful?" That keeps it from becoming a ritual that exists because it's scheduled rather than because it's serving both of us.