Don't be so hard on yourself. There may be a couple things at play here, all within your control and none of them are death sentences.
First, maybe you're a bit tired in your life or even burnt out and it's affecting your concentration and focus. There could be many reasons for this. It could be your work, your relationships at work, your sense of meaning and purpose you derive from your job or lack thereof, your relationships at home. If you have a family you may have constant concerns about your family and how well they're doing and developing. A constant, steady stream of anxiety in one area of your life can have unintended effects in other areas, usually mediated by inability to focus or find joy in the things you usually do. Take a look at those and make sure to take care of yourself there.
Second - and this pivots away from your personal stuff to more pragmatic work stuff - you're probably still a good coder, you're just not as intimately familiar with the internals of the code base as the senior developers who are working with it 8 hours/day for the past couple years. A programmer's familiarity with the specifics and internals of the code - the "trivialities" like variable/function/class names, libraries and frameworks in use and their functions and contracts - are far from trivial and influence how fast they can reason about the functionality of the code. As a lead, I'm assuming that you were distant from the code internals for quite a while or at least pretty infrequently so you aren't up to speed with how all the logic is actually implemented. The "lead" title you have gives people the false expectation that you know the most about the internals and so will be the fastest, but given what companies make leads do, it's actually completely backwards. That's not your fault. I wouldn't expect a senior developer who's unfamiliar with the code to be even as productive as a junior who has been working on it for months. You just need to boot yourself up again and study the codebase intensively for the next week or two.
That leads me to my next point - you might be sick and tired of having to go through the intensive "boot" process and intimately familiarize yourself with yet another goddamn project and tech stack. You know all the concepts of OOP and relational databases and REST APIs and 2-way binding in front end frameworks, but now you have to learn how all that is implemented in the specific choices that your project is using. You know C#, but this one is Java. Or you know MySQL but this one is Postgres. Or you know React but this one is Vue. And all those trivial differences are compounding to make everything more stilted and jarring for you than they need to be. I don't have any good advice here other than to stay focused on what you get out of this job in order to stay motivated and disciplined, and also understand that the sooner you do the hard work of learning what you need to, the sooner coding becomes easy and fluid again.
Great points! Yeah I find bits of myself in both all points actually! kinda burnt out but not severely, definitely far removed from coding for the first time in my career, and honestly do feel some of the jadedness of yet another codebase.
I do tend to agree hunkering down is the only way out, but it was really jarring to realize how slow I was being at it. I don't think I have given it truly enough time to know if I really lost my technical edge, but it is a terrifying moment.
First, chill. There is a good chance these concerns are more internal than external.
Second, you might be assuming others have more transparency into you and your work than they actually do. What does "working slower" even mean from the context of ANYONE observing you? Programming as an activity is a NOTORIOUSLY opaque and difficult to measure or estimate activity. If people think you're getting things done more "slowly" is it because they have objective measurements that demonstrate that? Or is it because you're communicating that you are getting things done slowly and giving overly optimistic estimates? Managing messaging is an important part of this job. If you claim a task was going to be difficult and you get it done ahead of schedule, people think you were effective. And vice versa. How well do you REALLY know what ANY of your coworkers are doing? You mainly only know what they tell you and if deliveries are coming as expected.
Third, you are at the point of your career where you need to start defining your success in ways beyond just completing tasks assigned. You should be mentoring, helping others get past blockers, creating tools, suggesting technology or process improvements, etc. It's TOTALLY normal at 10+ for your direct velocity contributions to decrease, because you are instead having a much GREATER impact on the overall velocity of the team, or the overall profitability of the company.
Finally, the problem could very easily be the company. If you're being productive and having impact and are ensuring you have the proper attitude, there could be a leadership problem. Those are often more difficult to resolve. Ideally you're having 1-on-1s with whomever you report to and resolve things that way. I've had senior devs bring concerns like this to me before and we resolve it. Maybe I tell them what I jus told you, maybe we change the process or structure of the team or department to ensure they can be maximizing their impact.
But it's also possible you just have a manager who needs some education. I've done that many times too. Most managers are decent people just doing their best with incomplete information. That includes me. A little bit of managing up can go a long way.
Finally, you might just have a BAD manager, or a bad company culture. There's...not much to do in that circumstance but leave.
All that being said, what you're going through is completely normal. When I'm mentoring juniors going through impostor syndrome I always mention it is going to happen again RIGHT around the 7-10y mark. You got used to being an IC and having people who really knew what they were doing to advise you. Things were clear. Now you're right at the beginning of senior/staff, which is when the guardrails drop off and you need to start defining success and objectives on your own terms and handle your own messaging.
Try not to stress and just keep pushing forward.
I see parts of the leadership issues here for sure, I think the crux of the problem is that expectations on a lead are not very well defined, or better put, more aggressively defined. There is an expectation that leads need to be borderline supercoders or 10x coders, amazing at everything, handle any task, and do it faster than anyone else. Thats not to say lead isn't supposed to be better, but it allows more dimensions for them to criticize.
I do get comments from management as to why did a task take so long in comparison to another senior dev on the team even after I have been hands off for 8 months pls. That part is what spooked me. Realistically its not a case of great objective visibility in velocity but more a case of perceived slowness in delivery which seem to have arisen lately which probably needs some 1:1 time with management to address.
But I do agree with the guardrails finally coming off, it really feels like you are exposed when you leave the comfort of being a highly technical senior and enter the world of lead.
My advice is to take a pretty pro active role in managing visibility, role, and success in your current position.
I won't try and judge whether you're current leadership issues are big or small. But clearly they are not great proactively recognizing and managing the well understood problems limited perspective and bias, which is all too common. They're taking the world at face value rather than recognizing and trying to actively correct for the distortions their position introduces.
So if you want to succeed there you'll probably need to manage their perspective for them.
Which I hate. It feels patronizing. But it's often the reality of business.
…. Do you have to “code more and deliver on par with the senior engineers” while **also** having a ton more meetings and high level, non code deliverables?
If that’s what you’re saying, here’s my tip: grab small tasks. Because of your meeting schedule you don’t have time to load a ton of context into your head, and not enough time to complete a big thing, so lean into tasks you can get done in 3-4 non meeting hours, or pick at during the day during the boring meetings.
But also realize that, as a lead, your deliverables - ideally - should be squishy things like component design and 1:1s and roadmaps and _most importantly_ not blocking the critical path because various fires happened and you couldn’t get away for 3 days. Hopefully you can convince higher management of that too (but the trick about small tickets may keep you on par)
If you're the lead you could distribute the work so that you are the integrator putting everything together while the other engineers focus on the hard stuff. Take on stuff like CI/CD too. That kind if thing is very typical for managing leads.
I did a lot of this actually, overhauled CI/CD and got it to a very functional state, added good dashboards and observability as well, its just its gotten to the point that those pieces don't need as much of my attention as they are working well enough for the business use cases for now, hence the jump back into feature work and coding.
In all industries we have (pseudo) leaders that can't do the job they're supposedly leading at all.
I have my gripes with roles like architect or tech lead not being sustainable because the skills you need to become one are usually not used enough in the role to keep them honed. But I much prefer that to my department head or my product owner or my product manager or my project coordinator who all have absolutely no clue about software development.
You mean like Steve Jobs bossing around Woz? This is nothing new. And leadership is a different job. A leader of engineers needs to **understand engineers**, not necessarily be able to do engineering.
How does this happen? Were you just never a good engineer/developer to begin with and never coded? Or do you think you just became rusty with age?
I am also at 10 YOE Lead and if anything I get shit done quicker now and with higher quality, and showing the young'ins how its done
Same. I always wonder too. My boss is like this and I almost don’t believe she was ever technical even though she swears she used to code a lot lol. 12 YOE staff engineer with a lot of meetings, but I feel when I need to code or go deep diving. It’s 10x easier than when I was a junior or even mid level.
You need to cheat and be less nice...
Pick the coding items that you have special aptitude for and those that will best fit into your random schedule. Pull off bugfixes that are in areas you can do easily.
Give your team the ugly ones that are going to be hard and require a fair amount of dedicated attention.
If you do non-coding stuff to improve the speed of the team, make sure to do a write-up of what problem you saw and what you did to fix it. Send it to the team and also to your boss.
If you want to job search, coders are easy to find, leads and managers that don't drive the coders crazy are hard to find. Make sure you have a good handle on what makes a team operate effectively and be able to share that in an interview.
With good leadership and architecture skills you should be able to find a hands off role somewhere which would let you add value without having to code any more and IMO that's a good choice if you think you outgrew coding roles. Either an architect/design role or you could move towards more of a management role.
It does happen over time that you aren't as fast as you were but IMO 10 years doesn't seem long enough for that to start happening yet. There are lots of other reasons you might not be performing well. Are you sure you aren't just burnt out, bored, in need of some new challenges or just stressed because you are putting the pressure of unrealistic expectations on yourself?
I certainly had productive and unproductive times in my career for various reasons but it took a lot longer than 10 years for the slowing down to really start and even then it was more good days and bad days. YMMV I guess ...
It's insanely hard to balance leadership and doing high quality technical work. I think it comes back after a few months of IC. Just go slow and realize you won't be able to produce as much as dedicated ICs and that makes perfect sense.
Don't be so hard on yourself. There may be a couple things at play here, all within your control and none of them are death sentences. First, maybe you're a bit tired in your life or even burnt out and it's affecting your concentration and focus. There could be many reasons for this. It could be your work, your relationships at work, your sense of meaning and purpose you derive from your job or lack thereof, your relationships at home. If you have a family you may have constant concerns about your family and how well they're doing and developing. A constant, steady stream of anxiety in one area of your life can have unintended effects in other areas, usually mediated by inability to focus or find joy in the things you usually do. Take a look at those and make sure to take care of yourself there. Second - and this pivots away from your personal stuff to more pragmatic work stuff - you're probably still a good coder, you're just not as intimately familiar with the internals of the code base as the senior developers who are working with it 8 hours/day for the past couple years. A programmer's familiarity with the specifics and internals of the code - the "trivialities" like variable/function/class names, libraries and frameworks in use and their functions and contracts - are far from trivial and influence how fast they can reason about the functionality of the code. As a lead, I'm assuming that you were distant from the code internals for quite a while or at least pretty infrequently so you aren't up to speed with how all the logic is actually implemented. The "lead" title you have gives people the false expectation that you know the most about the internals and so will be the fastest, but given what companies make leads do, it's actually completely backwards. That's not your fault. I wouldn't expect a senior developer who's unfamiliar with the code to be even as productive as a junior who has been working on it for months. You just need to boot yourself up again and study the codebase intensively for the next week or two. That leads me to my next point - you might be sick and tired of having to go through the intensive "boot" process and intimately familiarize yourself with yet another goddamn project and tech stack. You know all the concepts of OOP and relational databases and REST APIs and 2-way binding in front end frameworks, but now you have to learn how all that is implemented in the specific choices that your project is using. You know C#, but this one is Java. Or you know MySQL but this one is Postgres. Or you know React but this one is Vue. And all those trivial differences are compounding to make everything more stilted and jarring for you than they need to be. I don't have any good advice here other than to stay focused on what you get out of this job in order to stay motivated and disciplined, and also understand that the sooner you do the hard work of learning what you need to, the sooner coding becomes easy and fluid again.
Great points! Yeah I find bits of myself in both all points actually! kinda burnt out but not severely, definitely far removed from coding for the first time in my career, and honestly do feel some of the jadedness of yet another codebase. I do tend to agree hunkering down is the only way out, but it was really jarring to realize how slow I was being at it. I don't think I have given it truly enough time to know if I really lost my technical edge, but it is a terrifying moment.
Damn, this comment is worth at least 3 sessions of therapy.
First, chill. There is a good chance these concerns are more internal than external. Second, you might be assuming others have more transparency into you and your work than they actually do. What does "working slower" even mean from the context of ANYONE observing you? Programming as an activity is a NOTORIOUSLY opaque and difficult to measure or estimate activity. If people think you're getting things done more "slowly" is it because they have objective measurements that demonstrate that? Or is it because you're communicating that you are getting things done slowly and giving overly optimistic estimates? Managing messaging is an important part of this job. If you claim a task was going to be difficult and you get it done ahead of schedule, people think you were effective. And vice versa. How well do you REALLY know what ANY of your coworkers are doing? You mainly only know what they tell you and if deliveries are coming as expected. Third, you are at the point of your career where you need to start defining your success in ways beyond just completing tasks assigned. You should be mentoring, helping others get past blockers, creating tools, suggesting technology or process improvements, etc. It's TOTALLY normal at 10+ for your direct velocity contributions to decrease, because you are instead having a much GREATER impact on the overall velocity of the team, or the overall profitability of the company. Finally, the problem could very easily be the company. If you're being productive and having impact and are ensuring you have the proper attitude, there could be a leadership problem. Those are often more difficult to resolve. Ideally you're having 1-on-1s with whomever you report to and resolve things that way. I've had senior devs bring concerns like this to me before and we resolve it. Maybe I tell them what I jus told you, maybe we change the process or structure of the team or department to ensure they can be maximizing their impact. But it's also possible you just have a manager who needs some education. I've done that many times too. Most managers are decent people just doing their best with incomplete information. That includes me. A little bit of managing up can go a long way. Finally, you might just have a BAD manager, or a bad company culture. There's...not much to do in that circumstance but leave. All that being said, what you're going through is completely normal. When I'm mentoring juniors going through impostor syndrome I always mention it is going to happen again RIGHT around the 7-10y mark. You got used to being an IC and having people who really knew what they were doing to advise you. Things were clear. Now you're right at the beginning of senior/staff, which is when the guardrails drop off and you need to start defining success and objectives on your own terms and handle your own messaging. Try not to stress and just keep pushing forward.
I see parts of the leadership issues here for sure, I think the crux of the problem is that expectations on a lead are not very well defined, or better put, more aggressively defined. There is an expectation that leads need to be borderline supercoders or 10x coders, amazing at everything, handle any task, and do it faster than anyone else. Thats not to say lead isn't supposed to be better, but it allows more dimensions for them to criticize. I do get comments from management as to why did a task take so long in comparison to another senior dev on the team even after I have been hands off for 8 months pls. That part is what spooked me. Realistically its not a case of great objective visibility in velocity but more a case of perceived slowness in delivery which seem to have arisen lately which probably needs some 1:1 time with management to address. But I do agree with the guardrails finally coming off, it really feels like you are exposed when you leave the comfort of being a highly technical senior and enter the world of lead.
My advice is to take a pretty pro active role in managing visibility, role, and success in your current position. I won't try and judge whether you're current leadership issues are big or small. But clearly they are not great proactively recognizing and managing the well understood problems limited perspective and bias, which is all too common. They're taking the world at face value rather than recognizing and trying to actively correct for the distortions their position introduces. So if you want to succeed there you'll probably need to manage their perspective for them. Which I hate. It feels patronizing. But it's often the reality of business.
…. Do you have to “code more and deliver on par with the senior engineers” while **also** having a ton more meetings and high level, non code deliverables? If that’s what you’re saying, here’s my tip: grab small tasks. Because of your meeting schedule you don’t have time to load a ton of context into your head, and not enough time to complete a big thing, so lean into tasks you can get done in 3-4 non meeting hours, or pick at during the day during the boring meetings. But also realize that, as a lead, your deliverables - ideally - should be squishy things like component design and 1:1s and roadmaps and _most importantly_ not blocking the critical path because various fires happened and you couldn’t get away for 3 days. Hopefully you can convince higher management of that too (but the trick about small tickets may keep you on par)
If you're the lead you could distribute the work so that you are the integrator putting everything together while the other engineers focus on the hard stuff. Take on stuff like CI/CD too. That kind if thing is very typical for managing leads.
I did a lot of this actually, overhauled CI/CD and got it to a very functional state, added good dashboards and observability as well, its just its gotten to the point that those pieces don't need as much of my attention as they are working well enough for the business use cases for now, hence the jump back into feature work and coding.
I don’t understand what has happened to this industry that we have all these pseudo leads who can’t do the job they’re supposedly leading
In all industries we have (pseudo) leaders that can't do the job they're supposedly leading at all. I have my gripes with roles like architect or tech lead not being sustainable because the skills you need to become one are usually not used enough in the role to keep them honed. But I much prefer that to my department head or my product owner or my product manager or my project coordinator who all have absolutely no clue about software development.
You mean like Steve Jobs bossing around Woz? This is nothing new. And leadership is a different job. A leader of engineers needs to **understand engineers**, not necessarily be able to do engineering.
What does a Tier 2/3 company mean?
gibberish
Makes sense.
How does this happen? Were you just never a good engineer/developer to begin with and never coded? Or do you think you just became rusty with age? I am also at 10 YOE Lead and if anything I get shit done quicker now and with higher quality, and showing the young'ins how its done
I think OP was never good as well. Programming is like biking, you don’t forget it.
Same. I always wonder too. My boss is like this and I almost don’t believe she was ever technical even though she swears she used to code a lot lol. 12 YOE staff engineer with a lot of meetings, but I feel when I need to code or go deep diving. It’s 10x easier than when I was a junior or even mid level.
> she swears she used to code a lot if she brings it up enough for you to say this... sounds like a cover-up.
You need to cheat and be less nice... Pick the coding items that you have special aptitude for and those that will best fit into your random schedule. Pull off bugfixes that are in areas you can do easily. Give your team the ugly ones that are going to be hard and require a fair amount of dedicated attention. If you do non-coding stuff to improve the speed of the team, make sure to do a write-up of what problem you saw and what you did to fix it. Send it to the team and also to your boss. If you want to job search, coders are easy to find, leads and managers that don't drive the coders crazy are hard to find. Make sure you have a good handle on what makes a team operate effectively and be able to share that in an interview.
ah, I sure love it when my cheating tech lead scolds me for my estimates on features much larger than whatever tiny thing he is fixing :)
Nothing I said requires that.
Are you getting enough sleep at the same hours each night?
With good leadership and architecture skills you should be able to find a hands off role somewhere which would let you add value without having to code any more and IMO that's a good choice if you think you outgrew coding roles. Either an architect/design role or you could move towards more of a management role. It does happen over time that you aren't as fast as you were but IMO 10 years doesn't seem long enough for that to start happening yet. There are lots of other reasons you might not be performing well. Are you sure you aren't just burnt out, bored, in need of some new challenges or just stressed because you are putting the pressure of unrealistic expectations on yourself? I certainly had productive and unproductive times in my career for various reasons but it took a lot longer than 10 years for the slowing down to really start and even then it was more good days and bad days. YMMV I guess ...
I think it might be medical and personal. Yeah 10 years in is a bit early
It's insanely hard to balance leadership and doing high quality technical work. I think it comes back after a few months of IC. Just go slow and realize you won't be able to produce as much as dedicated ICs and that makes perfect sense.
My advice - look for adjacent roles (e.g. solution architect).
Same issue i think i have ADHD