Ask HN: How to deal with inexperienced/unqualified technical lead?
14 comments
I see only one good solution:
The dev lead was the first technical person, so he knows the history and understands the business needs best.
So convince the founders that he should become the product manager (work on deciding features), but stop coding. Not get involved in the how (technical decisions), but only the why (what to build).
The dev lead was the first technical person, so he knows the history and understands the business needs best.
So convince the founders that he should become the product manager (work on deciding features), but stop coding. Not get involved in the how (technical decisions), but only the why (what to build).
This is something I can agree with. I worked with someone like OP describes but with the added side effect that he had management's ear by complaining about every developer without their knowledge. I left and have no regrets, but I agree that sometimes people could bring value by being involved in non-technical product decisions
You want to get the guy out of there, and you don't want to appear petty, jealous, or malicious. The solution's simple: help him get a better job. That way your motives are pure.
Internally, tell the founders he needs to be promoted to a more managerial role. It's a bizarre request, but I think if they hear it from the whole team, they'll take the hint. You're not calling for him to be fired, so when he gets wind of it, he'll thank you for it.
Externally, reach out to a few recruiters you know. Talk up his credentials, estimate how much he's making, and try to get a recruiter to entice him into leaving (for a higher-paying job). You can even cloak it in an entrepreneurial desire to get the kickback for a referral in case he suspects something.
Honey, not vinegar.
Internally, tell the founders he needs to be promoted to a more managerial role. It's a bizarre request, but I think if they hear it from the whole team, they'll take the hint. You're not calling for him to be fired, so when he gets wind of it, he'll thank you for it.
Externally, reach out to a few recruiters you know. Talk up his credentials, estimate how much he's making, and try to get a recruiter to entice him into leaving (for a higher-paying job). You can even cloak it in an entrepreneurial desire to get the kickback for a referral in case he suspects something.
Honey, not vinegar.
That's a tough one. I think you're probably doing the right thing by leaving, but I think more good could come from sharing your grievances with the engineering lead when you leave rather than the founder. If he has gone from being an engineer to managing with no prior experience, it could be he is struggling with learning how to properly manage a team.
Basically what I'm getting at is give the guy a chance before you go scorched-earth and try to ruin him. From what you've said it seems like he is willing to listen, and you gain nothing if you're severing your relationship with the company anyways.
Basically what I'm getting at is give the guy a chance before you go scorched-earth and try to ruin him. From what you've said it seems like he is willing to listen, and you gain nothing if you're severing your relationship with the company anyways.
We had such a tech lead. He had never designed a system until this one. He used the very latest techniques and technologies. He estimated the contract and recommended a fixed cost 5 month contract with 5 people. The project was terminated after 18 months with 10 people full time. All 27 developers from the company were fired and within a year the company went under.
If a company can go bust just because a lead developer gave a bad estimate(not uncommon) there is something else deeply wrong at that company.
You like the company, and would want the tools get better. I bet the lead can vouch the same. But the tools break too often.
Track it! And make it visible to everyone both devs and non-devs. Especially non-devs, as they are likely the users to face the problem.
I would propose/demo an issue tracking system, that would quantify the failures, and the amount of time it takes to resolve. It's on the 'best practices' list and is familiar to all, your lead may indeed agree.
It's a team effort, eventually the team would come to realize how to proceed - rewrite or not, reshuffle the lead or something else.
Make it visible for everyone, then your're not alone. BTW, management loves when things are tracked, as it makes their blame job easier, but it is a good team tool too.
Track it! And make it visible to everyone both devs and non-devs. Especially non-devs, as they are likely the users to face the problem.
I would propose/demo an issue tracking system, that would quantify the failures, and the amount of time it takes to resolve. It's on the 'best practices' list and is familiar to all, your lead may indeed agree.
It's a team effort, eventually the team would come to realize how to proceed - rewrite or not, reshuffle the lead or something else.
Make it visible for everyone, then your're not alone. BTW, management loves when things are tracked, as it makes their blame job easier, but it is a good team tool too.
Usually it is good to have second side of story. We can not, so, let me be the devil's advocate.
>There have been numerous technical arguments where it is all of the other engineers against the lead, which go nowhere.
If you can not convince lead, may be it is not her fault?
>The code the lead has written is also atrocious
It is hard to agree on quality of code between several programmers. It is easy to agree on quality of OTHER guy's code.
Two biases in-place here:
- You work only on problem code, not well-functioning one
- https://en.wikipedia.org/wiki/Fundamental_attribution_error
>, and if I didn't know better I would say it is actively malicious (in terms of nobody else is able to maintain it).
Skill you lack - handling problem code
>However, the non-technical side of the company is very frustrated with how often everything breaks
This is a real problem, here I can not indulge her
>I am trying to fix things but the codebase is not in a great condition and the lead has no interest in making it better.
No interest or no resources?
> Non-technical folks have talked to me about just doing a rewrite, since there really isn't much code, but the lead will not even consider the idea.
Joel calls it "single worst strategic mistake" in https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Code amount is not a good characteristic of system complexity. May be buisness people underestimate amout of effort required.
(Edit):Fixed EOLs
>There have been numerous technical arguments where it is all of the other engineers against the lead, which go nowhere.
If you can not convince lead, may be it is not her fault?
>The code the lead has written is also atrocious
It is hard to agree on quality of code between several programmers. It is easy to agree on quality of OTHER guy's code.
Two biases in-place here:
- You work only on problem code, not well-functioning one
- https://en.wikipedia.org/wiki/Fundamental_attribution_error
>, and if I didn't know better I would say it is actively malicious (in terms of nobody else is able to maintain it).
Skill you lack - handling problem code
>However, the non-technical side of the company is very frustrated with how often everything breaks
This is a real problem, here I can not indulge her
>I am trying to fix things but the codebase is not in a great condition and the lead has no interest in making it better.
No interest or no resources?
> Non-technical folks have talked to me about just doing a rewrite, since there really isn't much code, but the lead will not even consider the idea.
Joel calls it "single worst strategic mistake" in https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Code amount is not a good characteristic of system complexity. May be buisness people underestimate amout of effort required.
(Edit):Fixed EOLs
Honesty will bring a resolution. Maybe not the one you want, but it will get you somewhere. If you sit down and tell your lead what you feel is going on... and make it a polite, constructive conversation, not just saying, "You suck.", then you will quickly figure out if he is willing to adapt or not. Maybe he doesn't realize what is going on because nobody has actually talked to him about it. Maybe he does know, but has low self-esteem and will want you to leave for daring to challenge him. Maybe it will be somewhere in the middle.
But most of the time, in such scenarios, you can figure out a path forward. And whether that path results in you staying or leaving, at least it will be done with honesty, transparency, and mutual respect.
But most of the time, in such scenarios, you can figure out a path forward. And whether that path results in you staying or leaving, at least it will be done with honesty, transparency, and mutual respect.
I was doing consulting work for a small startup that had senior-level "architect" that was responsible for designing the software.
He was producing a lot of tech debt. Instead of automating things he introduced a lot of processes that required manual work. Pretty stubborn person in general, and was adding a bunch of code that was sub-optimal and hard to read.
I quit that gig after 7 months, not worth it when people like that lead the development of the product. Eventually, that product will either have to be rewritten or the it will (along with the company) fail to deliver. Tech debt is dangerous, it can destroy the business if not handled.
He was producing a lot of tech debt. Instead of automating things he introduced a lot of processes that required manual work. Pretty stubborn person in general, and was adding a bunch of code that was sub-optimal and hard to read.
I quit that gig after 7 months, not worth it when people like that lead the development of the product. Eventually, that product will either have to be rewritten or the it will (along with the company) fail to deliver. Tech debt is dangerous, it can destroy the business if not handled.
I think you have two good options here. The first is for the whole engineering team to present a united front to the team lead in a meeting and make the case for what the technical approach should be moving forward so that the team can help ensure the success of the company (aka your livelihoods). The second is to tell the founder that the team lead needs to be moved out of an engineering lead role and either into product management or into a non-lead engineering role for the sake of the company (aka the founder's reputation).
As engineers, we have lots of options when it comes to work. When faced with a situation, you need to consider if this is a hill worth dying on. I've only faced a situation like this once in 30 years. I tried to explain it to the manager that the new guy didn't know his stuff without throwing him under the bus but it was too late. (The new guy had snowed management.) I had to drop the client. Life it too short to deal with bad situations if you have other options.
Yea you are right. quitting is the only option here.
The current engineering lead is unqualified and inexperienced. There have been numerous technical arguments where it is all of the other engineers against the lead, which go nowhere. There have also been times where the lead has told me to do something which is wrong, and I have to explain why it makes no sense to do things in that way and what the proper way would be to do it (which the lead eventually agrees with, usually). The code the lead has written is also atrocious, and if I didn't know better I would say it is actively malicious (in terms of nobody else is able to maintain it). The lead was the first engineer, which is the only reason I think they were promoted.
Being the first engineer is challenging and tech-debt will accumulate. However, the non-technical side of the company is very frustrated with how often everything breaks and I think they believe engineers are just bad at their jobs. It is really disheartening to have to explain that it shouldn't be like this, and that I am trying to fix things but the codebase is not in a great condition and the lead has no interest in making it better. Non-technical folks have talked to me about just doing a rewrite, since there really isn't much code, but the lead will not even consider the idea.
I really like the company as a whole and I agree with the mission. The founder is non-technical, and I think they do not know what poor engineering looks like, which is why this has continued to go on. I really want to just tell the founder "Hey, your engineering lead is awful, you really need to find someone new."
What should I do in my situation? I am currently planning on leaving, and telling the founder then. Is there another path I can take that isn't incredibly frustrating and would allow me to stay?