I’m addicted to building products with computer code. It’s a blood lust. But one thing I’ve noticed in the past decade of working with software engineers is a reluctance by our profession to solve valuable problems because of a bias toward working on only the most scalable problems. As engineers we like to clean up the messy world that surrounds us. If you can abstract a problem, and synthesize it into your “clean” model of the world, you think you’ve won. You think you’ve solved this problem once, gotten a 1000x multiple on your engineering time, and will never have to revisit it again.

You can see this when engineers decide on a problem they’d like to solve for a new tech startup. Especially in Silicon Valley, where there are droves of trivial problems getting a solution. But, you can also see it every day inside almost every tech company on earth. A customer has a problem to solve, and engineers insist that it can’t be solved, isn’t worth solving, or that the customer should change their business processes and then it wouldn’t be a problem.

The fact is, when engineers synthesize problems their customers face into our “clean” model of the world, we’re not creating value. We’re just selfishly making things easier on ourselves. One thing I hear way too often when working with other engineers is that we “spend way too much time dealing with customer X”. That’s the wrong attitude, and it comes from our desire to clean up the mess of the real world and make it “scalable”.

But the mess is needed. The mess is valuable. We can’t make it go away, and we shouldn’t try. Paul Graham wrote a great essay on this called Do Things That Don’t Scale. For an engineer, that can be read as blasphemy. But he has a great point.

Startups take off because the founders make them take off. There may be a handful that just grew by themselves, but usually it takes some sort of push to get them going. A good metaphor would be the cranks that car engines had before they got electric starters. Once the engine was going, it would keep going, but there was a separate and laborious process to get it going.

You show me a perfectly scalable software product from day 1, and I’ll show you a worthless one.

Use Your Big Problem Mindset

My favorite problems to solve are the big ones, with seemingly impossible design constraints. I think all good engineers are like this.

How do you build a space company from scratch without a government budget?

Find a way to make the rocket reusable.

How do you build cars that the masses can afford?

Find a way to build them faster — The assembly line.

The list can go on and on. These are the most fun problems, but we let ourselves get into the weeds of what we are working on and forget how value is created. Instead of embracing the design constraints our customers are giving us, we start to rail against them in the name of scalability.

Space X had to do “consulting” work for the government in order to fund development of their scalable solution to affordable space flight. Henry Ford had to find a way to recruit, hire, train, and reward that human machine assembly line.

Look at the problems around you holistically. Your customers are bringing them to you. You don’t even have to look. Embrace the design constraints you’re given. Without impossible design constraints, a problem is trivial and not valuable to anyone.

Listen to your customers. They’re telling you how to create value. Combine their constraints with the constraints of your business, then constrain the problem even further to find a way to get a multiple return on your engineering time.

Solve those problems. That’s how you’ll find meaning in your work.