Mentorship, fixing your Scrum and, wait, do PMs need project managers?
Let's talk about mentorship
I recently came off the back of a mammoth 76-person mentoring streak which has lasted from January through to this week. I originally put out a call in December expecting a handful of responses but was blown away by the appetite for mentorship.
I've come to the end of my current cohort and have realised I don't scale. I enjoyed the conversations (and was hopefully helpful!) but have turned now to trying to match other mentors & mentees with my buddy Nicole. We've set up a matching initiative, so if you're interested in being a mentor or a mentee please sign up here.
Fixing your Scrum!
I'm sure that we all have mixed feelings about Scrum but that most of us are using it, either by choice or because we've been forced to. It's also fair to say that Scrum gets a lot of unwarranted criticism from people that, on closer investigation, aren't doing it as recommended by the Scrum Guide. Now, full disclosure, I can take or leave Scrum but it does have some good principles (shared with the Agile Manifesto of course).
I recently read Fixing your Scrum, which is a good book detailing many of the common issues with Scrum, and some of the things you might do to fix them. I'm sure it's not a magic bullet, but there's some good stuff in there and I recommend the book.
One thing that resonates with me is fixing the dreaded daily standup, which often defaults to a round the table status update with every team member accounting for their days in minute detail. That's not what the meeting is for, and an interesting reframing is to "walk the board" rather than going person by person around the room. That means that, rather than asking each person what they did yesterday and what they're doing today, go task by task on the board and let people speak about whether that work is on track or there are any issues. This prompted a decent discussion on Twitter.
This subtle reframing will give you all the important information but removes the self-justificatory need to account for the fact that individuals have been working hard. We should trust that people are working hard! If they're not working hard, that's a whole different discussion for a whole different meeting.
New podcast episodes
The One Knight in Product podcast train continues! I've got two new episodes to talk to you about.
Firstly, I had a good chat with David Dylan Thomas, author of "Design for Cognitive Bias", which is an excellent, accessible book about the ways our brains can trick us and what we might do to interrupt that. You can check out the episode here.
Secondly, I spoke to my good Twitter buddy Dan Chapman, who is working on internal products to help some of the cleverest scientists in the world cure diseases. No small feat, but working for Big Pharma isn't the same as working for that scrappy 2 person startup (as Elizabeth Holmes found to her cost) so it's not all the same. Check out some of Dan's thoughts here.
Product Voices
I recently guested on JJ Rorie's new podcast "Product Voices" where I talked about B2B product management. I speak about that a lot, of course, but it was great to support this new podcast & have a great conversation with a wonderful host. Check out the episode here.
Do product people need project managers?
I ran an interesting poll on Twitter recently asking for product managers' opinions of project managers, and whether they want to work with them. Project managers get a bit of a rough ride in product management circles and much of the classic literature, but what did people really think? I was pretty surprised.
I was surprised because nearly 60% of people seem to want to work with project management in their product development process. That's not a slight on project managers from me... I have worked with some fantastic project managers in my time! However, it does run counter to the traditional product management narrative.
Some of the replies to the poll were interesting and made me think a little bit about the role of project management in product development, where project managers can deliver value, and the types of project managers that we might work with. I broke them down into four main groups (I'm sure there are more) in order of desirability:
The emergency Scrum masters
This is an interesting one that you might see in a company that is digitally transforming or moving from a professional service to a product mindset. That's a good transformation to undergo, but we all know it's not just a case of splitting your waterfalls into 2-week chunks and carrying on as usual. It takes substantial cultural change to do any of this stuff properly, and simply assuming that your project managers can take a 2-week course (if you even send them on a course at all) and become Scrum masters is not it at all.
That's not to say that project managers (or anyone else for that matter) can't train to be effective Scrum masters because I'm sure that many absolutely can. But if they're just going to be treating each Sprint as a mini project and micromanaging the ceremonies, that's not it. It really isn't.
Red / Amber / Green Gantt jockeys
People in this group are mainly interested in creating beautifully crafted delivery plans and trying to introduce predictability to the product management process. They see the way to do this as asking people for constant updates so they can produce status reports for the leadership team showing whether things are on track.
My issue with this is that it prioritises working to an initial plan and on-time delivery over the impact of what you're building. Building great products doesn't work like that and I'm not really a fan of this style of project management for continuous product development.
Internal dependency wranglers
This is where it starts to get a bit tricky. If you read books like Team Topologies or Inspired, you'll be aware of the Nirvana of product development; we need to organise our teams for flow and have as few dependencies as possible. Teams should be cross-functional and have everything they need to deliver value quickly without handoffs.
That's the dream and, in many cases, the reality. I strongly believe we should get as close to this as possible. But many of us work for non-ideal (or at least non-by-the-book) companies and may well have structural inefficiency baked in. Ideally, a strong leader will change this, but change takes time and we need to do something in the meantime.
In this case I don't really see the dependency wrangler as being a project manager per se, but more of a delivery manager, tasked with cross-team coordination and making sure we can deliver value as continuously as possible. I think this is a good person to have if you work in an environment that needs it, but I would ideally like to see the inefficiencies designed away at some point.
External dependency wranglers
This is one case where actual project managers can make a great deal of sense. When I'm talking about external dependencies, I'm including stuff like:
• Regulatory requirements
• Coordination with essential external partners
• Client-specific engagements
I'm sure there are more. The basic point is that we are all parts of a system. In today's world, it's less and less likely that we'll be completely separated from external dependencies. We may be operating a mixed product / services model, or have a roadmap that includes integrating with selected integration partners, or have hard dates we have to hit to even be allowed to continue operating. In these cases, where we have things to schedule, dependencies to manage, possibly budgets and costs to navigate, I would absolutely recommend a project manager as these are... projects.
That's all folks
TL;DR There's nothing wrong with project managers! We all work for businesses that are complicated systems inside of other complicated systems. We need to do what we can to make sure we're delivering valuable products effectively, but let's not get hung up if we need to find a non-standard way to do that.
Thanks for reading! I'll be back soon but please share with any product-aligned friends you think this would be interesting to.