It’s been a year and 1 month to date (as of me writing this) as a Lead Engineer (aka squad lead/team lead/senior engineer, whatever you prefer to call me). It’s also been a little while since I last wrote about anything useful. The reason for that is I’ve been getting my ass kicked by the role.

Now, technical leadership is not as consistent across the industry, based on my experience chatting to colleagues across the aisles. The role tends to be tailored to what is needed, and, to be honest, the purity of this utilitarian nature is something I can’t help but admire (except in those moments when the situational ambiguity is an absolute pain in my ass).

Today, I write about 3 of the biggest lessons I’ve learnt or gotten much better at, and the rules of thumb that have served me well and will, hopefully, continue to do so.

1. People come first

An obvious statement, but fucking hard to do right.

If this is not an obvious statement, and it’s not obvious because of your company culture or because it’s not “a part of your job description,” then let me make a rational argument for this.

• a. Your remit (primarily) is the technical success of the platform and/or applications within your scope
• b. Technical delivery and the SDLC are the primary methods to get this right (albeit not the only ones, but I think we’re sufficiently past the point of arguing about this as an overall software engineering faculty)
• c. Who are the indispensable drivers of this process? People*.

I hope this argument is enough to convince you, my fellow maestro of logical reasoning and problem solving.

If the reason is not the above but rather “I don’t care about the people,” I hope this argument helped you to care, but I would put money on you having some tough years ahead if you don’t, and I’m not a betting man.

(If the reason is company culture, move. You deserve better.)

Putting people first is not about buying them pizza on late nights (note, I’m not saying anything about pay and reward; that’s different. That’s about the company treating its people right and is largely out of your control). It’s not about letting them work on what they find cool, and it’s not even about being friends with them.

So far I’ve come to realise that it’s more about:

• a. Understanding their chosen growth journey (which requires them to have one. I’m not wholly confident I can effectively help people who are confused about where they are and want to be yet; I’m way too self-assured in what I do. Here, I seek help; see 3 below.)
• b. Identifying and executing on opportunities to put them in places that are, in-turn opportunities for them to progress on their journey
• c. Being their second, having their back, but never, NEVER firing their bullets for them. (They won’t learn to shoot straight unless they actually practice shooting.)
• d. Giving them feedback on their progress, whether good or bad. (That’s not to say throw the book at them. Not all bad or critical feedback can be delivered equally. This is the hardest part for me. As someone who prefers their feedback neat, giving feedback with some ice and exotic cordials is a skill I’m still learning.)

This is the biggest lesson that I’m still learning. I’m grateful that my own leaders are admirably good at this, and I learn from them every day.

2. A delivery program ends - the user experience and developer experience stays

I’m not saying be a purist about delivery. It’s admirable, but not often useful.

Technical debt is a business line of credit that is not subject to actuarial models. I’m sure actuaries could build a predictive model that could help with the utility of when to incur debt and when not to, but for some reason they haven’t, which in itself is interesting (I think we still need to work on getting a few seats at a few tables).

Because the risk of debt is a function of the certainty of default (or lack thereof), debt is, formulaically, a high-risk liability. The catch is that engineers are usually the only people who truly know this, and they usually only know it intuitively, which doesn’t make for a good PowerPoint to our more business-functional colleagues.

My solution so far, besides taking care and treading lightly, of course, is to communicate! Don’t complain about it after the fact; communicate your discomfort upfront. Communicate “why,” ideally with objectivity, which, as I just explained, is hard to do.

The tip that has served me well personally is to understand why things need to be done by some seemingly arbitrary deadline. Understanding breeds empathy, and empathy is the most important tool for breaking down hostile relationships.

In my experience, putting in the work can result in 3 cases. The best case (as in, easier for you personally) is that, shit, the reason is actually a good one. There’s some time-to-market sensitivity, for example.

Middle case: You agree with the reason but still think that compromise will not lead to good outcomes. I’ll get to this in a minute.

Worst case: The reason is actually objectively arbitrary. This is the hardest one, because you’ll need to argue, not because you’re a person of high character who worships at the altar of engineering excellence, but simply because you’re being paid to do this. It’s your job, friend.

Your remit is the technical success of the platform/application, which brings us to the middle case. My advice, and really this is advice I’ve inherited from good leaders, is to be hyper-objective and unemotional, but also extremely clear that you’re not against or pushing back on this for personal reasons. Rather, your professional opinion and remit obligate you to do so, based on the facts you need to lay very clearly and unemotionally before the stakeholders/delivery managers.

Either they take it with grace, intelligence, and trust, or they don’t. The outcome is that you will at least have a clear conscience (you’ll be fucking pissed off, but leadership sometimes means looking for silver linings as you get pushed into the storm that has them).

3. Seek help: your job doesn’t operate in isolation

Unless you work for some government agency that probably tracks our phones and mines our data, and your job contract consisted of more NDAs than I’ve probably signed in my entire lifetime, you are allowed to ask for help.

Not confident handling a non-technical leadership conundrum? Seek help from someone. The key, though, is seeking help from someone you’ve seen handle this in a way that you admire.

I phrased that very specifically: not someone you’ve been told is good at this, but someone you’ve seen in action and literally admired.

Statistically, your admiration for how they’ve handled something is probably an indication that their methods are something you relate to, and you’ll therefore find it more palatable to work with that person.

Warning: Pay attention to why and what you admire about things. It often points to things you either find interesting or desperately need (or both)

Notes

*If you say “ai agents” as an answer to this question, hit me up on socials. I’d genuinely love to get your take on this. I promise I only have honest questions to ask, and none of those are sarcastic.