Own the Question

While I've been professionally developing software since 2005, it wasn't until I joined Amazon in 2010 that my view of "software development" meaningfully expanded beyond the core activity of writing code. Over a decade later, I'm not convinced writing code is the most important part.

Necessary? Yes, clearly—we need the bits that tell the box what to do. But the hardest part of software development is deciding exactly what bits are important, and when to write them. And figuring out the What and When requires really understanding the Why.

The Why is the problem you're trying to solve. It's the motivation. It's the value exchange you're enabling between you and your customer. It's the urgency and importance.

Note what it's not: it's not the technology. It's not the system or service. It's not the program. It's not the artifact. The artifact is the answer—not the question.

It's the question that's interesting. Who is asking that question, why they're asking it, the market/technological/regulatory context in which they're asking it: all of these things form the environment.

As the environment changes, the current answer becomes less and less ideal.  So while a software team may create an answer (the widget, the service, the app, the system, the library), their job isn't to own the answer—it's to make sure the answer they provide remains correct as the environment changes.

Sometimes that means making small adjustments. Adding a new feature. Removing a legacy one. Integrating with another service. But sometimes remaining correct requires more radical changes. It might mean building a new product that competes with your old one. Or sunsetting a product altogether.

If your ego is tied to these things—these answers—you're going to have a Hard Time. When you tie your ego to specific answers, you put blinders on. You limit your ability to objectively evaluate the question and the environment. You fall in love with your answer. You cherish it, caress it. You're unwilling to let it go—to let it die. You drone on and on about your favorite answer, even as the conversation—the question your customers are asking you—changes around you. Do this long enough, and whatever trust your customers had in you will be redirected to someone who is actually answering their question.

If you're in charge of building teams, focus them on the questions, not the answers. Give them the resources needed to sustain the answers they've given, but don't reward maintenance for maintenance's sake. Instead, tie their success to their willingness to own the question: to stay focused on their customer's needs, to stay aware of their environment, to continuously challenge their assumptions, to stay vocally self-critical, to invent and simplify. Reward curiosity and the willingness to chase a question wherever it goes—across surfaces, systems, teams.... whatever.

Challenge your teams to own the question, and your customers will love you.