I’ve helped organise Deliver Sessions meetup for a few years, and now I try to write a few notes after each one so I remember all the good topics they cover. In March 2024 we were hosted at Zühlke’s office in Piccadilly Basin, where we had 3 talks and plenty of time to discuss them.
All the people in a software team are trying to achieve the same things (meet user needs, deliver business value, all that stuff). But the specifics of how that works can feel very different for different roles. Speakers shared stories of different roles learning to work together.
Working with developers – intervention without overstepping
“It can be hard as a delivery manager to know how much technical knowledge you need, and how much you should get involved in developer decisions, practices and processes. This talk looks at where and how you should get intervene, and when you should leave them to it.”
– Eleanor Mollett (former delivery manager, now a software engineer)
“I was once a delivery manager worried about overstepping”: Eleanor shared her experience of looking for ways to help the engineers on her team, and then moving into a developer role and working on the other side of this equation. This is a great motivator to go learn more about things – both in general, and on your own team – and to talk more in your team about what things you could get more involved in or what just needs space.
Eleanor’s tour included: things it’s not helpful to try getting involved in – topics like the choice of programming language, architecture, and frameworks are best left to the engineers who’ll be doing the work with them.
And: things you should understand the value of, so you can help them get equal attention – pairing, collaborative ownership, refactoring as part of daily work are all things it’s easy to let get pushed aside as the team and business focuses on new features you can see.
And finally: a nice list of specific areas you can get involved in helping to change. One example was “A lot of teams focus on ‘How are you getting on with that card, when will you get that card finished’… and don’t focus enough on how the work from that card will get out into the world”. There’s often loads to do on your release process – focus there is fantastic.
Eleanor’s shared lots more on all these topics on her blog: https://eleanormollett.com/.
Beyond the backlog: building a better product together
“In this talk I’ll aim to answer two questions. What do I wish others knew about the product role? And, what have I learned from others about working cross functionally?”
– Zoe Rigley (head of product)
Zoe had lots of examples from her product career of learning to work better in teams – including stories from outside of tech, like when she joined an EDI board to work on improving equality, diversion and inclusion in sports. This involved some very challenging topics, where everyone wanted the same thing in the big picture but the details were hard. She saw skilled facilitation and thoughtful work from everyone in the room to listen and problem-solve together. This felt like a real contrast to some work situations about what should have been much easier decisions! This led her to learn more about how to resolve conflict, negotiate and compromise – skills we all need in teams.
Some ideas Zoe shared:
- Communication degrades unless you put effort into it every single day.
- As you become more senior people are less and less willing to ask you questions – you need to be aware of that and keep inviting questions about anything.
- Encourage everyone to question the roadmap – there’s no bad outcome to that. Either we get to add new things, or everyone gets better understanding of why it is the way it is.
A practical tool: the empathy game! For any retro format (e.g. the classic mad/sad/glad headings), each person writes their own answers, then picks someone on the team with a different role than theirs and makes their best guess at what that person might put. Sharing and comparing these can help people feel heard and understood, and lead to all kinds of improvements in how you work together.
Dialling up communication & feedback: Design and engineering working better together
“How our team experimented for months on bringing disciplines closer together for better communication and feedback. Doing more together naturally in real-time over waiting for pre-booked sessions, looking at theory and putting it into practice.”
– Suhail Hussain (designer) and Shane Ryan (delivery manager)
Shane got my attention right away with two book recommendations: The goal (great book) and The birth of lean (haven’t read it but sounds great). The goal gets recommended a lot, and there are various options if you’re put off by reading a long book about a 1980s factory:
- it’s also available as a graphic novel,
- an audiobook with ensemble cast and realistic factory sound effects,
- and The Phoenix project: an homage covering lots of the same lessons from the Goal, but using software-specific theme (and it’s shorter).
Shane explored how the factory metaphor is useful, up to a point, for software teams: from the moment you’re happy a change is “done” and you want it live to the world, you should be looking for a repeatable, automated release process – but earlier than that, when the team and supporters are deciding how to design and implement the work, you should expect much more variation and unpredictability. However, for all parts of the team’s process, the idea of continuous improvement is valuable: keep looking at how your team works and trying ideas to make things better.
Suhail talked through how their team’s been changing over the last several months – from a fairly static, and “doing OK” way of working, to a much more open, fluid, and reflective mode where people from different roles drop into each others’ open video calls to answer questions and hear suggestions. Short daily retrospectives help everyone take part in checking what’s useful for them, and what they might want to try changing tomorrow. “It feels like the whole team is playing the same sport.”
The presenters talked through some lead times that might be useful to work on:
- If someone asks a question: how long does it take to get an answer? Some teams regularly lose weeks to waiting or discussions.
- If someone suggests some team habit could do with changing: how long until we get to try that? Sometimes retros are so spaced out that you can barely remember what’s happened since the last time, and you find huge piles of pain points and possible actions make it a hard conversation.
- If you learn something interesting in a user research session: how long until that idea’s in production and you can see how well it works? This team would love to see something go from research to live in the same day at some point – it’ll take a lot of steps to make that possible.
More from the meetup
Deliver Sessions will be back! Sign up to follow the meetup and get emailed as new dates get booked. And 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: