One-on-Ones That Actually Move Your Career Forward

Written by joachimz | Published 2026/03/04
Tech Story Tags: software-architecture | growth-hacking | data-science | design | manager-coaching | performance-conversations | feedback-loops | trackable-progress

TLDROne-on-ones work when there’s intent and ownership. Bring wins, one blocker, a skill gap, and a concrete ask to make real progress.via the TL;DR App

I hear mixed opinions about one-on-ones all the time. For some people they are a blessing. For others they feel like a waste.

My own experience has mostly been positive. I worked with managers who took these conversations seriously. The good one-on-ones were never a ritual to survive. They helped me think clearly, get unstuck, and leave with a better plan.


Some one-on-ones genuinely shaped careers. People felt seen, challenged, and supported. They still reach out to former leaders because those conversations mattered.


Others felt like calendar fillers. Status updates disguised as coaching. A manager trying to track activity instead of improving conditions.

The difference was rarely the template or the cadence. It was intent.


The best one-on-ones happened when the manager showed up curious. Curious about what was blocking me, what was unclear, what was slowing me down, and what I needed to grow. The worst ones happened when neither side owned an outcome.

That is why one-on-ones are powerful, but only when they are part of a system, not the system itself.

Preparation

The one-on-ones that failed for me were extremely predictable:

  • no clear goal
  • no evidence of progress
  • no concrete ask

In short, no preparation.

When that happens, the conversation defaults to updates, logistics, and whatever fire happened that week.

None of that is bad. Some one-on-ones should be casual. But I am talking about the ones that are meant to help you grow.

The meeting is not where growth happens

I used to think one-on-ones were where growth happened.

Now I think they are where growth is reviewed.


The real work happens before and after the meeting:

  • pick a skill to improve
  • practice it in real work
  • collect examples
  • ask for targeted feedback
  • adjust based on what you learned


Your manager can support this process. They cannot run it for you.

What to bring to every one-on-one

Once I started bringing structure, my one-on-ones got much better.

These are the four things I try to bring every time.

1. A short wins list

Not for ego. For evidence.

What did you ship? What improved? What impact did it have?

If you cannot point to outcomes, the whole conversation stays abstract.

2. One real blocker

Not ten complaints. One blocker that matters.

Maybe your pull requests take too long to merge. Maybe stakeholder alignment is messy. Maybe you freeze in architecture discussions.


Pick one. Make it specific.


A good manager does not need this meeting to track your tasks. There are better systems for that. The meeting is more useful when it focuses on what is preventing good work.

3. One skill gap you are working on (optional sometimes)

This is the part most people skip.

Say it directly: I need to improve at X. Here is how it shows up.

Examples:

  • turning ambiguous tasks into executable plans
  • giving clear technical updates to non-technical stakeholders
  • writing smaller, easier-to-review pull requests


Clarity makes feedback useful.

4. One concrete ask

If your one-on-one ends without an ask, do not expect much to change.

Ask for something actionable:

  • Can I lead the next incident retrospective?
  • Can we define what senior-level ownership looks like for my scope?
  • Can you review my design doc and challenge my assumptions?


Vague ambition gets vague support.

Development plans that actually survive

Most development plans start strong and then disappear.


Not because people are lazy. Usually because the plan is vague and fragile. It starts with motivation, then real work takes over, and nothing concrete remains.

What worked better for me was treating growth like a real project, because real projects are where you actually grow.


Build a six-month plan, then break it into trackable pieces.

Six months is long enough to change behavior and short enough to stay grounded.


A simple structure:

  • Pick one growth theme for six months.
  • Define what “better” looks like in observable terms.
  • Break it into monthly focus areas.
  • Create one monthly opportunity to practice.
  • Collect real feedback as your data.
  • Review monthly and adjust.


“Become a better leader” is not a plan.


“Over the next six months, lead one cross-team technical discussion per month, write a short recap, and ask two stakeholders for written feedback each time” is a plan.

The uncomfortable part

It is easy to say my manager is not helping me grow.


Sometimes that is true. Some managers are not the best coaches. Some environments are genuinely limiting. Some organizations split people management and technical leadership, which can make craft feedback harder.


But in many cases, the harder truth is this: we expect growth to happen around us, not through us.

We wait for better projects, better timing, better guidance, better recognition.

Meanwhile, weeks pass, then months.


One-on-ones do not create progress by themselves. They reveal whether progress is happening. If every meeting feels the same, something is not moving. That is the moment to reset expectations and change the inputs.

Final thought

One-on-ones matter. Development plans matter.

But they are multipliers, not magic.

If you bring clarity, evidence, and ownership, they can accelerate your growth. If you bring nothing, they become calendar theater.


It’s up to you to make things happen.



Written by joachimz | Senior Software Engineer at DataCamp | Product & AI Engineering | Writer
Published by HackerNoon on 2026/03/04