Weeknotes 357
I did:
Risk management
I’ve been doing some work on risk management. I had started by using inductive reasoning to collect up all the individual risks across the team and lots of different projects and try to manage them separately. But after a chat and a rethink, I now think a deductive approach that starts with bigger themes for risks and records the mitigations as actions for specific circumstances is a better approach.
Of course, the same old problem continues; adoption. It doesn’t matter how great your risk management system is if no one uses it. Making the loop of raising risks, recording them, figuring out the mitigations, getting them approved and actioned, and reporting back to those that raised the risks, that’s the real work.
Retro
I ran our monthly retro using a pretend chatbot to ask questions. One of the ideas I wanted to try out with the team is whether some team health metrics might be useful for measuring how things are changing over time. One of our challenges has been taking the issues raised in our retros into action and looping back around to measure what impact they’ve had. I don’t what the right things to measure are just yet, but I’m keen that we figure out how to make an effective improvement loop.
I read:
Rules of flow
I’ve been reading Goldratt’s Rules of Flow: The Principles of The Goal Applied to Projects. It’s one of those ‘teach the ideas by telling the story of someone learning the ideas’ book, which I quite like. Some of the idea, like triage and limiting work in progress, are fairly familiar. But ideas like ‘full-kit’, having everything required to complete a project before starting the project, are going to take a bit more thinking to understand.
Charity chatbot
Charity replaces humans with chatbot. Chatbot says harmful things. Charity shuts down chatbot and rehires humans. As cautionary tales go, this one takes some beating. I’d love to know more about the people in the charity who made those decisions and what due diligence they undertook. I bet it was a case of the tech company not understanding the needs of the charity (and possibly not even understanding their own GPT models) and the charity trusting what the tech company said and not having the expertise to question them. The charity sector needs more tech expertise.
I thought about:
AI hype continues
People are starting to realise that GPTs have a lot of limitations and products built on top of them struggle with adoption and retention. As a personal productivity tool, GPTs aren’t even on the same level of impact as email and nowhere near copy & paste. The media propaganda around the AI threat to humanity is in full swing to obscure the real threat of how AI is being and will be used to make some people richer and everyone else harmed in the process. I see the medium term future for AI being more like that of IoT than mobile phones. Businesses will make greater use of AI, and they’ll use it in products and services that consumers use, but AI won’t be a consumer product for a while yet.
Institutional knowledge
With any organisational process, there is ‘the thing’. And then there’s the stuff that supports ‘the thing’. And then stuff that supports the supports. And so on. How ever formalised ‘the thing’ is, those other layers are always increasingly informal.
They rely on relationships and tacit knowledge to provide the support that makes ‘the thing’ work. But we tend just to measure ‘the thing’ and conclude it’s performing well. But, the more we understand all the support layers that are required, the more we can aim for global optimisation of the entire system.
Example: IT support request process. Raising a request and handling a ticket is ‘the thing’. The process is easily documented and works effectively if you look at it in isolation. There are plenty of metrics to improve the local optimisation. But what isn’t measured is the knowledge people have about what kinds of requests to raise, how quickly to expect a solution, what barriers exist to slow down resolution, etc. That’s one layer of support that ‘the thing’ needs to be successful.
And then, when a new person joins the organisation, they need to develop the knowledge about who has that knowledge and develop a relationship with them to get support to build their knowledge of supporting ‘the thing’ to work. So, without deeply understanding what is going on here, it’s easy to jump to the solution of better documentation. But all that does is introduce another layer that still requires those tacit support layers.
Better, I think, to realise that fundamentally, an organisation is a group of people who do better when they have stronger relationships with each other. Better to go easy on processes and documentation and put more effort into relationships and knowledge sharing.
Intentionally developing deep institutional knowledge about the organisation, how things work and who knows what, etc., isn’t measurable in the same way creating documentation is, but it makes it easier to optimise the entire system of organisation.
We should all be aiming for global optimisation. It’s better for the organisation, better for the people in the organisation, and better for those the organisation serves.
Modern product practice
Modern product practice organises for the fast flow of value. That means continuous everything:
- Research
- Experiments
- Value proposition
- Discovery
- Market analysis
- Ideation
- Design
- Validation
- Development
- Measurement
- Insight
- Delivery
- Business models
- Adoption
- Roadmapping