SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

How to hire your first employees in a startup

Say it’s you and your co-founders (or maybe just you). How do you go about hiring your first employees?

It’s a ton of work. At least one co-founder should be spending 50% or more of their time on this. If that co-founder is you or will be you, read on. I’ve got about 2000 words that will help you.

Tools

You need an Applicant Tracking System. Spreadsheets don’t cut it. There are many. I like Lever for early stage companies and Greenhouse as you scale up. Try and choose one focused on small companies that is fast and easy to use. You don’t need every single feature bullet point. The core is about tracking candidates across stages, and constantly, fairly scoring them on their different interviews.

These might feel expensive when you are small, but I don’t like to skimp here.

Prioritize the work to be done

As you are early stage, you will have 1000s of things to be done across dozens of roles.

Your core goals at this point is to identify what are the work and roles that you need to or want to offload from the founding team. Need to offload means the work isn’t being done or is being done poorly. Want to offload usually means the founding team doesn’t like it or it’s not the best use of time.

Identify where and when a SaaS app, no-code tool or a contractor can help out. A founder should probably not be doing the taxes for the company. Get an accountant. A founder should probably not be manually sending marketing emails. Get an email campaign SaaS app.

Your early priorities are almost always one of Customer Development, Building, Selling and maybe Fundraising. If you are hiring for something other than this, I have concerns.

List the work done

For each open slot you are trying to fill, make a list of the kind of work a mythical dream hire would be able to do. Remember that you will never find this unicorn who leaves rainbows and cookies in their wake as they float gracefully across the room. We call them unicorns because they don’t exist. But the exercise of defining your unicorn is useful. Here’s an example of what an single early builder hire might conceivably be asked to do:

  • Eng skills: front end, back end, infrastructure, mobile, test, tech management, fast working prototyping, long term architecture, etc.
  • Product skills: Customer development, project management, planning, feature prioritization, etc.
  • Design skills: UI/UX, customer research, wireframes, mockups, graphic design, etc.
  • Oh and it’d be nice if they can help with sales calls to close early customers.

It’s not reasonable to hire someone good at everything. But your first few employees need to be able to do many things well. Generalists instead of specialists.

For an engineer, it’s unreasonable to expect them to excellent at engineering, product, design and sales. It’s not unreasonable for an early startup hire to be an excellent full stack engineer, who has good product sense and can wing it with sales and is probably hopeless in design. Or some similar permutation.

Tech Eval

If you don’t have a technical cofounder, you will need some combination of family friends, advisors, consultants, etc. to do some kind of technical evaluation. Do not skip this. ever. References, linkedin bio, work history are not enough. You need to conclusively prove that they can ship product fast in a chaotic environment. There is no single coding test for this.

Again, full stack generalists are way more important at this stage. You typically won’t need engineering specialists of any kind until your eng team headcount starts to hit double digits.

Bonus points for experience at early stage startups (single digit employee number ideal). They will likely have a better shot at sticking around if they know what they are getting into.

Over-index on character

Early hires will dictate the culture of the company going forward.

Work ethic, empathy, getting things done, flexibility, gratitude, etc. are all important characteristics for a nascent company.

Similarly, ego, drama, argumentative, us vs them mentality, empire-building and other forms of toxicity will poison a small company.

Do your homework with references. Back channel if you can.

Over-index on diversity

Diversity is hard. Full Stop.

But it gets harder the longer you wait. No one wants to be the first guy in a team full of women or vice versa.

Do what you can here to start with good practices. This mean unconscious bias training. Reduce bias in the pipeline and process you use. Constantly ask yourself if you are introducing bias in the system.

Remind yourself after every interview that you are trying to project if a candidate is good at a job instead of judging if they are good at interviewing.

Outbound, not inbound

Your small startup won’t have much or any inbound. (even medium startups and some large companies don’t have much inbound)

Resign yourself to outbound. As a founding team, you should expect someone to spend 50% or more of their time working on this. It’s probably the CEO.

Figure out what you have to sell. Every company has something to sell:

  • Tech: open source? Cool ML/AI? Scale? Niche language? Greenfield design and architecture opportunity?
  • Career: weak many hats, leadership, ground floor,
  • Company: people, culture, mission or vision, industry, job satisfaction, full or portal remote work
  • Comp: salary, equity, benefits, perks

There are more. Figure out your message. Create a drip campaign and use that fancy ATS or whatever to interact with your candidates.

I like to send at least three emails from three different people highlights different aspects of what I’m selling. Example:

  1. from CEO: about company, vision, product, your potential role and how you’d take us to the next level
  2. from product manager: Tech stack, cool twist on product, leadership opportunity, you will work directly with X
  3. from CTO: short, final followup. Best wishes, final words, etc.

Space them out. Make sure the tone is human. Your campaign software should hopefully let you customize messages to the candidate.

Outbound again

Stress your network and your network’s network. Use the “just one” trick.

Don’t say “please forward this to everyone you think might be a fit” Instead say “Please introduce me to just one person you think is a fit”

The first has a high burden of cost on the people you are asking. The second does not and in most cases gets you both more and better introductions.

(This versatile trick works for intros to candidates, founders, customers, etc.)

I’ve had better success with high quality candidates with linked in ads than with paying for slots on major job boards. Your results may vary. One exception to the job boards is niche job boards. If your tech stack is golang, find the one or two golang job boards or the weekly golang newsletter and see if paid campaigns drive candidates your way.

The most important thing about paid candidate acquisition is to measure. The second most important thing to do is measure.

If you can’t tie results to your paid campaigns, you might as well just throw money in a dumpster and light it on fire. Cut off the campaigns that don’t work and double down on the channels that do. It’s easy to double down on ads, but you can double down on a good job board by increasing the number and variety of job descriptions.

Remove bias

Since you won’t have as much candidate flow as a FAANG, it’s important to understand you cannot recruit like them.

Early and mid-stage startups have much less tolerance for false negatives and false positive in the process than large companies that have size and budget advantages.

You must do everything you can to remove bias from every stage of the pipeline.

Start with Unconscious bias training. Even the free online web versions are shown to help. Professional on-site training is even better if that makes sense for you.

Some examples:

  • Job Descriptions
    • Inclusive language
    • Minimal bullet points and minimal must-haves or requirements. I usually have as few must-have bullet points as possible. For the nice-to-haves, paragraph form is better.
  • Initial intro call
    • Sell as much as possible here. You should have a large pass rate here, like 90 or 95%+
    • They don’t seem that interesting or they were hard to understand is not a great reason to decline
    • For me personally, someone has to be truly rude or mean to bomb out. Don’t hire assholes, even talented ones.
  • Technical phone call
    • These can’t be too hard. Aim for proving the fundamentals.
    • FizzBuzz, proper use of maps vs arrays, etc.
    • Architecture or data modeling can also be done here, but they should be simple and straight forward. This is hard to do over the phone and ideally should be done with a whiteboard or an online diagramming tool.
  • Onsite or Later-stage remote interviews
    • As much as possible create exercises that mimic the real work being done. At no time, resort to brainteasers or trick questions.
    • Remember that people don’t code on whiteboards or in web browsers. They use IDEs on their laptop and your exercises should reflect this.

Across all stages, you should standardize your questions per stage per role. If every engineer asks their own pet question, you can’t accurately compare your candidates and both your false negatives and false positive rate will increase.

Lastly, constantly remind everyone in the process that you aren’t judging people on how well they interview. You are projecting whether they will be a successful employee 6, 12, 24 months from now.

You aren’t done. Removing bias is a constant process. You should be constantly iterating to reduce false pos/neg rates.

Warning flags

In line with removing bias, there aren’t that many true warning flags. You want to give people the benefit of the doubt.

However, two true warning flags to look out for:

  • Mean, rude or dismissive. Especially of support staff such as receptionists, recruiting coordinators, wait staff, etc.
  • Confidently incorrect.

Onboarding

You do have to worry about onboarding. You don’t need a comprehensive onboarding program. Your earliest employees set the tone an culture for many of the employees that come after. Additionally, they tend to create the onboarding programs you use as you scale.

Your earliest onboarding can be as simple as one shared document where people write things as they learn them or don’t know them: - things they need to know to get to work - open questions they have - how I did X or Y - things they learned but wish they new earlier.

No need to get fancy here. investing in a wiki or FAQ is likely overkill. A shared google doc or notion page is enough. It just has to be searchable. An #onboarding channel in slack is a good start, but it tends to be unorganized and hard to search. it’s a great rplace to ask and get info however. Try to normalize getting the info out of slack and into your doc. if you copy a url to a slack convo, normalize copying the contents of the conversation as well.

Wrapping up

Don’t get too wrapped up in creating process. Your first few hires should be scrappy and mostly manual. Poor fits and toxicity are magnified. Over time, you’ll find things that work and eventually will be ready to scale. Only then should you invest in a recruiting team that is skilled enough to put the process together with the cooperation of your existing teams. Recruiting should start messy and over time evolve to something repeatable and scalable by partnerships and iteration.



in lieu of comments, you should follow me on bluesky at @amattn.com and on twitch.tv at twitch.tv/amattn. I'm happy to chat about content here anytime.


the fine print:
aboutarchivemastodonblueskytwitchconsulting or speaking inquiries
© matt nunogawa 2010 - 2023 / all rights reserved