Just now, Avdi had a miserable experience buying curtains. He went to pick up an order that he placed last night, but Lowe’s didn’t have it. The order was sent to the wrong store and it was a huge pain to figure out.
Software is hard to get right. And every time we don’t, customers leave.
Appointment scheduling that sends a calendar invitation “Join the Zoom” without a link. Checkout screens that delete my credit card number when I change the shipping address. Complete Order that comes back with “Please try again later.” Items can’t all be shipped, can’t all be picked up, and this is a maze to figure out (also Lowe’s). A shopping cart that pops up a generic error modal when any single call to the server fails.
Sometimes it feels like I need to be a hacker just to buy something — opening the network tab, finding the real error message, which says “Account state invalid. Call customer service” — thanks Nordstrom, I see that I must check out as a guest.
And Avdi will order the next thing from Amazon. 😔
Software is customer service. It is my experience; it is your product.
Why is it all so bad?
Some teams can build good software. It takes repeated iteration: notice the error messages (by emitting events), make them better, then reduce the chance of error. Find where the customer gets tripped up, why the checkout takes longer for some people that others. Get notified about problems like the orders going to the wrong store, then make that less likely.
Good software comes from a strong product team continually improving it. These teams exist! We know how to build them!
But not at Lowe’s, apparently. It’s a large company, and this is Enterprise Software. Or maybe they do build them….
It is possible to build a good software team, that can build good software, inside an enterprise. It takes shielding to protect them from the constraints that the company imposes, but it can be done. Industrial Logic can do it for you, Pivotal Labs has done this a lot, I’ve seen Integral do it. You can hire someone at director level who knows a dozen top developers who will follow her anywhere. We know how to build teams and gel them, and the teams know how to build good software.
The enterprise can get great software teams. But they can’t keep them.
In my observation and a dozen other sources: a great team in a large company doesn’t last long.
Great teams get squashed in several ways.
One reason: the corporation imposes constraints that make it hard to work. Cheap laptops, flaky VPN, language and library restrictions, picky authorization, no public cloud, a year-long security review that usually ends in “no”, all spending approved a year in advance — these slow development, and tell developers that they aren’t valued. Bummer.
Another reason: organizational politics. That new guy, who thinks his team doesn’t have to follow the rules, is a threat to directors who were promoted within the usual way of doing things. If he leaves or loses authority, the team’s autonomy shatters and its developers scatter. Dang it.
The biggest reason: A small, quick software team moves faster than the enterprise wants to go.
The marketing department plans a launch or two per year. Their annual reviews are structured around commitments made many months ago. Incremental improvements don’t fit.
Software has to interface with the other systems in the enterprise. Inventory, ordering, warehouse, invoicing, authorization. These don’t move quickly. Maybe they’re Agile, and then as long as you get your requests into the quarterly planning meeting, they can get into the backlog three sprints ahead of grooming. Then a design sprints, two sprints before development, a sprint or three and then QA. Now you can plan for Q2 of next year.
Now that’s a speed that Marketing can work with. It’s a lot of coordination, and the enterprise is good at coordination.
The enterprise needs a software organization to work at its speed.
A property of systems: the bigger they are, the slower they move. So to get software work at the speed of enterprise, size helps. More developers, lots of PMs to coordinate them. An architecture department to oversee important technical decisions.
Making software slowly is more expensive than a few good teams. Yet that’s what the enterprise needs.
We aren’t just making software; we’re making software that works with surrounding software, and we make it in a way that meshes with the surrounding social, political, bureaucratic system. This is what works.
It works for the enterprise, that is. Not for customers.
Smaller, software-first companies have a chance of producing good software, because the organization as a whole might still be compatible with good software teams.
For a smooth checkout process, I’ll go look for a company that started from software (hello, Etsy!) or who buys the services of one who did (yay Square and Stripe).
and when I need something from Lowe’s, I’ll go inside and shop like the old days. It’s built for that.