Strategy · Cavite

Why We Hire Generalists in Year Four

March 9, 20213 min read

Four years in, our hiring position has stayed consistent: we look for generalists at the senior level. Not people who know a little about everything, but people who can go deep when required and have demonstrated they can navigate unfamiliar territory. Here is the reasoning behind that position and how we put it into practice.

Why Generalists Over Specialists at a Small Studio

At a large company, specialization is efficient. You have enough people that a frontend engineer can stay purely in the UI layer and a DevOps engineer can stay purely in infrastructure. The team is big enough to absorb the specialization.

At a studio with five to ten people working across multiple concurrent projects, that model does not hold. Projects do not arrive pre-segmented into neat frontend, backend, and infrastructure buckets. They arrive as problems. The person solving the problem needs to be able to move across the stack when the work demands it.

We have also found that generalists tend to be better communicators on technical topics. Someone who has worked in design, frontend, backend, and deployment has a feel for the whole system. That holistic view translates to better conversations with clients who do not have engineering backgrounds. A specialist optimizes for their layer. A generalist can see the whole thing.

This is not a universal truth. There are problems - particularly in data engineering, machine learning infrastructure, and security - where depth is irreplaceable. We have engaged specialists for that work. But for the core of what we build, generalists are more valuable to us.

What Generalist Actually Means

We do not mean "knows a bit of everything and masters nothing." That is a different problem.

What we mean is: someone who has genuine depth in at least one area and has demonstrated the ability to ramp up effectively in adjacent areas they have not specialized in. The depth gives them credibility and pattern recognition. The ramp-up ability is what makes them useful when the work goes somewhere unexpected.

The portfolio signal we look for is a project history that spans more than one layer of the stack. Someone who has shipped a frontend application and also written the API it calls is more interesting to us than someone who has written many frontends but has never touched what they connect to.

How We Screen for It

The paid task we give senior candidates is deliberately multi-layer. It requires work that touches more than one part of the stack. We do not tell candidates in advance how to split the work. We give them a problem and observe where they go.

The candidates who ask clarifying questions about the expected user experience before writing any backend code are the ones we usually want to talk to. The candidates who build a perfect backend and deliver no working interface, or a polished interface with no real data behind it, are telling us something about their defaults.

In the interview, we ask about a project that went sideways. How did they diagnose it? What did they have to learn quickly? Did they know when to ask for help? These questions reveal adaptability more reliably than asking about specific technologies.

The Tradeoff We Accept

Generalists take longer to come up to full speed on a project than specialists do on the specific layer they are expert in. A deeply experienced backend engineer will hit the ground running on backend work faster than our generalist senior hire.

We accept that tradeoff because the generalist's total contribution over the engagement is higher. They can help unblock frontend issues. They can contribute to deployment decisions. They can participate in client conversations at a system level. The specialist's peak performance on their layer does not compensate for the gaps their specialization creates everywhere else.

For a small studio, this math works. It might not work for a larger team where specialization is more viable.

If you are thinking about the right shape of hire for your team, the first question is always: what does the work actually require, not what would be impressive to have?

Start a project →

Need this built for your business?

Let's scope it together.

Start a project