I recently became the Technical Lead at the company I work for, Primitive Social. We're a smaller software team, but growing somewhat quickly. Th...
For further actions, you may consider blocking this person and/or reporting abuse
I don't think any two tech lead roles are the same, as context is so, so important. What I can do is share my own experiences from being a tech lead myself, and serving with other great tech leads.
Being a tech lead to me is less about the tech, and more about being a lead. It's as much about having a relationship towards the more business aspects of the company and the dev-team as it does the technology itself. From a technology perspective, a tech lead should provide guidance by showing a clear direction about where your specific tech choices are headed and tie those choices back to business outcomes.
Guidance is an important word here, since it doesn't mean being prescriptive, but rather giving boundaries of what is expected, and allowing other team members to experiment within those boundaries. It's also about listening and mentorship. Your role as a lead is to communicate your vision to other team members and gather individual feedback that help the whole when it makes sense.
It means being hands-on the tech as much as possible, but perhaps focusing more on integration and communication between people, teams / services instead of the nitty gritty implementation details. It also means experimenting on technology (with other team members where it makes sense), and having an idea of where the technology needs to be in x number of years to continue to support the business aka "The Vision".
One of the most important aspects, though, is that you don't need to have all the answers. Instead, seek out opinions and views of others on the team, and amplify their voices. You may have the veto-call, but the less the use it, the more influence you will have on the team's direction and support.
I'm going to assume you'll be directly managing the team vs some sort of leveled up developer, but still an individual contributor...
You're now a bonus multiplier. Your individual contributions are less relevant (ie. LOC, etc.) and your focus is on increasing the over all output of the team as a whole. This means getting them the tools/info they need to be as productive as possible and removing all the roadblocks.
It means doing more code reviews and asking the team to stay on top of code reviews in general.
It means listening to the team, even giving one of them "project lead" status, but reserving the [not often used] ability to mandate a decision.
It means regular 1:1 meetings and asking for pointed feedback. Don't ask "Is there anything I can do to make your life better?" ask "Tell me one thing I can do to make your life better." Same question, but the latter shows you really do want that feedback.
Ensure praise goes to the team and blame goes to you (whether or not it's deserved). "The team did a great job delivering this feature" and "I missed this acceptance criteria which is why the feature was late."
And a bunch of other stuff too :)
Great answer! I love the idea of being a Bonus Multiplier!
I find it really helps me get over the "I'm not pushing code. Gah!" mentality.
Oh, the other thing... don't take tickets that will block the team if you don't get them done ASAP. Cause you'll get pulled into all kinds of meetings and a ticket that would take 1/2 day will take 2-3.
This is a good one, and something I struggled with personally. Blocking the team because you can’t get work done is just not OK (over time).
There’s a challenge though. It’s easier to then lose contact with the codebase and state of things.
Do you have any recommendations to avoid this?
Not any super good ones no :)
Do more code reviews. It's not quite the same, but at least you'll see the new code that's going into the app.
Chip away at ancillary things, nice to haves, things that won't block anyone, but still keep you somewhat close.
Take a tricky bug now and then. The code snooping you have to do to fix it will get you back into things.
Tech lead: designing/architecting solutions to problems, gathering & refining requirements, facilitating discussions when requirements conflict, choosing the right technologies (and maybe creating PoCs), and mentoring the developers as needed.
A tech lead is the highest-level position that still intimately knows the codebase(s). The next higher level position will know what your project(s) do, and probably how they work, but will not be familiar with the code itself.
A word on creating PoC's. Only you can know the people above you, but if they are almost ALWAYS gonna take the PoC and want it to become a production feature, be sure to also ALWAYS code the PoC as if it will be production code. Otherwise you risk getting a lot of tech debt in production very quickly.
I see alot of leads slipping to far into management, for me leads must write code as well as organising the work and taking part in design. If your in the trenches with your collegues you know where the pain is and in the best position to help design solutions to improve everyones lifes.
I always remember a quote from Martin Thompson were he compared architects to airforce captains. Those guys have to log the hours to keep there wings. Technical leads and architects should be doing likewise
Tech lead positions vary a bunch from company to company, and your experience will depend on one factor - whether you have managerial authority over your team or you don't. Both are tricky.
If you do, great. Your team is fully in your control. fire/hire the right people until your team is awesome. If you don't, well shit. Isolate and contain your problematic teammates until your team is awesome.
your main job is primarily to support your team first and foremost. This might mean fixing some process, facilitating discussions with multiple teams re: design decisions, or maybe someone on your team had a bad day and wants to talk.
you are the interruptable one. Since your main job is to support your team, your focus should be on letting them work distraction-free. The consequence is that people ask questions and need answers at many points in the day, and that's why you're there as the lead.
you can't expect to still code full time. You can no longer anchor important work, that's what your team is there for. While you still can code, you're not going to have 3 uninterruptible days to focus on resolving that issue because multiple other issues will come up. My balance was 3/5 days were interruptable and subject to discussions/meetings, the remaining 2 days I could code. This meant that I could only really work on small tasks.
mentoring is on you to facilitate. If you have juniors on the team, you or your team needs to show them how things are done. And it's on you to make sure everyone on your team has a similar answer to that question.
if you are a senior dev who became a tech lead, you are there to make your team as effective if not more effective than you were. It does not mean that you do all the hard work and farm out all the easy tasks. You won't be there one day (vacation, sick, or you no longer work there), and your team will be expected to continue delivering.
In short, make yourself useless on your team. Because that means that your team can do everything and doesn't need you anymore. At which point you can get back to coding 😁.
I'll add a few more things to what everyone has already said (lots of good stuff).
I've heard over and over that a lead shouldn't necessarily be "the best coder" on the team.
While that's true, I think it's usually taken to the extreme and posed as "Well, leaders do mostly non-technical stuff like communicate with business stakeholders, high-level stuff, mentoring, etc.
But for a tech lead that's a terrible situation to be in...
Why do I say that?
The most important aspect of being a leader is trust.
Any leader can only lead and support others that trust him/her, otherwise they will either "not follow" or just pretend like they care.
If you aren't a very good programmer, let's say, your team won't really trust your solutions and guidance. Now, I'm not saying you should have all the answers, but if you (the lead) have to ask other developers all the time for help - that's a huge problem.
If you are, for example, a lead for PHP - you should know PHP fairly well. You are a tech lead after-all.
I've been on a few teams who had this problem - in particular, one with a senior architect who fit the description above. Nobody trusted him. Nobody enjoyed working on the project's that this person was involved in.
In tandem, this would include things like design patterns, at least a fundamental understanding of paradigms like Domain Driven Design, some real (good) knowledge and expertise with system architecture etc.
If you are a tech lead with over, let's say 10 years experience and you really can't tell me 3 useful design patterns for the specific solution at hand, struggle with the programming language's syntax all the time, etc. then I'd say that's a problem.
No one will give you their trust in that case.
Someone had said "it depends" and that's true. A tech lead for a software team that builds really simple software vs. a tech lead for some SOA based solutions will different quite a bit.
But in general, I think being a tech lead (specifically) does imply that you should have the knowledge and skills to teach to your follow developers - otherwise how can you teach something that you don't know or can't do?
Hi there!
I am a part of Dev team at an Organisation worked under a few Tech leads.
I'm writing here about how I expect my lead should be.. Considering Tech lead like a Senior person who excel in some technology and a leader to a Team as well
2.There might be very tight deadlines for a Project to go live, a lead must have the capability to Convince/Confuse :P the Client in such a way that they should not feel bluffed instead they feel something better could be delivered if given sometime more, if tech lead himself is Customer facing
3.When any new requirement comes up, choosing the Test driven Approach is something I would suggest. Meaning showing up a prototype or a PoC what customer expects for you and Customer being on a same page.For Sure there will be a few customers whose Requirements will show up multiple expectations [like a word whose synonyms are plenty] and if we build by chosing one among them; Post Production they would come back and say "hey these are what we expected and you designed it the other way around which we didn't expect"..
4.Feasibility analysis of the requirements to Technology you've chosen and solution that can be implemented must be made because there will be a tough part to achieve in any solution for a technology chosen. Identification of that affront would lessen the effort to build or develop.
5.Assessment of your team capabilities and division of tasks among them based on their expertise. Again there will two visions here one would think to give a out-performing member a new technology to work on.This could be decided based on the deadlines you have..
I wrote this out of my vision on how my lead should be.. ignore my flaws if any.
Suggest if I can think of any mentioned points in a better way.
There could be many suggestions for betterment of a Leader ultimately -
Lead should be like Know the Way, Show the way and Sometimes drive the way..:)
It's impossible to write a code if you have at least 15 people in your team. From the coding part you only have a time for a code review and merges. All other time goes to tutoring, explanations, architectural decision, translating tasks from managers and stack holders to human readable and so on.
Most of tech leads were senior developers before and mainly focus on resolving big tecnhinical issues. But when them become tech lead, their mainly task is to lead/help the team to execute their tasks and work efficiently.
This change is the hardest from a non people skills professional, that was focused on technology only.
Something usefull is to take a look on kanban team and think what can I do to help my team resolve tasks today. Maybe given some tips to pass a hard time, or provoke some thoughts of the task, or given a time to let them thinks for themselfs.
But, certainly, do not try to solve the problem yourself.
This is an excellent question, and has infinite answers.
One resource that I found super helpful in my transition to a more senior position was Talking With Tech Leads by Pat Kua, CTO at N26.
The book consists of interviews with a number of technical leaders from varying industries, experience levels and attitudes. Super easy to read, and full of useful nuggets for anyone interested in technical leadership.
For my part, I want my Tech Lead to enable and elevate me as a developer. I want them to provide me with clear technical vision and push me to grow into a better developer by constantly challenging me. I also want them to be in the code at least 70% of the time. There's nothing worse than technical leadership that isn't familiar with the current state of a codebase.
That book has been a life saver getting me started!
Solutions for source control platform, branching strategy, IDEs/tools, lib-stack, linters, PR procedures, deployment, infrastructure, unit/e2e testing. Then plan and break the work up into bite sized chunks and feed to developers - provide guidance during development. Shouldn't need much more than that for strictly a tech lead. If you include architecture, you're going to be looking for audit-ability, exit-strategies, backup systems, viability of vendors, support contracts, long term support, future-proof, synergies with existing solutions.
Use work assignments as an opportunity to leverage strengths of weaker devs and career progression for stronger devs. Spot blockers early and tackle those first.
Work with management to understand team key performance indicators and orient processes toward improving those numbers.
Work with product/requirements sources to ensure their KPIs are measurable in the final product.
I'd expect a lead to be very hands-on.
Focus on developer UX. Can they choose their favorite IDE, clone a repo, build, test, PR, merge and deploy with minimal hiccups without delay? Then you've done a good job.
EDIT: I forgot to stress to not be a tech dictator, but work with tech resources on the project to make the decisions and understand them as a group. When they understand and agree you have buy-in you won't have disgruntled devs.
You find the answers for the team (for even tiny problems) and minimize the allover costs of building / shipping the next great idea.