At some point in your career, someone will ask you:

“So… are you going to stay technical, or go into leadership?”

And honestly? It can feel like a trap.

You’ve spent years learning to code. You’ve built cool stuff. Maybe mentored a junior or led a feature or two. And now you’re supposed to pick one direction? Like it’s a train you can’t get off?

Here’s what I’ve learned: you don’t have to choose right away. But it’s worth thinking about. Not to lock yourself into a path, but to steer your growth in a direction that fits who you are today.

Let’s explore the fork in the road: technical vs. people leadership and everything in between.

The Technical Path

Some devs just know: they love solving complex problems. They light up when diving into architecture, performance, or design systems. They’re the go-to person when no one else has the answer.

If that’s you, awesome!

You might grow into a staff engineer, principal developer, or architect. Not just writing code, but raising the quality of the whole system.

What this path looks like:

When it fits:

This is leadership! Just through technical influence instead of team management.

The People Path

Others (like me) discover a different kind of joy: helping teammates grow, creating clarity, making the team better, not just the code.

The first time I really helped someone wasn’t by fixing their bug, but by explaining the concept behind it. That’s when something clicked!

People leadership is about creating the conditions for others to do great work.

What this path looks like:

You might grow into a team lead, engineering manager, or even CTO someday.

When it fits:

For me, the code didn’t disappear. It just became one of many tools I use and not the only one.

False Myths, Real Choices

Let’s bust a few myths I’ve heard:

“If I want to grow, I have to manage people.” Nope. Staff roles offer serious growth, pay, and impact (even without people management).

“Once I choose a path, I’m stuck.” Definitely not. Careers are long. You can pivot. You can blend. You can evolve.

How I Chose (And Why I Still Experiment)

As a junior, the path was clear: Become a medior. Then a senior.

But after that? I didn’t know.

I liked mentoring. I liked writing docs. I liked owning features. So I started trying things: leading retros, supporting juniors, talking to stakeholders. Over time, I realized: what gave me energy wasn’t just writing code. It was helping others do great work and making the whole system better.

A Few Questions to Reflect On

If you’re at that fork in the road (or getting close), try asking yourself:

You don’t need to have all the answers: just stay curious.

When Growth Isn’t Handed to You

Here’s the hard part: Not every company helps you figure this out.

Sometimes you’re just…stuck. Repeating the same tasks, no one asking where you want to go.

I’ve been there.

Here’s what helped me when I felt like I’d hit a ceiling:

  1. Pick a growth theme. Choose something to go deep on: testing, animations, DX, accessibility. Apply it in small ways.
  2. Suggest a value-adding initiative. Tie your learning to business value. Performance? Dev experience? Faster handoff?
  3. Be visible. Share what you’re learning. Demo your findings. Onboard a junior.
  4. Use side projects as your lab. Stretch yourself outside of work if you need to, but please be mindful of the time invested and not burning out!
  5. Start the conversation. Talk to your lead: “I’d love to grow in [X], is there room for that here?”
  6. And if nothing changes… move. Seriously. You deserve a place that supports your growth, not just your output.

Final Thoughts

You don’t have to have it all figured out, but you do have to stay honest with yourself. The technical path is deep, while the people path is wide. You can walk both, or switch later.

Just keep asking:

And remember: it’s your developer path.

💬 I’d love to hear your story. Are you leaning toward tech, people, or still exploring? What helped you decide? What are you struggling with right now?