Weeknotes 435

I did:

Meta-work

This week felt pretty fast. Lots going on that needs to happen sequentially at pace to prevent other things from becoming blocked. And Christmas is getting closer.

  • Chatted about our OKRs, how we set them and how they prioritise the team’s work, even if the team isn’t always aware of it. What gets internalised (and accepted as a given) and what gets externalised (and stated explicitly) is really interesting and connects to cognitive load, I think.
  • Had a great coaching session. I was really impressed with their degree of connected thinking across different domains and appreciation of the implications from a change in one domain. It got me thinking about how tools like roadmaps are representations of product manager’s critical thinking.
  • Was reminded that complex systems that work always evolve from simple systems that worked. It’s one of underlying principles of modern product teams that gives us prototyping, iteration and the like. Upfront design of the perfect end state is risky and costly.
  • Talked a lot about simplifying things to reduce cognitive load, and tried to practice it by writing things clearly for people.
  • Went to n levels of inception to do some glue work for those doing the glue work for those doing the work.

Championing user needs

Wrote about how product managers can approach championing user needs. Not my best work but at least it gets the ideas out of my head.

I read:

Design Thinking for Change

Samantha talks about Design Thinking as having a focus on discovery and definition and needing to work with other methodologies such as Agile and Lean which focus on delivery. I’m really interested in how we get different methods to work together coherently. I think that offers more value to teams than creating new methods and frameworks. We need to learn from what we know about the downsides of handovers between teams (information loss) and apply it to methodologies.

Centre of expertise

I read a paper about how organisations should be designed for optimising the expertise of knowledge workers. It’s a tough challenge but one I think creates a competitive advantage for organisations. For sure, there’s more to the answer than just writing more stuff done as we know most knowledge is tacit so can’t be written down and even when it is there’s a large percentage of information loss. It’s interesting to think about designing an organisation around knowledge management rather than thinking the solution is a tech system.

Middle-Out: Turning Strategy into Action with the Decision Stack

Jonny Schneider says, “The power of the Decision Stack isn’t in being comprehensive—it’s in being clear. While the top half (vision, strategy, objectives) typically remains stable over months or years, the bottom half (objectives, metrics, initiatives) evolves rapidly through learning and execution. This isn’t oversimplification. It’s about distilling complexity into actionable clarity. Teams still go deep in ways that suit them best, but the Decision Stack becomes the one artefact that consistently motivates aligned action.”

Not being sure

I like Debbie Blanchard’s definition of product management as being about taking on the uncertainty, listening to the experts, and placing the bets.

Mess mapping

I thought about:

Organisational self-image explains organisational culture

I have a theory about organisational culture counter to dominant idea that culture is made up of the collective behaviours of individuals. I think “organisational self-image” explains culture better. Self-image is a mental picture that is generally quite resistant to change.

If the organisation makes takeaway pizzas, the culture probably prizes speed and low-cost efficiency. If you work in a bank and regard banks as careful, reliable, and steady, that’s the kind of culture you’ll have. If you work in a university and assume universities last for a long time and that academic consensus arises dialectically, then you’ll have a culture with no urgency and lots of discussion. How everyone “sees” the organisation is how the organisational culture manifests.

So, if you want to change the culture, change the mental image people have of where they work.

Brooks’ Law

Brooks’ law is an observation about software project management that “Adding manpower to a late software project makes it later.” The reason is that more people requires more coordination which means each person spends an increasing percentage of their time not working. It’s often expressed with a diagram showing an increasing number of points and how the number of connecting lines between the dots increases exponentially, but gets misunderstood as communication, rather than coordination. Coordination doesn’t require the same amount of time for everyone, that’s why coordinating roles like project manager and organisational structures like hierarchies exist, to reduce the coordination effort for some people.

Now, I’m not saying Brooks was wrong, I’m pretty certain he was and still is correct. But I am saying that confusing communication and coordination also slows down teams. Both are necessary, but not always to the same degree for everyone at the same time. Being intentional about coordination, communication, collaboration, etc., makes a big difference to how people spend their time.

Talking is competitive advantage

The more people talk to each other, the more knowledge is shared. And in modern knowledge work, sharing knowledge is a competitive advantage.

Uncertain outcomes

When thinking about the outcomes and impact of product work, there are two boxes you can put the work: ‘Most likely won’t succeed, and ‘Might succeed’. There is no box called, ‘Will definitely succeed’.