At some point in your career, someone will ask you: “So… are you going to stay technical, or go into leadership?” “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: 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 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 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 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 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? 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: Pick a growth theme. Choose something to go deep on: testing, animations, DX, accessibility. Apply it in small ways.
Suggest a value-adding initiative. Tie your learning to business value. Performance? Dev experience? Faster handoff?
Be visible. Share what you’re learning. Demo your findings. Onboard a junior.
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!
Start the conversation. Talk to your lead: “I’d love to grow in [X], is there room for that here?”
And if nothing changes… move. Seriously. You deserve a place that supports your growth, not just your output. Pick a growth theme. Choose something to go deep on: testing, animations, DX, accessibility. Apply it in small ways. Pick a growth theme. Suggest a value-adding initiative. Tie your learning to business value. Performance? Dev experience? Faster handoff? Suggest a value-adding initiative. Be visible. Share what you’re learning. Demo your findings. Onboard a junior. Be visible. 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! Use side projects as your lab. Start the conversation. Talk to your lead: “I’d love to grow in [X], is there room for that here?” Start the conversation. And if nothing changes… move. Seriously. You deserve a place that supports your growth, not just your output. And if nothing changes… move. 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? 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?

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Homelab: What to Run

Pocket Guide to SEO: Title, Keywords, Headings, and Meta Descriptions

DevOps for Quantum Computing: Architecting a Deployment Framework for Hybrid Qiskit Applications

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

Homelab: What to Run

Pocket Guide to SEO: Title, Keywords, Headings, and Meta Descriptions

DevOps for Quantum Computing: Architecting a Deployment Framework for Hybrid Qiskit Applications

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps