The Editorial Independence of ‘what’ and ‘how’


After a small stint working for a media company I’ve seen a little of editorial independence in action, I think it has benefits for freedom of press. I mention this by way of analogy as I think there is also a benefit to separating out ‘what’ you want to achieve the product goal, and ‘how’ you want to achieve it and having the best possible ‘how’, the architectural approach, at least initially not constrained by the pressure of also defining how and when it will be delivered.

I’ve seen many examples where development teams loses this valuable separation due to product organisations which either can’t or won’t comprehend and manage the more product technical requirements, by that I mean things like requirements for how financial reconciliation works or how an embedded system boots up. These are customer experience defining parts of products which often (in my experience) fall to tech teams to define, which can lead to a lack of focus on building the product right, and an overt focus on building the right product.

In my view this can be an issue because:
1) work is often busy enough already with needing to do someone else’s job (products folks either own all requirements or they don’t)
2) taking the time to think about the architecture, the lower levels of design etc are critical steps which shouldn’t be ignored just because working out what to build took time

I see the above two issues leading to product owners (and their respective leadership) and Dev teams (and their respective leadership) both thinking they are managing at different levels of abstraction, but in reality having incomplete views.

I believe there are at least a few ways to solve this issue (these aren’t mutually exclusive):
1) don’t organise teams around rigid product owner / scrum master (or development manager) constructs. Instead look at the theme of the current work and make sure someone owns the vision, the delivery detail and the quality – to allow some independence (arguing with yourself can be hard / insane) these might be best as separate people.
2) take the people who know the product best and have them do the detailed questioning, that could be product people but often it is the more senior tech folks who have enough experience of the product to know how it really works.
3) make sure you don’t fall into a trap of thinking agile means no up front thought. We address this by having great architects who see themes of customer need and define solutions to them before being asked.

I believe building the right product and building the product right are both hugely important and obsessing over just one can lead to tech debt or something the customer doesn’t want respectively. Both of these scenarios don’t pan out well, so best to consider them in advance…..

Leave a Reply

Your email address will not be published. Required fields are marked *