Four Engineering Startup Killers Tips

Recently, I gave technical advice to a first time entrepreneur building a seed-funded food delivery marketplace. In my view, every technical choice made by the company had made was wrong.

The CEO’s believed in “empowering the today’s engineer.” They then let their first engineer choose the framework  because it was what the engineer wanted to use, not because it made sense for the company, their use case, or the recruiting pool. Much of the early technical work had been outsourced. Their product roadmap was widely optimistic despite the fact that most of the business was still unvalidated by many companies. 

Startup engineering process is different from any other type of software engineering. It demands short & medium term productivity, relative to the right way of building the systems. It values people who are able to make change very quickly and are comfortable with hacky code. It rewards new innovations in technology choices versus picking the most hype or stable technology.

If your startup has yet to find right product market fit, there are four common engineering traps to avoid .

Premature Scaling

The most common startup engineering mistake is to scale prematurely.

Premature scaling means building for large scale when you’re still small. Premature scaling trades immediate productivity for far off, and often never realized, benefits. Premature scaling troubles are everywhere in startups. 

Premature scaling wastes various engineering resources. Scaling before reaching product-market fit is devastating for early startups who have little money and few engineers but huge feature requirements and the constant need to iterate.

Why does premature scaling occur so often if it is the number one startup killer?

First, scaling is fun. The initial version of Twitter was a simple monolithic CRUD application that any bootcamp engineer can now build. Just a few years in, 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 in the scaled technologies to address these needs made the job more exciting and more attractive to those joining. The excitement makes early scaling an easy trap for engineering teams to fall into.

Second, building performant systems seems rational. Some engineers are appalled by “hacky” systems as if they are a moral failing. This aversion to potentially inelegant solutions is especially an issue for startup engineers who worked for large tech companies where everything must be done at scale. “Do things that don’t scale” and it applies in engineering as much as it does in business processes.

Technical debt kills less early stage startups than you think. If you’re successful, you’ll often have the money to fix all the engineering mistakes you’ve made.

Third, engineering roadmaps and tools are built around hyper-optimistic views of the future. Startup leaders are idealistic about how their business grows because, let’s face it, they wouldn’t have started the company otherwise. Even once you hit product-market fit — a critical milestone when engineering decisions need to be reassessed — the danger is that you overestimate the level of scale you’ll need.

Trying to anticipate future needs before they arise takes valuable resources away from your immediate goal — builda product that people need in newest technology.

Using Untested Technology

Startups hurt themselves when they rely too much on  newtechnology.

Shiny technology is technology that software engineers rely on but future might not be there. Shiny technology often makes an engineer’s life easier and more enjoyable, especially in the extreme short term. But relying on the newest tech misses what will be most productive for the broader team in the medium term.

Let us take an example, MongoDB’s Javascript-like DSL and JSON data store made writing code an easier experience for Javascript developers compared to using relational SQL databases. But ease of use should not be the primary metric when choosing a database.

During an interview, a software engineer told me that he’d never work at a company that didn’t use JavaScript. His refusal to even consider other tools promised problems if the right solution was at odds with his preference.

New technology has its own issues. The failure states of new tools are poorly understood, so it’s hard to anticipate how things will break. New languages/frameworks don’t have libraries or many engineers who can write in them. This lack of resources increases the development effort and makes recruiting challenging. It also means committing your startup’s scarce engineering resources to learning something new when you could be focusing on creating features that your users value.

Part of the problem is that engineers — especially non-founders — want to implement technology that makes them seem relevant in the market. That should worry a startup. In spaces like front-end engineering, having engineers chase the current hype cycle might mean rewriting the stack every  6 to 12 months.

Developers early in their career are especially susceptible to using new and shiny technology instead of tools that make the most sense for the project at hand. They haven’t been through a few hype cycles or seen the downsides of choosing the latest technology. 

Worse, these developers don’t realize that just because a technology is hyped that doesn’t make it appropriate in a startup environment. It’s common to take a tech stack of a well known startup or large company and transplant its stack, without assessing the appropriateness of these choices. When teams are small, developers don’t always have the mentorship from seasoned engineers to counteract the external media they see.

Startup developers cite Paul Graham’s famous post, The Python Paradox, where Python increased startup productivity compared to Java. Graham’s post is often used to justify implementing every latest framework and language. However, Graham’s real point was that software engineers should pick tools that maximize startup 

They need to have a can-do attitude. They rise to the herculean challenges in front of them while moderating, but not naysaying, the optimism of the product owners. These engineers need empathy and intuition for their users because they often play role of product when iterating.

One cautionary note. Even among startup engineers, the experience gained at each stage of the startup is radically different. A startup engineer who is effective at five engineers may be terrible at 25. For startups hiring talent, seeing an engineer who was part of a successful startup often overwhelms the nuance of what that person actually did there.

Startups should look beyond the name brands and hire based on fit for the current project.

Problems with Product and Management

So many startup mistakes stem from product and management, not engineering.

Startup founders are wildly optimistic. The product roadmap then usually exceeds the capabilities of their small teams. This optimism leads 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 didn’t set a clear and narrow vision.

The always bepitching startup mentality of founders also gives a mistaken sense of certainty to the engineering team about how the system should be built, despite the uncertainty that exists in the business model. A better mindset is to support optimistic engineers and develop (internally) pessimistic business leaders, with both sides working together to find product-market fit.

Another problem for new startups is that management often finds engineering advisors — engineers at other successful startups — to guide the new company. Importing supposed “experts” from potentially unrelated companies or fields raises problems when these advisors transplant what 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 its engineers are a critical component of any major product decision. Too often, a company’s engineers are seen as a service organization that can be steamrolled when important business decisions arise.

Don’t Shoot Your Startup in the Foot

Even if you avoid these startup engineering pitfalls, you’ll still be faced with challenges aplenty. But by steering clear of these traps, you’ll worry less about self-inflicted wounds.

You can visit our website for more info Neolite Infotech India Pvt Ltd

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.