Weeknotes 426
This week I did:
Alignment
Had a day off this week and noticed how quickly some things became misaligned and misunderstood because the necessary discussions didn’t happen on the day I was off. Maybe all the rain interfered with crystal ball because I didn’t see it coming. Other stuff happened too.
- Now that I’ve handed-over a proposed new piece of work to the product manager who’ll be owning it I can work on the next two. These are about user experience and data maturity. Lots of conversations ahead to get support from people and shape the work, which I’m looking forward to.
- A month ago I reflected on not doing enough to support some team members. This week I tried to fix some of that.
- Went into the office twice this week. To be honest, on site meetings have a high bar to make up for the lost productivity of being remote.
- Went to a talk about how we’re using machine learning and generative AI. They are table stakes for large modern organisations. Is AI going to revolutionise everything, no. But it’ll probably change things like content generation and data analysis on a similar scale to how email changed communication.
- Had a chat about a piece of work that had lost alignment with the service it was trying solve for. Made me realise I need to do more to communicate how different things fit together so others don’t feel misalignment in my work. Maybe I need to make my roadmap more public.
- Refined the outcomes (remembering Josh Seiden’s definition of a change in user behaviour that drives business results) we’re working on. Firstly, thinking about how to communicate them and then how to measure them.
- Did a retro for the last four weeks of work. One of the things we talked about was documentation. We discussed what should be documented, where we should store it, etc., etc., but my thoughts are that you don’t need to tackle those kinds of problems until you’ve got into the habit of documenting. Otherwise you can put a lot of time into organising only to find out you’ve got nothing to organise. As with so many product problems, user adoption is one of the most important to solve.
Four principles for great teamwork: communicate, collaborate, contribute, coordinate
Or in plan language: talk to each other, work together, be helpful, check things are going ok.
Updated my roadmap
I reorganised and redesigned my roadmap to help me focus on what might help achieve my goals over the next few months.
Radical Product Thinking
I’ve set myself a goal of doing lots of small online courses, and I started with Pendo’s Radical Product Thinking. It’ll be interesting to think about the difference between the pure practices shown in training and the pragmatic principles that actually work in my experience.
I read/listened:
Risk Schmisk
Beware of the Team Doughnut
Brilliant insight into using the Team Onion to improve how teams work from Sport England.
10 principles for the design and delivery of greener services
A set of principles that aim to guide project teams to design and deliver UK government and public services with lower environmental impacts.
Networks for the win
I’ve previously blogged about how authority flows through hierarchies and information flows through networks, but this article from Corporate Rebels does a much better job of explaining why networks trump hierarchies.
I thought about:
Signals
I thought a lot about signals in teams. And how language, incentives, behaviours, rituals and artefacts signal what work (and often who) is important. What doesn’t get taken as a signal gets taken as noise, and considered unimportant. So that means there is a signal-to-noise ratio to understand within teams.
A crash course in modern work
Wondered about what you’d want to teach someone for them to learn about modern ways of working. I’d definitely include psychological safety, dynamic reteaming, agile, lean. Might make an interesting blog post.
Four principles for great teamwork: communicate, collaborate, contribute, coordinate
Or in plan language: talk to each other, work together, be helpful, check things are going ok.
These are my four principles for team work.
Communicate
Communication doesn’t mean one-way information from those in the know, and communication doesn’t happen well when intermediaries (especially software tools) get in between people. Talking to each other is the best way to communicate.
Collaborate
Collaboration means working together to achieve the same goals, not working on different things separately or with different goals. Lots of work gets done in isolation. The best work gets done in collaboration.
Contribute
In some teams, everyone has specific roles and responsibilities. They all know what they do and they only do that. But in better teams, people use the breadth of their knowledge, skills and expertise to contribute, even if it isn’t in their job description. Being helpful makes a big difference in how teams work. Sharing knowledge, offering to chat, making introductions, taking on tasks when someone is busy, it all makes the difference between being a group of individuals and a team.
Coordinate
Coordinate used to mean centralised upfront planning and giving people instructions to follow, make sure they’re doing the right things and staying on track. Now it means looking for signals about what’s happening, what has changed and responding in real time. That’s why checking-in with each other is so important. If one person shifts their focus, maybe it’s a signal they know something the rest of the team don’t. But if everyone notices they can check that they all still have the same understanding of what the team should be focused on.
So, teams can use ticketing systems, have separate goals, stick to their roles, and plan ahead if you want, but they’ll probably do better if they talk to each other, work together, be helpful, and check things are going ok.