As a Tech Lead I feel more like a manager and I hate it

Question

6 months ago, I became a Tech Lead, previously I was a Senior Developer.

My team has around 20 members (including QA, UX and Devs).

After I became a Tech Lead my work has become more like managing than anything else, I don’t do more code and just a little technical stuff (what is funny when you consider the name of the position).

All I do is understand requisites and help developers to understand either, follow the “process” (that is really massive and takes a lot of effort and time), do diagrams and participate in a bunch of meetings.

Sometimes I help Junior developers to understand some concepts, but this is the only “code” that I touch, besides help with API specs - things like this. Most of the work is just things that I really hate because I feel like I’m not learning anything that I consider useful.

I need to code in my free time and study other stuffs, so I can feel a bit updated, this is making me feel very sad. I’m scared that in some time I will become worthless, I will be that guys that just lead and don’t know nothing about code, new technologies and so on.

But when I research about the “developer career path” I always find the “Tech Lead” role in the steps to earn more money, and then I think that I can’t go back to being a developer, as it would make me regress.

Is there a way out of this “destiny”? How can I stay updated and don’t become obsolete to the market?

---

Edit: Thank you, all answers helped me a lot. I will try to use 50% of my time to code as a Tech Lead and make clear to my managers that I want to be useful more like an individual contributor than a lead. However I can use the other 50% of my time to teach and do some docs too, no problem. If that doesn't work I will search for a place where I can do what I like the most: to code.

Answer 1

Yes indeed you have discovered why software development in general is not a very competitive environment: most developers love their profession (not their specific job, but that they are paid to develop software) and would not want to be promoted into a management position.

As far as a "career" goes, you have to "advance" into management. Either project management or people management or tech management, but management. Because short of the owner of the whole thing, a "career" ends in being CPO, CEO or CTO.

Now, I put "career" in quotes, because that is something that other people think you should have. I have never seen a developer coming up with the goal to move out of software development as a career goal. Sure, some may find that after a while they enjoy something else more, but unlike other jobs, where you know when you start the job that you don't want to do that shitty job forever and it's just a necessary step on the ladder, software development is what most in our job actually want. Not a necessary temporary evil on the way to a great job, but a great job in itself. So competition for the next step on the career ladder is incredibly low compared to other professions.

I have been a department manager, tech lead, architect, project manager, product owner and scrum master. Quite frankly because I cannot keep my mouth shut while developing software and I want to make the job easier for us developers and if you have good ideas and plans how to do that in the company and can sell them, you end up in one of those roles. But every time I look for a new job, I look to be a software developer. That is what I love. And I don't think you can make a good plan for improvements if you haven't experienced the actual process yourself (assuming that you only work there because it is a good job to start with, everybody can improve a shitshow).

I can do all those things and I'm more than happy to make use of those skills for my employer in a temporary capacity. For example I'm more than happy to stand in for others on holiday, maternity leave or any other temporary capacity. I think that is an excellent selling point to hire me. But as a long term job that I intend to keep for years... I want to develop software on a level that requires a debugger, not a planning tool.

So yes, you have found a truth in software development or actually professional life in general: leading roles have nothing in common with the actual role. You will not open an IDE or debugger as anything that contains lead or manager in the title, just the same as the lead or manager of sewer cleaners will never see a sewer from the inside again. For the later that is a great step forward, for us developers it feels like a big step back.

Only you can decide if a little more money and prestige can buy you so much happiness that you can leave development behind with a smile. Some can. Many don't think it's worth it. And don't be afraid to take a step "back". There is no official direction here. Only people that hate their jobs see "direction" on the ladder. The important part is whether you make enough money to support you and a potential family. In any western country, the answer to that should be "yes, being a developer pays the bills easily". And as a second priority, you should be happy with what you do. You would need to earn a ton of money to compensate for being unhappy 8-10 hours any working day. That is a huge part of your life.

Somebody else, I don't remember who, compared it this way: if you had kids, what father would they probably deserve? The father who comes home happy, plays with them and when they are 16, buys them a new bike for their birthday, or the father, who comes home angry every day, is generally grumpy because they don't like the idea of going back to work tomorrow, but can buy them a car when they are old enough?

It's your decision.

Answer 2

Is there a way out of this “destiny”? How can I stay updated and don’t become obsolete to the market?

The role of Tech Lead varies from company to company (and sometimes from team to team within a company). I have worked in some companies where the Tech Lead was mostly a manager. And I have worked in some companies where the Tech Lead was basically just a super developer.

You just need to find a job where the Tech Lead role is more tech and less lead. Those jobs exist, but perhaps not at your company.

While interviewing, make sure you dig in with enough questions to learn the expectations of the job. You may ask to speak with some future peer Tech Leads if the company has some. See what a "day in the life" is like for them.

Answer 3

What you have to realize is that in general, your value to an organization multiplies when you can teach and lead more people. You can only get so much done coding, as opposed to teaching 20 people how to code right. So even on the “technical track,” many promotions and such have various sorts of mentoring and technical leadership requirements.

You can:

1. Just take “coding only” jobs. You can make plenty of money doing that at e.g. FAANGs. You will still be some variant on a senior developer but making more $ over time. Or at startups, but there you’re not going to get money, just share “lottery tickets.” But when looking for jobs, clarify you are interested in coding not leading. You won’t get the top jobs this way (no one in the world making $1M+ is making it because they know the newest programming language) but you can get good jobs.
2. Take lead and tech roles in alternation to keep your technical edge sharp. Or in smaller orgs where more of the work is done by everyone and there’s less pure leadership work to be done.
3. Go into consulting, where you can go far just getting the job done.

Eventually you will either top out and just say “I want to code and make 150-200k/year for the rest of my life,” which is a fine life, or you’ll mature into leadership.

Answer 4

Companies vary significantly in how far you can go as an individual contributor. In some places, there are a lot of strictly technical roles above the "senior developer" level. They include various flavors of "principal engineer" or "architect", etc.

No matter what happens, as you advance your job will become less about directly writing code. On a purely technical track, the job focuses more on designing software and systems, improving processes, making technological decisions, etc. You need to leverage your expertise by delegating and influencing instead of doing everything yourself. Being able to improve something bigger than your own personal work is what makes you worth more money.

If you are very good at writing code, though, then it can still be productive to spend a lot of time doing it. At no point in my career (and I'm pretty old) have I spent less than 30% of my time coding.

If you really don't want to follow a management track, then maybe you should start looking for a job at a company that offers more advancement for individual contributors. It will probably work out better for you if you do it now, when you're not in a hurry.

Answer 5

These 2 quotes may help guide you.

Steve Wozniak (Apple):

To this day I'll stay at the bottom of the org chart as an engineer because that is where I want to be.

Mark Twain (Author):

Find a job you enjoy doing, and you will never have to work a day in your life.

If you loved development, and if you tried and don't enjoy another career path, then there's absolutely no shame in pursuing the career you like more: development!

EDIT: found the video of Woz

Answer 6

Tech lead can be an awesome job. You just need to make it that way.

I don’t do more code and just a little technical stuff (what is funny when you consider the name of the position).

You are the one who owns the technical bottom line. If you have to own it, you get to run it the way you want. A key part of this is deciding which activities are worth a tech lead's time and which can be delegated. You should only be doing things that are (1) important and (2) can't be done by anyone else. Usually these are also the things that are the most fun.

All I do is understand requisites and help developers to understand either, follow the “process” (that is really massive and takes a lot of effort and time), do diagrams and participate in a bunch of meetings.

You are far too important to the organization to be doing busywork. Delegate. If your team needs someone to explain requirements, see if you can get a Business Analyst on the team, even 0.5 FTE can make a big difference, and sometimes they can fall on the business side of the organization, meaning it doesn't hit your team's budget. For boilerplate paperwork like change request forms, assign those to QA engineers, who will do a thorough job, and are generally well-suited for repetitive tasks. One of your more clever QA might even figure out a way to automate them.

Sometimes I help Junior developers to understand some concepts, but this is the only “code” that I touch, besides help with API specs - things like this.

Your experience as a coder is extremely valuable. A company's best coder is sometimes ten times as productive as its most junior. You can set aside time for the most important (i.e. the most interesting) coding tasks. If you don't have time, declare a "flow day" on Wednesdays during which there are no meetings and everybody has time to focus on coding-- including you. It's for the good of the team.

Most of the work is just things that I really hate because I feel like I’m not learning anything that I consider useful.

I need to code in my free time and study other stuffs, so I can feel a bit updated, this is making me feel very sad. I’m scared that in some time I will become worthless, I will be that guys that just lead and don’t know nothing about code, new technologies and so on.

Is there a way out of this “destiny”? How can I stay updated and don’t become obsolete to the market?

The answer to this is simple. You have a team. If there is a new technology that may be of value to the team, assign a developer to research it and give a presentation. If it's really interesting you can ask him to lead a technical session or two. Some organizations do this kind of thing as a "brown bag" lunch activity.

My point is-- the tech lead is the heart of the team. And a chief part of that is your own productivity and your own happiness. From your position, you can exert a lot of control over it.

Answer 7

Rethink your concept of engineering

As a techie, you're naturally focussed on producing good code. But...

As a senior engineer, you're actually focussed on producing a good design. The code could be any appropriate language you like to implement that design, and if you moved to a new place then you could redo that design with their favoured language. C++, C#, Java, whatever, the concepts remain the same. Pretty much the definition of a senior engineer is recognising this divide and not being hung up on any particular language. With that kind of experience, I would expect a senior engineer to pick up any language to a functional level in under a fortnight anyway. What matters are the concepts, not the implementation.

And then you take the step up to tech lead. At this point, you aren't producing a good design for your individual component. Instead, you're producing a good architectural design within which your engineers can produce their own designs for components. You're setting coding standards and design standards to help them achieve this. You're making sure they have good requirements, and all that good stuff.

Your engineering tool now is not a design, it's a team. Your job now is to engineer your team environment to achieve results that work efficiently and robustly, in the same way as your design job was to achieve code that worked efficiently and robustly. You're still looking for bugs, except now the bugs are things which stop the team working instead of just stopping code working.

This is a combination of systems engineering and process engineering. Both are well-recognized fields of expertise, and you can learn how to do both of them well.

And those who can, teach

How many hours do you have in a day? Even if your worst team member is only a quarter as fast as you, a team of 8 people will still double your output. If you can use your time to get them half as fast as you, they'll get 4x your output for the input of 1x your time. That's a win. That's what you're there for.

Is this for you?

If you have no interest in mentoring other people, and you don't want to step up to the next level of expertise, that's fine. You are currently at the level you can work with, and you will remain at that level and no higher for the rest of your working life. That's not a bad thing - I know a few engineers who've made that call because the extra responsibility would affect their family time. But then you need to make peace with the fact that you aren't going anywhere further than this, because there isn't a technical career path beyond this.

Or to be more accurate, a very few technical career paths exist for a deep specialisation in some aspect of engineering. You can't get there just with coding, because no deep specialisation exists just in that. And even then, that specialisation will involve most of your time being spent mentoring other people, not actually doing it yourself.

Answer 8

Unless you are overwhelmed from just managing the project and team, I didn't really get what is stopping you from coding. I can think of 2 ways you can also code while managing your team:

1. Assign some coding work to yourself too.
2. Review and refactor the code of your junior developers.

(The second option would be better as you will learn how your developers think, the junior developer can also learn from you and you will get a good idea of the ability of the developers that will greatly help you delegate tasks to the right person thus making your job easier).

Answer 9

Other answers are good, I just want to address this specific point:

I’m scared that in some time I will become worthless, I will be that guys that just lead and don’t know nothing about code, new technologies and so on.

Consider the idea that scarcity increases the value of something. In software development, most engineers want to keep their heads down and write code, without having to interact with people. If you are one of the few engineers who can deal with interviewing, employee growth, performance reviews, etc. you are the opposite of worthless, you are more valuable.

Also consider the difference in technical skills vs human skills:

• technical skills require constant updates to an ever-changing landscape of technologies
• human nature is relatively constant accross time, so your people skills will be timeless

If you're not up for this and would prefer to keep your head down, put a price on it. i.e. How much would someone have to pay you to not code and to deal with people? For me, this was a high dollar amount, but it was the right amount for my boss, and I am now getting paid (more) to mentor people. It becomes easier over time, just like every other skill.

Answer 10

Initial days will be exactly like you have said. See if the below plan makes sense to you.

1. While you assign/ explain tasks raise the bar of expectation from the dev. Example: Ask them to check how your competitor is doing the same thing. Ask them to brain storm and come up with solutions. You just be the devils advocate. Keep showing them holes in their solution.
2. Now what happens is you will learn more than what you would have, if you had coded things yourself.
3. Once they come up with solutions you will have visibility into bigger problems to solve. Example: what if somebody resigns. Or single point of failure in the system.
4. Eventually you will have a handful of trustworthy people to whom you can delegate a lot of work.

There is a whole set of world outside just coding. When you read the software documentation you will discover so-many new features, which otherwise you may not discover if you just code.

Answer 11

As someone who hit this issue, and beat it, in a parallel sphere of work, this is my hastily compiled list of top tips..... hope it helps!!

Companies differ a lot, and there are other ways to build a career path than the one you have in mind, that may suit you far better.

I moved early on, from a large to a smaller company (SME).

A large company needs a manager who just manages. A smaller company on a good niche, needs a manager who is also a generalist and "hands on" part of the team. You end up being Head of Tech, with a team of 5-10 not teams of 20 -200. And the payoff is HUGE, if its a good professional company and you get on with your manager (essential, focus on this in deciding acceptance).

Its very well paid because you're in effect either the CTO, or the head of that team directly under CTO. You get a lot of say on the product and approach, priorities, innovations, the choices what to implement, and how to pilot and implement them. So you can ensure its done right. But that's not really the main part of the job you're doing. You still need to be out there coding; on a small team it's not going to write or debug itself. But also, as 2nd in the tech team, your CTO handles much of the team admin side, your role is much more to make code happen - and not just by making sure others code while you executive.

Smaller but thriving companies might be getting going, or not yet big enough to need dedicated senior tech managers, or an entrepreneurial startup looking for someone competent to make their product work, and prepared to start with a team of 3 now and a team of 15 in 4 years.

I also after that, switched to a niche area, and worked as a contractor

Managing isn't the only way to get high pay. A niche is another way. Examples in tech might include for example, IT security. Cobol. Custom SAP extensions. Databases. High availability. Specialising in a critical product area like medical software or airline software. Troubleshooting. Rescuing projects in need of "no expenses saved" intense coding work for some crucial deadline or market need. Upgrading older code to modern code. There's probably many niches that pay you well, to be hands on in front of a computer. Find a specialist niche that centres on the coding life you want.

Such roles can be run as an employee. But also consider contracting, or even starting your own thing. If you run your own tasks and clock, you get to do the work you love, and the only question is finding places needing high level skills in things you want to do anyway, who are prepared to pay for it. For which, see above.

If successful, then you get to hire someone else or outsource the stuff you don't need, or do a partnership with some other small operation, that lets you grow and still focus on the coding you love.

TL;DR - more than one way to skin a cat. Your present type of company may have become over time, a misfit for your desired work life.

Answer 12

If I were you I would have a frank conversation with my manager:

I wanted to move to the next level because I wanted a higher salary. But the nature of the work has changed and I’m really not enjoying it. I would like to spend more time coding, and I feel like my level of productivity justifies the higher salary, even if I’m not a “force multiplier”. Can you help me find a way to go back to doing my best work without it feeling like a demotion?

A good manager will find a way to exploit your strengths and interests. Some possible outcomes:

• you keep the title of “Lead” with more emphasis on leading by example and being a subject matter expert
• there’s another title / job description that fits you better, even if you’re the first person in the company to hold it
• you can switch back to your old title without taking a pay cut.

This conversation may come as a relief to your manager. It’s possible they already knew you weren’t going to like the new role, but you’ve earned the opportunity, it’s not their place to tell you what you do and don’t like, and they don’t want to lose you.

If the conversation doesn’t go well it’s probably time to look for another job.

Answer 13

One of the things that should be the job of a tech lead is to steer the direction of the technology stack. That can be different from enterprise architecture, because EA is more about the big picture, but it is just as important.

Take that recent excitement about log4j. Does your organization use it? And who made that decision? Are all your services/servers using it, or only some, or none? If not, what else are they using?

Such a decision could be left to (senior) engineers. But if there is more than one, who leads?

Answer 14

Do you think you need to keep practising your programming skills to do a good job as a tech lead? If so there's no shame in carving out a fraction of your time for development. Treat it as sacred as anything else you feel like you "must" do.

If this leaves too little time for all the other tasks people expect of you, the problem is not with your time allocation but with their expectations. Work to fix that.

It is your job to allocate your time in ways you think is optimal for your long-term performance. That doesn't change when you become a tech lead -- if anything, it becomes even more important. Don't let other people and processes allocate your time for you. They tend to do an awful job of it.

Answer 15

If you want to have a technical leadership role and at the same time, still wants to be hands on, you could consider the role of a Software Architect. The definition and interpretation of this role varies across companies, still in general, it is seen as very positive if an Architect could still code.

The key difference of the role of Architect with that of the role of a Tech. manager is that an Architect is not a people manager. Still, if you are really senior, there will be an expectation that you behave like a grown up and you may have to guide, coach and mentor juniors. Also you need to handle company politics and stakeholders well, but this is the price you pay for higher salary that comes with this title.

But you can code either by prototyping new use-cases or even by implementing new features. But keep in mind that you better be good at it, otherwise developers hate it.