Life has been full, rich and rewarding.
I moved job in Jan 2022 and was a Senior Delivery Manager once again. In July that year, I moved sideways into Product Management and it’s where I remain. Goodness, have I learned a lot.
A colleague I knew from Hackney (the amazing Bea Vega) invited me to be a guest speaker at her delivery community of practice and I thought that reflecting on my two perspectives of delivery and product would be a good topic for that. I got good feedback from my team (who proofed the deck for me) and from the actual presentation so I thought I’d share the deck and my speaker notes here incase anyone else finds them helpful. I must caveat though, these are MY reflections and learnings. No-one elses.
You can view the slides via Slideshare and I have included my speaker notes below because I couldn’t work out how to add them into Slideshare, (naff user experience, sorry folks).
Slides 1 & 2
No notes
Slide 3
A space to host applications in a tailored environment:
1) Secure and connected to key networks and services
2) Provides standard ‘features’ to take the pain out of hosting:
— Standard monitoring
— OS level patching
— VM back up
— Bastion secure access
— Supported by a dedicated team
Slide 4
I’m here to talk about my experience of moving from delivery to product and how I now see a way to synergise them without unhealthy conflict.
Slide 5
I loved being a delivery manager. LOVED IT. I felt really connected to all the people and felt like I was truly getting sh*t done (which is one of my favourite things) and adding value. I had so many years of experience behind me that I sort of felt I was on rails. Because I knew what I was doing delivery wise, it was obvious to me that the Azure Landing Zone team needed a Product Manager, not a Delivery Manager. They were lost having been in a very project focused, command and control mindset with their previous ‘delivery’ manager. The technology they were using was something I felt really motivated by and could see the future of in my minds eye.
I should mention that I have, historically, not had the best relationship with product people so I was VERY nervous about the opportunity. The clincher of me deciding I would go for it was my reflection that, having had terrible Delivery <-> Product relationships in the past, I was in a great place to avoid them in the future.
I took the plunge and applied for the Technical product manager role and got it. I transitioned into the role on July 1st 2022 and have been readjusting ever since.
Slide 6
Seeing as I transitioned from one DDaT (Government skills framework) role to another, I thought it might be a useful starting point to reflect on what the DDaT Framework says a delivery manager should know how to do vs what a product manager should know how to do.
There’s a lot of cross over and similarities but I’ve tried to simplify what I see the roles as being primarily about on the next slide.
Slide 7
Both roles are people focussed but focussed on slightly different people.
Both roles are focused on ‘the thing’ but on different stages of the thing.
Both roles advocate for progress but on different stages of progress.
These three things are where I think the majority of tension comes from between product and delivery. Both roles are looking at the same stuff but from different perspectives. I quite like the infographic on the next slide to visualise this a bit better.
Slide 8
A product manager will tend to focus on and own the left of this circle and delivery on the right. There’s cross over. You see that product strays into the left side around choosing the best option. Delivery strays into customer feedback on the right side.
Add into this that, on both sides, your delivery manager should have autonomy over the organisation of discovery AND delivery with the product manager taking ownership of the scope, everything starts to get a bit, no, a lot, hazy. This is where the tension emerges for me. I am not really that much of an advocate for staying in your own lane but, with these particular role dynamics, I have evolved to think it’s one of the only ways to maintain a healthy tension for me. Delivery and product skill sets are closely aligned and both people can end up feeling they should have autonomy over both sides of the infographic we have here. When that happens, relationships break down and tension becomes unhealthy and moves into direct conflict. As we all know, that’s not helpful for anyone…I always fall back to this statement in times of confusion and tension…
Slide 9
Neither of us is right. Neither of us is wrong. We’re both trying to advocate for our own perspectives. To do that in a productive way, I’ve had to learn some lessons from a product perspective and unwire some delivery habits.
Slide 10
Respect is paramount and that’s why I have put it first. Since being on the product side of the fence, I can honestly say that product feels powerful. You have a lot of people telling you that you are all knowing, that you’re the captain of the ship and that your word is law. It’s VERY hard not to let this go to your head and stay humble. I can now see how that reinforcement can make it seem very difficult to challenge product people. THEY ABSOULTELY NEED CHALLENGING. My initial thoughts and assessments are wrong 80% of the time. If I didn’t respect all the other roles in my team as deeply as I do and actively seek their opinions and feedback, I know I would make bad decisions. If the other people in my team didn’t respect their roles enough to challenge me, they all know I would make bad decisions. Respect your team, respect your role and …
COMMUNICATE
Product feels much lonelier than delivery. You can seem like this ethereal thing mostly focusing on next and not being present now. That can make it really hard to connect with and support your team in the way they need you to. Most of this can be combatted with communication. Your message and ideas will likely be spread and advertised by the team and the delivery manager. The importance of establishing good communication and routines with them cannot be downplayed. If you can’t communicate well with them, they’ll not understand properly meaning delivery can’t build a sense of ownership with them which will undermine all the work they do and their enthusiasm. As they’re your ‘front door’ as it were, you need them to be 100% on board and in it to build your…
REPUTATION
Build authentic, trust based relationships with your users. Believing is seeing so deliver them what they need when you said you would. Sharing is caring. Share all your relationships with your team but mostly with your delivery manager. The relationships you build while discovering and refining needs will be invaluable to your delivery manager during build and release. Do yourself a favour and spread the love so that you can make…
PROGRESS, NOT PERFECTION
Just what’s on the slide.
Slide 11
No longer do I need to watch time, capture things, follow up on actions that aren’t my own and do all those other lovely facilitatory things but…I can’t seem to stop. I need to be told to get back in my lane very regularly and I try to take that with grace.
As delivery, your decisions are kind of time boxed to the next iteration. That can be a few weeks to a few months. Product decisions are much longer term. Making decisions as product still terrifies me. I want a huge amount of data before I commit. That amount of data is, generally, way more than I need. As a delivery person, I just used to go and get what product asked me for. Now I am doing the asking, I have to work really hard on reigning myself in. I also have to work really hard to not die on the hill of my decision when it turns out to be wrong. No one likes being wrong but as product I am wrong first time far more than I am right (this could be a reflection on the fact that I am actually a crap product person but we’ll just gloss over that). Being responsible for a decision, for me, means you are responsible for the integrity of that decision long term so you have to keep testing and checking it.
An example of when I got a decision wrong was electing to keep the old monitoring system we inherited despite it’s less than optimal implementation and poor take up. That lasted about 6 weeks. The evidence just kept rolling in that the solution was on it’s knees and needed sorting. We did a really zoomy discovery (like, 2 days) and elected to PoC a new monitoring system. PoC got done, people were clamouring to use the PoC so we productionised it. We’ve had more interest in our new monitoring solution in the 8 weeks it’s been live than the pervious one in the 8 months it was available. My decision to keep the old was wrong. I made the decision based on what was currently on fire and other pressures and didn’t listen to users enough.
Slide 12
That brings me to my final statement, that delivery and product are a match made in reality. Both roles need to be committed to that to make it work. Align expectations early through mutual respect. Communicate well to keep healthy tension. Build and maintain your reputation to design a good product and deliver it progressively. Simple, right?
