Should You Be a Tech-First or People-First Developer?

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

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:

• Deep dives into tech strategy and architecture
• Leading code reviews and design discussions
• Experimenting with new tooling
• Mentoring through code, not management
• Protecting technical excellence, even when deadlines loom

When it fits:

• You care deeply about maintainability, performance, and clean design
• You get energy from solving hard problems
• You’d rather talk design patterns than people problems

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:

• Facilitating team rituals and retros
• Mentoring and coaching juniors
• Talking with stakeholders and translating chaos into clarity
• Giving feedback, removing blockers
• Taking ownership and making sure things get done

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

When it fits:

• You enjoy seeing others grow
• You’re interested in how product, process, and people intersect
• You like connecting the dots more than writing every line

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:

• What kind of developer do I want to become?
• When do I feel most in flow: deep in code or helping others?
• Where do I bring the most value to my team right now?
• Do I feel energized or drained by mentoring and leading discussions?
• Is there room to grow in my current role? If not, what can I suggest?

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:

• What gives me energy?
• What impact do I want to have?

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?