Weeknotes 412
This week I did:
Convergence
Quite a few things felt like they are starting to come together this week.
- Did quite a bit of work on socialising our new workflow process, especially talking through the problems we’re trying to tackle with it and how the different artefacts fit in. I know it’s a very product-y thing to focus on making sure we understand the problems before trying solutions, and although I sure what we’ve designed isn’t perfect, I can confidently connect each part of the process to a problem. That feels important rather than dropping in a standardised process that isn’t context aware.
- Had a few interesting discussions about user journeys, service boundaries, aligned measures of success and the analytics required to support understanding. It’s a big, joined-up piece of thinking with no easy answers.
- Started to understand some complicated supplier relationships.
- Welcomed a new team member who’ll be helping us change how we scope work to make it more collaborative.
- Thought about our long-term roadmap, how to visualise it, and what kind of thinking needs to go behind it so it doesn’t come across as a sequential timeline.
- And last minute question that came up on Friday – should we do some team sessions on agile to get everyone to the same understanding? I think team discussion is great, but when it’s about how people understand something vague like agile it can easily go nowhere. And training that tells people one person’s definition of agile doesn’t help them unlearn. Lots more thinking to be done.
The numbers
Completed 41 tasks.
Wrote 13 pages of notes.
Spoke to 33 people.
Had 16 hours of meetings.
I read:
Demanding predictable solutions for uncertain and complex problems
I nodded all the way through Audree’s post about the tension between the output-orientated worldview that tries to create predictability and the outcome-focused worldview that doesn’t accept things can be predicted.
Maybe it’s a chicken and egg problem. Those asking for outputs might not have confidence that those who are being asked are able to achieve outcomes. And those asking to be given the space to achieve outcomes have no way of demonstrating they can do it. There’s a lot of trust and understanding required, which doesn’t exist in the early stages of a new relationship, especially if those involved have mutually exclusive views. Something’s got to give.
Sociotechnical systems theory
I started learning about sociotechnical systems theory, an approach to complex organizational work design that recognizes the interaction between people and technology in workplaces. The interesting thing is that when it was introduced in the fifties, it was pioneering for its shift towards considering teams as the primary unit of analysis and not the individual. The theory says that the ability of individual team members to perform their function is not the only predictor of group effectiveness, and that team cohesion and leadership at the level of the team, referred to as “responsible autonomy” (Trist & Bamforth,1951) matters more. The idea of self-organising empowered teams has been around since 1951! Who knew?
Let it flow
I started reading John Knight’s doctoral dissertation about unifying agile and service design work. This is where the intellectual action is right now; figuring out how disciplines, principles and frameworks fit together, not in creating new frameworks.
Product management in one thread
Shreyas Doshi, well-respected thought leader, posted this definition of product management:
“Role: Define the product & coordinate actions across the org to enable its success. Success: User adoption, Business impact. Skills: Common sense, immense empathy, influential communication. Traits: Low ego, deep care, high agency. Simple, but not easy.”
I appreciate the posts I don’t agree with more than those I do because they make me think about my opinion. This definition isn’t exactly wrong, but it is completely uninspiring. I wonder if the context of this view is the backlash of Marty Cagan’s view of a product manager and trying to recognise the realities of many product roles in many companies. Anyway, I don’t believe there could be a single definition of the product management role, it’s still too new and changing with the digital times to know what it is yet.
And I thought about:
Measuring an uncertain world
I spent far too much time thinking about OKR’s and what environment they need to be effective (thanks, brain. Maybe try letting go a bit more). I realised that OKR’s can only be effective in a stochastic worldview where you are trying to achieve uncertain outcomes. If an organisation has a deterministic worldview with measurable targets to reach, OKR’s aren’t the right tool for understanding progress towards those goals. I feel some relief at resolving that particular brain itch. Might write about it one day.
Sprinting to infinity
To me, the point of sprints is to create fast feedback loops. Do a small piece of work and put it in front of a user to find out if it’s solving their problem before you invest more time in it. But increasingly I hear people talking about working in sprints as having value itself, even without the feedback loop. So, I wonder, what is that value? Is it in breaking the work down to bring it within the cognitive load of humans? Is it in appearing to be more agile? I genuinely interested in figuring out the value of practices like sprints.