Originally written for the Seedcamp resources website.

How to find and hire good engineers seems to be a common problem amongst startups of all sizes. Whether you’re looking for your first non-founder hire, an executive level CTO or are building out a large team, sourcing and hiring engineers is difficult.

In this post I’ll start at the beginning with how to go about sourcing candidates – getting applications into the top of the funnel in the first place. A followup post will go into how to run the actual hiring process itself.

Groundwork – what is it like to work here?

Your first task is to put in place the foundations needed to get people to apply. You don’t need to do any (or all) of these things but they are worth the one-time investment which will pay off with a larger candidate pool in the future.

The key question you have to answer is: why would I want to work for you?

You need to provide evidence to help potential applications answer this question and then the followup: why would I want to work for you instead of Company X.

You essentially need to show off!

So how do you do that? This can be through your website and/or the job ad itself, but you should be thinking about the following:

• Where will the candidate be working if they are successful? If this is an office-based job then explaining the details about the office environment with photos and videos will help them picture where they will be. This should include basic information like the office address, nearest public transport, facilities such as showers, bike storage, desk layout and places to go to eat/drink in the area. Do you have a philosophy behind your office choice e.g. open plan offices to help people communicate, or quiet areas for engineers to get into the zone.
• How will they work? What tools and processes do you have in place? How does the engineering process work and what technologies are being used? If the team is remote, how do things actually work – chat, video calls, regular meetups, etc? These are all good topics for blog posts as well.
• What are your company policies? Publish your handbook if you can but if not, highlight key policies like holiday, sickness, maternity/paternity leave, complaints procedure, code of conduct, pay and performance reviews and how the policies might be adjusted in response to feedback.
• What are the company benefits? This is an important part of the overall compensation package but you may offer certain things to everyone e.g. insurance, car, mobile phone, equipment, travel allowance, conference allowance, profit sharing, share options, etc.

A good way to find out what to include is to ask your current team and/or think about what questions you had when you joined your first company.

Most businesses are quite bad at showing off their policies, even when they are positive and a great selling point. You can stand out by being transparent and having the candidate already partially sold on working for you before they even speak to you.

This is a good opportunity to consider whether your policies are appropriate for different types of people. Fresh graduates renting with friends have very different requirements from an industry veteran living with a family.

Showing you have thought about key things like a code of conduct and maternity/paternity leave also has an important effect on encouraging more diverse applications. With the diversity challenges in the IT industry, it is beneficial to show candidates that you have thought about this in depth and already applied policies within the company. Having to adopt policies dynamically if problems arise is not a good way to build a trusting, friendly work environment.

The job ad

The ad itself is probably the first time a potential candidate has encountered your organisation, so it has to sell both the job itself and the company. Many of the things above can be included in the ad so it works as a standalone article e.g. if it is read on a job board outside your own website, or sent via email.

Things you might want to consider including in the ad:

• A detailed list of the tasks and responsibilities that are part of the role. This should answer the question “what will I be doing?”.
• Who they will be working with and for, and what the day to day might look like. Knowing which team or group you’re going into allows you to understand the context of the role in the wider organisation, and perhaps even look up some of the people who are already working there. Understanding who your manager is going to be also gives you a view on the company hierarchy and seniority of the role. Reporting to a project manager is quite different from reporting to the CEO, for example.
• Describe the selection process so the applicant knows what is going to happen and when. If you can give timelines then that is particularly helpful (and unusual). The experience of most people of applying to jobs is like a black hole – they never hear back and even when they do, it’s on what seems like an arbitrary timeline. There is basically no reason to keep candidates on hold and you should aim to progress people within days or a week. As the process gets to the end it may lengthen because it can be easier logistically to combine interview days, for example, but the early stages of an application process should be very efficient. Consider how you would want to know the current status of the process if you were the applicant. Make the whole process exceptional and the candidate will think of your positively in the long run even if they’re not hired. You may want to work with them in the future, or they may buy your product.
• Avoid listing detailed requirements and long lists of “must have” attributes. I prefer to have more applications that I filter rather than have potentially good people self-filter because they don’t happen to hit one thing in your list. This is a particular problem with trying to improve your application diversity.
• I also like to leave off any degree requirements. Many of my best engineers have had no formal qualifications and are were self taught. Of course, this may vary depending on the types of problems you’re trying to solve – deep technical requirements or specialist topics may require certain qualifications. There is also a certain advantage to having gone through the experience of university (regardless of the subject), but it does select out many excellent engineers. Again, I prefer to filter on other criteria yourself e.g. their experience.
• Where possible use real numbers to show off about the interesting things your company is doing. This can include customers (numbers & names), money raised, revenue and the scale of the technical challenges (e.g. requests per second or dataset sizes). Some of these are vanity metrics but they help to add to the context. Engineers like to know they’re working on meaningful projects.

Where to source candidates

Unless you have a big reputation, you’re unlikely to get many direct applications with the ad solely on your own website. Even the biggest companies use various methods to bring candidates in. There isn’t just a single location that will work so you need to put time and effort into all of these.

Job boards

Job boards are a relatively quick and passive place to get your job ad out. They’re about volume so aren’t necessarily going to get you targeted candidates, but will help to increase the reach of your ad.

There are specialist job boards for different types of roles and people. For example, PowerToFly is a recruitment platform for women whereas RemoteOK is specifically for remote jobs. I recommend building a list of the main job boards relevant to your role and then posting on all of them.

Other ones to check are AngelList, weworkremotely.com, jobspresso.co, workingnomads.co and WorkInStartups.

Candidate search platforms

Direct candidate search is time consuming but is a good way for you to filter through profiles on specific search terms and then directly get in touch with people who fit the criteria.

LinkedIn and StackOverflow Careers are two popular examples, with StackOverflow being very specifically for engineering roles.

LinkedIn also has a job board product which is worth using because the ads show on your business profile and it has a huge audience, but you will be able to be more targeted if you spend the time to search profiles. The problem with LinkedIn is it is very general and I’ve found engineers are less likely to maintain active accounts and/or pay attention to messages which are often spam.

Other sites to consider using include Snap.hr, Hired and AmazingHiring.

Community involvement

Much more long term but often with good quality results, getting involved with the relevant engineering community groups will help you build a profile and meet people with similar interests. This can be specific technology meetups e.g. London Python or focused on techie-types in a certain geographic area e.g. Oxford Geeks.

Speaking at meetups and conferences is a good way to build your reputation. Aim to educate and/or tell an interesting story rather than going with the goal of selling/hiring, but remembering to mention what it is you’re looking for at the end of your talk! It is usually easier to get a speaker slot at a meetup because the organisers are usually looking for people to give talks. These can then lead into conference slots in the future.

In London, the SiliconMilkRoundabout event which is a larger scale jobs fair. They have minimum requirements for applicants so there is a quality bar to the people you meet as a company.

Education links

Although limited to graduates or academics, building links with universities and other educational establishments can help you with a regular pipeline of (inexperienced) talent. This is essential for building a company in the long term but does have training overheads because they are all going to be relatively inexperienced. Timings are also linked to academic terms so this isn’t as useful for immediate hiring needs.

Building an internship and educational recruitment program is quite involved but there is a good book on this topic: Recruit or Die.

Recruiters

I have left recruiters to last because I think they’re the least effective method of finding people.

I have written about this in more detail elsewhere but the problem is that in all cases, the incentives are misaligned. You need a recruiter who 1) is looking for good candidates that fit your criteria; 2) who will find you someone who is good to work with; and 3) someone who will will stay with you for a long time

The only way to find a recruiter who can hit all three of these is by hiring someone full time in-house. Using a success fee or retainer through a recruitment agency means the financial incentives simply don’t match. Either the incentive optimises for finding someone quickly or to create a long process which maximises the retainer income.

Hiring a full-time recruiter who you know gets your company values and will actually work in the same office and probably sit next to the person they hire is the best way to align incentives..

However, in-house recruiters have all the overhead as a full time employee so aren’t necessarily appropriate for small numbers of hires. They only really make sense for growing big teams.

A possible compromise is an exclusive, contract recruiter who is working for you for a defined length of time e.g. 6-9 months. That person can get into the company culture and take the time to find the right candidates, but then leave once they have built the team.

The advantage of using recruiters is they supposedly have good networks of people, although that is really only true for the top end executive search firms, if you’re looking for contract roles or for less skilled general administrative positions (not engineering).

The best engineers can pick and choose a small number of places they want to work at, so they don’t use recruiters. This means for hiring engineers, it’s really tricky to find a recruiter that will actually deliver.

The best way forward is either having someone full time on your team to focus on this and/or focusing on the other sourcing options above to seek out the candidates yourself. Indeed, building your early team is probably the most important thing you can be working on. Without a good team, you can’t build and deliver a quality product to your customers.

Recruiters have a bad reputation, especially for spamming.

I get a lot of emails with unsolicited CVs. Whenever I’ve posted a job ad online, I know to expect that volume to increase. At least they’re helping train my spam filters when I click the “Spam” button!

This kind of behaviour means their reputation is well deserved. The problem seems to be that in almost every case, recruiters have completely misaligned incentives when it comes to finding you good candidates:

• Success fee based recruiters are incentivised to place someone as quickly as possible and have no stake in the long term outcome of the candidate. Although they all have “refund” periods where you get your fee back if the candidate leaves after a certain period of time, the length of time is usually insufficient to properly judge whether someone is a good fit unless they crash out very quickly.

  Even if the refund period applies, they are then even less incentivised to find a good replacement because their profit margin quickly diminishes if they have to spend all the same effort again to get you more candidates.

  That is also the case if you’re too picky. I’ve worked with a number of recruiters (all recommended through referrals) where activity tails off after a period. There’s always an initial burst of profiles but as you reject them, they lose interest. This highlights the lack of incentive to persevere and find those good candidates.

• Retainer based recruiters have the opposite incentive – to create a long process with no time pressure. They get paid regardless of the success of the project or whether the candidate stays with you or not. It can mean you get a more in-depth search, and is sometimes combined with a success fee, but there is still no incentive for them to place someone or put in more effort than the minimum. After-all, they still get paid.

The problem is that in both cases, the incentives are misaligned. You need a recruiter who 1) is looking for good candidates that fit your criteria; 2) who will find you someone who is good to work with; and 3) someone who will will stay with you for a long time.

There are always going to be exceptions, and no doubt the recruiter pitching you will claim they have a new and exciting approach that makes them different, but in reality the only way to match incentives is if they are working for you exclusively full time i.e. they’re an in-house recruiter.

This will be someone who really understands your company values, will work in the same office and probably sit next to the person they hire. They might not be an engineer themselves but they will want to work alongside someone good.

Of course, in-house recruiters are potentially expensive full time employees so aren’t necessarily appropriate for a small numbers of hires. They only really make sense for growing big teams.

A possible compromise is an contract recruiter who is working for you exclusive for a defined length of time e.g. 6-9 months. That person can get into the company culture and take the time to find the right candidates, but then leave once they have built the team.

They won’t be as bought into the success of the hires as a permanent member of your team but it gets close.

The advantage of using recruiters is they supposedly have good networks of people, although that is really only true for the top end executive search firms, if you’re looking for contract roles or for less skilled general administrative positions (not engineering).

The best engineers can pick and choose a small number of places they want to work at, so they don’t use recruiters. This means for hiring engineers, it’s really tricky to find a recruiter that will actually deliver.

Stay tuned for my next post on how to source engineering candidates without recruiters.

In the beginning there were servers, and they had a fixed cost per month. You ordered a certain spec and had a fixed price which was predictable every month. Sometimes you might exceed your bandwidth allowance but most hosting companies included a huge allowance so that was unlikely.

Regardless of how little or how much traffic served and activity performed, the cost remained the same.

For many early switchers to the cloud, the cost remained somewhat fixed. Although you didn’t contract a known price up front (before instance reservations), if you were just using VMs (probably on EC2) then you were still paying a fixed fee.

Network usage was the first real “pay as you go” element for most people moving to the cloud. Both public and private traffic was billed for precisely the amount used, which might have been a nice reduction but was probably a nasty surprise.

Moving from fixed, all inclusive contracts to pay as you go removes a safety net which makes you responsible for optimising your network usage whether it is wanted or not. You no longer have control over spikes and have to pay for sudden popularity or malicious attacks.

This is quite a drastic change of mindset, particularly with regards internal traffic. Verbose network protocols such as for database replication or queuing systems suddenly have a real impact on your budgeting, yet they are very difficult to predict because they’re out of your control.

But that’s just the beginning.

For new cloud-first architectures, every single element of your architecture is billed on a usage basis. Every message in a queue. Every row in a database. Every serverless function call. You can just as easily save a lot of money on low traffic applications as blow through your budget with highly trafficked systems, poor design or bugs.

For developers, this means efficiency matters again. Performance improvements have a direct impact on the bottom line and developer time spend on optimising and refactoring can now be given a dollar value.

The gain is in handing the undifferentiated heavy lifting to a cloud service. Instead of spending time reinventing a standardized component, time can now be spent on the core application code that differentiates you service.

DevOps no longer really means developers understanding how to operate their applications. It’s more about how their applications operate in terms of performance, and therefore cost.

This is quite a shift in mindset.

Understanding the business stage is important when trying to decide the best way to incentivise your team. Startups exist in a state of uncertainty, rapidly iterating to find product/market fit which can scale up. This is quite different from a large corporate with revenues that are likely to be sustainable for the long term.

Incentive schemes must be stage appropriate. They have to reward reaching key milestones which allow the business to transition to the next stage. So what does this actually mean for a startup? How should incentives be designed for those initial 12-18 months of the life of a startup?

Salary

At its most basic, an incentive is a trade. You’re trading an object of value for something else of value. For employees, this starts with money being exchanged for time. The value of that time is determined by a number of factors particular to the individual – their experience and their skills – in relation to the availability of someone similar within the market. Of course it’s not quite as simple a calculation as that, but this a basic approach to thinking about salary.

But salary is just the starting point. There are many other aspects of an employment package which make up compensation, which is in turn just one part of what incentivises people to work.

This is important because incentives have to be more granular than just a salary. The salary is really there just to trade money for time in the pursuit of a goal, but it doesn’t change whether that goal is achieved or not. Indeed, it’s not supposed to – a good proportion of someone’s salary is for subsistence. It’s what they need to live. Rent/mortgage. Food. Travel. Clothes.

The only thing that salary is linked to is the survival of the business. If it fails, you’re out of a job. Certain roles tie success not to the entire business but hitting quotas or targets, such as in sales. Those who are not very good at the job quickly move on. But for most role, there’s not such a direct association between quantitative success and whether you get fired or not.

By itself, salary is therefore an insufficient incentive for most startups.

Bonuses and commission

Bonuses and commission are the next thing which come to mind as very common options for incentives.

Commission is quite easy to deal with because it is just like linking salary/being fired to quotas. Commission is appropriate for sales based roles, whether new business or account management. It directly incentivises increasing the revenue of the business, which is the main goal for most for-profit organisations. However, it is very specific to sales roles and so isn’t helpful when considering a broader incentive scheme.

Bonuses are more challenging. The criteria which determines when a bonus is paid needs careful consideration. The goal must be clear and quantitative. It has to be achievable, but not too easily. And achieving the goal should provide more value to the business than the monetary value of the bonus (at least over the long term). Some consideration should also be paid to exceeding the goal – is it a binary state of achieved vs not, or is there a scale of achievement? In a pure sense, once the goal is achieved and bonus paid, there is no incentive to go any further even though this may be beneficial for the business. So can the bonus amount increase based on what is achieved? How high should it go?

Bonuses also have organisation-wide context. Who gets a bonus and how does it relate to the bonus structure for the rest of the team? People will compare their bonuses both in terms of the value and what they have to do to hit it. It’s very difficult to equalise all bonuses so there may be a negative incentive because someone is unhappy that their bonus is smaller or harder to hit.

Organisation wide goals

Salary, bonuses and commission are all paid to individuals on individual success. How do we incentivise a team or the whole organisation?

Well, bonuses apply here too. Everyone should be working towards a single goal for the organisation and if the effort of the group means you hit it, the group can benefit.

All the problems of bonuses apply here though so for more mature businesses, a profit sharing scheme is a good alternative. It is not a fixed amount so aligns both the goals of achieving a profit, and growing it. With proper transparency into the spending patterns (and decisions), the team can be involved with commercial decisions about whether to increase spending and how to cut costs.

Startups usually use stock options as another form of incentive. However, these only have value if a) the business is acquired (for more than the strike price); or b) the business goes public. Both outcomes are extremely rare and so far into the future that for all incentive based discussions, their value is basically zero. There is of course some value to feeling like you own part of the business and you will benefit in those two events to which you have contributed, but that value is not quantifiable in advance.

That’s not to say stock options shouldn’t be a standard part of startup incentive plans, but for the purpose of this discussion their uncertainty means they’re not a particularly useful incentive.

More individual choice

The problem with organisation wide incentives like profit share, bonuses and stock options is that they reward everyone regardless of effort. There should be consideration for the differences between someone who is putting in 30 hours a week vs someone putting in 60.

There is a growing movement focused around work/life balance, with schemes like 30 hour weeks and ensuring staff get proper breaks by deleting all their email when they are holiday.

Whether this new way of working is reconcilable with the level of dedication needed in the early days of a startup is something I’d like to write about further. Is the legendary worth ethic of Jeff Bezos and Elon Musk necessary for billion dollar outcomes? But for the purposes of incentives, there has to be a link between effort and reward. Effort does not necessarily = results. Working more hours doesn’t mean better outcomes. According to some recent research:

…people who sleep fewer than six hours a night are 2.4 per cent less productive than those who get between seven and nine hours. Overall, the UK loses hundreds of thousands of working days due to insufficient sleep, costing the economy £40bn each year, or almost 2 per cent of gross domestic product.

At some point, the incentives to work more generate negative outcomes. As such, the level of productivity and output must also be part of the calculation.

Why not let people choose?

If your goal is something other than more money – family time, hobbies, travelling, reading – why not opt to work less in return for a different compensation package?

Of course, another word for this is “part time” but that typically implies a proportional salary reduction which might not viable for people who need their entire salary to live. How about if you could trade fewer working hours with your bonus, or a lower commission? Indeed, this might even incentivise you to be significantly more productive to achieve the same (or more) in less time.

Amazon is piloting something similar with an experiment allowing technical teams that work 30-hour weeks for the same benefits and three-quarters the pay of 40-hour employees.

Innovation in incentives

It seems to me that just being paid a salary is quite an inefficient way of incentivising your team.

For the business, it is a fixed overhead that has no real power to incentivise achieving company goals (neither once nor as they evolve).

For the employee, it just serves to fulfil basic security needs and has no relationship between effort or achievement. It’s a backwards looking measure of your worth in the market at the time you were hired and does nothing to link you to the success of the organisation you’re spending so much time with.

With more and more focus on work / life balance, there has to be more innovation in incentives. Bonuses and profit sharing might not sound innovative, but it’s interesting to consider how they’re applied to help encourage achieving goals for the individual and the organisation.

I think we’ll start to see more choice for employees joining new, innovative businesses that help align them much more in the short term, the long term, with financial outcomes and overall wellbeing. Compensation packages should be just that – a package selected from various options that are truly linked to outcomes and motivations. This will provide a compelling differentiator in the labour market and make success more likely overall.

Over the last few years, there has been a trend (particularly in SaaS) where account management is now being called “customer success”.

The latter is considered more modern. There are conferences. There are products. A whole customer success industry has sprung up and everyone now wants to call themselves a “customer success manager”.

But they are not the same.

You can’t just move from account management into customer success and apply the same approach. They are very different skillsets which are also distinct from customer or technical support.

So what is the difference? The clue is in the title.

Account management

This is about focusing on the “account” i.e. the financial metrics.

Account management is usually a sales function with the goal of increasing the account size.

The main job of an account manager is to understand the usage and how to increase it, selling additional licenses, seats or additional products that may be relevant to the account.

There is usually a reactive element to provide the customer with a direct contact if they have problems, but the account manager will typically route those to the right person.

The metrics are account expansion and sometimes new sales. Account managers are usually on commission or have bonuses to match their metrics.

Customer success

This is about focusing on “success” i.e. ensuring the customer fully adopts and deploys the product, then ensuring they continue to use it.

Most customer churn happens because the product was never fully deployed.

The customer success manager is supposed to build a trusted relationship with the customer to help them figure out the best way to use the product without the customer being concerned they are going to be charged more.

Working to understand what problems the customer is trying to solve with their purchase of the product is important. Training and directly walking the customer through everything will be a standard part of the job. This will be a lot of phone and conference calls, sometimes on-site too.

Proactivity is key here. The CSM must understand the usual usage patterns, know when they change and dig into support requests to ensure product problems are solved quickly. They’re also often the internal advocate for the customer across multiple teams and getting feedback to product management.

The metrics are retention (churn) and NPS. There isn’t any scope for commission but bonuses may be attached to those metrics on an aggregate basis for larger businesses.

What’s the same?

Communication. If you’re not on the phone or in conference calls with customers throughout the day, you’re probably doing it wrong.

Email is fine to a degree but whether you’re trying to sell a new product as an account manager or helping a customer with their deployment, nothing beats actually talking with a customer directly.

This is different from technical support which might be better delivered via email/ticket for complex engineering issues (although still often backed up with initial or followup calls).

Deciding what to build and when is the most difficult task for any product/engineering team. There are always multiple competing interests that appear at different times, pulling you in every direction.

Without an understanding of how to prioritise, you can easily switch contexts too often, damaging productivity and making everything feel manic.

Despite this, it is it possible to define some prioritisation rules. These are mine:

1. Critical problems waking up your team
   Your team are the first of two crucial stakeholders. It sounds obvious, but without team members you can’t deliver your service! Stress and fatigue caused by outages have a knock-on effect on your customers because product quality suffers. Engineers must be on call for their own code and systems, but if there are too many out of hours incidents and the trend is not towards a reduction in volume, they will eventually leave. Being woken up (or interrupted out of hours) has a huge impact on quality of life which has to be addressed quickly.
2. Critical problems breaking service for your customers
   Customers are the second of the two crucial stakeholders that determine prioritisation. Your business only survives because customers generate revenue but without your team, you cannot service your customers. As such, customers come second. But any critical issue that is breaking a core service for your customers must be solved quickly. This can range from a complete outage to a major bug that is preventing functionality from working. These types of issues should be parachuted into the current development cycle and fixed first. It’s much easier to keep existing customers happier than to sign up new ones.
3. Bugs and improvements requested by or affecting existing customers
   Linked to #2, keeping existing customers happy is the best way to build a sustainable business. This is especially the case with SaaS, where accounts often grow and revenue can be increased without anywhere near the cost of acquiring a new customer. Existing customers also know what they want to see in the product because they’re actually using it. You don’t necessarily have to agree with them and it may not be appropriate to build everything every customer asks for, but bugs and smaller improvements help to improve retention. SaaS revenue compounds.
4. Innovation
   Since it has never been easier to start a business, differentiation is crucial to standing out amongst the inevitable competition. Products have to continually evolve because what is differentiating today is just a standard feature tomorrow. This means having a unique perspective of the market and what customers want from it. Building solutions to interesting problems helps attract the best team. It makes customers want to stay with you because they see the product evolve. And it makes you stand out from competitors. You can’t stay ahead just by copying.
5. What lost deals or prospects are asking for
   Having a unique position in the market isn’t sufficient if you don’t offer the key features everyone is asking for. Understanding why customers are not buying and/or what they are asking your sales team for will give you a good insight into what you should be building. Sometimes you can commit to delivering requests as part of a deal (or with a chargeable services element on top). I’d also argue there’s a place for a whole product team dedicated just to building requests that come out of the sales and marketing discovery process.
6. What your competitors are doing
   This is often linked to #5 if competitors are defining the market. You need to ensure you cover at least the core functionality for buyers who have a simple checklist, but then this is where #4 comes in to make your offering stand out. However, it is the lowest priority to simply copy what competitors are doing because by definition doing so will mean you’re always behind.

Whether you agree with the ordering above or not, the important thing is to have a set of rules which can be applied to inbound requests.

You’re going to get input from your team, customers, investors, board members, friends, competitors and more. Technical debt, refactoring and rearchitecting also have to be considered (maybe it comes under #1 in extreme circumstances, but it can probably be considered as part of a project that fits into one of the normal priorities).

Things will also change over time.

Only one thing can be top. Unless there is a single, ordered list of numbered priorities, nothing is the priority.

Since starting Server Density in 2009, a B2B enterprise SaaS business, my biggest challenge running has been commercial.

This is a broad area but covers everything from sales and marketing to new customers through to account management and keeping existing customers happy. In recent years, the latter has developed into “customer success” as a specific discipline distinct from customer support or technical support.

In the last 12 months I’ve been involved with hiring for commercial roles in both the UK and the US and there is a clear difference between countries when looking for that crucial enterprise B2B SaaS experience.

My conclusion is that whilst you can quite easily build out product, engineering and customer support teams within Europe and the UK, it is very difficult to do the same with early stage commercial teams. There’s the occasional highly talented individual who has done it before in the UK, but otherwise it’s almost impossible to recruit for commercial roles here. The initial sales, marketing and customer success hires need to be in the US.

The reasons for this are as follows:

The UK and Europe have well established communities around technical roles: engineering, product development, operations, developer relations, community, events, and customer support. You can find people doing these roles at all levels of experience and seniority at companies of all sizes. There are plenty of academic institutions linking with industry to develop more of the theoretical experience, and mainland Europe in particular benefits from a significantly lower cost base which has made outsourcing popular. This all means that there is a large talent pool that scaling startups, corporates and other businesses can access.

For commercial roles in enterprise SaaS, this ecosystem simply doesn’t exist. There are very few SaaS businesses founded and being scaled in the UK or Europe.

The “founded and being scaled” part is important because it’s not the satellite sales offices that count – at the point where you’re creating a new sales office, you have already figured out the repeatable business model and are simply scaling it. It is the stage where you’re still figuring out product-market fit that needs the highly experienced people in key roles who have done it before.

Those people are in the US.

From the BVP Cloud Index, 42 cloud/SaaS companies have a market cap of +$1bn. Of those, 36 are HQ’d in the US and only 1 in the UK (Mimecast).

This is a problem because it’s self-reinforcing cycle. Companies start and are scaled in the US because that’s where the experienced people are and the people are there because that’s where the startups are.

London is the best place to start a technology business Europe. With 58,000 tech firms already located here and more venture capital investment than in Germany, France, Spain and Ireland combined, I agree that London will remain a major hub for the types of businesses that already do well here – fintech, fashion, design, consumer, retail, eCommerce and mobile. But SaaS is lagging.

There are signs of improvement, although there is still some way to go:

• SaaS specific funds like Point Nine Capital and Notion Capital are sowing the seeds but their portfolio companies often relocate commercial operations to the US.
• Box recently opened its European HQ in London, but they have already IPO’d.
• Apple and Google have both announced major new HQs in London, although they are long past the challenges of startup scaling.
• Mimecast has their HQ in London and IPO’d several years ago, although they listed in the US on NASDAQ.
• NewVoiceMedia is a UK based company that looks like it might IPO in the future (given the amount of capital raised).
• A second round has been launched by the GCHQ Cyber Accelerator specialising in security products, most of which will come under the enterprise SaaS category.
• The UK is positioning itself to try and lead the world in AI, self-driving cars, space flight and other “deep tech” developments which tend to have a more B2B commercial focus.

In the meantime, what I think this means for SaaS businesses is that you can start off in the UK and Europe with an initial product and initial funding, but to scale the commercial model through to IPO you have to relocate that part of the business to the US.

Engineering, product, support and operations should remain in Europe because the expertise is available here at great value for money, but sales, marketing and commercial operations need to be where the talent pool is greatest – the US.

A different approach might apply if you’re not going for IPO or trying to build a big business – there are plenty of small, successful businesses in the UK and Europe. But then the risk of being outcompeted will arise instead.

With any product development, there’s always a tension between perfection and getting things released.

The engineering mindset is geared much more towards architectural, design and implementation perfection. The phrase “it’s done when it’s done” is the ultimate manifestation of this approach but that simply doesn’t work with any real product. Customers expect rapid bug fixes, regular iteration and ongoing improvements.

It’s difficult to get the balance between good engineering and “good enough” to release. Bugs hurt the customer experience, creaky architecture can result in poor performance or entire outages, and technical debt wears away at the happiness of your engineering team. But there are some things which might indicate you’re spending too much time on the engineering!

• Refactoring, rewriting or rearchitecting code as a project by itself. The best time to refactor is when you’re already touching the area of the codebase in question. Rewriting code delivers no customer benefit but takes up a lot of time, usually introducing new bugs as well. Major rewrite and replace is usually only justified once you’ve hit scale limitations but even then, taking a component based approach and delivering small changes sooner is better than a grand rewrite over months.
• Investing time building for a scale you have not yet reached. Code will usually last much longer than you expect and so unless you have instrumentation which is showing a customer (or on call) impact either now or imminently, this is probably not a good use of time.
• Rewriting in a new language, or introducing a new language into an existing codebase. Only dramatic changes in usage scope really warrant considering writing something in a language that isn’t already part of your stack. Hitting a scaling limitation might be a reason e.g. shifting from Python to Go for a systems problem within a high performance environment may make sense, but the right consideration should be given to the ongoing maintenance cost . Who else on your team has experience with that language for the future? How are you going to maintain the technology? Who is responsible for updates? What happens if that team member leaves and you have bugs to fix?

Generally speaking, starting a new project or component is the time to consider new technologies, languages, frameworks and approaches. Anything with the words “rewrite” or “rearchitect” should be approached with extreme caution and scoped within an existing project that will deliver customer benefits at the same time.

When I started Server Density in 2009, the company operated on a very low cost, bootstrapped model. I received a small amount of cash from Seedcamp in 2009 and then a few angels in 2011 but for the first few years, the total raised was only around $200k. The company grew off organic revenue with very low costs for the first few years and only more recently raised VC funding.

The years 2009 to 2011 were still very early in SaaS. The opportunities were mostly SaaSifying an existing on-prem business and both the number of SaaS businesses and funding sizes were small.

After 2011, SaaS was considered the business model of the future so competition ramped up and more companies were formed. This resulted in an increase in the capital required to build out and support a “proper” business.

Unless you had achieved a certain revenue scale, it was about to become very difficult to compete and even then, it was quite easy for a better funded competitor to overtake you.

As of 2018, I believe it is now impossible to start and scale a SaaS business without significant capital. Even established businesses are finding it challenging to scale when up against intense competition because of the cash requirements of so many areas of the business:

• The product must continually evolve. Feature comparison is now the standard way of looking at the options when evaluating which product to choose as a customer. SaaS is the only sensible way to have software delivered in 2018 so the sales discussions are less about SaaS vs on-prem but SaaS Vendor 1 vs SaaS Vendor 2. Regardless of whether you actually need all the features on offer, it comes down to how many features a vendor has. This requires a large product and engineering team to regularly release updates and improvements as well as fixing issues.
• Sales teams are expensive, especially in key geographies like the US East and West Coast. They have a high front-loaded cost and take time to ramp up. Recruitment is challenging and very costly. All this needs cash before you see any revenue.
• Self-serve models are very difficult to build up because they require high volume organic traffic. Content marketing is saturated so unless you already have a good ranking, it takes years to build up. Marketing expertise is there but as with sales, it isn’t cheap and it’s time consuming to generate new ideas, build campaigns and pay the huge fees to sponsor and travel to conferences.
• Supporting customers through a proper customer success operation requires experienced people, management tools and a proactive approach which is high touch. Again, building the team is the most expensive area.

Bootstrapping SaaS to sustainable revenues and profitability is so hard in 2018 because of the time it takes to grow organically. During that time, well funded competition will appear, out-build and out-spend.

Funding doesn’t necessarily mean success but it does make competing more difficult simply because it does usually mean a more feature-rich product can be developed.

That said, it is still possible to gradually build up a profitable small software business in a niche area that can grow over time. Many of these businesses exist and provide a great quality of life for the founders or small teams. But this is not the type of business I’m talking about here.

Instead, I’m saying that the model that Server Density took in 2009 to build a large scale, SaaS business around a critical business need like systems monitoring is no longer possible. To get into SaaS today you have to have a major differentiator, rapidly prototype, get some initial revenue and then raise significant capital. And not just that, you have to do it within a short 12-18 month window.

It’s certainly cheaper and easier than ever to form a startup. However, it is has never been more expensive and difficult to scale.

---

Following this post, on Feb 8 2018 I recorded a podcast with Seedcamp discussing this post in more detail:

I’ve been thinking about what the next 10 years of the technology industry will look like and have come up with a few things I think we’ll see develop.

• Self-driving, electric cars will become mainstream and they will be linked to ride sharing services in particular. We’re already seeing countries ban the sale of new non-electric cars. Logistics will be the first to take advantage of self-driving, followed by consumer vehicles. The self-driving transition will be led by ride sharing services, with Tesla entering the market with their own offering. Uber is best placed right now but their success depends on their ability to navigate their major cultural issues.
• Voice driven personal assistants will become significantly better, driven by direct access to your personal data. This will be easiest for Siri and Google Home because they have their own platform where the data resides (assuming Apple develops Siri into more of an open platform). Alexa will have direct access through integrations.
• SaaS as a software delivery model will mature and we’ll see more SaaS companies IPO. There will be no growth and revenues in non-SaaS software will contract – renewals of these non-SaaS licenses will drive most of the revenue, with minimal new business primarily from legacy businesses and/or with FUD reasons. The 2.0 era of SaaS is already over and we’re beginning to transition into SaaS 3.0 which will be about “real” AI driven insights on the data.
• Every consumer device will be connected and considered part of the “Internet of Things” but the largest scale users will be industry. There will be more and more major security incidents involving poorly architected IoT products until government regulation steps in.
• The cyber security industry will transition from 1.0 to 2.0 which will involve consolidation, the emergence of a few big vendors (likely AWS, Google and Microsoft) and a clearer approach to sales and marketing.
• China will become dominant as a world power (militarily and economically). Silicon Valley in the US will no longer be the number one place to be for technology, innovation and startups which will instead be in China. But this will only happen if China breaks down the wall that exists with Chinese companies only really operating in China, unless China is considered a big enough market by itself (it already is, but most technology companies want to go global which is challenging from within China).
• Clean energy will become ubiquitous but we’ll get there indirectly via fracking and natural gas and continue to be supported by nuclear for a very long time.
• We will return to human exploration of space through private enterprise. This will be led by SpaceX but China will become a major player here too, probably suddenly.

I look forward to coming back to grade my predictions in 2028.