In November 2024 Deliver Sessions meetup was hosted at Northcoders’ office in Manchester Technology Centre, for an evening of talks about how people have got better at what they do. We asked speakers to think about:
- What’s helped you improve how you do your job?
- How have you used that experience to help others?
Here’s a few notes on what they put together.
From Engineer to Head of Product Delivery: Hard Lessons and Stronger Foundations
“Transitioning from an engineer to head of product delivery taught me invaluable lessons—many learned the hard way. In this talk, I’ll share the realities of stepping into delivery management, from balancing client demands and team well-being to implementing governance that truly supports the team. Now, as I train a new graduate entering delivery, I’m passing forward these insights to the next generation of aspiring delivery managers.”
– Jessica Bailey (head of product delivery)
Jess worked as a project manager before she did a Northcoders bootcamp and got a new job as a software engineer. She enjoyed writing code, and also gravitated towards people-focused and getting-organised tasks: leading planning and sprint reviews, coordinating work with other roles, mentoring newer engineers. All this lead her to move into delivery management.
She describes this move as “The Unlearning” for her, as lots of the skills that had helped in past roles were no longer serving her.
- Taking technical ownership of “how” each piece of work was to be done was something she had to consciously leave to engineers on the team now, it’s not helpful to stick your oar in too much.
- As an engineer, or project manager, there had been a tendency to focus on individual pieces of work – now, she needed to look up, thinking more about the big picture and the reasons for doing work. She focused more on “why” and on making connections outside the team.
- Project management had been about fixing scope and requirements, and now there was more planning in her role she was drawn towards that – learning to make plans adaptable, to iterate in small steps while still having overall direction, was important.
Practicing all of these helped her move into more senior roles. Now, she’s responsible for helping brand-new delivery managers learn the same things. How could she teach these skills?
Jess shared a series of lessons she’s been working on with people, all based on mistakes she made early in her own career. For example: it’s natural to specify work as if you’re going to be the one doing it (what information and upfront decisions do you feel would help you do it?), but if these structures don’t match people’s working style you they’ll struggle with it. Jess sets the new DMs tasks to help explore individual work preferences on their teams, and learn to make the most of those.
Other lessons include:
- “If it’s not documented, it doesn’t exist” – with painful stories from Jess’s past experience, and exercises like “undocumented chaos” (randomly delete an important doc and try to recover) and tasks to widely share useful documentation when it does exist.
- “Hard conversations are necessary” – with examples of over-promising or shying away from discussing limitations led to undermining growth and trust, and exercises like how to clearly discuss risks and timelines early, and roleplay practice to learn how to deliver hard messages productively. (I’m a big fan of this topic, see my “How to disappoint people” guide)
It was a great set of lessons, I’ll add a link if Jess writes them up somewhere.
How I got a bit better (and how you can help other people get a bit better too)
“Seven years ago I graduated from a bootcamp and embarked on a new career as a software engineer. This talk is about methods of learning and development that worked well, some that didn’t, some things I wish I’d known and some things I’m really glad I did know.
“I will also cover some of the ways that the brilliant people I’ve worked with in my career helped me develop and created supportive environments for learning.”
– Caroline Hatwell (senior software engineer)
Caroline painted a vivid picture of how tough things can be for an early-career software engineer: impostor syndrome is common. Somehow you got through the interview process, now you’re doing a job that you don’t know anywhere near enough about, and they’re going to find you out.
Her talk was full of reassuring advice: everyone starts out feeling this way – like there’s far too much to learn, and everything you look into reveals 10 more things you didn’t know. But that’s great! Everyone is learning new things all the time, navigating their way between things they don’t completely understand yet. It can be a fun process of continuous learning.
There really are no stupid questions: It’s fine to ask about things, or to note questions for yourself to Google or ask one person about later. And lots of things you think are technical (”I should know this!”) turn out to be things about the specific organisation you’ve joined, and no-one would expect you to know. Asking people about them makes friends – you’re the curious, interested to learn more engineer that people will come back to with questions of their own.
If you’re a more experienced person – in any role – there’s lots you can do to support these early-career engineers, and help them get comfortable in their job.
At one of Caroline’s early jobs, one senior engineer would always put her hand up and ask things like “What’s CQRS?”. She knew what it was, but she knew other people didn’t know. And now they didn’t have to ask. People really appreciate acts like this, they learn but don’t need to put their head above the parapet.
There was lots more fab advice on how to build a better environment for people – useful both for new engineers (one attendee, soon to start their first engineering job, described this as “exactly the talk I needed to hear”), and for anyone who might work with them.
Bringing people closer together part 2 – (de)Parting Words
As a follow-up to our talk earlier in the year, we’ll be sharing how we’ve continued to evolve how we work. This time with a twist: we’re both leaving the team. We’ll take this time to reflect on what has worked and the why behind. And what we’ll be taking with us to new teams.”
– Shane Ryan (delivery manager) & Suhail Hussain (lead user experience designer)
Shane and Suhail presented at Deliver Sessions in March, 8 months before this return visit, talking about how they’d been dialling up communication and feedback on their team to help everyone work more effectively. Since then, the team’s continued with those practices:
- Working in the open, with ensembles (group work) run on open video calls in team channels, so people of any role can drop in and contribute
- Shrinking feedback loops, with daily short retros and planning rather than the weekly or longer gaps they used to have
- Putting a strong separation between the “blueprint” and the “factory” – all the repeatable, waste-reducing lean focus should be in the space between code being committed and it getting into the hands of users, while those lean ideas are less useful in creative, exploratory earlier stages of the work.
They shared some newer experiments, that they’re keen to take on to new teams they’re joining. One was a high-level workflow for all of the team’s work, from idea to user feedback in live. Making something that actually reflects how things work was a challenge, but it seems to have helped with whole-team understanding — and it’s brought a level of rigour to ideas that are often based on gut feel. For example, if you’re suggesting adding people to the team: what inventory buildup would that help with? If it’s not at a bottleneck, are you sure it won’t just make things worse?
They’ve also been putting a lot of time into service quality.
Framing “protect economic value” as a priority for the team’s time has been useful, and works better if the team can be responsible for every stage – keeping features running and improving in production, not just building new ones and hoping they work.
We might hear from Shane and Suhail again – I’ve enjoyed hearing about all the changes their current team has made, it’ll be interesting to know what happens in new teams. Are people there willing to try the same things? And if so, will it work in a different place, just the same?
More from the meetup
Deliver Sessions meetup happens in Manchester every couple of months. Always fun and welcoming, whether you’re just wondering what work in tech is like or you have decades of experience. You can register on Eventbrite to get emailed each time a new date gets announced.
Deliver Sessions will be back in 2025, with a range of new speakers and workshop hosts – maybe including you? Get in touch with me or the other organisers if you think you’d like to do a talk or workshop there yourself sometime.
To pass the time until new dates appear, you might like to read about some past sessions: Deliver Sessions archives.
Leave a Reply