The one-on-one framework I use after fifteen years of getting one-on-ones wrong
Three fixed sections: blockers with deadlines, career trajectory, and one question the report chooses. Structure creates safety without drift.
For the first decade of my career, I ran one-on-ones like status meetings. What are you working on? Any blockers? Cool, see you next week. The meetings were twenty minutes of information I could have gotten from Jira. They built zero trust, surfaced zero problems early, and felt like a chore for both sides.
Then I overcorrected. I read every management book and turned one-on-ones into therapy sessions. How are you feeling? What is your energy level? Tell me about your long-term vision. The meetings became forty-five minutes of meandering conversation that made people uncomfortable and still surfaced zero problems early.
It took fifteen years and a lot of bad one-on-ones to find a format that actually works.
Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “The founder said ship in two weeks. I said no. Here is what happened..” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.
The Three-Section Framework
Every one-on-one at FinanceOps follows the same structure. Thirty minutes. Three sections. No exceptions.
- Blockers with deadlines (10 minutes). What is preventing you from making progress right now, and by when do you need it resolved? This is not a status update. It is a commitment. If someone says “I need access to the staging database,” I write it down and assign myself a deadline. The next one-on-one starts by reviewing whether I delivered on my commitments from the previous one.
- Career trajectory check-in (10 minutes). Where are you relative to where you want to be in twelve months? This is not a performance review. It is a calibration conversation. Are the projects they are working on building the skills they want? Is there a gap between what they are doing and what they need for promotion? If yes, what are we going to do about it this quarter?
- Report’s choice (10 minutes). The direct report picks one topic. Anything. Technical deep-dive, team dynamics concern, an idea for a new project, feedback for me, or just venting about something frustrating. This section is theirs. I listen more than I talk.
Why This Structure Works
The blocker section works because it creates accountability in both directions. Most one-on-one frameworks focus on what the report should bring. This one also tracks what the manager commits to. When your direct report sees you following through on your commitments every week, trust compounds. When they see you dropping the ball, they stop bringing you problems. The accountability is the trust mechanism.
The career section works because it forces a regular conversation about growth that would otherwise only happen during promotion cycles. By the time you are discussing career trajectory in a performance review, it is too late to course-correct. Monthly or biweekly career check-ins surface misalignment early enough to fix it.
The report’s choice section works because it gives people permission to raise things they would otherwise sit on. Most engineers will not interrupt a structured meeting to say “I think the way we handled the last production incident was unfair.” But if there is an explicit ten-minute block that is theirs to use however they want, that concern gets surfaced. The structure creates safety.
Common Failure Modes
This framework fails in predictable ways, and I have hit all of them:
- Skipping the career section because blockers took too long. The career conversation gets deprioritized every time there is urgency. Protect it. Set a timer if you have to. The urgent will always crowd out the important unless you defend the important with structure.
- Turning the report’s choice section into your agenda. The moment you start saying “I wanted to talk about…” in their section, you have stolen it. Stay quiet. Let them lead.
- Not following up on blocker commitments. If you commit to getting someone access to a system by Thursday and you do not deliver, you have taught them that one-on-ones are performative. Deliver on your commitments or do not make them.
- Running the same framework for every person regardless of their needs. A staff engineer and a junior engineer need different conversations. The framework is the skeleton. The depth and focus of each section should adapt to the person.
What I Measure
I track two things to know if my one-on-ones are working. First, how often do problems surface in one-on-ones before they surface in standups, retrospectives, or Slack escalations? If problems are showing up in one-on-ones first, the framework is creating the safety it is supposed to. If problems show up elsewhere first, something is broken.
Second, how often do direct reports cancel or reschedule? One-on-ones that feel valuable do not get canceled. If someone consistently tries to move their one-on-one, it means the meeting is not useful to them, and that is my failure to fix, not theirs.
Earlier in this story I was mostly trying to survive the blast radius myself. Here I was trying to design a system where the team did not need heroics in the first place. The same philosophy now shapes lifeos and bisen-apps.
The purpose of a one-on-one is not information transfer. It is trust maintenance. The structure exists to make trust-building repeatable, not to make the meeting efficient.
Fifteen years in, I have finally stopped trying to make one-on-ones feel natural. They are not natural. They are a structured mechanism for building the kind of trust that makes everything else in engineering leadership work. The framework is simple. The discipline to protect it is the hard part.