Team Talk: Should You Hire A Specialist Or A Generalist To Scale Your Startup?
How do we decide who to hire to scale our startup? When you’re building a new business, getting the right people on board is vital. Our Head of Engineering, Pete, explains our thought process when it comes to hiring.
When our CEO Ishaan founded Trussle back in early 2015, his first two hires were software engineers (including myself). We set about trying to validate the idea that by using technology we could improve on an outdated and inefficient mortgage process. So we spent nine intense months in the back of our investors’ offices working on the first version of Trussle and trying to prove it.
During those months we found ourselves multitasking and doing things that weren’t part of our job description - between us we covered branding, acquisition, design, operations, engineering, and customer success. By working together as a team the business started to take shape. We raised our seed round of funding less than a year later from investors LocalGlobe, Zoopla, and Seedcamp, meaning we could begin to grow the team.
Does a larger team provide a place for specialists?
Even with a bigger team, we found that this pattern of multitasking continued: our Growth and Partnerships Lead was running our data analysis because he had the relevant SQL skills; our Customer Success Manager was also the unofficial office manager and accountant; one of our developers was our part-time tech recruiter and designer, while our Product Manager did the odd bit of front end development.
No one was asked to take on these extra responsibilities; instead, we were intent on getting whatever needed to be done to advance the business. Everyone took the initiative to take tasks on themselves to ensure that the things that needed to happen happened.
Startups tend to lean towards generalists
It’s a common assumption that startups in their infancy are made up of mostly generalists. The discussion around hiring specialists versus generalists has been going on for some time now, and the modern consensus in the startup community seems to be to hire generalists early on. Uber did it, Airbnb did it, and there’s good reason for this: not only are generalists capable of spanning more disciplines, they also make connections that specialists might otherwise miss.
There’s also the option of hiring specialists as and when needed. There are a few reasons for this:
In the very early days of the startup it’s all about validating the business idea, so it might not be clear which specialisms are needed.
Cash is in limited supply. Often, the amount of tasks that need doing outnumber the number of people you can hire.
There can be a lot of unknown unknowns in the early stages of a startup, so having adaptable people will be an advantage. At this point, specialists could become redundant.
Are all roles specialist in their own way?
In Trussle’s case, I was hired as a software developer. Arguably, this is a specialist role in itself - in the same way that providing customers with the best possible service is a specialist role. So you could say that Trussle hired specialists from the outset, and these people generalised when gaps in proficiency showed up - and by that I mean tasks that can’t be fulfilled by the current team’s time allocation or skillset.
Technology is changing how we work
So why is it that in the past hiring specialists were deemed more valuable than generalists? One argument is that the barrier to being proficient at certain tasks became smaller over time as technology and tools improved. The door is open for people to excel in previously-specialist roles without needing deep domain-specific skills or knowledge.
At Trussle, for example, we have a database setup that allows us to have a redundancy failover, which means that if our primary database server dies, we have a secondary server ready to go instantly. In practice, this means that if one computer stops working, work is automatically accessible from another machine. We also take regular snapshots to backup our data, and we have the ability to rollback our database to a particular point in time. Our separate replica database of our production database means that if we need to do any ad-hoc querying we can do so without affecting our customers’ on-site experience.
As a software developer, I have enough knowledge to know that these things are important. Although I don’t have the expertise in Postgres (a database) to configure this setup, I’m confident that given enough time I could learn. The good news is that right now I don’t have to, because a tool called RDS can manage the complexity of the job for me, with a simple interface that I control. Rewind a few years and Trussle would have needed somebody with more depth of knowledge in Postgres to achieve this setup.
Similarly, if you have an idea for a product or website but aren’t very technical, there are tools around to help you build a website landing page, MVP, or sometimes even the entire product. This is a relatively new development - it’s not that long ago that you would have to be able to deal with all of the complexities of building and deploying a website by yourself.
Are generalists and specialists mutually exclusive?
When does generalism end and specialism begin? If you’re not an engineer, you might think that a software developer is a specialist. But within that field you’ll find engineers with more depth of knowledge in a certain area - eg. databases - and then again, you’ll probably find a specialist who knows aspects of databases at an even deeper level. So the term generalist and specialist is relative.
Maybe it’s not a matter of choosing between hiring specialists and generalists. Instead, maybe it’s a case of hiring people with a specialism who aren’t afraid to venture into the relative unknown to fill a task gap and get the job done. When I hire a Full Stack Engineer (a fancy way of saying ‘Generalist Software Engineer’), I still always ask myself what they’ll bring to the team that we don’t already have. This could be a proficiency in a certain area of technology, a different way of looking at the world of software, or even a diversity in personality. Either way, we don’t want to hire clones of ourselves - we want people to bring new ideas and new skills to widen our knowledge.
Although our team has now grown to over 40 and our engineering team has hit double digits, we still want to avoid hiring specialists who narrow their focus too deeply in their specialism comfort zone. Specialists can sometimes run the risk of having a cognitive bias in thinking that every problem can be solved using their particular specialism. We don’t want to fall into the ‘if you have a hammer, everything looks like a nail’ trap, which is why we hire specialists who aren’t afraid to generalise.
Psst, we’re hiring! Take a look at our vacancies - we’d love to hear from you.