📬 The Backlog #198

The long-term improvement risks of focusing on action, a practical way to simplify product work, and a fascinating case study highlighting the risks of local optimisation.

1. “OK so let’s just get going, we’re talking too much” said one participant about an hour into a two-day managers offsite I hosted earlier this year.
   
   It was hard to get that guy to slow down and take stock of where he was at. I thought of him and the organisation’s structures that contribute to his mindset when I read Zach Bonaker’s The Cult of Action: How ‘Bias for Action’ is Brainwashing Organizations.
   
   Bonaker explains in some detail how balance is important when it comes to taking action and seeking understanding. If your organisation prioritises action and putting out fires, it’s going to get stuck in a repeating cycle of “delivering urgent, hasty solutions that diminish the possibility of ever being able to address deep rooted issues.”
   
   As such, the short-term focus will hinder long-term improvement:
   
   “Organizations that prioritize action over understanding tend to experience a cycle of repeating mistakes and fail to learn from past experiences. This problem runs deeper than hindering improvement efforts today: a “bias for action” degrades the capability of the system to improve in the future, too.”
   
   

2. But then, what if you reach the point where you actually want to get started putting things in place for conducting product development work? What’s going to be your foothold - where do you position the first pieces of your iterative process?
   
   As a product manager or something close to it You want to do it right, but it’s easy to get lost in questions of terminology and definition. Is this thing an “O”? Or more of a general… theme? Would one categorise that other thing as a Product Goal? Or is it an epic? Do user stories require those, or can they exist without?
   
   Battle-tested writer and Product Manager Peter Hilton wrote a helpful piece on how to Simplify Product Work. He suggests that those questions and the multi-leveled information architectures fostered by answering them, are over-complications.
   
   Keep it simple, pick two levels and stick with those, Hilton says. Don’t overstate semantic barriers:
   
   “…key results are part of their objective‘s definition, defining success. Like a high-level definition of done, these outcomes don’t structure the work, they evaluate the results.”
   
   (Mic drop implied.) Nice read, part of Hilton’s five-part series of product work simplification articles.
   
   

3. Organizational design consultant Jurgen de Smet wrote an experience report about an org that wanted to increase agility but (initially) held on to existing constraints that no longer served them.
   
   In his colourfully-titled When you sub-optimize, it’ll bite you in the ass, De Smet details their journey and his approach with them. It’s refreshing to read the holistic considerations and his coupling of single-variable system changes with experiential experiments: He knew what would be a limiting constraint and helped the org design a series of experiments that let everyone participate and allowed the teams and people involved to experience the same limitations.
   
   

Have a proportionally ambitious week and Scrum on,
Thomas van Zuijlen