Zero to one vs. one to N Developers

Zero to one vs. One to N developers

On the book

This post builds on many of the ideas of Peter Thiel's book Zero to One, so if you haven't read it yet you should! The thesis of the book basically boils down to this: there are two types of businesses, those that create value by building something new and those that do so by scaling to be very large.

It's not binary

Similar to the book, developers tend to lean one way or the other. They are drawn to either creation or scale, but exist on a spectrum between the two. It's important to keep this in mind when looking for talent: rarely do developers land strongly on one end of the spectrum or the other, but if you interview them properly you'll be able to tease out their inclination.

One to N

Bigger companies hire this type of developer. As the business reaches product-market fit and grows, the engineering team grows along with it. Process and structure start to become important, as does predictability of delivery. Technical debt needs to be paid off and the product needs to scale up to accommodate lots of new customers.

Growing companies like this need developers to execute their pre-defined vision. They tend to hire developers with strong academic backgrounds who can take a well-defined problem and execute against it with precision.

Zero to one

Zero to one developers are creatives at heart. Their talent lies in their communication, collaboration, and business skills, which makes them ideal for bringing a product to market. They thrive in the chaos of an early-stage company and ship code incredibly fast, even if it doesn't completely work.

Early-stage companies need these developers because speed and flexibility are critical to going from zero to one. Since the problem they are solving is never well-defined and always changing, their ability to think through business problems holistically brings a great deal of value to early-stage companies.

What a mismatch looks like

Larger companies generally don't hire mismatches in the first place. They have rigid hiring processes that filter out candidates who don't fit the exact One to N profile that they're looking for. They're pretty good at this process, so this post won't belabor the intricacies of a notorious recruiting process.

Smaller (or barely-existent) companies do hire mismatches. Since they usually can't pay as much they have a more difficult time attracting talent and will hire from a much broader pool. The problem is, of course, that if a company needs a Zero to One developer and hires a One to N developer, everyone will be miserable. Here are some of the symptoms:

1. Complaints about changing priorities
2. Too much time spent on solving problems exactly right
3. Complaints about lack of/poorly defined requirements
4. No push-back or collaboration on requirements
5. Poor attention to UX

Of course, all developers display some or all of these qualities from time to time. It's when you start to see patterns emerge that you should be concerned. Remember: this doesn't make the person a bad developer, it just makes it a bad fit!

Know thyself before looking for talent

Before you look for talent, keep the above in mind. Know what stage your company is in and look for a developer who fits accordingly. Failing to do so will cost you a lot of time, money, and pain!

Need a hand?

I provide hiring, coaching, full stack development, and management for startups. Click here to learn more, or schedule a free 30 minute consultation.

Want to go more in-depth?

This article is pretty high-level. If you want more details and tactics on how to deal with developers, sign up to get 50% off my upcoming book, Dealing with Developers.

Questions or comments? Drop me a line at me@jeremyphelps.com or tweet me @remyphelps.