Empathetic Engineering

Whenever I interview someone to join our team, or talk to someone trying to break into the space, I inevitably share the same sentiment in some form or another. It’s the same insight I shared when I first interviewed at Rockhaven.

You can build the most technically impressive application in the world, but if the person you built it for can’t use it, all you’ve done is waste time.

It’s not a particularly unique thought. The sentiment has been echoed for a long time. But it is a lesson I think is particularly tough for folks to learn, especially engineers.

The Kubernetes room

Recently on the Pragmatic Engineer podcast, Kelsey Hightower, a legend of computer science, shared how he started what they now call “empathetic engineering” at Google. His example: he’d bring all the top Kubernetes guys into a room. (For those who don’t know, Kubernetes is what lets you run and coordinate a whole fleet of applications without babysitting each one by hand. Hugely valuable, and hugely finicky to set up.) He posed them a simple challenge. Install Kubernetes, but don’t use any scripts. He would then proceed to watch these genuine experts in the field fall on their faces struggling to do it.

Kelsey explained the point of the exercise like this:

“And so the question then was, from an engineering perspective, how will we make this better? And then people were like, well, if we had OS packages, this could have been apt-get install, and we could have just used local machinery. I was like, that’s a good idea. Someone was like, we will make that happen.

And so it was that empathetic engineering that helped me make a huge impact on cloud because I can go to every team, every org, and instead of guessing what their roadmap should be, given someone who would spend time in the field, given someone that had this enterprise background and hands-on experience across lots of tooling, I knew where people were coming from.”

Building is no longer the moat

The reason I’m connecting these two things is because, whether you call it empathetic engineering or not, I’m more bullish than ever that there is no more important skillset to learn right now than the ability to actually talk to people and understand what they’re trying to accomplish. Not just filling out a form, not just having them tell you what they want and then building it. You have to actually understand what it is they’re trying to accomplish.

As AI diminishes the technical barrier, as it makes development more approachable than ever, building is no longer the moat. Knowing what to build, knowing who you’re trying to help, that’s the moat. That’s the piece AI can’t automate away. It’s not that this skill wasn’t important before; it was critically important. But I’m of the belief that before, you could slip by if you were truly just an elite-level coder. And a business could slip by if they had enough friction preventing others from entering their field, even if they weren’t utilizing technology.

I’m now of the belief that even if those things are still true today, they won’t be tomorrow.

What does this actually look like?

Well, it’s not as simple as just asking people what they want. There’s a famous quote attributed to Henry Ford that you’ve likely heard, though it’s unlikely he actually said it:

“If I had asked people what they wanted, they would have said faster horses.”

The point holds either way. People will tell you the answer they already have, not the one they need. And if all you do is take the order, you’ve learned nothing they didn’t already know.

Assuming you’re not a doctor yourself, imagine a doctor walking in and asking what you need. Not what your symptoms are, just what you need. Then you diagnose yourself, say you think you need some random medication you looked up. They say “great,” write the prescription, and send you on your way.

Sure, the two of you might have gotten it right, at least partially. But that doctor didn’t utilize an ounce of their experience or knowledge. They put all the onus on you to give them the answer, and all they did was use the smallest part of their skillset and write the prescription.

Designing technical solutions is no different. You have to ask questions, have to understand the symptoms, have to learn what to look for. This can look different depending on your context, but the idea is the same. For me, working for a homebuilder, it meant I spent so much time trying to understand homebuilding. It meant spending so much time trying to understand accounting and purchasing and real estate and every function. That was far more critical than being a foremost expert on whatever the solution ended up being. I needed to diagnose the process itself and understand the why. It’s an idea not all too dissimilar from the general concept of first principles. In a time where you can deploy a fleet of agents at the click of a keyboard, being able to build is the easy part; knowing what to build is what takes effort.

The mirage

And here’s where I want to complicate my own point, because “building is the easy part” is only half true. Building something quickly is the easy part now. Building something badly, something that looks right, demos clean, and ships, has never been easier. That’s the trap.

Because here’s the mirage. AI now lets a person who doesn’t fully understand the problem work with a builder who never really listened, and together they can ship something that looks completely right. It demos well. Everyone nods. And then it breaks. And when it breaks, you find out that neither of you actually understands the system you deployed. Not the person who asked for it, not the person who built it. The old world at least forced someone in the room to understand it deeply enough to make it work at all. That friction was doing you a favor you didn’t know you were getting. Remove it, and you can go from idea to production without a single person ever having done the diagnosis.

That’s why I don’t buy that these skills are becoming less important, that the human is being put aside entirely. The easier it gets to build without understanding, the more valuable understanding becomes, because it’s the only thing standing between you and a system nobody can fix solving a problem no one was trying to solve.

Nowhere left to hide

I truly believe this has always been what sets the great computer scientists, the great engineers, and even just the great builders, regardless of industry, apart. This ability to diagnose, to understand the why.

For a long time, if you were an elite enough coder, you could get away without it. You could let someone else do the talking and still be indispensable. That coder was safe. They aren’t anymore. The barrier that used to protect them is the exact barrier AI just knocked down. The only skill left that AI can’t hand you is the one that was always the hardest to learn in the first place.

The difference now is that there’s nowhere left to hide from it.