How I run a 1:1 with engineers that actually works

How I run a 1:1 with engineers that actually works

In a 50 person engineering org, a CTO with 8 direct reports can spend 4 hours a week in 1:1s. That is 200 hours a year per report if you meet weekly for 30 minutes. If those hours turn into status updates, you just burned a month of leadership time.

Here’s my thesis. A 1:1 works when it builds trust and produces clear next actions, and when it surfaces problems before they hit production.

What is a good engineering 1:1 meeting, and what is it not?

Most CTOs I talk to fall into the same trap. The 1:1 becomes a private standup. You talk about Jira, blockers, and dates. Then you wonder why morale drops, why people leave, and why you hear about the real issues too late.

A good 1:1 is a weekly, private, predictable conversation that helps an engineer do better work and grow. It’s also your early warning system.

Here’s my quotable definition.

A working 1:1 is a recurring conversation that compounds trust and turns fuzzy concerns into specific commitments.

A 1:1 is not:

• A status meeting. Save that for standups, demos, and written updates.
• A performance review. You can discuss performance, but you don’t “surprise” people.
• A therapy session. You can talk about stress and burnout, but you still need actions.
• A gossip channel. Private notes stay private, and you don’t relay stories between people.

That last point sounds obvious. It still breaks trust fast. The Off by One guide is blunt about it: don’t share notes, don’t gossip, and don’t repeat what you heard in a 1:1 to anyone else, even if it is true (Running 1:1s for Engineers).

What a 1:1 can do well

• Alignment. Connect daily work to strategy and expectations.
• Risk detection. Catch friction, confusion, and burnout early.
• Decision quality. Pressure test technical choices with the people closest to the code.
• Growth. Build a plan that matches the engineer’s goals and the org’s needs.

End state: the engineer leaves the meeting feeling heard, clearer, and unblocked.

How often should CTOs run 1:1s with engineers?

Cadence isn’t a preference. Cadence is a signal.

I default to weekly 30 minutes for direct reports. For skip levels, I do monthly 30 minutes or quarterly 45 minutes, depending on org size.

Why weekly? Monthly is too slow for trust and too slow for risk. Josh Hornby says weekly or fortnightly works for most teams, and monthly is too rare to build a real relationship (Running Effective 1:1s as a Tech Lead).

Why not 60 minutes every week? For many CTO roles, it doesn’t scale. I use 60 minutes in two cases:

• New manager in first 90 days. You need more context and coaching.
• Active incident or reorg. People need space to talk.

Pluralsight makes a good point about depth. Short meetings get eaten by surface updates, and thorny issues show up later in the conversation (Effective 1:1 meetings with your engineering team). If you only have 30 minutes, you have to protect the agenda from status.

My hard rule: don’t cancel. Reschedule if you must, but don’t drop it. Cancelling tells people they’re not a priority, and Hornby calls that out directly (Running Effective 1:1s as a Tech Lead).

My 1:1 agenda that engineers actually use

I run 1:1s with a light script. Not because I love process, but because routine makes it safer to bring up the hard stuff.

I also use a named framework so my managers can copy it without guessing.

The P3 1:1 Framework: People, Product, Process

I didn’t invent this. I keep using it because it holds up.

Milan’s newsletter describes the “People, Product, Process” structure and makes the key point that 1:1s should focus on the employee’s needs, not status updates (How to run exceptional 1:1 for Engineers). Off by One recommends the same structure and stresses routine and written history (Running 1:1s for Engineers).

Here’s how I run it in 30 minutes.

• People (10 minutes). Energy, relationships, growth, stress.
• Product (10 minutes). What are we building, and why does it matter?
• Process (10 minutes). How work flows, where it gets stuck, and what to change.

If we need to go deep, we steal time from Product and Process. I don’t steal time from People.

The exact questions I ask

I keep the questions stable so engineers don’t have to guess what “good” looks like.

People:

• “How’s your energy this week, 1 to 10?”
• “What has been frustrating?”
• “Who have you been working with a lot, and how is that going?”
• “What do you want to learn in the next 60 days?”

Product:

• “What feels unclear about the goal?”
• “What trade-off are you worried we are making?”
• “If you were the PM for a day, what would you cut?”

Process:

• “Where did you lose time this week?”
• “What is the one meeting you would delete?”
• “What is one change we can try for two weeks?”

I also ask one question that keeps me honest:

• “What should I start doing, stop doing, or keep doing?”

Franz Vitulli describes a similar pattern. He starts by following up on the last concern, and he keeps notes per person so nothing drops (A Product Manager’s guide to doing 1:1 meetings with engineers). That follow-up step is the difference between “nice chat” and trust.

The note system that makes follow-through real

I use one doc per engineer. It has four sections:

• Open loops. Promises I made, with dates.
• Themes. Repeated topics like burnout, scope, or conflict.
• Growth plan. Skills, projects, and feedback.
• Private notes. Context I need for coaching.

I write during the meeting. I keep it short. I never share it.

Off by One is strict about privacy, and I’m with them. If people think your notes can show up in a performance packet, they’ll stop telling you the truth (Running 1:1s for Engineers).

A real scenario: the “status update” smell

A staff engineer starts every 1:1 with a sprint recap. That’s a smell.

I interrupt kindly:

“I already saw the PRs and the board. What’s the part that worries you?”

Nine times out of ten, you get the real topic:

• “I don’t think this design will scale past 10 million rows.”
• “I’m stuck waiting on security review again.”
• “I’m doing on-call and I’m not sleeping.”

That’s the meeting you wanted.

How I handle awkward topics without blowing up trust

The best 1:1s include topics you can’t say in Slack. Milan calls this out directly. You have to be willing to say the awkward things, and trust grows through small promises kept (How to run exceptional 1:1 for Engineers).

I use three rules.

Talk about behavior, not character

Hornby gives the cleanest phrasing I’ve seen:

• “You’ve been late to the last four standups” is behavior.
• “You’re unreliable” is character.

Behavior gives you something to change. Character starts a fight (Running Effective 1:1s as a Tech Lead).

Ask for their recommendation before you give yours

Nick Proud describes a pattern I use all the time. Engineers assume leaders have the answer. They wait for permission. The fix is simple:

“I don’t know. What would you recommend?”

Then you ask follow-up questions until the engineer hears their own plan out loud (Nick Proud on 1:1s).

This isn’t a trick. It’s how you build ownership.

Close the loop in writing

A hard conversation without follow-up is just discomfort.

So I end with two lines:

• “What will you do before next week?”
• “What will I do before next week?”

Then I write both in the doc under Open loops.

A real example from a platform team:

• Engineer: “Security review takes 12 business days. It blocks releases.”
• Me: “I will meet security lead by Friday. You will draft a one page proposal for a risk tier model.”

Next week, we review what happened. If I didn’t meet the security lead, I say so. I also say why. That honesty matters more than the excuse.

How 1:1s improve technical outcomes, not just morale

CTOs don’t get paid to run nice meetings. We get paid to ship reliable systems with stable teams.

A good 1:1 changes technical outcomes in three ways.

You find production risks before they page you

Engineers often see failure coming. They just don’t have a safe place to say it.

In a 1:1, you can ask:

• “What part of the system scares you right now?”
• “What is the failure mode we are ignoring?”

If you hear the same risk from three people, treat it like an incident in slow motion.

This ties directly to our guide to blameless incident postmortems at /tools/incident-postmortem. Use the same habit. Capture facts, actions, and owners. Then follow up.

You get better architecture decisions through pressure testing

A CTO can’t review every design doc. But you can sample the thinking.

I ask senior engineers:

• “What did we reject, and why?”
• “What is the migration plan if this choice fails?”
• “What is the cost curve at 10x traffic?”

Then I log themes in Command Center at /command-center as risks or tech debt items. That keeps the 1:1 from becoming a private complaint channel. It becomes input into a visible system.

If you need a clean way to document the architecture you’re debating, our ArchiMate Modeler at /tools/archimate helps. A simple model beats a 30 page doc.

You reduce burnout and attrition by catching load issues early

Burnout shows up as small signals:

• More sharp comments in code review.
• Less curiosity.
• More “fine” answers.

A LinkedIn post by Ido Shamun calls out the burnout trap when speed starts to crush wellness, and it pushes leaders to set tighter boundaries (Ido Shamun on 1:1s that matter).

In practice, I track one metric per engineer in my head.

Sustainable pace score: 1 to 5

• 1: on-call pain, late nights, constant interrupts
• 3: normal load, occasional spikes
• 5: steady work, time to think, time to learn

If someone sits at 1 or 2 for three weeks, I act. I move on-call load, I cut scope, or I add help.

Enterprise implications for CTOs

1. Skip-level 1:1s become your sensor network. In orgs of 150+ engineers, directors and managers filter reality. Monthly skip-levels catch cultural drift, hidden process debt, and quiet attrition risk.

2. Vendor and platform decisions show up as frustration first. Engineers will tell you “this tool is killing us” long before a dashboard does. Use 1:1s to feed your Build vs Buy calls, then document the decision in our Build vs Buy Matrix at /tools/build-vs-buy-matrix.

3. Security and compliance gaps surface as workarounds. If people admit they bypass reviews to ship, you have a control failure. Treat it like a system bug, not a morality play.

4. Your execution metrics get real context. DORA metrics can look fine while people suffer. Pair 1:1 themes with our Engineering Metrics Dashboard at /tools/engineering-metrics-dashboard so you can see both speed and strain.

CTO recommendations you can apply next week

Immediate actions

1. Lock the cadence. Put weekly 30 minute 1:1s on the calendar for 12 weeks. Don’t cancel. Reschedule.
2. Make it employee-led. Ask them to add the first agenda items. Pluralsight recommends an employee-driven agenda, and it works in practice (Effective 1:1 meetings with your engineering team).
3. Start with last week’s open loop. “You raised X last time. How is it now?” Vitulli uses this as his opener and it builds trust fast (A Product Manager’s guide to doing 1:1 meetings with engineers).
4. Write down two commitments. One for them, one for you. Put dates on both.

Policy framework

1. Privacy. Keep notes private and never quote them to others. Off by One is clear on this, and it’s the right bar (Running 1:1s for Engineers).
2. No surprise feedback. If a topic affects performance, raise it early in 1:1s. Then it never becomes a shock in review.
3. No status in 1:1s. If someone starts listing tickets, redirect to risks, clarity, and growth.

Architecture principles

1. Turn themes into tracked work. If three engineers complain about CI time, log it as tech debt with an owner and target date in Command Center (/command-center).
2. Ask for the failure mode. Every major technical choice has a break point. Make engineers name it, then plan for it.
3. Use 1:1s to test strategy language. Amazing CTO frames 1:1s as a primary tool to align people on vision, expectations, and upcoming changes (1:1s for Engineering Managers and CTOs). If your strategy sounds fuzzy in a 1:1, it will fail in an all hands.

The 1:1 Quality Checklist (link-worthy)

Use this after each meeting. If you hit 4 out of 6, you are on track.

• Agenda came from them at least in part.
• You talked less than 50 percent of the time.
• One awkward topic surfaced or you confirmed none exist.
• You captured at least one open loop with an owner and date.
• You followed up on last week before starting new topics.
• They left with a clearer next step than they arrived with.

Bigger picture: 1:1s are where culture becomes real

Look, culture isn’t your values slide. Culture is what people say in private when they think it’s safe.

If your 1:1s feel like status meetings, you’ll get late surprises. You’ll also push your best engineers toward the exit, since they can find a better manager in two weeks.

If your 1:1s feel like a place where hard topics get handled with care and action, you’ll hear the truth early. That changes everything.

So here’s the question I ask CTOs who want to scale: if you disappeared for two weeks, would your 1:1 system keep surfacing risks and growing leaders, or would it go silent?

Sources

1. How to run exceptional 1:1 for Engineers
2. Nick Proud on 1:1s with engineers (LinkedIn)
3. 1:1s for Engineering Managers and CTOs
4. A Product Manager’s guide to doing 1:1 meetings with engineers
5. Ido Shamun on 1:1s that matter (LinkedIn)
6. Effective 1:1 meetings with your engineering team: Best practices
7. Running Effective 1:1s as a Tech Lead
8. Running 1:1s for Engineers