What Your 1-on-1s Should Measure (and Don't)

Every week, hundreds of thousands of 1-on-1 meetings take place in tech teams around the world. They last between thirty minutes and an hour. They’re generally initiated by the manager. And in a surprising number of cases, they look like this: the manager pulls up the Jira board and asks “so, where are you on your tickets this week?”

That meeting could have been replaced by a dashboard check. The hour spent face-to-face produced neither information that the tracking tools didn’t already have, nor trust, nor resolution of any systemic problem.

That’s the failed 1-on-1. And it’s extremely common.

What the 1-on-1 Is Not

Starting with what the 1-on-1 is not helps clarify what it should be.

The 1-on-1 is not a status meeting. Ticket status, sprint completion percentage, current blockers on in-progress tasks - all of that is available in the tools. If the team has a usable dashboard, the manager doesn’t need an hour-long meeting to know where the tickets stand.

The 1-on-1 is not a reporting meeting. “I finished feature X, had a problem with Y, working on Z.” This information, if it matters, should exist in the team’s tools, not only in the developer’s head.

The 1-on-1 is also not a top-down management meeting. “Here are the week’s priorities, here’s what management expects from the team, here are the process changes.” This information can be communicated more effectively to the whole team, not in a weekly one-on-one.

What the 1-on-1 Is

The 1-on-1 is the only private conversation space between a manager and a team member. That’s its uniqueness and its value.

What it enables that no other format allows:

Detecting weak signals. Serious problems in a team rarely appear overnight. They accumulate over weeks or months: a deteriorating relationship with a colleague, progressive demotivation, a feeling of being stuck in one’s career, disillusionment with the company’s direction. These signals are rarely expressed in public, never in Jira tickets. They emerge in private conversations where the person feels safe enough to share them.

A manager who uses 1-on-1s to track tickets has no access to these signals. They discover problems once they’ve become crises: surprise resignations, open conflict, visible burnout.

Unblocking systemic issues. There’s a difference between a tactical blocker (a ticket blocked waiting for an API decision) and a systemic blocker (the developer is regularly blocked because the design team doesn’t respond in reasonable timeframes, and no one has addressed the structural problem).

The tactical blocker gets resolved in tools or at the daily standup. The systemic blocker requires a private conversation to be clearly named, and managerial action to be resolved.

Building trust. Trust between a manager and their team isn’t built in group meetings. It’s built in conversations where the person feels heard, where their concerns are taken seriously, where the manager shows they remember what was said last week.

A manager who doesn’t use 1-on-1s for this generally doesn’t have their team’s trust, even if they’re unaware of it.

The Opening Question That Changes Everything

The question that opens a 1-on-1 often determines the entire tone of the meeting.

Questions that close the conversation:

“Where are you on your tickets this week?”

“How is feature X coming along?”

“Did you have time to look at what I put in the shared doc?”

These questions call for short, factual answers. They signal to the developer that this is a status meeting.

Questions that open the conversation:

“What’s on your mind right now, whether technical, organizational, or anything else?”

“Is there something that regularly slows you down that would be hard to raise in a team meeting?”

“How are you feeling about your work right now, on a non-verbal scale?”

These questions give permission to go beyond ticket tracking. They signal that this meeting is for the person, not for the manager.

The Structure That Helps

A 1-on-1 without structure easily becomes a drifting conversation or a manager monologue. A light structure helps without making it rigid.

An approach that works for many managers: the agenda belongs to the person, not the manager.

In practice: the person prepares two or three points they want to discuss. The manager also prepares points, but they come after the person’s items. If the person hasn’t prepared anything (which happens), the manager opens with an open question about what’s weighing on them.

This agenda reversal sends a clear signal: this meeting isn’t here to satisfy the manager’s information needs. It’s here for the person.

The common manager reaction: “If I let the person drive the agenda, we’ll never talk about what matters to the team.” That’s a legitimate concern and usually an unfounded fear. Developers are generally well aware of team priorities. When given space to talk about what matters to them, the topics that emerge are often more useful to the manager than what they would have brought up themselves.

What the Manager Should Measure

Most developer managers implicitly evaluate their 1-on-1s on criteria like: is the person making progress on their tickets, are they delivering on time, are they aligned with team priorities.

Those criteria are measurable via tracking tools. They don’t require a 1-on-1.

What the 1-on-1 makes it possible to measure, and what few managers deliberately track:

Engagement level. Does the person talk about their work with energy or resignation? Do they share ideas or just answer questions? Has the engagement level changed over the past few weeks?

Clarity on priorities. Not “are they working on the right things” (visible in the tickets), but “do they understand why those things are priorities.” A developer who executes without understanding the purpose is a developer making poor implementation decisions and gradually disconnecting.

The state of team relationships. Friction between colleagues, frustration with processes, misunderstandings with other teams - this information doesn’t arrive in tickets and rarely in group meetings. It arrives in 1-on-1s.

The Right Frequency

What’s the right frequency for 1-on-1s? The standard answer is weekly. That’s a good default frequency for teams who work together daily.

What can adjust the frequency:

Newness. When someone joins the team, a higher frequency during the first few months helps detect integration problems before they become structural ones.

Periods of tension. When the team is going through a difficult period (organizational change, project under pressure, interpersonal conflict), increasing the 1-on-1 frequency creates more opportunities to detect and address weak signals.

Relationship maturity. With someone who has been on the team for several years and with whom trust is well established, a biweekly frequency may be sufficient. The 1-on-1s become deep check-ins rather than frequent touchpoints.

What not to do: regularly cancel 1-on-1s because the manager’s calendar is busy. The signal sent is unambiguous: these meetings are not a priority. That’s exactly the opposite of the message the 1-on-1 is supposed to send.

What the Manager Learns About Themselves

One last rarely discussed aspect: 1-on-1s, when practiced well, teach the manager things about their own way of working.

If several team members regularly mention the same blockers, the same confusion about priorities, the same frustrations with a process - that’s a signal about the organization, not about the individuals.

A manager who uses 1-on-1s solely as a performance tracking tool misses this feedback about their own functioning. They’re the last to know why the team is frustrated, and that frustration always appears to them as an individual problem rather than a systemic symptom.

1-on-1s are the best tool a manager has for keeping a team healthy. Not because they allow ticket tracking, but because they allow hearing what tickets never say.

Using these meetings as status reports wastes the only private space in the management relationship.