Ask HN: How to deal with inexperienced/unqualified technical lead?

Yea you are right. quitting is the only option here.

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).

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.

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.

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.

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.

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).

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.

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.

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

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.