To err is human, and I certainly have made my share of mistakes in my career as an engineering leader. Undoubtedly, I still have quite a few yet to make. Like with software incidents, it is vital to reflect and learn from mistakes, so that our system becomes more robust and we grow as professionals.
Today, I thought it would be interesting to go through 6 mistakes I have made as an engineering leader.
1. Skipping 1-1s
Skipping 1-1s was never really a habit for me. I've always made it a priority to be available for my team. However, I've had reports who didn't take enough ownership over their 1-1s. When that time of the week came, I would sometimes get a chat message:
Hey, I don't have anything for 1-1 today. Shall we skip it?
We were super busy, so agreeing was highly tempting. In doing so, I was missing out on the opportunity to:
- Share my expectations and feedback around 1-1 ownership.
- Empower and motivate the individual.
- Set goals and maintain accountability.
Later, I learned to ask better questions, put the individuals in the driver's seat, and make the most of 1-1s.
2. Underestimating having a clear technology strategy
Many managers dictate and involve themselves in every technical decision their teams make. I want to empower my teams to make their own decisions and genuinely have agency over the software they build, ship and maintain. However, for multiple squads to do that consistently, you need a couple of things:
- Excellent communication across teams/squads.
- A clear technology vision and strategy.
It took me too long to support my teams by sharing a clear technology vision and strategy that would become the principles on which they could base technical decisions. Once I did that, it felt like magic. We were all rowing our technology in the same direction.
It doesn't need to be too comprehensive. Just be clear about the kinds of tradeoffs you want the team to make. I will dive deeper into this one at some point with a separate article.
3. Not setting clear expectations
There have been instances where an individual was surprised when receiving feedback from me. That is usually a robust signal that expectations were not clear enough. As long as expectations are clear, folks have enough self-awareness to reflect and identify a problem after receiving feedback about something not working out great.
Making the expectations of each role in your organization public is a fantastic tool.
- Help everyone understand what is expected of them.
- Increase equity, people in the same role are not evaluated against different standards.
- Greater understading of what it takes to progress.
- When shared externally, it can be a great recruiting tool.
Of course, you should complement this with great 1-1 sessions, good cross-team understanding of roles and responsibilities, etc.
4. Not hiring Engineering Managers first
Back in January 2021, I found myself in the position to increase capacity fast. To do that, I had to grow the Aula engineering team from 7 to 25 in record time.
Yikes!
I knew hiring Engineers was hard, but finding fantastic Engineering Managers (EMs) is much worse. In Europe, managers also tend to have longer notice periods, up to 3 months!. The pressure to increase capacity was so high that I mistakenly prioritized individual contributor (IC) roles over the manager ones.
As a consequence, my team grew well beyond my management capacity. If I remember correctly, I had 15 reports at one point. I still had to do all these Engineering Manager interviews, so the quality of my feedback went down, and it became increasingly hard to help the team push in the same direction.
What would have happened if I had focused on increasing managerial capacity first? Maybe short-term velocity would not have gone up, but I would have achieved a few things:
- Much higher hiring capacity with lower pressure on ICs.
- Significant improvements to feedback.
- Greater alignment across product squads.
5. Not investing enough in team building
In a rapidly growing organization, folks start working closely with other people they do not know at all. Even though everyone works hard, software delivery does not progress as expected.
There is no trust.
Not because you hired the wrong people, but simply because you have made no room for individuals to build trust with each other. Thanks to the feedback I received, we invested much more in getting to know each other and building that trust. The team gelled and worked much more effectively together after that.
🙌 Thanks for reading. Hopefully, some of these have provided you with some insight.