Weeknotes 422

This week I did:

Let down

This week’s overall feeling is of letting people down. I should have done a better job of supporting some team members. I need to really think through where I got things wrong and what I can do differently. But there were positives too:

  • I’m enjoying working with another product manager on a business case. It’s great to have someone that gets what I mean when I talk about switching direction because we learned something from data analysis that we didn’t know before.
  • Talked through prioritising some upcoming work with team leads and encouraged them to influence others about the priorities. I’m really keen that work gets prioritised by the team and not by me.
  • Set up artefacts and routines for the new work we’re starting next week. I’m not confident about it as I haven’t had time to properly talk to people about it enough, and I think there’s a direct correlation between socialisation and adoption.
  • Started outlining a training session on OKR’s. In true Jeff Gothelf fashion, I’m using delivering the training as an example of an OKR.
  • Got into some IT processes, which has been fascinating. Maybe there’s some version of Conway’s Law that explains the industry around documentation within IT organisations. And at the opposite end of the spectrum, saw a nice example of a team solving an alignment problem with a checklist (which is a solution pattern that shows up in the safety literature for aeroplanes and operating rooms).

I read:

Why Cynics Are Less Likely to Succeed

One of my three word definition I think about for leadership is ‘bring the energy’. Or maybe another version of that is ‘set the vibe’. Either way, I’m trying to express how the main job of leaders is to create a sense positivity. If cynics are less likely to succeed, I wonder if the opposite is true and those that bring positivity to their work are more likely to succeed, and so become leaders.

Understanding team effectiveness

Someone (sorry I forget who) shared on LinkedIn the old Google research which found that what really matters for teams to succeed is how they work together. It says the factors that most affect a team’s success are psychological safety, dependability, structure and clarity, meaning and impact.

WTF is delivery management

Watched this video of Jonny Williams talking about delivery management.

And I thought about:

How delivery management works

Inspired by Jonny’s video above, I mapped out a presentation about delivery management, just to get the thoughts out of my head. It starts with sociotechnical theory and says that the aspect of the organisation Delivery Managers affects in ‘people’, then uses impact mapping to figure out what activities the DM does to achieve the outcomes (using Josh Seiden’s definition of outcome as a change in human behaviour that creates business results) we want. Maybe one day I’ll type it up as a blog post.

Am I doing product management?

Someone asked me this question. Guess the answer depends what you mean by product management. If you mean managing a backlog of tasks for others to do, then no I’m not, but I don’t want to be doing that kind of product management anyway. If you mean finding worthwhile problems to solve, including understanding barriers users face, helping others to do good work and grow, helping the team learn modern ways of working and experimenting with new ideas, developing approaches to stakeholder engagement and communication that will scale in near future, unpicking infrastructure constraints, etc., etc., then yes, and that’s exactly the kind of product management I want to be doing.

Weeknotes 421

This week I did:

I felt like I had more thinking time this week, mostly due to quite a few of the people I work closely with being on leave. It created a natural experiment for keeping WIP levels consistent and moving bigger things on, which included:

  • Reviewed some work from one of our BA’s who’s working on transforming how we create a shared understanding about new work. It’s an interesting challenge with a nice balanced metric. If we reach a shallow “understanding” too quickly, we’ll see misalignment issues later in the work. If we reach a deep enough understanding but we take too long, we’ll see work go too slowly. So the balance is in getting to a deep enough understanding quickly enough.
  • Couple of conversations about levelling up, thinking more strategically, having more impact. There’s so much opportunity for our people to do bigger and better things.
  • Worked with our new senior product manager to get ready for a new piece of work. And we had an interesting chat with insights and data science people on the analysis for supporting the business case.
  • Started bringing together a few different threads on how our team communicates with stakeholders. I want us to be clearer about why we’re communicating and what we hope to achieve before we spend lots of time “communicating” for the sake of it.
  • Cool chat about product strategy and that deckchair work doesn’t shift the needle but can provide learning for innovative, business model shifting product work (which made me think about Guy Kawasaki’s point about jumping curves).

I read:

Working with leadership teams, outside and in

Cara Bermingham’s post on leadership teams has been doing the rounds this week. What’s particularly refreshing about it is how it shows that leadership teams often aren’t teams at all and have lots of challenges in figuring out how to lead together. It’s easy for others in organisations to look at leaders and think they should have all the answers, so if things aren’t going well it must be their fault. In fact, it’s always more complicated than that, and it’s always a system problem.

Digital Playbooks

Amy Lin wrote about government digital playbooks and how they’re an underrated tool for user researchers. I like any resource that helps teams stand on the shoulders of giants, but I think where these kinds of playbooks could be even more useful is if they contained more contextual information about how they were created, where the playbook is and isn’t applicable.

Weeknoters

Thought about:

Meetings

There’s lots of stuff about how to make meetings more effective by always having an agenda or that most meetings are a waste of time. I have a different perspective. I think the meetings are the work. Because before you can do the work work, you need to do the work of getting to know people, creating trust, figure out how to work together. Meetings are the vehicle for doing that. So, if you’re making meetings all about the work work, treating people like robots who have to follow instructions to the letter, then I can see why your meetings aren’t very effective. Probably rethink how the true purpose of meetings is to create social space and time for people to develop a sense of belonging and go from there.

Economics of product

Been thinking a lot recently about the economics of product, stuff like how to reduce opportunity cost and ways to understand return on investment. It’s one of the few internal things about product management that I’m actually interested in (I’m always a bit meh about stuff like stakeholder management). I guess because having the numbers to back up the assumptions fits nicely with my idea that product management is about finding worthwhile problems.

Looking to the future

More and more, I think that an important part of a product manager’s job is to think about the future, well multiple possible futures really. If they are solely focused on the present, which usually means being focused on delivery, then they aren’t giving themselves the best opportunities to lead their product. More thinking about future possibilities and lot’s more talking about them to get others thinking.

Atychiphobia

How much does the fear of failure stop us from doing things, especially new and uncertain things? And do we try to cover up that fear by finding reasons not to do things?