Sometimes a development team has to make a technical decision. Actually, a development team has to make techical decisions all the time, and 99% of the time those decisions are focused entirely on the development process and therefore entirely at the discretion of the developers. But sometimes it’s not so easy. Perhaps they are thinking about a significant refactoring, or want to make a tricky change for security reasons. A while back I was working with a team who was discussing whether two changes, which each required a short system outage, should be combined or separated into two outages.
Ordinarily the team’s work has clear business (and user user) value, and the product owner makes priority calls and decides what’s good enough. But some teams worry that if they leave these technical decisions to the product owner they won’t get prioritised, or will continually slip down the list.
For me, even with these technical decisions, the product owner has to make the call. But they have to make it with advice and support from the technical people. And they will make it from a business perspective.
But for this to work (at least) two things have to happen. One thing is that the technical people need to be able to explain the significance of the decision, and of the trade-offs, in business terms. This is not about “dumbing down”; it’s about recognising that even technical decisions have business consequences, whether it’s about future operational costs, delivery speed, risk management, or something else. Another thing is that the product owner needs to have the long term interests of the product (and its users) at heart, including how easy or painful it will be to continue to develop it in, say, 12 months time. They need to be sticking with the product, not flitting from project to project.
In the case of the one or two outages the decision was simple: one of the changes would be delivered a bit earlier and provide much-needed functionality. It would give the users what they needed sooner, and the cost of the outage, to them, was minor. The debate between the technical people finished quickly, and the reason for the decision was clear. But it took a product owner to make it.
niksilver.com 