Making One-on-Ones Actually Useful: A Guide for Developers and Their Managers
For three years, my one-on-ones were: "What are you working on? Any blockers? Okay, see you next week." Fifteen minutes of status updates that provided zero value beyond what the daily standup already covered.
Then I worked under a manager who ran genuinely useful one-on-ones. They accelerated my career growth, helped me navigate difficult situations, and built the kind of trust that makes work meaningful. The difference was not time investment (still 30 minutes weekly) — it was structure and intent.
Why Most One-on-Ones Fail
The failure mode: the meeting becomes a project status update. "I finished the search feature, I am starting the profile page, I am blocked on the API spec." This information belongs in standups, Jira tickets, or async updates.
Why this happens: neither person prepares, so the path of least resistance is "what are you doing?" Neither person has clear goals for the meeting. And status updates feel productive without being valuable.
The fix: explicitly declare what one-on-ones are NOT for (status updates) and establish what they ARE for.
What One-on-Ones Should Be For
Career development: where are you heading? What skills are you building? What growth looks like in the next 6-12 months. This conversation is impossible in any other meeting context.
Problem-solving: "I am struggling with X" — not technical problems (those belong in code review or pairing), but interpersonal challenges, process frustrations, or strategic questions about how to approach complex situations.
Feedback exchange: regular, specific feedback in both directions. Not annual performance review feedback — weekly observations about what is working and what could improve.
Relationship building: understanding each other as people. What motivates you, what stresses you, what your communication preferences are. This trust enables everything else.
The Structure That Works
I divide 30-minute one-on-ones into three sections:
First 10 minutes — the developer's agenda: anything the developer wants to discuss. This is YOUR time. If you have nothing: that is fine, but prepare something. Topics might include: a challenge you are facing, a career question, feedback you want to give, or something you want to learn.
Middle 10 minutes — the manager's agenda: topics the manager wants to cover. Might include: context about company decisions, upcoming changes that affect you, feedback on recent work, or requests for your perspective on team issues.
Last 10 minutes — meta/growth: step back from the day-to-day. How are you feeling overall? Are you growing? Is anything bothering you that you have not mentioned? What can we improve?
Preparing for One-on-Ones (As a Developer)
Spend 5 minutes before the meeting noting: one thing that went well this week (celebrate wins), one thing that frustrated you (address before it festers), one question about your career or growth, and any feedback for your manager (positive or constructive).
Even brief preparation transforms the meeting. Without preparation, you default to status updates because they require no thought.
Topics That Create Value
Career direction: "I want to move toward architecture decisions. What opportunities can you create for me to practice this?"
Process improvement: "Our code review process is taking 3 days on average. I have some ideas for improvement — can I run them by you?"
Team dynamics: "I noticed tension between me and [colleague] during the last sprint. Do you have advice for how to improve that relationship?"
Growth feedback: "What is one thing I could improve in the next month that would have the biggest impact on my effectiveness?"
Organizational context: "Why did we decide to prioritize X over Y? Understanding the reasoning helps me make better daily decisions."
Giving Feedback to Your Manager
One-on-ones are the appropriate venue for upward feedback. Your manager cannot improve without honest input from their reports.
Frame feedback constructively: "When you [specific behavior], I felt [impact]. I would find it helpful if you [alternative]."
Example: "When you jumped into the technical discussion and made the architecture decision directly, I felt like my input was not valued. I would find it helpful if you asked for my recommendation first, then added your perspective."
This is hard to say. But managers who care about their effectiveness appreciate it enormously. They are not getting this feedback from anyone else.
What Makes a Great One-on-One Partner (As a Developer)
Come prepared with topics (not just status). Be honest about challenges (not everything is fine). Give feedback (constructive and positive). Ask for what you need (do not expect mind-reading). Follow through on commitments made in the meeting.
What Makes a Great One-on-One Partner (As a Manager)
Listen more than talk. Ask open-ended questions (not "is everything okay?" — instead "what is the most frustrating thing about your work right now?"). Provide context and transparency about decisions. Take action on issues raised. Create psychological safety for honesty.
When One-on-Ones Are Not Working
Signs: you dread the meeting, you have nothing to say, the meeting frequently gets cancelled, or you leave feeling like it was wasted time.
Fixes: explicitly discuss the format ("these are not working for me — can we restructure?"), change the cadence (maybe biweekly is better than weekly for your situation), change the environment (walk-and-talk, coffee instead of a conference room), or prepare more deliberately.
The Long-Term Value
Good one-on-ones compound. Over months: you build trust that enables honest conversation, you identify and resolve problems before they become crises, you make consistent career progress instead of drifting, and you develop a working relationship that survives organizational changes.
A 30-minute weekly investment in a genuinely useful one-on-one is one of the highest-leverage activities in your career. Not because any single meeting is transformative, but because the consistent accumulation of trust, feedback, and direction shapes your trajectory over years.
Written by AIDToolStack Editorial
The AIDToolStack editorial team reviews developer tools, AI products, and MCP servers with hands-on testing and honest assessments. We use the tools we review every day in production.
References & Further Reading
Related Posts
Sponsor Our Newsletter
Reach thousands of developers who are actively evaluating AI tools, MCP servers, and dev infrastructure. Our weekly newsletter goes to engaged technical decision-makers.
All sponsored content is clearly labeled per our editorial policy.