On Being a Generalist in a Specialist's World
I’ve written production code in Python, JavaScript, Go, and C++. I’ve done frontend, backend, infra, and now AI—including production agent systems at Robynn AI. Every few years, someone asks: “But what’s your thing?”
I never have a good answer.
For a long time, this felt like a weakness. Like I was somehow failing at the career game by not picking a lane. But I’ve come to see it differently.
What a generalist engineer is
A generalist engineer works effectively across domains—frontend, backend, infrastructure, AI—instead of going deep on one stack. The trade: less encyclopedic depth in any single technology, more skill at seeing how systems connect. Generalists win where problems cross boundaries: early-stage startups, platform work, and new domains where nobody has ten years of experience yet.
The Pressure to Specialize
Career advice is clear: be the X person. The React expert. The Kubernetes guru. The machine learning specialist. Pick something, go deep, become the person everyone thinks of when that topic comes up.
LinkedIn rewards it. Your title becomes your identity. “Senior Backend Engineer” tells people exactly what you do. “Senior Software Engineer” tells them nothing.
Job descriptions want “5+ years in [specific thing].” Never mind that a lot of these things haven’t even been around for 5 years. The industry rewards depth—or at least the appearance of it.
I’ve never had 5+ years in one thing. Not because I’m flaky, but because I keep getting pulled into new problems. Every time I get comfortable, something interesting appears in a different domain.
How I Became a Generalist
Here’s my actual career trajectory, in order:
Cisco (2017): Security, cloud infrastructure, Python.
PayPal (2018): Payments, distributed systems, scale. Now I’m thinking about transactions, consistency, and what happens when millions of people want their money at the same time.
Riverbed (2019): Systems programming, C++, network protocols. Completely different domain, different language, different problems—deep in the weeds of packet inspection and performance optimization.
Robynn AI (2025): LLMs, agent architectures, product. Suddenly I’m building AI systems, thinking about prompt engineering, orchestrating autonomous agents.
Each jump felt like starting over. Each time, I wondered if I was making a mistake by not staying to become the expert.
In retrospect, nothing was wasted. The systems thinking from Riverbed helps me debug AI agent behavior. The security mindset from Cisco makes me paranoid about prompt injection. The scale lessons from PayPal informed how we architected infrastructure at Robynn.
What Generalists Are Actually Good At
The advantages are real, and almost all of them are about boundaries.
Translation is the obvious one. I can talk to the ML team and the infra team because I’ve been both, and when those teams start talking past each other—which happens constantly—I can tell which of them is actually wrong.
Decomposition is the underrated one. Having seen problems in several domains, you develop a sense for which parts of a new problem are genuinely hard and which only look hard because they’re unfamiliar. That judgment is what lets you carve a big problem into pieces that someone can actually finish.
Then there’s speed: I can stand up a full-stack proof of concept—model, API, frontend, deploy pipeline—without waiting on anyone. Not beautifully. Fast enough to find out whether the idea deserves a real team.
And debugging, which is where breadth stops being a nice-to-have. The hardest bugs live at the seams. When the frontend, backend, and database are each behaving correctly in isolation and production is still broken, the person who finds it is the one who can hold all three in their head at once.
The Costs (Let’s Be Honest)
I won’t pretend there’s no downside.
I’ll never be the person who wrote the book on [X]. When you read about the world’s leading experts on some technology, I won’t be on that list. That door is closed.
In deep technical interviews, specialists will always have deeper domain knowledge. They’ll know the niche edge cases, the obscure configuration options, the historical context for why things work the way they do. If the interview is “how well do you know [specific technology],” I’ll lose.
And imposter syndrome hits different when everyone around you seems to have “a thing.” At conferences, people introduce themselves by their specialty. “I work on compilers.” “I’m a security researcher.” “I focus on distributed consensus.” What do I say? “I… work on things”?
Where Generalists Thrive
That said, there are environments where generalists have a massive advantage:
Early-stage startups. When you’re 10 people, you can’t afford specialists. You need people who can do whatever needs doing this week. Someone who can write the backend, set up the CI pipeline, debug the mobile app, and talk to customers. That’s the generalist’s home turf.
Technical leadership. To lead an engineering organization, you need to understand all the pieces. The CTO who only understands backend will make bad decisions about frontend architecture. The VP who only knows infrastructure will underestimate product complexity. Breadth is a prerequisite for leadership.
New domains. In AI, crypto, or any emerging field—no one has 10 years of experience because the field didn’t exist 10 years ago. Generalists have a pattern for learning new domains quickly. That’s valuable when the domain itself is new.
Platform and infrastructure. When everything connects to everything, you need someone who understands everything. Platform engineers live at the intersection of frontend, backend, databases, DevOps, and security. Specialists struggle here.
Why a Generalist Is Really a Systems Thinker
I used to think I was a “jack of all trades, master of none.” There’s a popular rejoinder that the real saying ends “…but oftentimes better than a master of one”—it’s a nice line, and as far as I can tell it’s a modern addition rather than the original phrase. I’d rather not lean on a piece of folk etymology to feel better about my resume.
The honest reframe doesn’t need it. I’m not a generalist because I failed to specialize. I’m a systems thinker, and my specialty is understanding how pieces fit together.
The T-shape model helped me make peace with my career: broad knowledge across many areas, with depth in a few. For me, those depth areas are distributed systems, AI agents, and web design. Not because I chose them strategically, but because I kept returning to them as I solved real problems.
Depth comes naturally when you’re solving real problems. You don’t have to force it. The generalist’s breadth gives you context; the depth emerges from repeated application.
The question “what’s your thing?” still doesn’t have a clean answer, and I’ve stopped treating that as a gap in the resume. The bridges between specialties don’t build themselves, and the person who sees the whole system is not the person who went deepest on any one piece of it.
If you’re a generalist who feels like a fraud at conferences: the feeling is real, the diagnosis is wrong.
