I’ve been a tech lead for several years at a few different companies. Each role has been somewhat unique, and yet there have been commonalities bet...
For further actions, you may consider blocking this person and/or reporting abuse
Extremely well written. Thank you for describing my role in ways I couldn’t do until now - very refreshing and into my bookmarks it goes.
Thanks Rodolfo!
Note on the questions regarding writing tests for the legacy project - do it. Even if it involves a super old tech stack. Once the tests are good, coverage is sufficient and integration is running you can refactor with confidence or even make breaking changes it just gives you muchore opportunities than without the tests since you never know without tests WHERE (not if) regression is introduced.
And in the process the test suite and tech stack can be updated step by step. This expensive but cheaper than keeping it legacy
In general I agree with you. And you're right that the main benefit of tests is that they allow you to refactor with confidence. I've written about this extensively in these articles:
It's important to remember though that the situation can be more nuanced at times. What you've described is a legacy project, likely large, making changes frequently, and making changes with an uncertain impact. In this scenario, your suggestion to invest in writing tests makes perfect sense, especially if this is a codebase you will be working with frequently over time and that you plan to refactor and update.
Now consider a very different scenario: Let's imagine you need to make a small change in a repo that's part of a much larger app, where the last commit in the repo was five years ago, it's unlikely you'll need to make another change in this repo for several more years, and the change is narrow in scope and easy to manually verify the impact. Is it worth investing in test infrastructure for this specific repo in this case, especially if it will take orders of magnitude more time than the actual task? Probably not.
The nuance here is that the first scenario has a high amount of churn, expected changes over time, and complexity; the second scenario does not. These are important factors to consider in your decision.
This is a great point. I like the easy to manually verify part so such a tiny part of code change in the vast amount of legacy code base.
In such case, what I will do is to make sure the how-to-manually-test-my-new-tiny-change is documented with code base, so QA and whoever touching this part knows what's matter/new and how the results could be verified as expected.
Absolutely. I'm a big fan of using merge request templates to provide additional context for other developers during code reviews, and one item I always include is a test plan for how to manually verify the change. These kinds of checklists are super useful!
More on that here: dev.to/thawkin3/managing-complexit...
Yes, totally agree with that!
Wow. You literally described my job to a "T". I don't think a lot of people understand the difference between a Senior Developer and a Tech Lead. This does a very good job.
Delegation and time management are areas I personally need to improve on so I will definitely be checking out the linked article.
Thanks!
Thanks Gary! That's good to hear I've hopefully captured some universal ideas in here that are applicable from company to company.
I’ve struggled to come up with an accurate description of what I do, but this does a pretty good job of it - though with the nuance that my team has always been very small, and at times I’ve been the only contributor.
Out of curiosity, would you make a distinction between “tech lead” vs “lead developer”?
Haha I've often had a hard time describing what I do as well, because it's a lot more than just writing code, which is what people usually think.
For the distinction between "tech lead" vs. "lead developer", it honestly probably changes from company to company. I guess you could say they're the same thing. Or maybe in some companies a "tech lead" would have more of an emphasis on project management whereas a "lead developer" would have more of an emphasis on the architecture. But even then, I don't think I've ever seen a company that has both "tech leads" and "lead developers", they just pick one term or the other.
"Lead developers" must be top-notch/expert in certain domains. I'd rather call them "Subject Matter Experts(SME)" than "lead".
Thank you!
This articles just RIGHT vividly describes the mindset change/struggles from my recent experiences. Wish I have had read this earlier so less confusions about my career/daily-works :(
Anyway, by far the one of the best technical leader explanation I have read and is kept in my bookmark now for future reference :)
Thank you Nate! Those are kind words.
All of this! Currently trying to put delegation/improving dev experience into practice...
When on a team that follows agile/scrum, getting pulled into sprint/task management, project planning, etc. also takes a good chunk of time and concentration. Sometimes context switching from that to actual "coding" can be jarring, but finding similar ideas and themes that apply to both can ease the transitions; treating both aspects as two sides of the same coin and leaning into the similarities rather than the differences. It's a feeling to be similar to learning a two-handed instrument where you have to finally put both left/right hand parts together and play the thing! :D
++++1 for "Always keep learning". Ironic that seniority in engineering can also come with increased complacency ("I've been doing X-development for 13+ years, I know it all"). This is literally the industry of fast-paced advancement, and constant learning is the only thing that will help us keep up with it!
Thanks for sharing!
Absolutely! The additional context switching and added responsibility are probably the hardest parts to manage as a new tech lead. It's a growing experience for sure.
I agree with a lot of what you said here. Time management can be quite hard when your responsibilities increase but like any situation you can adapt to it.
Absolutely! The additional context switching and added responsibility are probably the hardest parts to manage as a new tech lead. It's a growing experience for sure.
I agree with a lot of what you said here. Thanks for sharing.
Thanks for reading!
Thank you for sharing
This summarizes my role so well.
I have been working as a tech lead and the information I have just gained from the article will help me to improve my daily work routine. Thank you!
Delegation is such a touchy subject. Glad you delved into it in the linked post.
Great read!
Thank you!
I very much agree with your thoughts. Especially the time management is something that managers need to learn to be successful. There are endless amount things to focus so prioritizing the most valuable ones really makes a difference.
Absolutely! There is too much to do and a never-ending pile of work, so choosing the right things to work on is essential.
Thanks for the words.
Well written!
Because the "Tech Lead" seems to combine many roles, I would like to know, what kind of Team setup or project we should expect. Which roles would be needed as complement?
Also I think the following is the responsibility of the whole team (at least people should be interested doing this): "As a tech lead, you are no longer interested in only your own success. You’re invested in the success of the team as a whole. This means that the needs of the team outweigh the needs of the individual.". But I get the point in sense of accountability.
Thank you!
This is written from the perspective of someone in a normal cross-functional agile engineering team. These teams typically consist of:
Optionally you might also have a dedicated scrum master or QA engineer as part of your team, although the current trend over the last few years seems to be for those roles to be handled by the software engineers.
Hope that helps!
Thanks! Very well written, all clear as and I fully agree with the figure in the tech lead towards the team.
I think it is written from the point of view of a team player, but what about the teach lead towards his supervisor? You definitely had to relate to him/her as well, what did you learn?
Probably another article is needed, here I see only one side of the coin (do not misunderstand, well written and I absolutely agree), but I think the other side is complicated and not clear to everyone, especially when tech leads are the frontier of Tech and after there is only management with the figure of the product owner equivalent to water in the desert
What do you think, do you agree with me?
Thank you for sharing great post 🙌
Thank you for reading!
Very insightful article, thanks!
Thanks for reading!
first post that I actually loved reading on dev.to
thanks ;)
Awesome! Glad I could produce some worthwhile content. :)
Thanyou for sharing its really helpful for understanding the basic foudation and work of Tech Lead...!!
You're welcome! Thanks for reading.
A good one, thx
Glad you enjoyed it!
Very good article 👍, although I think some of the responsibilities you mentioned should be primarily for the scrum master and product owner ☺
Very interested, thank you for sharing!
Thank you for reading!
Spot on. Except for I don’t code that often. Even since I became a tech lead, my role has switched from delivering features to architecture design.