I’ve seen, and been part of, software teams that remind me of this great Simpsons quote (my edits in italics):
You know software with users is like the mule with a spinning wheel. No one knows how they got ‘em, and danged if they know how to serve ‘em!
It’s easy as a team to get distracted by struggles with process, tech debt, and debates over languages and frameworks. You can often forget that the ultimate goal of a software team is to provide a service, specifically by delivering working software. The quality and speed of this service is important (just like an API meeting certain SLAs), and the ultimate goal is to provide value to the software’s end-user that they couldn’t find otherwise.
Most engineers probably won’t attend sales calls or talk to users directly, fine. The quality of their code still impacts those end-users, so that voice of the customer needs to be front of mind in some form as they build out the product.
A previous manager of mine, struggling with a team’s delivery issues, had everyone think through the example of a pizza shop.
Think of our team as a pizza shop. Pizza shops need to deliver quality pizza. They also need to deliver quality pizza in a reasonable amount of time.
If we take forever to make pizzas, customers will leave.
If the pizza we make tastes like shit, customers will leave.
If customers leave, we can’t afford to keep the shop open and we all go home.
Customers don’t care about the oven you used to make the pizza (microservices, kubernetes, Java applets). They also don’t care how the pizza gets delivered (Agile bike delivery or Waterfall waiters). They’re hungry! Just make good pizza, and ask them what they liked and didn’t like!
Understanding this idea from a ground level really helps add perspective to your work. It’s common to feel disconnected from your product when living in abstract architecture land, but the technical decisions you make are important, and have a real impact on how damn good the pizza is.
Here’s some ideas to help break out of the silo:
- Gather feedback quickly and iteratively from customers, rather than build something in isolation for months
- Share that feedback with the entire org, and give engineers a chance to ask curious questions and even interact with customers. Your org should look and feel more like a living laboratory running experiments, not a slow-moving cruise liner
- Use data, not guesses, to figure out what the customer actually uses and where they get stuck
- Focus on the highest leverage points in the product that lead to the highest possible quality and best experience
I’m sure you can think of other principles that rhyme here, but the main point is to keep the focus on the customer.
 |
So take pride in your pizza! There’s always ways to make it better and faster. And that’s part of the fun of building software, we’re never done. Yes, AI will help us immensely. But I bet backlogs and roadmaps still exist in 10 years, so regardless of how fast you run, you can’t leave the customer behind.