One On One Training

Running Effective One-On-One Sessions When Nobody's Looking

I spent about three years managing a team where every direct report was junior enough to need constant hand-holding but senior enough that obvious micromanagement made them check out. The standard manager playbook—weekly 1:1s with a standing agenda, career development conversations spaced quarterly, immediate feedback on the spot—didn't actually fit the rhythm of the work. We were shipping sprints with hard deadlines, not working in open-ended research roles. So I had to figure out what actually moved the needle. The short answer was that structured One On One Training, when done right, compresses months of drift into weeks of visible improvement. When it's done wrong, it becomes just another calendar invite both people tolerate. Most people skip straight to picking a framework without asking why their team needs it in the first place.

One On One Training: What It Actually Means in Practice

There's a difference between a routine status meeting and actual training. A status update answers "what happened." Training answers "here's how you think about this differently next time." In my experience, the strongest 1:1 sessions blend both but lean heavily toward the latter. The person you're training should leave the conversation with a mental model they didn't have before, not just a clean task list. I usually start by mapping out three things before the first session: the skill gap I'm trying to close, the decision-making pattern I want to shift, and a concrete artifact that proves they've internalized it. Without that third element, you're just giving advice and hoping for the best. A code review with documented reasoning, a design doc that shows iterative thinking, a runbook they wrote themselves—that's the proof that training actually happened.

Setting Up the cadence Without Burning Out

Frequency matters more than duration. A 30-minute session twice a week is almost always better than a single hour-long meeting once a week. The spacing lets you observe patterns across days, not just reconstruct them from memory at the end of a long week. I found that biweekly rhythms also reduced the pressure to make every session feel like a major event. Some weeks the work was quiet, and the 1:1 reflected that. Other weeks everything was on fire, and we spent the whole time untangling priorities. The most important structural decision is who controls the agenda. If you do, you'll end up teaching what you find interesting, not what they need. If they do without guidance, the conversation defaults to tactical complaints. I settled on a hybrid: they draft three discussion points before the session, and I add one technical deep-dive topic. That keeps it grounded while still ensuring I'm putting real pedagogical effort into the conversation.

Teaching Decision-Making Instead of Answers

The instinct most managers have is to solve the problem for the person they're training. That's efficient in the short term and terrible in the long term. What actually sticks is making them walk through their reasoning out loud while you interrupt only to ask questions that expose gaps. I use a version of the Socratic method that feels less like philosophy class and more like debugging someone's logic. Here's a specific exchange I had with a junior engineer who kept deploying without checking edge cases in the error path. I didn't tell her to add a try-catch block. I asked her to describe what would happen if the database connection timed out mid-request. She couldn't. Then I asked what assumptions her code was making about external services. She realized she'd written the happy path as if nothing ever failed. We spent the rest of the 30 minutes walking through failure modes, not writing the fix. She shipped the corrected version herself two days later, and the pattern showed up in her next few pull requests without prompting. This approach takes longer per session, but the transfer rate is dramatically higher. People remember what they discovered, not what they were told. That's not particularly insightful, but it's easy to forget when you're under pressure to ship.

Documentation That Doesn't Become Dead Weight

One thing I learned the hard way is that notes from 1:1 sessions tend to either get too detailed and never read again, or too sparse to be useful. The sweet spot is what I call a training card: one page per skill area, updated after each relevant session. It has three sections—what I observed, what we tried, what changed. The observation section is the most important because it creates a record of baseline behavior that you can compare against over time. I ran into a specific problem about eight months in where a direct report improved dramatically on certain skills but regressed on others, and I couldn't see the trade-off pattern because my notes were scattered across emails and calendar invites. I started using a single shared document per person, organized by competency area, with dated entries. After six months of that, the regression became obvious before it became a performance issue. The fix was restructuring how we allocated time across competing skill tracks, but I wouldn't have caught it otherwise.

When One On One Training Doesn't Work

This approach assumes a few things that aren't always true. It requires the trainer to have genuine expertise in the area they're teaching. If you're assigned to train someone on a technology you're still learning yourself, the Socratic method falls apart because you can't ask pointed follow-up questions. It also requires the trainee to have some baseline agency—if someone is stuck because of organizational blockers rather than skill gaps, no amount of 1:1 will unblock them. Those situations need different interventions. Another honest limitation: this model doesn't scale well beyond roughly five direct reports if you want it to be genuinely effective. After that, sessions become diluted, and you're just checking boxes. At that point you're better off investing in group training, documentation, or process changes that raise the floor for everyone rather than trying to personally mentor each individual through every gap. If the person you're training is fundamentally mismatched to the role—wrong aptitude, wrong interests, wrong working style—no amount of good training will fix that. I've seen managers waste six months trying to develop someone into a role they were structurally unsuited for. The productive move is often to redirect rather than persist, which is uncomfortable to admit because it looks like failure in the moment.

A Practical Week-by-Week Template

For the first two weeks, focus on establishing rhythm and diagnosing the actual gap. Don't try to teach everything at once. Pick one skill area and run a baseline assessment—give them a task slightly above their current level and observe where they struggle. That tells you more than any performance review ever has. Weeks three through six are where the actual teaching happens. Use the biweekly cadence. Each session should have one clear objective tied to that skill area. End each session with a small assignment they complete independently before the next meeting. The assignment is non-negotiable; without it, the session is just a conversation with no behavioral change. Weeks seven through ten shift toward autonomy. Reduce the density of your direct instruction and increase the complexity of the assignments. You're now testing whether they can apply the mental model in new contexts without you holding their hand. This is also where you'll discover whether the training actually stuck or whether they're just good at mimicking behavior in the specific scenarios you practiced.

Week eleven and beyond is maintenance and expansion. Introduce a new skill area or deepen the existing one. The cadence should stabilize into a predictable rhythm where both parties know what to expect, and the conversations naturally drift toward more nuanced topics as competence grows.

Common Pitfalls I've Seen Repeatedly

The most frequent mistake is treating 1:1 training as remedial. It sounds harsh, but positioning it as "fixing weaknesses" creates defensiveness that blocks learning. Reframing it as "accelerating existing strengths" produces measurably better engagement. People work harder when they feel like they're leveling up, not being repaired. Another pitfall is over-indexing on technical skills while neglecting decision-making frameworks. You can teach someone to write better SQL queries in a month. Teaching them to decide which problems are worth solving takes longer and has higher impact, but it's harder to measure, so managers often avoid it. Don't avoid it. The technical skills are table stakes. The judgment is what separates competent workers from people who consistently make good calls under uncertainty. A third common error is not documenting the starting point. If you can't articulate what the person could or couldn't do before training began, you can't credibly claim the training had any effect. That's not just academic—the absence of a baseline makes it impossible to adjust your approach when something isn't working, because you have no reference for what changed and what stayed the same.

What Good Looks Like After Six Months

The people who went through sustained One On One Training with real effort on both sides don't just become more competent in specific areas. They become self-correcting. You'll notice it because they start flagging their own blind spots, asking for feedback before you offer it, and making decisions with less need for approval. That's the signal that the training has internalized rather than just been absorbed temporarily for the duration of the relationship. The alternative—people who improve during training but regress once the structure ends—is usually a sign that the training focused too much on specific tasks and not enough on transferable mental models. It's a subtle distinction, but it's the difference between teaching someone to fish and teaching someone how to understand water.