230919
Had some interesting meetings. A retro that shows real promise of non-digital teams adopting agile ways of working. And a sales client meeting which gave a small insight into validating a customer need.
Thought about how much good work never reaches full value because it lacks a good roll-out plan. Maybe if, rather than starting with direction-setting or discovery work, we started with distribution and only once we’re happy with that worked backwards.
Watched some videos on autism, but even though some were only a few years old, they mostly expressed outdated thinking. I still can’t find anything about being an autistic manager.
N body problem
Organisations are n body problems. Everyone’s behaviour influences everyone else’s behaviour.
Organisations as living systems
The tension of our times is that we want our organisations to behave as living systems but we only know how to treat them as machines.
Margaret J. Wheatley
230918
Wrote a blog post about how introducing a new method is the easy bit, changing the environment to make the method a success is the hard bit, but systems maps can help.
Watched some videos on teaming and psychological safety.
Worked on product strategy for our top 5 products. Still struggling to communicate how important managing work in progress is.
Listened to Matt Jukes on the Tao of WAO podcast.
Why new methods fail, and how system maps help us understand what to do about it
Sometimes, it’s easier to focus on introducing a new method for product teams in an attempt to change more fundamental things about how the team or organisation works. But any method or technique can only succeed if it has the right environment.
OKR’s is one popular method for setting goals. Looked at in isolation, it offers a great technique for communicating what you want to accomplish (the objective) and how you’ll know whether you’re getting closer (the key results).
But what might it look like if we mapped some of the behaviours that might happen outside of the OKR framework.
Key:
- Orange = The easy bit.
- Blue = The really hard bits surrounding the easy bit.
Setting OKR’s is the easy bit in the middle. Sure, it takes some time and some discussion, but there’s plenty to read that helps guide teams towards doing OKR’s well.
Then what happens?
If work that doesn’t contribute to the KR’s is explicitly prioritised or implicitly incentivised, then that work is done ahead of work that does contribute. This leads to reporting that the KR’s haven’t changed, and often without calling out that the reason was because other work came first. This can lead to setting new OKR’s (because the old one’s must have been wrong), continuing to do work that doesn’t contribute to the KR’s (creating a self-reinforcing loop), or no one takes any notice because the KR’s didn’t matter anyway.
If the work that can contribute to the KR is done, then one of two things can follow, either the change is reported or it isn’t. If the change isn’t reported, either no one will notice (which signals that no one cares about the OKR’s) or someone will notice and ask for the report. If the report shows no change, this can lead to prioritising work that doesn’t contribute to the KR’s and setting new OKR’s.
Of course, there are an infinity of variations in how these things can play out in real life.
I’m not picking on OKR’s specifically, that’s just for illustrative purposes. I want to show why introducing a new method or technique fails. If the environment isn’t also changed to create the conditions for success, in this example, tackling prioritisation and incentives, the culture around measurement, and the attention of leaders, new methods don’t stand a chance.
System maps can also help us design the consequences too. What should happen if non-contributing work happens? Or if change isn’t reported? Who does something about it? Consequences are the checks and balances that help keep the whole system optimised. Without them, or at least without intentional consequences, parts of the system will tend towards local optimisation.
So, if you want to improve prioritisation, incentives, measurement and leadership, don’t start by introducing a new method.
Weeknotes 372
This week I did:
Shaping strategies
What’s interesting about planning and prioritising work across products is what you do and don’t know at the time. It’s like having lots of boxes that are all identical on the outside, and uniquely different on the inside. You have to arrange them based on what’s on the inside, but you can’t see that yet.
We’re in Cynefin’s complicated domain here. Those boxes are our known unknowns. Which means we should use lean thinking and methods. Lean is better than agile here. Agile is the right choice for complex domains, but that’s not where we are. Fast feedback loops and course correction aren’t so necessary, not because they aren’t good things, but because the consequence of going in the wrong direction is low.
So, we’ve got to come up with a set of rules that are general enough to be applied when some of the boxes are opened. And still apply later when more boxes are opened. I’m thinking about how to recontextualise devops five ideals for this. The ideal of simplicity and locality tells us that each of those boxes needs to be independent and small enough that it can be opened and understood on it’s own. Focus, flow and joy could be in the work being true to it’s core value so that those working on it feel satisfied that it’s meaningful, impactful work. Hopefully I’ll make some time to explore these more soon, and I need to think about how ‘sense – analyse – respond’ works in this context too.
Productivity
Completed 40 tasks this week, which averages 8 a day. That’s the lowest number of any full week since I started tracking this way. I was focused on product strategies, which were bigger more important tasks, but it meant I didn’t achieve any of the other things I set out to last week.
Failed to consistently write daynotes too.
Slacker
My content discovery system seems to be working well. I’m reading more things, but reading them more lightly. Whereas previously, if I found something I wanted to read I’d share it to me website so I don’t lose it, now I know I’m not going to lose it so I don’t pay as much attention to it. Interesting unexpected consequence. Of course it could also just be the result of not-so-normal week. One to keep an eye on.
I read:
Agile Is the Steering Wheel, Not the Gas Pedal
Nice metaphor. And interesting point about the steering wheel being in the car, where the team driving the car can change course. Also makes me think about the roadmap metaphor and having multiple routes to the same place that the team can choose.
The influence of mobile technology on user cognition and memory
Might be doing some work on improving our website for mobile users so I’ve started collected interesting articles that make me think about mobile in different ways. The thing that caught my attention in this article was about the time spent on mobiles versus desktop devices. That’s obvious really. Our phones are with us 16 hours a day, whereas desktops, even if you use it for work, is probably only in front of you for 7 hours a day. So, time drives mobile traffic over desktop traffic. That’s different from availability being the driver. It isn’t just that more people have mobiles than desktops, it’s that they also use them more of the time.
And I thought about:
Simple rules in complex systems
The go-to example is starlings murmurating. They follow simple rules to avoid flying into each other. But, as I wandered past a football match, I wondered if the same applies. One team had three phrases they all kept using:
- “Give him options” – means support a team member who is being pressured by the other team.
- “Pressure them” – means act offensively towards the other team.
- “Unlucky” – recognises a team mate taking a risk and trying something even though it didn’t work.
Those three phases are enough to coordinate a group of people around a shared goal, within a fairly closed system with fixed rules.
Networks
I listened to two podcasts, both vaguely about networks. It made me wonder about workplace networks and how people are connected. What would a network map for your organisation look like if it showed the five people each person spent the most time with? Would it give you a better idea of how information flows? Would it give a more realistic picture of the organisation?
What if projects started with a reading list?
Before goals or scope or any of the practicalities of running a project, what if people spent time reading about the subject of the project? We talk about learning, but we expect it to come from and after the project. What if learning was built into the project, partly to get everyone some shared knowledge for the project and partly just to support professional development? Might try it some time.