Why generic 1:1 templates fail technical managers

When a technical manager reaches for a generic 1:1 template, the template often steers the meeting toward a status recap and a few broad check-in questions. That is the wrong meeting. A good 1:1 needs just enough structure to make planning easier, but enough room for the direct report to bring what matters. ^source The work an engineer is doing hides its problems in places a borrowed template may never ask 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, during a recurring manager-report conversation. GitLab's public 1:1 guidance, for example, recommends a consistent agenda format, shared agenda ownership, and open-ended questions because the shape of the agenda changes the conversation. ^source If the 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

The weak fit usually comes from one of two patterns: a people-process template that treats the 1:1 mainly as a wellbeing touchpoint, or a meetings template that treats it as a recurring agenda to fill. Both can be reasonable in the right context. Neither is specific enough 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. They are specific, open-ended, and tied to the work in front of the report. ^source 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. Atlassian's 1:1 guidance makes the same operational point: useful 1:1s end with clear action items, and topics that need more discussion should come back to the next agenda. ^source 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