Maybe you’re 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 don’t want to go full blown project management, because honestly, who really wants to be in that many meetings. You don’t want to be assigned tickets ad nauseum, because you’re 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

I’ve 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

I’m going to be blunt. You need to know your shit. You won’t be considered for becoming a tech lead if you don’t 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 don’t even need to be the strongest coder on the team, I know I’m not.

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

• Design Patterns
• Enterprise Integration Patterns
• Scaling And then the niche language specifics for what you’re 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 company’s 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 there’s no way I could be the person who holds all of the information. Just a good portion of it.

Know the Team

You can’t lead them if you don’t 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 don’t.
• People you work alongside and people working remotely.
• People who speak the same language as you and people who don’t 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 you’ve 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(there’s always a next phase)?
• What are the features that the client wanted but didn’t get?

You also need to know the people surrounding the project, as you’ll be interacting with them much, much more in this new role. No, you’re not a manager, but you’ll 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.
I’ve alluded to the fact before, in this post and elsewhere, but I’m not the strongest developer on my team. That’s a small slice of impostor syndrome and a large slice of humble pie. But, that’s fine.

I know that I’m 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 doesn’t translate well with everyone, and I’m working on that.

In Conclusion

Without a concise knowledge of the technology you work in, the team you work with, and the project you’ll be capitaining; you won’t make it far. But, if you can’t take an honest observer role about yourself or your work environment; you won’t 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 isn’t exhaustive by any means, but it’s 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.