Finding the right software engineers for your startup

Engineers are the most important recruits for early-stage software startups, but many startups fumble their first engineering hires because they don’t understand what type of engineer they need. Even a great engineer can fail at a company they’re not suited to. Fortunately, there are a few general principles that startup leaders can employ.

Look for experience

Early-stage startups do not have the foundations that make it easy to build great software. These foundations include comprehensive automated testing, reliable automated release pipelines, product management, and a user experience practice. Startup engineers need to be able to build quality software without these tools. Startups should hire engineers who are senior enough to solve problems independently in an unstructured environment with no technical foundations to fall back on.

When you build towards product-market fit, you don’t have time to lay perfect technological foundations. You don’t have the best DevOps practices and move so fast that your code lacks documentation and comprehensive automated tests. Many startups are tempted to staff their early teams with junior developers to save money, but inexperienced developers usually struggle to build software effectively in this environment. In software development, the quality of your recruits is more critical than the quantity. Similarly, many engineers who only have experience in large corporations may have never built something significant from scratch and may face similar struggles1. Engineering teams flounder when every new feature and technical improvement requires the leadership team’s guidance. When you only have a handful of engineers, you need every engineer to own what they build independently. For that to be possible, you usually need experienced engineers2.

Startups often make the opposite mistake, too. They hire engineers at a point in their career where they want to be a manager, software architect, or some other leadership team member. These engineers sometimes see startups as a great place to get in on the ground level and quickly move into a management role3. Sometimes, an engineer with a short timeline in mind for their move to management can struggle as an individual contributor, especially if they weren’t one in their previous job. So, you need to hire an engineer who is experienced enough to build software independently without guidance but who is still committed to writing code every day and not seeking a management role in the short term4.

Developers at early-stage startups also need good product taste and an eye for usability. To build great software, your team needs to understand the difference between good, usable software and poor, unusable software. Until you have product managers and user experience designers, this will be more of an art than a science. So, your engineers should be people who appreciate effective software design.

Comfort with the professional environment

In the early days, career development within a startup is unstructured and difficult to navigate. It is difficult for employees to clearly see the steps towards a promotion. It is also difficult for management to provide high-quality coaching, mentorship, training, and professional development5. All early startup recruits should be comfortable with this reality. The flip side of the unstructured nature of career development within a startup is the opportunity to leap from an individual contributor role to an executive position eventually comes up for many employees. Startup life is high-stakes in many ways, especially in the early days.

Due to poor resourcing, startups require their team to fill many roles. Product managers might do sales calls, engineers might do some UX design, and salespeople might scope out features. For some, this is chaotic and unfair. For others, this is exhilarating and engaging and a fantastic way to learn about and try out other roles you may not have considered for yourself.

Technical experience

After you achieve product-market fit, the importance of software quality skyrockets. As you hire more engineers, developer/platform experience becomes crucial. This transition from moving fast at all costs to carefully balancing speed and quality (i.e., startup to scale-up) is much easier if your engineers have experience with these mature software practices.

In the early days of product development, you are likely to cut more corners than you would like to admit. Eventually, though, you’ll have to repay this technical debt. You will need to build infrastructure, testing, and deployment automation, a user interface style guide, stringent cybersecurity procedures, development environments, documentation, performance and cost optimisations, and more6. This transition will be easier if you hire engineers with experience standing up these practices. Not only because they already know how to do it but because they know how to build software from day one that is easy to transition and mature. Most crucially, at least one of your early engineers should be an experienced stickler for cybersecurity.

Hiring junior developers

Junior developers have a place in all startups, though I think your first few hires should lean more experienced. Junior developers tend to thrive in an environment where mentorship and solid developer tooling are available to them. Some startups get to this place very early in their lifecycle. Others do not. Suppose you hire very junior developers before the working environment of your startup is suitable. In that case, they will struggle to be productive and distract your more senior engineers from their efforts to build the product.

Startups should hire exceptional junior developers when they come across them. Otherwise, they should stick to more senior developers until they have seasoned leaders on their team who have time to act as mentors and adequate developer tooling to empower juniors to contribute early in their tenure. At the same time, startups should strive to reach this point as early as possible because some of the best engineers you’ll ever hire will be those you professionally developed internally. Less experienced software engineers are also sometimes the people most comfortable with the professional environment of a startup (young people can afford to take more risks in their careers).


  1. Just because you have relied upon or tweaked a continuous integration pipeline doesn’t mean you know how to best set one up from scratch. ↩︎

  2. It is common to come across individual engineers with very little experience who are perfectly capable of building great software on their own. The principle of hiring for the right level of expertise should not rule out all relatively inexperienced candidates. ↩︎

  3. It is usually true that startups are a great place to move from an individual contributor role into a leadership position relatively quickly. But, in all roles from engineering to sales and product, recruits with leadership ambitions need to be prepared to contribute individually until the scale of the startup permits them to move into management. ↩︎

  4. No engineer is too experienced to work as an engineer at an early-stage startup because not all experienced engineers want to be managers. Experienced engineers with no management ambitions can be the most valuable contributors to a team. Similarly, the best engineering managers are rarely the best developers. Different people are suited to each role, and it is unnecessary to think of engineering managers as more experienced or even senior engineers. ↩︎

  5. It is the responsibility of startup leaders to provide the best support and professional development to their teams. This benefits not only employees but the startup and the leaders themselves. However, it is unrealistic to expect any of this to be perfect in the early days of development. ↩︎

  6. While startups can and should strive to build these foundations as early as possible, it is unrealistic to expect perfection in all of these areas. If you gold-plate everything you create in the early days, before you even know what your product should be, you will inevitably waste time building tooling for things you will soon throw away as you pivot towards product-market fit. ↩︎

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.

Subscribe for advice

Free weekly advice covering product strategy, development operations, building teams and more.

More advice

Understanding tacit knowledge

As great as it would be to solve all problems with clearly defined processes and documented knowledge, the reality is that most organisational knowledge tends to be tacit. So, companies should factor this into their ways of working.

Australia to quash angel investing

The Australian Government is about to make it nearly impossible for successful startup workers to reinvest their earnings into new startups. Let’s explore the upcoming changes and how they will affect startups, workers, and the Australian economy.

Stepping on toes

How much should competent people, confidently managing their responsibilities, meddle in the affairs of other teams they perceive to be dropping the ball?