Weeknotes 531
I did:
Artificial constructs
My team is on a bit of a leading edge with AI. We’re the first to be doing things like using an MCP server and figuring out how to navigate proprietary AI systems. It’s very cool and I want us to keep it up and show the value of what we’re doing. Also did this stuff:
- Talked about AI, EU AI act, and how a product approach can derisk AI features.
- Ran a workshop with an operational team to help design new processes.
- Talked about roadmaps (the artefacts) as an expression of the shared understanding of the roadmap we all hold in our heads.
- Prepared roadmaps and backlogs for a prioritisation session.
- Started building a little AI product operating system for a piece of work.
- Started my new annual objectives and set up tracking in my kanban so I can see how much focus each objectives gets.
- Chatted about shared practices and processes for product teams.
- Played with a new analytics tool.
I read:
The AI-native SDLC playbook
Claude’s AI-native SDLC playbook is a really useful guide to thinking about where and how to use AI in the software development process. It describes how each stage ends by writing to files AI can access, with the next stage beginning reading them. Fundamentally, it’s the same as a human approach to software development, with each stage building on the information generated in the previous in a cause-and-effect way. The difference is in the type of knowledge used. Software development relies on a lot of tacit knowledge, implied understanding and assumptions that only humans have. They can’t be codified for AI to use. So, the thing to figure out is what parts humans play and how we use AI to do the things we’re not so good at.
Why are software development task estimations regularly off by a factor of 2-3?
This quora post was mentioned by Elisabeth Hendrickson and Joel Tosi in Signals and levers. It uses a hiking trip as a metaphor for software development. It wrote about this kind of measurement problem a few years ago too. We all know that estimations of uncertain work are always wrong, but it’s important to understand why.
The chipping and the craft
Really nice post from Simon Morgan-Wilson on the difference between how we do product work and how we do product work.
He says, “Chipping is easy to see and easy to count. Things shipped, deadlines met, boxes ticked. Craft mostly shows up as things that didn’t happen: the feature not built, the wrong direction not taken.”
I thought:
Flow efficiency
Thought about classifying work by its flow efficiency as a way of showing actually focus/time spent, which indicates whether the work is being treated as a priority or not.
Imagine a priority piece of work that 10 people are involved in. To make the numbers easy we’ll say they each have 30 working hours a week which is a total of 300 hours a week. Counting up how many hours they spend on this work in one week, we find together they’ve spent 40 hours on it. That’s a flow efficiency score of 15% Is that acceptable for a priority piece of work or should they spend more time on it?
Now imagine that all work has a flow score and is in buckets of >80%, 60-79%, 40-59%, 20-39%, 0-19%. We’d easily see whether work we consider to be a priority is getting the necessary time spent on it.
Rise or fall
James Clear said, “You do not rise to the level of your goals. You fall to the level of your systems.” He was talking about personal habits could have been talking about work in organisations. I’ve been thinking about objectives this week, which inevitably means thinking about creating the systems that make achieving objectives more likely.
Part of my system is tracking the work that contributes to my objectives in my kanban. That makes it easy for me to see how many tasks or meetings are about an objective, and plan next week accordingly. Feedback loops are important in any system.
Storming, norming, forming, performing
Tuckman’s stages of group development are a really useful lens for understanding how work happens (particularly in matrix organisations), because of course, all work is done by groups of people.
When a new piece of work starts there is a flurry of activity, different people getting involved, no one is clear what the work will involve. That’s the storming stage. Then things settle down, the work becomes clearer, some people figure out they don’t need to be involved. That’s norming. When the people who are left get together and figure out the work, they are forming. Eventually, they get into a rhythm of working together and get to the performing stage (although sometimes the work is finished before the group achieves this stage).
Those stages have to happen. There is no way to avoid them. Organisations can choose how and with who they happen, but they can’t choose for them not to happen.
The benefit of stable teams working on standardised things in consistent ways is that they aren’t involved in the storming and norming. It still happens, but it happens with another group of people, often leaders, figuring out what the work should be before handing it to a team that is already performing. There are pluses and minuses to this. It can make delivery more efficient, but sometimes the solutions don’t achieve the results because there’s too much disconnect between people involved at each stage.
The other way is for leaders to involve teams at the storming stage, have them help norm the work. There are pluses and minuses to this way too. It’s often more time-consuming (see flow efficiency above) but it can result in better solutions and more effective outcomes.
Product vision
Every product vision implicitly ends with “…because we believe this will make the world a better place”. If adding that to your vision statement doesn’t make sense, then you haven’t got a good vision. Try again.
The weeknote machine
Matt Ballatine (weeknote extraordinaire) built an app for insights from his 800 weeknotes. Makes we wish I had time for doing cool stuff like this. So many ideas, so little time…
Here’s one for the content designers…
The best frequently asked question ever.
