
Ask HN: How to deal with inexperienced/unqualified technical lead? - throwawayJ8nf
I have recently joined a small startup with a fairly small engineering team. Most of the company is non-engineers, and the engineering team is responsible for the internal tools and external tools.<p>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&#x27;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.<p>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&#x27;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&#x27;t much code, but the lead will not even consider the idea.<p>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 &quot;Hey, your engineering lead is awful, you really need to find someone new.&quot;<p>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&#x27;t incredibly frustrating and would allow me to stay?
======
alain94040
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).

~~~
arenaninja
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

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

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

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

~~~
UK-Al05
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.

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

------
hotdox
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](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-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

Code amount is not a good characteristic of system complexity. May be buisness
people underestimate amout of effort required.

(Edit):Fixed EOLs

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

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

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

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

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

