I’m fashionably late with this lookback at 2024, but I hope you’ll forgive me – my mind’s been occupied with other priorities until this week.
As is now traditional, I’ve put together some thoughts on the things I learned managing software engineers over the past twelve months. If you’re curious, you can read the equivalent blogposts for 2023 and 2022, but otherwise, read on to hear about the lessons I learned last year.
Sacrifice your team members
An obligatory disclaimer: I’m not proposing that you offer up the lives of your direct reports to the Jira gods, or as some kind of blood penance to obtain c-suite approval. Neither am I suggesting that you should throw them under the bus in order to save yourself. No: what I’m talking about here is giving someone up in order to achieve something better for them.
Midway through 2024, my team were struggling for meaningful work. The engineers were bored, the things we were working on were constantly blocked, under-developed ideas or just plain tedious. It’s not hard in these situations to read the runes and worry that you may be developing a flight risk or two.
One of my engineers in particular was hungry for something different, having served the longest time on my team without interruption (eg. a secondment or internal move). I knew another squad was being set up for an ambitious project with unconventional processes and experimental technology unlike anything we were using.
I spoke to that team’s boss, who was keen to onboard anyone with the right skillset (and attitude). I raised it with my team member and he too was interested, his curiosity piqued. I then had to persuade my own bosses that my team could afford the headcount reduction, and reassure the product and delivery leads that we could still hit our quarterly objectives even with the loss of an individual – I was confident about this, alas, because of the limited scope of those goals. I didn’t think I could argue convincingly that my own needs from this individual were stronger than those of the newly-forming team with a more business-critical product.
The engineer moved across, helped set up some foundational architecture (and processes) for the new team, and is still there today. And my existing team? We missed him; we were weaker without his input – but everybody rallied and expanded their individual remit to cover his loss, with the safety net of his continued employment there to reassure us that we could still call on him if we got stuck. And the team still managed to deliver on our requirements.
I learned that sometimes, sacrificing some of your own needs (and team members) is the right thing for the bigger picture, and the longer term.
Just have the awkward conversation
I like being open and direct. Not because I’m inherently confrontational, or because I’m one of those “I just speak my mind and tell it like it is” charlatans. It’s simply because I’m not very good at lying (don’t play Avalon with me) and my social memory isn’t powerful enough to do “politics”. It’s much simpler to just be truthful and transparent rather than attempt to play games.
We had a situation where an internal, company-wide DevOps team were able to define a percentage of every team’s roadmap, in service of some business objectives around improving performance, security, availability etc. All totally reasonable stuff, and things we should be prioritising. But this work was often difficult to interpret: the other team wrote lengthy, wide-ranging documents to outline their expectations from a one-size-fits-all perspective, which were intended to make it simple for teams to go away and implement.
Intentions and reality are never fully aligned, though, and many of the implementing teams—mine included—were stumped by some of the requirements and technical expectations. We couldn’t ask for documentation: there was already tons of it. But we couldn’t understand it. Months of deadlock followed, with the DevOps team frustrated that nobody had begun the work, and the individual teams trying to gain clarity about expectations, and debating priorities with product leadership.
Eventually I got bored of reading Confluence docs and spreadsheets and just put in a call with the DevOps team lead. My reading of the situation was that both parties were frustrated with the other: “Why haven’t they just done the work, since they haven’t asked for help?” was one side’s take. “Why can’t they spell out in plain English what we need to do? How can we do all this in the time we’re allocated?” was another. We should have spoken much sooner.
This call allowed us both to candidly state our positions and extend some empathy in both directions: certainly I was able to understand the other team’s quandaries about the work, and their perplexity about why nobody was raising any red flags but also not implementing anything. I was also able to provide some examples of the kind of documentation and process we’d need to really kick off the work, and we were able to reach an understanding and agreement together. What was super helpful too was being able to understand which parts of the work were really required, so I could go off and emphasise to my team that we should focus attention mainly on one aspect of the work. We were able to wrap up much of the implementation within that quarter.
I learned that in these stand-offs, it’s better to just put aside the documents, tickets, spreadsheets and trackers and just be human beings together.
Get out of good peoples’ way
I was lucky to work with some super-talented engineers last year, all in a variety of career stages: juniors, mid-levels and experienced senior/staff folk. And it was my pleasure to basically back off and let them be talented without me getting in the way.
One was a super-curious early-career dev with an interest in everything. She had the opportunity to become the team’s designated Security Champion, which I nominated her for with keen excitement to see what she did with it. Another engineer with similarly knowledge-hungry attributes was also interested in this area, and between the two of them, they came up with a process to tackle the team’s mounting third-party package dependency updates by building a day into each sprint for a nominated person to work through upgrading them. They branded it—brilliantly—“Thunerability Thursdays” (thank you, JJ). I had no involvement in any of this besides backing the idea when they brought it to me, and making sure the wider team understood it was happening. And it was great! The team upgraded packages, documented their learnings (for other teams to benefit from) and made our apps more secure. And I didn’t even need to do anything.
Other engineers on my team planned and designed a department-wide shared packages initiative, identifying areas of repeated code across teams and modularising the functions into a monorepo, installable by any team, to simplify (and improve) codebases. Again, my role here was minimal: the engineers identified the issue and the solution, and all I did was encourage them to keep digging, and poked my counterparts on other teams to make sure they were aware of the work (and got involved too, where possible). The team achieved this work because I let it happen organically and didn’t try to steer or over-organise something they already knew better than I ever could.
Another engineer had rapidly grown in DevOps expertise and had already led our team through a portfolio-wide overhaul of our monitoring systems. She stepped up last year to take charge of the process of moving all our hardcoded/”clickops”-powered services into monitoring-as-code. I didn’t even know this was a thing! All I needed to do was applaud from the sidelines while she documented the requirements, expressed it in a form other teams could work from (see the previous learning for why this was so vital), and socialised the work so others could understand what they needed to do, and what our expectations were for this kind of project. Another big win for the team which I did nothing at all to direct or influence.
As I write this learning, I’m beginning to worry that I’m blogging myself out of a job. All these achievements were things that came from the “grassroots” of the team – my involvement was simply to reassure, support and share the work. But I think that’s a leadership lesson: I don’t know better than the team, and when they’re convinced and motivated about the value of something, I certainly don’t want to get in the way or slow them down unless I genuinely think it’s the wrong path – and if so, what do I know that they don’t? Why don’t they already know it?
Step in early when things fall apart
This was perhaps the most difficult lesson of last year.
I wrote above about the middle of the year feeling challenging due to blocked work, missing requirements and other external factors. Around this time, a key team leadership member unexpectedly left, and the rest of the team were suddenly fending for themselves.
In hindsight, the writing had been on the wall for a while: we were unfocused, undermotivated, and distracted. No team produces great output in these circumstances, and given what happened next, I find myself wondering even now whether we could have swerved the team disbandment that eventually came for us.
These situations are difficult: lots of personal/individual circumstances at play, often at peer level or above. When my direct reports are struggling or underperforming, I can—and do—have those conversations with them about support mechanisms, workload changes and other avenues for help. But this stuff isn’t always possible moving across a team or organisation, and you can find yourself feeling like a hapless sailor on a ship you’re not in charge of piloting.
But in retrospect, I’m reassessing what I could have done differently, or at least, what I’d do instead next time. My learning? When it’s so obvious that things aren’t working very well that I’m saying it out loud, don’t waste any more time. Shout loudly, get the support the team needs, and have the difficult conversations to pull focus and tighten things up. We were doing too many things at the same time and unable to point to the one area that we should have been directing the team’s energies on. This was obvious to me at the time but I didn’t do a good enough job making it clear to everyone else. By the time things were clearer at a wider level, the dice had already been rolled – the team was disbanded. And (probably) rightly so – but by then it was too late, like the boiling frog in the hot pan. This is the lesson I’ll carry with me most from 2024.
–
What about you? What did you learn about leadership in 2024? I don’t have comments on this blogpost so you’ll have to let me know elsewhere – LinkedIn, email or BlueSky. I hope 2025 brings me (and you) new learnings, and new wins too. Good luck!