Don’t let engineers over-engineer

In any engineers creative heart is a desire to build great things and design a scalable system they can be proud of. But in business, not all problems can or should be designed carefully. Instead, startups often need a scrappy prototype that can be easily changed and shifted during the early days.

this is where many startups hit a wall- their early team has designed a system that was optimized for an early set of requirements, but those requirements have now shifted, and velocity has taken a big hit. Now the teams need to refactor old logic and abandon the early progress the team was proud of. Egos can get in the way, and many series A-B startups end up with embarrassing bugs and significant technical debt.

I have made all of these mistakes earlier in my career, in my startup The Approach. I designed and built a full stack web app I was proud of, but ultimate hit a wall when it came to scaling our early sales effort.

Early engineering teams should instead focus on velocity, keeping a high quality bar, and avoid wading into too much technical debt. Often, this means saying no to feature requests or the last 10% of a product spec. I have found that simply becoming aware of this trap has saved me and my teams countless hours. There’s not always a silver bullet- but I find that almost any engineering design can be simplified for improved internal velocity.

Fighting the engineering mindset to craft and theorize and optimize can lead to immense productivity improvements, and better relationship with the business overall. Craft, theories, and optimization all have their place in healthy learning of skills, but can often bite the business in the butt if not checked.