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

Wait 5 sec.

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 PathSome 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 architectureLeading code reviews and design discussionsExperimenting with new toolingMentoring through code, not managementProtecting technical excellence, even when deadlines loomWhen it fits:You care deeply about maintainability, performance, and clean designYou get energy from solving hard problemsYou’d rather talk design patterns than people problemsThis is leadership! Just through technical influence instead of team management.The People PathOthers (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 retrosMentoring and coaching juniorsTalking with stakeholders and translating chaos into clarityGiving feedback, removing blockersTaking ownership and making sure things get doneYou might grow into a team lead, engineering manager, or even CTO someday.When it fits:You enjoy seeing others growYou’re interested in how product, process, and people intersectYou like connecting the dots more than writing every lineFor me, the code didn’t disappear. It just became one of many tools I use and not the only one.False Myths, Real ChoicesLet’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 OnIf 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 YouHere’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.Final ThoughtsYou 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?