Tech Lead Handbook
The Focus Shift from Individual Contributor to Engineering Manager
GitHub Contributions page tells the story of the transition from IC to EM
My journey from an Individual Contributor to a Tech Lead / Team Lead / Engineering Manager on a small team (less than 10 developers). I am trying to answer a question about how much code an Engineer / Manager contributes to the codebase. In this article, I am using GitHub Contributions as a proxy for the amount of code I contribute. Note: these metrics are strongly opinionated and biased.
What are GitHub Contributions
First thing first, GitHub Contributions put your commits, code reviews, discussions, and issues in a calendar view. Check 👉 [contributions that are counted] for details.
Put them on a timeline (Year on Year)
The Individual Contributor Phase
From year 1 to year 3, I worked as an Individual Contributor. It started relatively low during my first year at a new company, went up in year 2, and peaked when I was a Principal Engineer in year 3.
The IC phase tells a simple story of how domain knowledge, relationships, and familiarity with internal tooling can contribute to your performance. Are they transferable when you leave the current company? Kind of, with a discount. What are the transferable skills then? Coding, troubleshooting, architecting, etc are more transferable. It helps you find jobs and grow quickly in a new environment.
The Transition Phase
By year 3, I was ready to lead the team. 🎉 !! Still, the transition phase was a pain in the ass. I was working in 2 roles -for most of the year, I had to cut code, coach the team, line manage engineers, hire new talents, architect solutions, support product discovery, and contribute to the leadership team, and lots of admin work…A LOT.
Despite being crazy busy, I know what I’ve done for a better future for the team. Looking back, I can think of three things that were most important — coaching, delegating and hiring.
- If a task could be done by someone else, delegate it. If they aren’t ready, coach them.
- Never micromanagement. Never. Provide the space for growth, especially for high potentials.
- Hire the right talents. Hiring no one is better than hiring the wrong one.
- Get the team aligned and focus more on the why
The Settlement Phase
As the team grew stronger and more mature, engineers can drive initiatives without your support. Seniors were willing to coach juniors or new team members to help them get started. The team maintained good engineering best practices and continued to raise the bar. The team members have good professional relationships and trust each other.
Other than cutting code (GitHub Contributions), I was able to work on high-level architecture, cross-team collaboration, execute tech strategy, monitor tech health metrics, etc.
I can focus more on the long-term stuff. I have time to zoom out and see the big picture and contribute to the problem space, product, business, and strategy.
My New Chapter
Right now, the team is a self-sufficient high performing team. And I am joining a new team in a slightly different role, more on architecture and technology, less on line management. I am proud of my achievements and meanwhile, I am excited to see how I apply my knowledge to the new environment.
