VII. We Will Not Accept the First Solution a Dev Thinks Up

“Go with your gut,” “trust your instincts,” and “follow your intuition” have something in common: They’re terrible strategies when you’re making a decision.

Why? There are too many ways for an engineer’s instincts to get hijacked. It’s too easy for an engineer to think that they’re choosing a technology or approach because it’s the best for the situation when something else is going on.

Here’s a typical scenario: You need to create a simple documentation site. You tell the engineer. The engineer has been reading about how great Hugo/Gatsby.js/Next.js/whatever is. The engineer says you should use Hugo/Gatsby.js/Next.js/whatever and you say, OK. Now instead of spending time on the actual documentation, your engineer is spending time getting Hugo/Gatsby.js/Next.js/whatever to work properly.

This simple documentation site could be a single HTML file. The v1 could be created and deployed within an hour. Instead, the engineer is fiddling with React server-side rendering, webpack nonsense, and a specialized build pipeline for days. Why does this happen?

The important thing to remember is that your engineers have different priorities than you do. You want new features that help your customers and coworkers—as quickly and as bug-free as possible. Your engineers want to solve puzzles in new and interesting ways. Sometimes these priorities align. Often, they don’t.

Is the single HTML file the “best” approach? Not always. However, the HTML file solution is probably the simplest, and that was the stated goal up-front. This is a scenario where it’s easy to spot misaligned priorities.

The answer depends entirely on the purpose of the site. Is this needed just to check a box for a potential client and it’ll never actually be used by a human? Is this site going to be a major selling point that needs to be feature-rich and slick as hell? Or was this solution needed yesterday, and anything later than a week from now (no matter how amazing it is) is useless?

Devs who always want to do the most feature-rich, slick-as-hell version are just as problematic as the devs who always want to do the quickest, dirtiest, most hacky version. However, the problems don’t actually start until they get attached to an approach and start fighting alternatives. So how do you prevent disaster?

I’ll tell you what not to do. Do not tell your engineers how to solve problems. You are the “what”; they are the “how.” If you take that away from them, they won’t have any stake in the outcome. Any bugs or issues will just be chalked up to doing it differently than they wanted to.

So how do you both have the engineers take ownership of the approach and avoid them choosing problematic approaches?

Don’t accept the first solution they come up with. Make sure that they know that single approaches will not be accepted. They must come up with at least three alternatives to avoid digging in and becoming emotionally attached.

When a dev only presents a single approach, it becomes theirs. They’ll interpret your rejection of the idea as a rejection of them personally. This is why you often see irrational arguments when a dev pushes back on an idea.

If we take the example above, you might say that the site needs to go up quickly and you don’t want the team to have to learn a new framework. The engineer might respond with how popular Gatsby.js is, how much faster the site will load because of server-side rendering, or that it’s “modern” or “best practice.”

There are infinite ways to achieve any desired outcome. They certainly won’t all be viable, but it’s a fallacy to think that there’s only one right answer and it’s always going to be the first thing your dev thinks up. The last thing you want is to have to make an “all-or-nothing” decision.

If the goal is to get to the other side of a river, your engineer probably wants to build a bridge. If this is their only idea and you suggest that it might take too long, they’ll dig in and say that Google and Apple build bridges, bridges are the safest way to cross a river, and users love bridges and constantly take photos of them. It won’t matter if any of these things are relevant to your situation.

A different thing happens when your dev presents multiple approaches. When you tell them that a bridge will take too long, instead of fighting you like their ego depends on it, they’ll present a different solution. They’ll tell you that instead of building a bridge, you can just pay to rent a helicopter. Too expensive? How about a rope and simple raft?

Your constraints will invariably be some combination of high-level categories like time, quality, and price. Therefore, an easy way to cover your bases is to make sure that of the three approaches, one is inexpensive, another is quick, and only the final one is full-featured.

Why doesn’t this happen naturally? It’s uncomfortable to sit with open problems. Engineers like to build. The sooner they have a solution in mind, the sooner they can get to the “real” work.

However, if you want your devs to be creative, you need to train them to resist the urge to take the easy way out. They need to tolerate that uncomfortable feeling while they think through multiple facets of the problem.

There’s also the fallacy that quality and quantity are at odds. A better way to think about this is that the truly great ideas are underneath the pile of mediocre ones. You need to give your engineers time to dig through multiple lackluster approaches before they can get to the good stuff.

Attachment is the enemy. The goal is to think deeply about the problem itself. So align your devs’ incentives with yours and your company’s.