A Product I Want to Work On
A question keeps coming to mind lately. It's less "what company do I want to work for" and more "what kind of product do I want to work on?" It doesn't matter if that's inside a company or just my own idea. For me, it comes down to two things:
- Money: I have responsibilities to my wife, my daughter, my family and my community (I won't cover that in this post).
- Problem-solving mindset: the one I want to talk about here.
As part of my evolution as a software engineer, I'm grateful to have found Rich Hickey. Over the past ~3 years he shifted how I think about the work, from delivering tickets as fast as possible to solving real problems. The difference is subtle, and one phrase of his stuck with me:
Humans get good at whatever they repeatedly do.
And the question that came later:
Do you want to be good at delivering features, or good at solving users' problems?
After that I read a book on the Socratic Method and started asking a lot of questions (I don't think my teammates were happy about that). Over time I got better at asking good ones, and I started pushing our engineers and product managers to demand more from users too.
There's a tension in this I'm aware of. Nassim Taleb makes a related point in Antifragile, in a debate between Fat Tony and Socrates. Socrates keeps pushing people to give a clean, spoken definition of something before he'll accept that they understand it. Fat Tony pushes back: real knowledge doesn't always need to be put into words to be valid. It can come from doing, testing, and having skin in the game. I think asking good questions matters, but questioning can easily turn into performance, talk for the sake of sounding thoughtful, if it isn't grounded in building and testing something real.
Then I started applying the same discipline to myself. I ask myself the questions too, and I wait until the answer is cooked (that doesn't take long, but it's more than a day if the question is hard and important).
I think users don't know what they want maybe 80% of the time. Part of our job is helping them figure out what they actually want, before we tell them how we'll get them there (with this system, that automation). Sometimes the answer is to build nothing at all, because a spreadsheet solves the problem just as well.
Rich Hickey told a story that shows the difference:
Someone asked for a way to swipe a finger across a screen while driving a car — and it got built, simply because someone asked for it, without anyone stopping to ask whether it should exist at all.
That's what happens when nobody asks why. You deliver exactly what was requested, even when it's the wrong thing to build, or a dangerous one.
So, basically, I want to work on a product, whether at a company or on my own, built by people who care more about solving users' problems than about delivering features.