In 2016, I gave technical advice to a first-time CEO and entrepreneur building a seed-funded food delivery marketplace. In my view, every tech choice the company had made under his direction was wrong.
He believed in “empowering the engineer” and let the company’s first engineer choose the framework (Scala/Play) because it was what that engineer wanted to use — not because it made sense for the company, the company’s use case, or its recruiting pool. Much of the early technical work had been outsourced. The company’s product road map was also wildly optimistic (building web and mobile concurrently) despite the fact that most of the business was still unvalidated. It was a recipe for disaster.
Startup engineering is different from any other type of software engineering. It demands short- and medium-term productivity, relative to the “right way” of building systems. It values engineers who are able to iterate quickly and are comfortable with hacky code. It rewards pragmatism in technology choices versus picking the most hyped — or most stable — technology.
If your startup has yet to find product-market fit, here are four common engineering traps to avoid.
1. Premature scaling
Premature scaling — the most common engineering mistake startups make — trades immediate productivity for far-off, and often never-realized, benefits. It means dedicating time and resources toward large-scale builds when the company is still too small to know what might be needed in the future.
Premature scaling troubles are everywhere in startups. In the early 2010s, relational databases were shunned partly for the (perceived) infinite scalability of NoSQL databases like MongoDB and Cassandra. The startup productivity benefits of monoliths has been lost in the excitement around microservices. For years, Rails has been called unfit for startups because it is slower than other frameworks.
Scaling before reaching product-market fit is a waste of engineering resources, and can be devastating to early startups, which often have little money and few engineers to deliver on huge feature requirements that require constant iteration.
So, if premature scaling is so deadly to startups, why does it occur so often?
First of all, scaling is fun. The initial version of Twitter was a simple, monolithic CRUD application. Just a few years in, however, Twitter had a panoply of interesting problems: large amounts of data to query, a huge cost to downtime, large usage spikes, a huge user base. Adding the scaled technologies to address these needs made being an engineer there more exciting and attractive to those looking to join the team. That excitement makes scaling too early an easy trap for engineering teams to fall into.
Second, building performant systems only seems rational. Some engineers are appalled by hacky systems, treating them as though they are a moral failing. This aversion to potentially inelegant solutions can be especially hindering for startup engineers who are used to working at large tech companies where everything must be done at scale. But there’s a reason “do things that don’t scale” is a regular missive at Y Combinator, and it applies to engineering as much as it does to business processes.
Technical debt kills fewer early-stage startups than you might think. If your company is successful, you’ll often have the money to fix all the engineering shortcuts you’ve taken and mistakes you’ve made.
Third, engineering road maps and tools are built around hyperoptimistic views of the future. Startup leaders are idealistic about their business growth because, let’s face it, they wouldn’t have started their companies otherwise. Even once a company hits a product-market fit — that critical milestone when engineering decisions need to be reassessed — the danger is still that you’ll overestimate the level of scale you’ll need before you actually need it.
Trying to anticipate those future needs before they arise takes valuable resources away from your immediate goal: building a product that people need.
2. Using shiny, untested technology
“Shiny” technology is tech that software engineers clamor for. It often makes an engineer’s work easier and more enjoyable, especially in the extreme short term. But jumping at the chance to use — and rely on — the newest, shiniest tech risks missing better options that are the most productive for the broader team in the medium term.
For example, MongoDB’s JavaScript-like DSL and JSON data store made writing code an easier experience for JavaScript developers used to relational SQL databases. But ease of use should not be the primary metric when choosing a database.
During a job interview, a software engineer once told me that he’d never work at a company that didn’t use CoffeeScript. (Today, the debate might be about using Elixir.) His refusal to even consider other tools promised problems down the line if the right solution was at odds with his preferred programming language.
New technology has issues, too. The failure states are poorly understood, which makes it hard to anticipate how things will break. New languages and frameworks don’t have libraries, or many engineers who can write in them. This lack of resources increases the development effort and makes recruiting new engineers challenging. It also means committing your startup’s scarce engineering resources to learning something new, instead of creating features that your users value.
Engineers — especially non-founders — want to implement technology that makes them seem relevant in the market. While that makes sense for their own interests and skill-building, that kind of approach should be worrying as part of a startup plan. In spaces like front-end engineering, having engineers chase the current hype cycle could mean rewriting the stack every six to 12 months.
Early-career developers can be especially susceptible to choosing new and shiny technology instead of tried and tested tools that make the most sense for the project at hand. Until you’ve been through a few hype cycles or seen the downsides of choosing the latest technology firsthand, it can be easy to be blinded by glossy marketing pushes in Hacker News or at “hackathons” and conferences.
Just because a technology is hyped doesn’t mean it’s appropriate in a startup environment. When teams are small, new developers don’t always have the mentorship from seasoned engineers to counteract the external media they see.
Engineers are already taking a huge risk in joining a startup. Adding hyped-but-unnecessary technology to the mix only heightens that risk.
3. Hiring the wrong engineers
It’s become a bit of a running joke about job descriptions these days, but startups often make the mistake of looking for “rock stars” or “ninjas.” They want employees with fancy educational credentials and the pixie dust that comes from having a team made up of people who’ve been part of other successful companies.
In Silicon Valley, startup job posts favor candidates who use new and shiny technology over more pragmatic engineers who can learn the necessary tools quickly. Once a company starts looking for these perceived ninjas and rock stars, it sets the tone for every subsequent hire.
The vast number of software engineers don’t work for startups, and startup engineering is rarely taught. As such, most engineers who join startups don’t come in with the skill set or attitude to succeed in a startup environment. Consequently, startups often rely on engineers who aren’t a perfect fit for their projects.
Each of these engineers brings a different sort of risk to a startup:
- Large company engineers are often used to scaled systems and may not feel comfortable with hacky startup code. They’re also much less likely to have been exposed to their users.
- Elite computer scientists often get bored by the plumbing-type engineering typical of early startup tasks, which can lead to overengineering.
- Junior engineers, who are often attracted to startups, may inject too much shiny, new technology or poorly architect their systems.
- Development shops often favor technologies that let them be productive across many clients. These shops have no incentive to learn new tools for a particular client, and also don’t have the long-term skin in the game needed to make critical early tech decisions.
Startups need to look beyond degrees and fancy resumes to find the best engineering candidates for their projects. Ideal engineers for early-stage startups are those who are excited about the company’s mission. This ensures they’ll stay, even when the company inevitably hits challenges along the journey to product-market fit. These engineers have a minimum viable product (MVP) mindset and are comfortable with constant iteration. The best startup engineers often have a few years of experience in the workforce or on open-source projects — they’ve learned how to maintain systems, not just build them.
Rather than seeing particular technologies as silver bullets, great startup engineers favor productive tools that meet the medium-term needs of the organization, and see technology as a means to solving a problem. They think about the problem space (the user’s needs) and how software can be used to solve the problem, rather than looking for a problem that a shiny, new technology can solve.
They need to have can-do attitudes and rise to the Herculean challenges in front of them while moderating, but not naysaying, the optimism of the product owners. At the same time, these engineers need to have empathy and intuition for their users because they often play the role of product when iterating.
One cautionary note: Even among startup engineers, the experience gained at each stage of a startup is radically different. A startup engineer who is effective in a team of five engineers may be terrible in a team of 25. For startups hiring talent, don’t let previous experience as part of a successful startup overwhelm the nuance of what that person actually did there.
4. Problems with product and management
Startup founders are wildly optimistic. They have to be. But this means that the product road map usually exceeds the capabilities of their small teams, leading to too much hiring, too much fundraising, and, eventually, burnout. For management, this cycle begins to look like the engineers aren’t performing, when it actually means that management hasn’t set a clear and narrow vision.
The “always be pitching” mentality of startup founders can give engineering teams a mistaken sense of certainty about how their systems should be built, despite the uncertainty that exists in the business model. A better approach for startup founders to adopt is to support optimistic engineers while developing (internally) pessimistic business leaders, with both sides working together to find product-market fit.
Management teams also often turn to engineering advisers — engineers at other successful startups — to help guide their new company. Importing these “experts” can cause problems when these advisers try to transplant what has worked at their particular company to a new startup that they have spent only a few hours trying to understand.
Finally, management needs to recognize that engineers are a critical component of any major product decision. Too often, engineering teams are seen as service organizations that can be steamrolled when important business decisions arise. Ensuring a healthy relationship between product and engineering teams is just one more reason it’s critical to have hired the right engineers (see number three).
Even if you avoid these four startup engineering pitfalls, you’ll still be faced with challenges aplenty. But, by steering clear of these traps, at least you’ll worry less about self-inflicted wounds.