Most 1:1 templates a technical manager finds online were built for an HR check-in, not for running engineering reports, so they quietly steer the meeting toward a status recap and a few generic feelings questions. That is the wrong meeting. The work an engineer is doing hides its problems in places a borrowed template never asks about: the decision they are still unsure of, the task that is harder than it should be, the thing that slipped since last time. A template that does not reach those places will run smoothly and surface nothing.
This matters because the template is not neutral. Whatever questions sit on the page are the questions that get asked, week after week, on the one slot of the week that is hard to reschedule. If those questions are borrowed from a tool built for someone else's meeting, you inherit someone else's meeting.
The borrowed template is built for the wrong job
A generic 1:1 template usually comes from one of two places: an HR product that treats the 1:1 as a wellbeing touchpoint, or a meetings tool that treats it as a recurring agenda to fill. Both are reasonable for what they were made for. Neither was made for a manager whose direct report spends the week inside a codebase, a design doc, or a migration that is three days behind.
The mismatch shows up in the questions. HR-style templates lean on "how are you feeling about your workload?" and "what are your goals this quarter?" Agenda-style templates lean on "what did you ship?" and "what is blocked?" The first set is too soft to reach a technical problem. The second is something you can read off a ticket board without spending a person's time. Run either one on autopilot and the meeting fills up without doing the thing only a conversation can do.
What a generic template actually produces
Watch a borrowed template run for a few weeks and you see two outputs, neither of them useful.
The first is the status recap. The report walks through what they finished, you nod, the meeting ends on time, and nothing was said that a written update could not have carried. It feels productive because ground was covered. It is the most expensive way to receive information you could have read.
The second is the empty feelings question. "How are things going?" gets answered with "good, busy," because the question is too broad to answer honestly under time pressure. A vague question gives the report permission to stay vague, and a tired engineer on a Thursday afternoon will take it.
Both outputs are the template doing exactly what it was designed to do. The design was just aimed at a different meeting.
What to ask a technical report instead
The questions that work for technical managers share one trait: a status update cannot answer them. Three reach most of what stays hidden otherwise.
The first is about decisions in flight. Not "what are you working on," but "what are you about to decide that you are not fully sure about?" Technical work is a chain of small commitments, and the risky ones are usually the choices nobody flagged because they did not look like decisions at the time.
The second is about friction: what is harder than it should be? A task that is taking three times as long is rarely just slow. It is often a sign of a bad abstraction, a missing piece of access, an unclear requirement, or a dependency that is quietly broken. The friction is the signal, and it almost never shows up on a progress percentage.
The third is about follow-through: what slipped since last time? Not to chase it, but because the gap between "I'll look into that" and what actually happened is where the real obstacles live. If the same item slips three weeks running, the problem is not the item.
The fix is a template you can shape, not a better fixed one
The instinct after reading this is to go find a better template. That is still the wrong move, because the next borrowed template is also fixed, and your team's work is not the same as the team it was written for. What a technical manager needs is not a perfect form. It is a form they can shape to how their work surfaces problems, and that keeps its shape across every session so the meeting compounds instead of resetting.
That is the case for treating the template as something you edit rather than something you adopt. In 1on1, questionnaire templates carry roles, so an admin can set a sensible default, a manager can adapt the questions to their own reports, and the member sees the version meant for them. source A template AI editor helps you turn a rough intent into concrete questions without starting from a blank page. source The point is not more structure. It is structure you control, aimed at your meeting rather than someone else's.
If you want to test whether your current template reaches anything, you do not need a tool to start. Open the last three 1:1s you ran and check each question against one filter: could this have been answered by a written status update? Every question that could should be replaced. What you put in its place is the meeting you actually wanted. You can pilot that with one manager and one report before changing anything for the rest of the team. source
