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.
Top comments (9)
Great post! One thing that I'm missing is: Know the Business. When I think about Teach Lead I imagine an experienced developer with leadership skills and ability to translate business requirements into code and architecture. I believe that the biz element is crucial to succeeding and often forgotten. Without business value, in IT projects we end up with great, scalable apps with an amazing performance that nobody uses because it doesn't respond to business needs. Tech Lead is a person in the best position to connect both worlds and deliver with the team products that are loved and used.
Hey Krzysztof, thanks for the feedback. I'm struggling with how I feel about the statement of needing to know the business that you and Vaibha are suggesting.
On one hand, you're right, someone needs to have an understanding of the business to translate the client request into firm requirements. But I have been fortunate enough to work on a team with either a seasoned project lead or a business analyst who can make that translation for us.
The tech lead is definitely a "bridge", and I think that the size of the company/project team is going to define what that bridge connects.
If you are the direct connection between the development team and the business, then I agree with you 100%.
If you are acting as the connection between the PM/BA and the development team, then your skill set is useful outside the particular business vertical you're currently working in.
You are right, PM/AM are the first when you think about connection between tech and biz. But maybe I'm a bit radical with this :D
I think that when we keep Devs away from biz, it's expected they deliver tickets and not valuable feature. When we keep both parties siloed with only one person as link dinner or later he will become a bottleneck. When we have a team that understands biz requirements and tech lead can prioritize and evaluate it there a more chances to scale and collaborate.
Those are some great points! I hope to work in such a closely integrated team.
Agreed, i'd probably add Know the Business to the top as well! Acting as the bridge! Good post nonetheless :)
Nice article, thanks for sharing! And really like your blog/website on tech leads.
It would be nice to know the context on what the tech lead position was in your case. It seems there’s a wide range on what this role means at different companies. Was it running one specific project (so similar to being a senior developer plus project lead)? Or was it to be the lead for parallel projects?
Also, did you still have time to code yourself, or did leading, coaching, project managing and stakeholder management take up all your time?
Hey Gergely, I've answered some of your questions in earlier posts, so I'll try to give a brief overview here.
In my first role as a TL, I oversaw one project at a time, with the obvious overlap that our SLSA required. In my current position, I'm the lead of one suite of applications and the numerous projects that fall under that umbrella.
That primarily means that I have a team that works on requests for sizeable enterprise application and we dole out work as resources become available.
For the second question, I still find some time to code. The previous article in this series speaks specifically to that point. I don't get to work on requirements as often as I'd like, but I have found ways to make sure I still get to code.
Hope you find some use to the blog. I'll add your idea of "defining the role" to my queue of topics to write about. So, thanks for that!
Nice article! I am always on the lookout for opportunities to get myself into a tech lead position. While I still have some work to do, it’s nice to see posts like this to help me chart my course. Thanks!
Thanks for the kind words, Joe!
Knowing you have work ahead of you is a great first step on the journey. It's a lot better than stumbling into the role and trying to figure it out on the fly like I did.