So the context is that I was recently assigned as Tech Lead for a POD, which holds both frontend and backend capabilities. However in my previous working experience, I think my expertise is 80% backend and 20% frontend (had not written frontend code for several years). Now my team needs to adopt React and Vue as major frontend tech stacks.

To what degree should I push myself to learn these, to make later cooperation between my frontend colleagues and myself smoother, as well as to make a better product?

  • 6
    What is a "POD" or is it not relevant to the question? Commented Nov 10, 2021 at 16:18
  • 1
    Depends on what "tech lead" means in your company/team and to which degree people depend on you to make or supervise frontend-related decisions. Commented Nov 10, 2021 at 16:43

5 Answers 5


In what degree should I push myself to learn these,...

There is no predefined number which can be used here. As a tech lead, based on your responsibilities, you need to visualize the requirements, analyze the solution and (sometimes) implement it. Whatever amount of mastery you need on the technologies/domain to perform this, you need to achieve that level.

I have seen people considering themselves learners solving the trickiest problems and people calling themselves masters not being able to fix a minor bug so these terminologies do not matter. You need to have clear idea and concepts, so that you can understand, think and solve problems. That's it.


You shouldn't need to learn it in depth, but you need to learn it will enough to:

  • Make important decisions about code design
  • Recognize when code isn't robust or can cause issues.
  • Guide your team on what frameworks to use or how to approach building a feature-set.

Obviously more knowledge will be great, so I wouldn't argue you can just achieve this and then sit back and do nothing, but I'd argue that if you can check those three points off, you know the technology well enough to be able to do your job properly. While further knowledge would be nice, I think you'll find it won't vastly improve your ability to be a tech lead and that gaining more knowledge is nice-to-have.


Focus on the business problems

As a full-stack developer myself, sometimes frameworks are chosen out of "coolness" and trying to be "modern", while neglecting basic business practice of solving actual problems.

Software development is complex. If your stacks do not solve any actual problems that your developers have, then you're only adding to the pile.

For you, really grill the higher ups on what business problems you are solving with the frameworks and evaluate two things:

  1. Does the stack actually do what it needs to do?
  2. Are the devs using the stack properly to solve those problems?

I'll take an anecdotal example from an actual web project I inherited... the project uses an MVC framework, but at first look, it was obvious the developer didn't know how to use MVC frameworks at all. Instead of splitting the business logic from the presentation layer and having the Controller and Model handle it, the guy got the bright idea of stringifying all his objects into JSON, then passing that super fat JSON object between the pages via Javascript AJAX. It functionally works, but that's not how an MVC framework is suppose to be used and added no value to the project at all.


This is how i do. Lead the team from the front. You be in the front line.

  1. You create the initial project setup etc. Google. Do the work.
  2. As requirements pour in, you will know if you need additional skills. If yes. Then you pick up the usecase and implement it your self. If NO, then dont work on it.

As tech lead you need to be clear on the concepts. Otherwise you cant participate in debates. Suddenly people resign. You should be ale to debug (even if it takes time) your self.


It really depends on what the business expects from you. Most of the time they just want you to solve problems regarding IT. It can be through calling the right people for domain info, sometimes to train and help colleagues, make decisions regarding architecture etc.

In this case you might solve the problem, not by trying to catch up yourself but by finding people in your team that are more senior in this field and ask them to train more junior colleagues. Or what about organizing a training / course for the team?

Of course to make informed decisions you need to learn these subjects as well, than one could say: to a degree that you can understand what you choose and why.

Not the answer you're looking for? Browse other questions tagged .