Thirty minutes with five engineers, a week of commitments, searchable on Friday.

Tuesday morning: the manager's calendar has five one-on-ones scheduled back-to-back from 9:00 to 11:30. Each person gets a half-hour block. Each conversation covers their current project, blockers, career growth, concerns, and any feedback that came in from peers or customers. By the end of Friday, ten recordings sit on the Mac — two per engineer, one week's worth. Nobody's concern gets lost to a rushed summary at the end of the week. Nobody's career goal slides out of memory because it came up on Tuesday and it is now Thursday.

What makes one-on-ones hard to manage isn't the meetings themselves. It is remembering, three weeks later, exactly what someone said they needed help with, or what you committed to doing for them, or what metric you said would be ready by the monthly all-hands. A manager who runs five direct reports across ten meetings a week learns quickly that the problem isn't logging time — it is logging what was actually said in the time.

8:55am — before the first person joins

Recording starts before anyone shows up. The purpose of pressing record is not to miss the opening sentence. The first engineer's first word lands in the transcript, not reconstructed from memory afterward. The Mac's microphone and the video call's audio are separate tracks from the first second, so you hear your engineer clearly without trying to write while you listen.

A manager in a one-on-one is listening for what's blocking work, what's next for them professionally, whether they're getting what they need from you or the team. Adding "capture exactly what they said" to that task used to mean you either missed nuance or had to take notes while they were talking, which kills the conversation. The recording takes that constraint off the table — you can listen fully and know that the exact thing they said is sitting on your Mac when the meeting ends.

9:00am — the first person: growth plan revision mid-year

Your first engineer starts the one-on-one with something they prepared for. They want to revisit their growth plan. When they were hired six months ago, the goal was to lead a small feature team by end of year. They've hit the technical benchmarks. But a reorganization in Q3 changed the team structure, and they want to know whether the plan still fits or whether it needs revision.

This is the kind of conversation that happens once, matters a lot, and is easy to misremember in reverse six months later. They might remember it as "the manager said I could definitely lead a team by end of Q4." You might remember it as "we agreed to revisit whether the reorganization changed that timeline." The transcript settles it.

9:35am — between the first and second person, reviewing what you committed to

You have five minutes before the next one-on-one. The first engineer asked you to check whether the platform team can deliver by October. Before the second meeting starts, you pull up that transcript and confirm: you did commit to checking that timeline. The moment the second one-on-one ends, you send a Slack message to the platform lead asking the question. Same week. Same memory of what you promised.

9:30am — the second person: blocked on a technical decision

The second engineer is stuck waiting on an architecture decision made by the principal engineer team two weeks ago. Nobody's given them a timeline for when it will be resolved. This matters because their feature is on hold until the decision lands. What they actually need is to know whether the decision comes this week or next month or never.

The difference between "the decision is coming" and "the decision is coming on Wednesday" is the difference between them spinning their wheels and them planning their week. Without a recording, you're remembering whether you said "this week" or "next week" or "ask again next Friday." With a recording, the engineer is remembering what you actually said they should do, and you're remembering what you committed to checking with the principal team.

10:05am — the third person: feedback they need to hear

The third engineer gets feedback from you that is hard to hear. Someone on the team said their code reviews are taking too long to turn around, which is slowing down the people who report to them. They didn't know anyone felt that way. They're defensive at first — code review is supposed to be careful. But by the end of the conversation, they understand: they can be careful and also faster.

This is a conversation you want to handle right, and a conversation the engineer wants to remember accurately. Without a recording, there's a chance they hear "your code reviews are taking too long" and miss the part about it being fixable. With a recording, they can listen back to the exact tone you used and the specific example you gave, and they remember that this is feedback you're giving because you think they can change it, not because you're sidelining them.

10:40am — the fourth person: retention risk you didn't know about

The fourth engineer opens with a concern: they're thinking about leaving. Not in the next month. But if things don't change, they'll look in Q1. What's wrong? The work is interesting. The team is good. But their last promotion was a year and a half ago, and they don't see a clear path to the next level in this org.

This is the moment you remember exactly what the growth plan conversation was supposed to prevent. This engineer made it clear on the call that they want to understand the path forward. You take that seriously, you commit to a plan, and you send a summary of that plan within the week. Without a recording, you're hoping you remember what they said matters. With a recording, you know.

11:15am — the fifth person: shipping on time

The fifth engineer doesn't have blockers or concerns. Their project is on track. They're shipping a feature this week that they built from the spec, on budget, on time. This conversation is celebration and planning. What comes next? What was hard about this project that affects how you plan the next one? What did they learn?

This conversation is the easiest to skip, the easiest to not write up carefully, and often the easiest to get wrong when you look back. The engineer did good work. You want to recognize it specifically. You want to know what made it work so you can set up the next project the same way. The recording preserves both.

Tuesday afternoon — three more to go

By 1:00 Wednesday, you have five transcripts and five summaries on your Mac. Five people. Five different conversations. Five different outcomes and commitments. None of it is in your head. All of it is searchable.

Wednesday through Friday — one-on-ones two through five

By Friday morning, you've done ten one-on-ones. Five people, two weeks running. Each person's transcript from both weeks sits on the Mac. Finding what Engineer Three said about code review speed on Tuesday is a search. Finding what Engineer One said about the October platform deadline is a transcript lookup. Neither one requires reconstructing a memory of a conversation that is four days old.

Friday afternoon — the review that actually checks your memory

Friday's a busy day, but before end of week, you sit down and review what you committed to this week:

• Check with platform team on architecture guidance timeline for Engineer Two
• Create a staff engineer path plan for Engineer Four
• Have that plan review for Engineer Four next week
• Send project retrospective template to Engineer Five
• Circle back with Engineer One on platform team deadline
• Follow up with Engineer Three on code review speed after a week of trying the new approach

All five of those are in your one-on-one transcripts. Not as "I think I said something about that," but as specific sentences, with timestamps, exactly as spoken. When you forget one — and you will forget at least one — searching for the engineer's name in that week's transcripts gets you there in thirty seconds.

Two weeks later — Engineer One checks in on the platform deadline

Engineer One comes to you asking whether you've heard back from platform team on that October deadline for the architecture decision. You have a few seconds to either guess at what you asked them to do or to search. You search. You find the specific sentence: "Platform stable by October, lead role by January." You know exactly what you committed to, what Engineer One committed to, and when you're supposed to have the answer. You send them the answer within an hour, not days later when you reconstruct it from memory.

The career conversation you want to remember accurately

Career conversations are the ones that hurt most when they go wrong. An engineer who thinks you promised them a promotion that you didn't promise, or missed the specific timeline you gave them, or doesn't remember that you said this specific skill was the blocker — those misalignments compound over months. The transcript isn't a legal document. It's proof that you both heard the same thing.

The hard feedback that needs to be specific

When you're giving tough feedback, the engineer needs to hear three things: what the problem is, why it matters, and what specifically needs to change. All three need to survive the meeting intact. Without a recording, one of those three usually evaporates by Friday. With a recording, the engineer can listen back and know exactly what you said matters and exactly what you said to change.

Noticing the pattern nobody mentioned

By Friday, after ten one-on-ones, you notice something: three of your five engineers asked about timelines or paths that connect to the same reorganization uncertainty. That pattern is easy to miss in individual conversations. It's hard to miss once you have five transcripts and you search for "reorganization" across all five. You now have a signal that you need to communicate something to your team about what's happening next. The signal came from the transcripts, not from your own anxiety or intuition.

What doesn't fit in this workflow

Nothing here integrates into a performance management system or a HR tool. The recordings don't sync across a shared system, don't contribute to a 360-degree review process, and aren't meant to be browsed by someone else on your team. Each engineer's transcripts live on your Mac, across up to three of your own machines on one licence, entirely under your control. A company that runs reviews through a shared system has reasons to stay there — this workflow is local-first because that's what a one-on-one meeting actually is.

The moment it becomes muscle memory

The first week of recording every one-on-one feels deliberate — remembering to press record, remembering to file each transcript as the person's name so you can find it later. By the third or fourth week, it stops being extra. By week five, a report asking you "wait, did we talk about that?" gets answered with a search, not a guess.

What it costs, what it runs on

Coii AudioNotes is $19, once, covering up to three of your own Macs, with a 30-day trial needing no card and no account. It runs on macOS 13 Ventura or later, Apple Silicon or Intel — the same machine you use for video calls with your team. The full case for an engineering manager's notetaker covers why this matters in more depth than a single week can show, and how to search your old meetings walks through finding what was said weeks later. How to write minutes from a transcript and how to turn a transcript into action items both walk through the mechanics of turning recordings into the summaries and the follow-up lists this page only showed in motion. How to ask questions about a past meeting covers the technique of working backward from a concern to find the conversation that sparked it. The round-up of private meeting recorders covers the wider field of tools that don't upload your conversations to a server.