Non-technical guide to evaluating engineers
As part of my work at Neatly Labs, I get to talk to a lot of founders of early stage startups. One of the first challenges that founders often face is figuring out how to execute on their MVP. The MVP is a founder’s first crack at translating their idea into a product that’s live in the market and accessible to real users. A well-executed MVP can help validate one or several of the startup’s riskiest assumptions and result in some initial traction, or it can help illustrate flaws in the initial idea and point the founder in a different direction.
As a non-technical founder, there are several possible strategies you can take to build your MVP. In the ideal scenario, you already have a technical cofounder with whom you’ve worked before and who is prepared to go all in on your vision as an equal partner. In this case, figuring out how to build the MVP obviously falls on the technical cofounder’s shoulders. Unfortunately, many founders don’t have this luxury, as it’s rare to find a talented engineer who is both available and whose timing, priorities and passion all happen to align with yours. Drew Houston wrote a good answer about this on Quora.
If you’re in this position, then your next best strategy is to invest some capital into building an MVP, either by hiring an engineer (or several) full-time for a mix of cash and equity, outsourcing the work to freelance developers and closely managing the development effort, or hiring a reputable dev agency to build the initial product. If all goes well and you’re able to get some traction in the market, you will now be in a much better position to attract a high quality CTO.
Regardless of what strategy you take, sooner or later you will find yourself trying to evaluate a technical person or a dev agency. But being non-technical, how the heck do you do this? In this post, I’m going to share some powerful tactics to do just that.
1. Look for the reliable creator
You are looking for someone who can take your idea and translate it into a kick-ass product that solves an important problem for its users. It may sound obvious, but the best indicator of someone fitting the bill is a person with a proven track record of building high quality products in the past. So when you’re looking at someone’s development portfolio or LinkedIn profile, look for proof that they’ve built web and/or mobile products in the past and had a significant, hands-on role in those projects. The nature of the projects can be paid work for a company or startup, freelance gigs, side projects that they took on for fun, profit or learning, or even school projects. The important part is that they demonstrated an ability to execute on a product end-to-end and launch it to real users within a reasonable time frame.
Don’t stop at hearing about each project — actually visit the website or download the app and use it. If none of their past projects are still live, ask them to send you a project some other way or demo it in person. Using a product built by an engineer is the best way to gauge the quality of their work.
As they tell you about their previous work, ask them to explain various product decisions and look for passion for building products. Look for an ability to not only talk about the technical aspects of the system, but also demonstrate a clear understanding of the user, the problems solved by the product for its users, the business model, and the product fit within the broader market.
Look for proof of reliable execution. As an early stage founder, time is of the essence. Not only are you paying to have your MVP built with real dollars, but there’s a high opportunity cost to your own time. The last thing you want to face after investing time and money into an MVP is for the project timeline to double or triple, or to be forced to rebuild the whole product from scratch. Unfortunately, these outcomes are all too common.
So look for engineers who have shown an ability to execute reliably — on time and on spec. Look for people who have excelled in a startup environment, as freelance developers, or have had success in weekend hackathons or other types of competitions. It signals an ability to drive forward and execute in a fast-paced environment filled with uncertainty, and it likely resembles the environment they will face when building your product. The best way to test for this is to simply ask people who have worked with the engineer before.
On the flip side, it should be a red flag if someone is ready to dive in and start building your app before thoroughly understanding and defining the product. They will likely run into unexpected issues and delays later on.
2. Look for the modern engineer
The software world doesn’t stand still. In fact, it moves forward constantly. What used to take 2 weeks to implement a few years ago could be a simple integration of an open source library or third party service with a few lines of code today. You want to build a technical foundation for your company that’s based on modern technologies and uses the best tools for the job, rather than some old technology that your first developer happened to be most familiar with.
To be a good engineer, it’s incredibly important to stay with the times. The best engineers are constantly learning and upgrading their skills. Their solid foundation in software development allows them to pick up new languages, technologies, and libraries very quickly. Unfortunately, I come across developers on a daily basis who are still stuck in the past. Fortunately, it’s actually pretty easy to tell if the tools someone is using are modern or outdated.
A modern web developer is likely to be using Ruby on Rails, Node.js (frameworks like Express.js or Koa.js), Python (Django) or Go on the back-end, using RESTful APIs as the interface for web and mobile clients. On the front-end, they’re likely using React, Angular, Backbone or Ember, alongside a CSS framework like Bootstrap or Foundation. They’re creating responsive websites that look and work well across web, mobile and tablet devices. The modern mobile developer is building apps either natively in Swift for iOS and Java for Android, or using React Native. The modern engineer is also using a revision control system like Git and a continuous integration/deployment strategy to automatically test their code and deploy it to cloud infrastructure hosted on Amazon AWS, Digital Ocean, Google Cloud, Heroku, Azure or other similar services.
If the developer is still building custom apps in PHP, they’re very likely stuck in the past. If they’re a .NET developer, they’re also likely either stuck in the past or too deeply invested in the Microsoft ecosystem.
These rules of thumb are of course generalizations and there are many other good modern technologies that I didn’t list above, but I think it’s a powerful filter. In specialized applications and environments, there are very legitimate reasons to use languages like C, C++, Java, Scala, Clojure, Perl, and many others, but there has to be a good reason. One such environment is embedded systems (hardware) or legacy systems at larger companies. The important thing to look for is that the engineer is flexible to use whatever technologies are best for the job rather than being tied to a specific language or framework only because it happened to be their first love.
Ask the engineer what technology stack they would use for your application. Get them to explain why each of these would be a good choice and how everything would fit together to form a cohesive system. They should be able to clearly explain the big picture, even to non-technical people.
At the end of the day, using the best technologies for the job will make it easier to add functionality in the future, help you move faster, and very importantly, make it possible to attract good engineers in the future when you’re ready to scale up your team. The best engineers will refuse to work with outdated technologies or spend most of their time battling with legacy problems resulting from poor technical decisions early on.
3. Get a second opinion
When you get far enough in vetting a technical person or agency to work with, consider getting a second opinion from a seasoned engineer. It will require some hustle to find someone to help out but it will be worth it. Ask them to review your technology strategy and stack and tell you if they see any red flags. Ask them to look at and assess the engineer(s) you’re planning to work with.
In fact, many founders decide to go a step further and seek out a formal technical advisor for their company. Given that technology is a critical part of your startup, this is not the last time you’ll want advise from a technical person, so involving someone long term in an advisory capacity can be a good alternative while you don’t have a full-time CTO.
Leverage your personal network to find a seasoned engineer who has been in a leadership position before (founder, CTO, VP engineering or lead developer). If you don’t know someone personally, try to find someone with a unique fit or interest in the area or problem your company is tackling and get them excited about being part of your mission. You’re looking for a pretty small time commitment in exchange for a chance to be involved in something potentially big, so finding an advisor should be much easier than finding a CTO/cofounder.
Whatever tactics you take, the decision of how to execute on the MVP and who to work with should not be taken lightly. It can make the difference between getting to the next stage of your business and being forced to fold your operation after dedicating months of your life to it. Successfully executed, you’ll end up with a solid technical foundation for your company and a product that solves important problems for its users and can be built upon quickly.
I hope you found this post helpful. If you’re thinking about similar challenges building your MVP feel free to reach out to me via Neatly Labs, Twitter or LinkedIn.
