Being a better Delivery Manager

I often like to self reflect & thought I’d document what I do as a DM. I wanted to document some of those key principles, things I do & areas I always want to focus on, maybe you will find this interesting as a DM when you start with your organisation & your brand new. This is by in no-way an exhaustive guide or a dictate of ‘do this’, speak to one-hundred DM’s for example & they’ll all give you a different opinion but, there are some guiding principles I personally like to follow & check myself & maybe you will want to consider too, to set yourself up for success in your first engagement & set a foundation for future excellence as a Delivery Manager.

Understand the RACI

One of the first things you want to do is explore both the on-paper RACI of who is who & who does what, but actually go & do introductions to all the true movers & shakers on the project. This is a key skill as a DM to build these relationships from the outset. You’ll be able to get so much leniency if people like you, so be authentic, straight, personable & make those relationships work. In today’s hybrid working world, you’ll stick out a mile (for all the right reasons) if you go to the effort to meet in person at the outset, to forge those initial relationships. Don’t be shy, say hello to the most important people the chain as well as everyone else – this is your project, and your opportunity to set up shop.

Being a DM is about being a people person. Negotiating tricky decisions, delivering bad news or gee’ing up your team to get a code drop across a deadline, the more effort you put in at the outset to win hearts & minds, the better you’ll do. This takes huge effort. Over communicate. You can always dial back, but failure to communicate up front will give people the opinion you’re not in control. Even if people don’t agree with your decisions, effective leadership means your team will do as you ask, as long as they understand the why. So be transparent, take charge, & set your stall out early.

Get your House of Governance in order

Truth be told, it doesn’t really matter so much how you do this, but as a DM you always need to both *have* your project under control but equally importantly *convey* that your project is in control at all times.

If you can plate spin the latter, you’ll give yourself time to sort the former. You can in part do this through timely effective project governance. So, you’ll need a RAIDD log, a quality backlog that’s refined, estimated & in line with your scope, a true understanding of what you & your team are here to do & why, alongside setting up a mechanism to deliver project updates weekly. Where you can, automate everything. In Jira or Azure Devops, you can set conditionally formatted dashboards & reports which can parse data to anywhere you want using middleware like Zapier or IFTTT. Maybe to automatically populate a Powerpoint deck, maybe a spreadsheet (ugh) or anything in between. Be innovative. You’re a techie after all!

Whilst the nature of your project & client may drive how you achieve some of the above or dictate the information required, the principles are the same. Maintaining logs, reports & backlogs are often a chore. Failure to set a standard at the beginning will just create debt for you & your team later down the line when things become unwieldly. Get a backlog in shape as early as possible, agree prioritisation with the team & client, refine, estimate, get going & report weekly.  

Doing the difficult things first

Often forgotten about is one of the key things I do differently where many others don’t. That is, do the most difficult uncomfortable things first. As human beings its natural to often shy away from the more difficult things in our lives. We procrastinate & pre-occupy our minds with the more easier tasks as that’s a quicker route to getting a nice ol’ slab of dopamine delivered to our brains when we complete something.

The key to being a really good DM is standing from afar, looking at the project, what you’re there to do & then honing in on the one, two or three things which are the major PITA & tackling them first. It doesn’t matter if it’s a trickly client stakeholder who hates consultants, a feature which requires an upstream dependency, a conversation with a rival consultancy in a mixed supplier landscape or putting your hand up & saying ‘I don’t know’.

Do all these things first. Really. It’s quite acceptable to start your project, & immediately drop into a RAG status of red, as long as you’re up front, over-communicate & then create a path to green. Got an upstream dependency to tackle? Tackle it in Sprint 0. See a fire up ahead with a supplier who won’t play ball? – raise it in your first meeting. Got a tricky team member who doesn’t like you – tackle that too. You’ll thank yourself later for not only tackling this debt from the outset, but the more you train yourself to do the difficult things, the easier it will become to do again & again.

Accepting imperfection

You’ll always want to immediately draw from the experience from your last role or project. For comfort mostly, when things get uncomfortable, you’ll even want to re-create what you’ve done before, immediately in your new role. The known is more comfortable than the unknown. Doing what you know though, won’t always work. The American Pie ‘this one time, at band camp’ etc will often set your focus in areas of no use or of limited value – pontificating on how things should be versus reality is wasted effort. I often need to cram some Agile into a Waterfall process – that’s fine. A client will always want to use a janky tool which makes your life difficult. That’s fine. We’ll often have to pay more lip-service to ideal world, than practical real-world delivery constraints – again, that’s all fine.

What isn’t fine is if you become so uncomfortable around the constraints, or so immovable on principle ‘ideal world’ you’ll pollenate your project with this negative bias. This impacts your decisions, the shadows you will cast as a leader, & how you are interpreted as the DM. So be ok with things not being ok.

Discovery is the storm before the calm

We do a phase of delivery at BJSS known as discovery. It’s an incredibly important phase where we dance with the client to try & understand what they actually want, versus what they say they want, versus what your org have sold them. It’s a constant sometimes uncomfortable melee of debate, discussion, conflict & can be massively jarring if it’s your first time. It’s here where most mistakes are made. Teams desperately try & ‘understand’, the client who can often be impatient & you as a DM often can’t do any of the things I covered above in terms of Governance because well, no one knows what the hell is happening. This is pretty normal.

It’s now where your people skills & leadership come into play along with a bit of acting to take charge, whilst behind the scenes details are being formed.

This is ok. Challenge the client, challenge one another & use it as an opportunity to build a foundation of success. Just like you build a quality Devops pipeline for software delivery, now is the time during discovery that you set a communication pipeline for success. Not every discovery phase of course is complex, some are far from it, but if you’re not fortunate enough to land that gig, then best to develop your skills here in this situation. Be comfortable with chaos & tap dancing on fire.

Learn the stuff you don’t know but probably you should know about….a bit….

Be honest, do you really understand that burn down chart? Can you really explain what DevOps is? There’s nothing wrong with being experienced & not knowing everything but learn the things you should know about. Our community has a wealth of experience with everyone happy to help & support. I’ve been grateful to everyone in my career who has spent time to help me understand stuff I’m not sure about, without making me feel stupid in the process.  If your knowledge on path-to-cloud is sketchy, read up. Don’t know your Jenkins from your Kubernetes, there’s several hours of YouTube with your name on it. Not familiar with a tool like Azure Devops? Get familiar. I personally believe a good DM lives, breathes, eats & sleeps digital & tech. If I could distill a top five of things-to-do I recommend every DM could do to help keep fresh, the below would be it;

• Learn DevOps Stand up an end-to-end engineering pipeline using standard DevOps tooling, write some code, automate the testing of said code, & publish it live somewhere. Maybe use this to build a website, or maybe just a simple ‘hello world’ demo but the process of doing this from scratch will teach you a lot.

• Repeat the whiteboard scenario you probably did at Interview with BJSS. Consider how you approach projects now, versus what you did previously. Look at where you’ve got better or maybe where you need to work on, & refine your skills. Record yourself, play it back, rinse & repeat. Why not use your existing project as a case study?

• Learn a new framework or delivery approach once a year. Whether it’s Nexus, or SAFe or anything in between. Broaden your horizon, and find the time to read. Use the techniques & tips I wrote about in term of managing your calendar here to help create time.

• Get expert-level with both Jira, & Azure Devops. Don’t be shy. I see a lot of skills gap in using Azure Devops & it’s not as scary as it looks. So get to use it & start to love it. You can register a free Azure account & a cloud-based account.

• Know your cloud. Use some cloud storage, whether its an AWS bucket or an Azure blob. Play around with a few automation features or document a home tech project. Automate your Christmas lights, play around with NFC, (not to be confused with NFTs!), tie this into your engineering pipeline in point one. You’ll have an entirely different viewpoint once you’ve done this stuff in terms of tech, & some of the challenges our technical teams cope with on a day-to-day basis.

You can often practically apply the principles you will learn above, to how you may consider your day to day project delivery, how you interact with more technical folk, or understand some of the constraints of Digital at scale.

In Summary

We are all different, this is what I like to do. I’d be really interested to hear in others opinions & what they do to keep themselves in shape. If you’re interested as a DM in discussing any of the topics in this blog, Get in touch for more details.

M