Maybe youre thinking about accepting that job offer or just starting to think about what the next stepping point in your career as a developer is. You dont want to go full blown project management, because honestly, who really wants to be in that many meetings. You dont want to be assigned tickets ad nauseum, because youre pretty sure the company can hire an intern to implement most of these enhancement requests. The role of a Tech Lead seems appealing enough, but what is the path to get there?

Originally posted on TeachingTechLeads.com

Ive made some light jokes about how I stumbled into my first role as a technical lead, but there was a lot of prep work that went into it. I had to figure out if I wanted to take on the role and then I had to figure out the path to get there. This is the short and sweet blueprint that I followed and the steps I took towards fulfilling every step along the way.

Know the Technology

Im going to be blunt. You need to know your shit. You wont be considered for becoming a tech lead if you dont know the tech.

Do you need to be a 10x engineer, or whatever the fad name for the fabled unicorn developer is nowadays? No. You dont even need to be the strongest coder on the team, I know Im not.

But, you need to know the area that youre going to be working in. This means a better than working knowledge on the following general subjects:

• Design Patterns
• Enterprise Integration Patterns
• ScalingAnd then the niche language specifics for what youre working on. For me, that was mainly the Spring Framework, Activiti, and Apache Camel.

Pretty specialized, but we were writing a workflow management tool for rather large merchandising company, and this architecture fit well within our companys wheel house.

Did I know everything about Spring Framework? No, not even close. I delegated a lot of it away. One particular member of my team took over the Spring Security research and became a SME by the end of the second sprint. They were an extremely valuable resource because theres no way I could be the person who holds all of the information. Just a good portion of it.

Know the Team

You cant lead them if you dont know them.

Not your first time through, a few projects down the road, sure. You can walk into a new team and use your prior experience to integrate yourself. But, your first time through, you need a team that you have worked with previously and trust you.

After a while, knowing them becomes knowing their archetypes.

You need to be able to lead all types of people.

• People you get along with and people you dont.
• People you work alongside and people working remotely.
• People who speak the same language as you and people who dont understand sarcasm in the least bit.

So, get to know your current team and figure out what you can take away from every relationship that youve formed there.

Know the Project

You need to know the ins and outs of the actual project itself.

• What is the expected release cadence?
• What does the project manager expect to see weekly or bi-weekly?
• What is in the pipeline for the next phase of the project(theres always a next phase)?
• What are the features that the client wanted but didnt get?

You also need to know the people surrounding the project, as youll be interacting with them much, much more in this new role. No, youre not a manager, but youll need to know how to manage up and manage expectations, tactfully.

Know the Environment

Every company has a particular working environment or climate.

You may be a shop that claims to be agile-ish, but still requires up front roadmaps and hard deliverables. Or maybe the architects are disagreeing with the overall technical approach of the CTO. Perhaps you can only get the ear of your product owner if you know how to get on the good side of a particular downstream employee.

These are all things you need to know.

No one can actually define this list for you, but you need to figure it out in order to be truly effective at your role. Because when you need to be an advocate for your team, there might be only one way to get everyone out of that ridiculous mandatory meeting. You better know it.

Know Yourself

This is a bit meta, by definition. You need to know why you want to do this.
Ive alluded to the fact before, in this post and elsewhere, but Im not the strongest developer on my team. Thats a small slice of impostor syndrome and a large slice of humble pie. But, thats fine.

I know that Im actually much better at helping people along than I am at producing perfect code. So, guess where I fit in pretty darn well? Into the Tech Lead role.

After my first two projects, I also know a bit more about myself:

• I know that once I get over 4 developers on my team, I can no longer lead effectively.
• I know that once I approach 60 hours for the 4th week in a row, I can no longer form sentences as well as I can on a regular work/life routine.
• I know that my code reviews can become overly pedantic if my blood sugar is too low.
• I know that my self deprecating humor doesnt translate well with everyone, and Im working on that.

In Conclusion

Without a concise knowledge of the technology you work in, the team you work with, and the project youll be capitaining; you wont make it far. But, if you cant take an honest observer role about yourself or your work environment; you wont even make it out of the gate.

Once you can say that you are comfortable in these five fields, then you are well on your way to approaching leadership about the role that you want to fulfill.

This list isnt exhaustive by any means, but its the bullet points I considered before accepting the role offered to me. I had been working with my local team for years. I had been working with the remote team for close to 6 months and felt rather comfortable with them. The technology had become rather secondhand to me and I was regularly helping the current tech lead with design sessions. Project management sat two rows over from me and the system architect sat behind me, so I knew the environment I was getting into.

Once I felt comfortable with the notion that I could add more to the project by not developing, I was ready to move out of my current role and become a tech lead. But how about you? What was the catalyst for you, or what do you think is holding you back?
Let me know below.