The past two years of my engineering management career have been both fulfilling and challenging, particularly in the first half of the period as I rebuilt my self-confidence after a difficult previous role, and sought to define what my role actually was in the absence of solid documentation. I made plenty of mistakes in that first stage, and spent 2022 trying to double down on the things that were working, and learn from the stuff that wasn’t. Here are the things I reflected on at the end of 2022 that I learned about managing teams of people.
Your understanding of reality is subjective
This one sounds obvious when written down, but it bears repeating. I’d initially succumbed to what I now think is a leadership cliché: your job is to “protect” your team from negative things (blockers, pointless bureaucracy, etc). In practice, this translated into me attending a series of dull meetings and calls to occasionally chip in when asked to provide a t-shirt size estimate for a piece of work.
It was only after being challenged by one of the engineers that I managed, that I realised this “shielding” was doing my team a disservice. Your role as a leader makes you a filter: you’ll be exposed to tons of information, lots of it irrelevant or incomplete, and you have to figure out what to communicate to your team.
I initially thought I was doing a good job of this: keeping people informed and only sharing things when they were stable/decided. In practice, though, I was leaving my team out of technical decision-making. They weren’t sitting through the calls and meetings I was in, and were only exposed to the outputs – which then created the impression that these calls involve high-level signoffs and decisions that they have no input into.
It was difficult to reconcile this initially, but I realised that my perception of things was obviously skewed because I held all the information. “There’s no technical decision-making happening in those calls! I just blurt out ‘sounds like a medium’ every fifteen minutes!” I thought. But how were my team to know that?
I addressed this by writing up a bullet-pointed list of every step in the process between “A product owner suggests a new feature” and “A user is able to see this feature in production” and shared it with the engineer in question. This was another eye-opener: they were unaware of half of the steps in my list (and confident the rest of the team wouldn’t know them either). Together, we added additional missing steps, eg. “Senior engineers are present at this discussion call to add technical input”.
You can’t solve a problem you don’t know you have – it might be a useful exercise to test your assumptions with your team about what they know and whether they think they should know it.
If you didn’t document it, did it really happen?
A new joiner on my team taught me this one. I was initially quite proud of the open culture my team had gradually established: lots of trust, everyone knew each others’ working style and habits, and the array of products we worked on was well understood. I’d do a quick overview of each one when a new starter joined us, and they’d pick it up… eventually.
But how did our institutional knowledge survive when a key person was on holiday? How did we keep everyone informed about the weird edge cases or the error alert you can safely ignore because it’s a red herring? Turns out we didn’t really know anything about our stuff.
You aim instinctively for “self-documenting code”, and in a purely programming-based sense, this is solid enough. But complex interacting systems can’t solely rest on JSDoc strings and the odd multi-line comment littered through source control and pull requests. We needed runbooks for the things we’d have to support out-of-hours, and we needed to assess our technical estate and highlight the gaps (rather than pretending there weren’t any).
The energy of a new joiner who was passionate about this topic helped cement the value of it in our team, and the first time we found ourselves relying on these documents (and others written by similarly-aligned colleagues on other teams) I was embarrassingly grateful. I even spent a fruitful, quiet day rearranging the team’s Confluence space for maximum findability, and even got my emoji game on point. Today, I have a little more confidence that when we don’t understand something, we have a starting point – and I also know the awkward areas that aren’t covered enough, because they’re conspicuous by their absence.
Add personality/humanity whenever you can
Work is hard, especially the last couple of years. I always try to keep things light on my team and I like to get people to do silly “challenges” or non-work tasks as a way of blowing off steam when we’re stuck on a difficult problem (“right, this isn’t working, let’s have ten minutes of Skribbl”).
I believe that when you personify these things yourself as a leader, it gives your team “permission” to do the same, and humour can really build trust and empathy between teammates. Sometimes the price I pay for this is willingly subjecting myself to social media mockery for not understanding slang, but I think little moments that say to your team “it’s okay to be silly sometimes and make each other smile” directly contribute to the trust (and therefore performance) of your team.
Someone else’s achievement becomes yours too
No, this doesn’t mean taking the credit for the work your direct reports have done. This one is about reaching the stage where you genuinely take pleasure/satisfaction in seeing another person get something they deserve, that you’ve helped them achieve.
This year I had a team member make a big ask: a relocation to another country. I’d never handled something like this before and the early internal guidance made it sound like an unlikely proposition. But one business case, much paperwork and one visa appointment later and his plane ticket was booked. My job in making this happen was really quite minimal – a few emails and some proofreading of documents was all it really amounted to. But I knew how much this meant to my team member and seeing it happen for him gave me as much satisfaction as if it had been happening for me.
I feel like reaching this stage of “leadership maturity” has been really valuable for me – the same goes for seeing my other engineers progress against their goals and achieve promotions and kudos. In all of these cases, I haven’t done much besides just nudge them along paths they were already firmly exploring, using their own talents and abilities that far outstrip mine. But I still get to feel the achievement as something that’s mine too – not because I made it happen (they did!), but because a high-performing team’s wins belong to all of us.