The generalist vs specialist question has followed me for most of my career. I have been asked which one I am more times than I can count, and for a long time I did not have a clean answer.

I work as a Growth Engineer. I run SEO, build web products, and ship mobile apps. I picked up pgvector and RAG to build a vaccine reference assistant without a formal ML background, because the product needed it. I maintain a self-hosted homelab on Oracle Cloud with about a dozen services running. I also shoot photography on the side. None of that fits a single job title neatly.

For years I treated that as a weakness. Now I think it is the point.

This is not an argument that generalists are better than specialists. Both paths work. But if you have been quietly wondering whether your scattered interests are a liability, this is the playbook I have built for myself — and why I think breadth is an underrated edge in tech right now.

Generalist vs Specialist: What Is the Actual Difference

A specialist goes deep on one domain. Think of the backend engineer who knows Postgres internals cold, or the security researcher who lives in one CVE class for years. They are trusted precisely because of that focus. In fields like medicine, law, or systems programming, that depth can be irreplaceable.

A generalist moves across domains. They may never be the best at any single thing, but they can hold the map when everyone else is reading their own section of it. They connect what the frontend engineer built to what the marketing team is trying to say, and to what the data is actually showing.

Neither is universally better. The honest answer is it depends on your career stage, your industry, and what you are optimising for. Early in a career, going deep on something builds the credibility and intuition you need before you can bridge disciplines meaningfully. Spreading too thin before you have real foundations just leads to surface-level knowledge everywhere.

The tension only becomes interesting later, when you have some depth and start asking whether to dig deeper or go wider.

Why Generalists Have an Edge Right Now

AI is automating the repeatable parts of specialised work fast. Code completion, SEO audits, legal summarisation, data cleaning. The tasks that used to justify hiring a narrow specialist are increasingly handleable by someone with broader skills and the right tools.

What AI cannot do well yet is hold context across domains. It cannot take a conversation with a clinic director, a Supabase schema, and an App Store review thread and synthesise a product decision from all three. That kind of synthesis is what a generalist does by default.

The other shift is company size. A lot of valuable work happens in small teams now, where one person needs to cover ground that would previously have been three roles. Growth engineers, product engineers, full-stack marketers. These are generalist roles even if they have different names.

That said, the generalist who cannot go deep on anything is also not that useful. The version of this that actually works is what most people call T-shaped: genuine depth in one or two areas, plus enough breadth to operate across adjacent ones. That is what I am aiming for.

My Playbook as a Generalist

I did not set out to be a generalist. I followed what was interesting and useful at each stage, and this is the pattern that emerged.

1. Curiosity first, but pointed

I follow what is interesting, but I try to point it at something real. When I got curious about self-hosting, I did not just read about it. I set up Coolify on an ARM server, ran into a nasty S6_INITIALIZED bug during a containerd migration, debugged it, and wrote it up. That is now a piece of content that gets upstream links from the GitHub issue thread.

Curiosity without output is just entertainment. Curiosity that ends in a shipped thing, a written postmortem, or a deployed service compounds.

2. T-shaped learning

I cover a broad range, but I have chosen two anchors where I go deeper: software engineering and growth/SEO. Everything else I try to know well enough to not be a liability in conversation, and well enough to build on when needed.

The anchors matter because they give you something to return to. Without them, breadth just becomes noise.

3. Cross-pollination

The most useful moments in my work happen when something from one domain solves a problem in another.

Photography taught me about composition and light, which shaped how I think about UI and visual hierarchy. Building the RAG assistant for the Vaccines app taught me about embedding models and chunking strategy, which I now apply when thinking about content structure and semantic SEO. Running cron jobs with ntfy notifications for my homelab taught me about observability, which changed how I instrument production apps.

None of these were planned connections. They emerged from working on real things across different contexts.

4. Tool stacking

The real productivity gain is not any single tool. It is knowing how to wire them together. My day-to-day stack is Next.js, Supabase, Cloudflare, Expo, and a handful of self-hosted services. But knowing each one individually is less useful than knowing how they fit together and where the seams are.

The same principle applies to growth work. Combining Semrush keyword data with structured content and a backlink strategy from incident postmortems is more effective than any one of those tactics alone. The generalist advantage is seeing the full chain.

5. Side projects as proof

Side projects are where I test whether something I think I know actually holds up. The Vaccines app is a production iOS app on the App Store built with Expo, Supabase, pgvector, and RevenueCat. Before building it I had never shipped a mobile app. I learned by doing it for real, with real stakes.

Some projects fail. That is fine. The point is the accumulation of real experience across domains, not just theoretical knowledge of them.

The Hard Parts

Being a generalist is not comfortable, at least not early on.

There are consistent moments of feeling like you are not expert enough in anything. Impostor syndrome hits differently when you are surrounded by specialists who have been in their lane for a decade, and you are the person who touches everything.

Job descriptions make it worse. Most roles are written with a specialist in mind. A job posting for “Senior SEO Manager” or “iOS Engineer” assumes you are purely one thing. Generalists have to do more work to translate their value into terms that fit a box they were never designed to fit.

The fix I have found is to lead with one clear anchor when introducing yourself, then let the other layers come out as they become relevant. I say I am a Growth Engineer with a software background. That lands. The homelab, the app, the SEO work, the photography all come out in conversation, and they usually make the introduction more interesting, not less.

The goal is not to hide the breadth. It is to give people a handle to hold first.

Why the Future Rewards This

The workplace keeps changing faster. AI keeps eating the repeatable, specialised tasks. What stays valuable is the human ability to think across contexts, make decisions with incomplete information, and communicate between people who do not share a language or domain.

Generalists are not competing with specialists. They are the connective tissue between them. Where the specialist goes deep, the generalist maps the terrain and makes sure the depth is pointed in the right direction.

The most valuable people I have seen in fast-moving companies are not the deepest specialists or the broadest generalists. They are the ones who have enough depth to be credible and enough breadth to be useful beyond their lane. That combination is rare and hard to replace with a model or a job board hire.

Generalists as Translators

One thing that does not get talked about enough: generalists are unusually good at explaining things across audiences.

Because I have worked across engineering, marketing, product, and SEO, I can talk to a developer about database schema design and then walk into a conversation with a clinic director about patient-facing features. I can write a postmortem that gets read by other engineers and also write an onboarding email that a non-technical user actually understands.

That translation ability is undervalued. Specialists know their domain deeply. Generalists know enough of several domains to move between them without losing the thread. In a world where most real problems cross domain boundaries, that is genuinely useful.

What This Means for You

If you have been treating your variety as a liability, the reframe I would offer is this: your combination of skills is not something a job description can replicate, and it is not something a narrow specialist can copy quickly.

The bet is not that generalists win and specialists lose. The bet is that the generalist who has built real depth in a couple of anchors, worked on real projects, and can translate across domains is not replaceable by either a specialist or a model.

Follow the curiosity. Ship real things. Write down what you learn. The breadth compounds faster than you expect when it is attached to actual output.