Engineers are known for wanting to do things the hard way.
We prefer building things from scratch, even if 90% of the technology we need already exists. We like pushing boundaries. And we’re drawn instinctively to complexity. It’s like we think of the complexity of a given problem as a proxy for how much mental weight we’re capable of moving.
That drive, however — to show off, to impress our colleagues with our mental strength — is exactly what holds so many engineers back.
See, complexity breeds more complexity. The more parts a product has (and the more complex and custom those parts are), the harder and costlier every production activity around that product becomes. More complexity means more development time, more testing, more maintenance, more documentation, and more ramp-up hours needed for anyone new who will be joining your team.
Complexity is a lot easier to add than it is to remove, and as result, many complex products quickly become too complicated for their users and their developers.
The costliest mistake of engineering is over-engineering your product.
I’m guilty of this, but I’m also familiar with coaching for it as a former engineer, co-founder, and as a former head of studio at Glu Mobile. And over the years, here’s what I’ve learned: what engineers should be focusing on is not complexity or scale, but rather speed and simplicity.
There are a few key principles that engineers learn back in Design for Manufacturing 101 that are worth resurfacing, since many of us forget to follow them in real life:
- Reduce the total number of parts. The reduction of the number of parts in a product is probably the best opportunity for reducing its overall costs.
- Use standard components where possible. Standard, or pre-made components, can usually get you up and running faster and cheaper, and you’ll have a bigger community of specialists who can help you should you encounter problems.
- Maximize compliance and fault-tolerance. You don’t want errors in one small part of your system to crash your entire product. This requires discipline and good communication across your entire team.
In the end, the easier our tools, games, and apps are to use and understand, the better for everybody — our team members and consumers alike.
Here’s why.
Users don’t care how much work went into a given product.
The only thing users care about is how easy your app or game is to play. They care about the experience of the interaction. They don’t care about what’s happening underneath — and, as long as things continue to work, we shouldn’t either.
If we spend too much time obsessing over the engineering minutiae (which only other engineers care about), we risk wasting time and money.
The first company my co-founder, Alex, and I started, for example, was called TrackingSocial, a social media analytics platform. I was responsible for designing our data ingestion pipeline and our analytics products. And I remember being absolutely convinced that to truly impress our potential clients, the platform needed to be fully functional and dynamic to show off our engineering muscle. We dedicated months to it and delayed demos to make sure that what we were building met that high bar.
Ultimately, however, clients preferred reviewing our static UI/UX mockups for demos. And to top it off, many of those potential clients who finished reviewing those mockups ended up wanting something different than what we’d built.
The lesson? Before you build, put yourself in your users’ shoes, or even your investors’ shoes. We would have been much better off testing our mockups at the outset to confirm that what we were building was what people wanted. This lesson sounds corny, and has been said a lot before, but it’s true.
Complexity compounds.
Of course, over-engineering can have internal repercussions, too. When even one aspect or component of your software becomes overly complex or time-consuming, it can easily spread and affect the whole system.
It makes it harder to ramp up new engineers to work on any of your complex components. In turn, testing, monitoring, and maintenance of these things becomes harder, as well.
And if this goes on long enough, your company may evolve into a culture of complexity — one where engineers will want to show off how complex of a problem they can tackle in front of everyone else on the team. This is something I saw a lot of while working at Microsoft, and I’m sure it happens at many other tech companies, too.
Any benefits of the initial complexity quickly erode into wasted time and money. So as founders, this is something you must avoid.
The reason? Over-engineering is bad for business.
This is pretty simple. Overly complex products are expensive, time consuming, and ineffective, as most of the time they’re not what users want.
That’s why it’s up to the team leads and company founders to check their engineers’ propensity for over-engineering, and instead push their people to prove out their assumptions with simpler, more effective tech.
At Dairy Free Games — the company Alex and I sold to Glu — I learned this the hard way. We were convinced, early on, that the prototype server infrastructure we’d built wouldn’t be able to handle a large enough influx of users for our beta testing. So we tried to strengthen it and improve the load-handling by nearly 1000x. This, of course, required tons of time and resources, and in the end, predictably, we found that our initial server was more than enough for what we needed at the time.
Here’s the thing: this mistake stemmed not just from a strategic error, but from our personal attraction to complexity, and the thought that bigger and more complex is always better.
And that, ultimately, is what holds engineers back.
The solution? Force yourself, always, to focus instead on keeping things simple. Prove your assumptions out using the simplest, fastest, and most standard ways possible before investing heavily in any unnecessary complexity.