For most of my career, I’ve been an individual contributor: focused on the tasks at hand, writing code, among other things. All of that changed about six years ago. I found myself managing products, releases, infrastructure, and making many software decisions. As a result, I was promoted to “Lead Software Engineer.” Other developers were looking to me for answers, and I was involved with high-level decisions for products and features, so it seemed like a natural progression. However, I was ill-prepared for what it takes to be a lead engineer.
First, let me define what being a lead engineer means at Zumba™:
- Work with product managers in determining the technical needs of a product.
- Ensure product milestones get reached on time.
- Orchestrate the tasks of the team to reach an ultimate goal.
- Manage production-related changes (schema updates, third-party provisioning).
- Provide technical direction to developers on my team.
- Write some code.
These may or may not be or mean the same thing at other companies, but I would imagine they are at least similar in scope.
The first real lesson I learned, which seemed counter-intuitive to me at the time, is that I had to let go of the fine details. I had to let go of control of how every task is completed. I just had to let go. It is a tough thing to do when you have been an individual contributor for years. I care deeply for writing quality software, its performance characteristics, and its security implications. The details of each part of the product are essential, but they are no longer my job. They are the job of the engineers on my team. To let go is to trust the individual engineers of my team will care for these things just as I did.
I have to give my team the same opportunities to learn and fail that was afforded to me.
Like a carefully planted garden, you have to cultivate these attributes into the team. It has to start with the lead being the embodiment of those values.
There’s also a strange phenomenon that occurs when you start to let go of the individual tasks: feeling unproductive. I began to spend a lot less time coding, and more time looking at other’s code or organizing task tickets or assisting with deployment planning. Indeed, my productivity did decrease which is the nature of this role. That lost individual productivity is regained if not amplified by the increases of productivity of my team.
There’s a term that floats around in the tech world about the fabled “10x” engineer. It is often misconstrued as one engineer being able to replace the output of ten other “lesser” engineers. The reality is that every organization has multiple “10x” engineers. They don’t replace ten engineers; they make ten engineers better.
Train people well enough so they can leave, treat them well enough so they don’t want to. ― Richard Branson
To let go of my old detailed concerns, I had to know to whom I was passing the torch. I needed to get to know my team; not just their birthday and favorite foods, but their capabilities, and more importantly: what they want their abilities to be. Only after you know what each team member needs can you begin to select a management style.
Over the years, I’ve learned the truth about management styles: there is no true management style. Each person on your team may require different styles. Treating a senior engineer the same as a junior engineer will either piss them off or cause them to leave (or both). Junior engineers need more support, and possibly some “micro-management” at the beginning. However over time, that junior engineer that you had to hand-hold doesn’t want to be hand-held forever, and if they do, they are not growing, and you are failing.
This concept of ever-changing teams and the growth of the individual team member opened my eyes to the real challenges of management: adapting management styles per person and over time.
Management is doing things right; leadership is doing the right things. ― Peter F. Drucker
When you start at the company towards the beginning of their tech stack and stick around, you tend to become a prolific individual contributor to the code base. Often your style ends up becoming a defacto standard way of doing things. This “spread” happens either from other engineers agreeing with your style and more often than not, from more junior engineers copying and pasting in the code-base. Good or bad, this is an example of passive leadership. It’s usually the first sign that you are on the precipice of leadership.
Once promoted, I noticed that my team was continually scrutinizing everything I did. If I criticized how something was done, it couldn’t be for things that I do myself. If it is something that I also struggle with, I acknowledge it, and then I follow through on changing it in myself. I can’t expect more of my team than I expect of myself. It is vital to be an example of the qualities I wanted to instill in my team. Showing someone the right thing to do is much more powerful than telling them.
Honest communication is built on truth and integrity and upon respect of the one for the other. ― Benjamin E. Mays
If trust is the foundation of the team, then communication is the cornerstone. Considerable effort has to be employed in establishing regular communication with and amongst the team, not just one-on-one, but also how project details and decisions are shared. I realized that not all communication is going to flow through me. It is impossible to control, and indeed highly undesirable to do so. Encourage participation and open discussions, and more importantly, the rigor of documenting the action items or decisions made due to that discussion.
The hardest lesson I had to learn was the delegation of work, of which I still struggle with today. It is yet another strain against the individual contributor’s tendencies. Ultimately, it is a lack of trust in the team that made delegation so hard for me at the beginning. I frequently refer to letting go and trusting the team; delegating tasks of the project (even those difficult ones), is the manifestation of that trust.
The constant need to learn and stay up-to-date isn’t just for technical skills for me anymore, and I’m not done yet. Continuous learning, self-evaluation, and checking my hubris served me well as an individual contributor, and I believe these attributes to be equally if not more so important as a tech lead.
Featured image by Markus Spiske
