Last year, I accepted a "Head of Engineering" position at Adevinta. It meant that I was moving from managing a single (big, with a complex domain) team in the cloud and infrastructure domain to joining the pure product and engineering side. I was about to manage managers for the first time. I learned a few things during the year and wanted to reflect on them.

Independent of how well my teams or I ran the show, I learned there's always a fire somewhere: a key person that leaves, a project that becomes complicated, misalignment across engineering organizations, or shifts in the business that require adapting. Sometimes, it feels like a never-ending circle. There's no "good state". This is a bit obvious: as you climb the ladder, you get more scope, complex problems, etc. An analogy I use is having babies. You know it will change your life, but you only realize there's no instruction manual once you're home with a newborn.

My primary learning here is that building a strong leadership team and delegating as much as possible is critical. I mostly failed on this point throughout the year. That lever creates quality time to think through problems (e.g., is it one-off or structural?), anticipate where needed, and support the team.

My motivation fluctuated throughout the year for various reasons. That fact led to more or less communication and perceived transparency from my leadership team. As a leader of a small (30-50) engineering organization, I'm ultimately accountable for creating excitement, seeing the glass half full, and enduring change with resilience. Of course, this is easier said than done. Especially when the company you work for fundamentally changes, there's a tricky balance between pointing out the good parts of the transformation while acknowledging that it can be unsettling and creating the space for digesting it.

I'd do a few things differently. The first thing is to discern between my feelings and motivations and what the teams need from me. It's different to lead 5-10 people than to lead people that lead people. The multiplier effect of being "demotivated" is too big to afford. The second thing is to keep communicating effectively and as transparently as possible, no matter what. I had a (good?) practice of sharing a weekly newsletter with my former team: Bricks of Love. However, I didn't bring it with me in the transition to my new role. I don't know exactly why. Maybe I wasn't sure what the correct information was to put there. Perhaps I wasn't confident about what I could share or not. I started doing it again recently and saw positive results and feedback.

Following Peter's principle, I have reached my "level of incompetence" on the corporate ladder for engineering leadership. The job is fundamentally different now. Leading organizations in big companies mean dealing with ambiguity and imperfect information and consistently trying to reduce it and de-risk it. That is a huge part of the job and a necessary one in big companies. 

A few years ago, I thought I'd like to lead big organizations (> 200 people) in big corporations. I changed my mind. In the future, I see myself leading an engineering organization of < 50 people or directly becoming an Individual Contributor again, following the pendulum. There are different reasons for this. One of the biggest ones is the increase in productivity that Large Language Models (LLMs) create for developers. Builders have more leverage than ever. I also anticipate that, in the future, engineering organizations will be leaner, and I want to adapt to that.

— João