Others’ Lessons

Earlier this month, I read a great blog post by João Alves offering some wisdom on how to earn trust and influence as a technical lead (among other insights). One of my favorite quotes in it is:

Building helpful things and standing by people when the system is on fire creates more trust than any title.

I love this line. On engineering teams, I really can’t think of a situation that shows the true colors of a leader than when there is a fire (possibly of the dumpster variety). Do they distance themselves and just ask for updates? Or are they getting their hands dirty alongside their team? Do they demand a resolution as quick as possible? Or can they take a step back, take an honest look at the priority of this fire, and tell their team to take a break (which may require taking some heat from further up the management chain)?

Engineers, or really anyone associated with the team, do not forget how these situations unfold. It makes all the difference in your credibility and trustworthiness as a leader.

This post got me thinking about what kinds of leadership lessons I’ve learned over the years…

My Leadership History

The first time I became a technical lead was in 2019. While many organizations make distinctions between “team lead” and “technical lead” or “product owner”, there was no such distinction in this case - it was one role that was responsible for both the technical direction of the team, as well as managing collaborations and agile ceremonies, customer communications and briefings, etc.

I had no idea what I was walking into with this particular team. It had a reputation of delivering incredibly high value, quick-turnaround capabilities to our customer, but was also notorious for burn-out and not being able to keep a tech lead for more than a few months.

I stuck it out for maybe a year or so, before I got hit with the burn-out myself. I told my management this and gave them four months to find a new tech lead, and was prepared to resign if necessary. Thankfully, they took my request seriously, and in a few months we had a new tech lead.

Ironically, being able to step into an IC role on the team actually did wonders for me in terms of leadership insights. Without all the pressures that come with being the tech lead for this particular team, I was able to see dysfunction so clearly, and understand how and why it has persisted. A dysfunction that, frankly, I took part in while I was tech lead.

Another part of that experience that helped shape some of my early engineering leadership beliefs was by watching the new tech lead and learning how not to lead a team. He was quite the opposite of what João describes as a good leader…and predictably, his credibility always stayed low with the team. While the team was working on time-sensitive, high-pressure requests from our customer, he was nowhere to be found. Yet when he did even the slightest of helpful things for the team, he went fishing for a disproportionate amount of praise and recognition from the team. Not only did the team suffer from this situation, but ultimately the customer did too. Watching his leadership style, it became painfully obvious that the first thing the team wanted to see is that their lead is at least willing to try, even when they might not know what to do.

Before we knew it, this lead was out, and we had another team leadership void. I ended up stepping in to do it (again), feeling significantly better about how to handle this team.

I stayed with this role for the rest of my tenure with that employer, and the team actually grew with more engineers. As I learned, onboarding new team members is actually a great time to re-calibrate expectations on the team, set new norms, and plant seeds for what a healthy, high-performing team looks like. Later on, I ended up becoming an engineering manager in addition to the tech lead role, where I was responsible for the career development of four engineers, which also greatly contributed to my personal philosophy on engineering leadership.

Since then, I’ve taken on more leadership roles in other companies, and each of those experiences has taught me unique valuable lessons.

Engineering Leadership Musings

I’ll end this post with some of what I’ve learned about engineering leadership. Or at least, what I’ve found works for me:

• While there are many different leadership philosophies, the one that I’ve found fosters the best engineering teams is servant leadership. Not only does it build a team that is empowered to “own, not rent”, but it expedites the building of mutual trust.
• Play to the strength of individuals on the team. Take a step back and remember that there is no “perfect” member of the team - while encouraging upskilling is important, it’s even more important to ensure the individuals on your team don’t feel deficient in any way. Tap into the unique experience and skillset that each team member has, and find a way to shine a light on that and let it shape the team for the better.
• There is no uniform process that works for every team. Sure, there are some processes that are more proven than others, but anyone that promises you that they know (for example) the “right” way to do agile is full of crap. Along with this - don’t do processes for processes sake, do the processes that work for your specific team. Don’t assume that what worked for your last team will work for your current one!
• Cut out toxic behavior early. In the best case it’s just an ego or arrogance problem, but in the worst case it’s a dismissiveness or defensiveness that compromises the team’s psychological safety. If you don’t cut this behavior out early, it sets an example that starts to become normalized on the team, making it that much harder to change later. These are some of the most difficult, but important, conversations to have as an engineering leader. Keep in mind that often times, people might not even realize how their behavior is affecting the team.
• Read The Five Dysfunctions of a Team. There were a few other musings I was tossing around in my head before realizing that this book describes them much better than I ever could (which is also where I learned some of them).