
Ask HN: I'm inheriting an incompetent dev team. What the hell do I do? - throwaway2k17
So I recently accepted a team lead position with very small start up. The CTO is very competent, so I imagined his team was quite good as well. Long story short, it&#x27;s very obvious that the CTO has been carrying the team this whole time. Worse, the CTO is leaving the company, so now I have to be the one that explains simple crap like Big O.<p>I don&#x27;t feel right immediately leaving a new job, but I don&#x27;t know how long I can surrounded by these guys without losing my mind.
======
itamarst
Everyone starts with no skills. Everyone can learn those skills, if:

1\. They're motivated.

2\. They're doing activities that lead to the right kind of learning.

So if you can teach well (or learn how to teach well) and they're motivated,
this is a problem that will be solved in time.

The problem with a startup is that you're often on a tight deadline. The nice
thing about a startup is that often software development's goal is _learning_
(e.g. "are there any customers for this product?"), not building something
that lasts, and so "quality" may not matter.

So it's very hard to say in the abstract without understanding the constraints
you're under and the company goals.

------
tompark
First, show them respect by expecting that they will complete their tasks.
That's not to say that you're setting them up for failure, make sure the tasks
are appropriate and they are committed, but don't spend your time trying to
teach, at least not at first. At least some of them can educate themselves.

Mitigate risk by having everyone write test code and do peer code reviews.

You'll probably do a lot of fire fighting initially. If your team is >7 and
truly none of your devs are "competent" (unlikely), then hire someone who is,
even as a contractor. If you don't have headcount, then fire someone to get
headcount. You need at least one other person you can rely on to fix urgent
problems if you don't have bandwidth to do it.

You said "very small start up" so I'm assuming team is <15, but if it's that
size then you prob need sr devs to help you lead the team. With a couple good
hires, you can wrangle a fairly large team of very junior devs.

I've had dozens of devs (~30) report directly to me, and a lot more than that
indirectly. I've never seen one who was totally incompetent. There was one
guy, and no matter how much I tried to encourage him, he was performing way
too poorly so I removed him from my team. Years later by coincidence I found
out that he was working at a friend's company. I asked about him, and it
turned out that he was a strong contributor on his team.

People sense when you don't respect them and once that happens the
interpersonal dynamic will negatively affect the team, so you have to police
your own attitude. Maybe you don't have much experience leading a team. You
could say, possibly, that you are as incompetent leading the team as they are
in swdev. Please try to respect them regardless of their competence level.

Find out your dev's strengths/weaknesses, so you know who to use when. I had
one eng who wrote the absolute most heinous code imaginable, but he got tasks
done super fast. I had to rely on him several times to meet customer delivery
dates -- and had to accept the technical debt too. You make those tradeoffs.

------
taway_1212
If that's any consolation, stuff like Big O almost never comes up in most
software jobs. I"d be more worried about these guys writing buggy and
unreadable code.

~~~
AnimalMuppet
I know what Big O is. (Obviously, they're a chain of tire stores - at least,
they used to be.) My first job out of school, though, I didn't. I think maybe
I learned it around ten years into my career. I've needed it very little.

~~~
rrrjjjqqq
I used to manage a team of devs who looked down on other devs for not knowing
what Big O is. I've argued with them more than once that yes, their algorithm
is technically more efficient, but the 20 extra network calls they're adding
means it's going to perform significantly worse without exponential growth.
I'd rather have a person on my team who can develop solutions for the
circumstances they're working in over a person that can write perfect, white
paper worthy code for spherical cows in vacuums any day.

~~~
dsacco
I think that's an orthogonal issue. Prematurely optimizing, or inappropriately
optimizing code by over-engineering its efficiency is mutually exclusive from
knowing how to optimize in the first place. It's a bit of a false dichotomy -
you don't have two camps, one which understands optimization and does it too
much, and another which doesn't understand it and produces code faster.

It's a fair expectation to have developers reasonably cognizant of computer
science fundamentals and _also_ to utilize them sparingly and appropriately.
In the same way, it's important to understand how microservice architecture
works and what its benefits are for scale at a theoretical level, at least.
But that does not mean that you split everything into microservices for a
GitHub side project or for a SaaS with fewer than 100 active users.

When you need the tool, you open your toolbox. But the mere presence of the
tool does not mean it will be used. I also don't think it's fair to look down
on peers for a lack of education, as long as they are not willfully
antagonistic to improving themselves.

------
telebone_man
Do them a favour and quit, so they can get someone up to the challenge in.

~~~
scalesolved
I think this is unfair to the OP, obviously she/he is stressed about the
situation, perhaps offer something a little more constructive.

~~~
telebone_man
I appreciate what you're saying, and agree this could be an opportunity for
not only OP to grow as a professional and also educate multiple team
members...

But in my opinion, OP appears to be asking for a justification to leave the
role, not for advice on how to get the most out of their situation.

In order to offer some advice on how to get the most out of their situation, I
feel I need to first explain why it's an opportunity in the first place.

In a saturated industry, there will be someone else who would ask "I've found
myself in a lead position, in a team of underdeveloped engineers, how can I be
more effective in my capacity as a lead?". So why bother converting OPs
viewpoint? If they've got into a lead position, they've probably been working
a while.

Therefore, it would benefit OP to move to another role they're happier with,
and also open up an opportunity for someone else who could better benefit the
employer.

------
venusiant
It's important to have faith in your team, if you don't believe in them then
they won't perform. If the CTO was carrying them then that's a way of showing
them he didn't believe in them.

As team leader, facilitate their growth. It's actually a good learning
opportunity for you.

------
moocow01
I can understand being surrounded by people who you don't think of as highly
skilled but some of the statements such as "so now I have to be the one that
explains simple crap like Big O" and "I don't know how long I can surrounded
by these guys without losing my mind" make me think you might not be happy in
a leadership role.

In any sort of leadership role you're supposed to be trying to extract the
best work from your people. Generally you are not going to be able to do that
effectively if you are looking down on them. Give them a bit of respect,
encourage incentives and comaraderie. Your new job is to be explaining stuff
to them so they can work better. If you don't like them figure out how to make
them better - its usually easier and way less expensive than firing and
hiring.

~~~
atmosx
I erased my comment because was not _positive_ but here are my 2 cents...

The author comes out as a arrogant. Looks like he expects his team to be
_skilled_ but it's crystal-clear that he wouldn't follow a leader that is less
_skilled_ than he is.

My take is that if the author cannot explain what BigO is in 5 to 10 minutes
and how to use it effectively, providing simple examples and leaving room for
questions, he is absolutely NOT fit for the job - I don't think he understand
what a _team leader_ actually is.

I had 4 team leaders/CTOs so far, the first was extremely technical (probably
the best, I've never came across another DevOps that was so well-rounded
technically). The second was less so, but he was extremely well rounded in
managing people. I came to appreciate his ability to express a concern or
point mistakes I've made without insulting me in any way.

Being a leader is about taking technical decisions but first and foremost it
is about teaching and managing ppl.

------
AnimalMuppet
You have three options: teach them, fire them, or quit.

The first question is, are they teachable? If they are, the best answer is to
teach/train them so that they become more competent. If not, the only options
are to fire them or quit.

The second question is, presuming they're trainable, are you able and willing
to train them? This isn't just a question of your knowledge. Do you have the
willingness to do so? Do you have the patience to do it? If not, you're back
to fire them or quit. But in this case, the problem is not just the team. Part
of the problem is that you aren't able or willing to do part of what leads do.

------
NumberCruncher
Joel has some good advices [1], if you do not want to quit your job. If none
of these works, you should quit. Dead hourses should not be ridden but buried
deep.

[1] [https://www.joelonsoftware.com/2001/12/25/getting-things-
don...](https://www.joelonsoftware.com/2001/12/25/getting-things-done-when-
youre-only-a-grunt/)

------
brudgers
Management is the art of getting people to do what they can do and channeling
what they do in a productive direction. That requires recognizing each
individual's capabilities and limitations including one's own.

Well that's not so much just management. That's also how teams work. Somebody
has to play goalkeeper and hopefully there's someone who can kick the ball in
the net and a bunch of people in between able to run (a lot). And some people
who can come off the bench when someone gets injured.

Sure I hate sports analogies. Being a good teammate is about more than
technical skill or resume. It's about playing well with others.

Good luck.

------
throwaway2k18
OP here.

You guys have made a lot of great points and I've come to see how I've already
set myself and my team up to fail with my poor attitude.

I'll work with my team to give them projects that will allow them to grow. The
current CTO is a massive micromanager and I'll make sure not to make the same
mistake.

Also, please drop the Big O thing. I chose a random CS concept for the sake of
anonymizing myself.

------
aregsarkissian
I think context matters here. In a small startup everyone on the team is
expected to be able to contribute their skills to make the startup grow. There
is no time for training and teaching. So either convince founders or
management that they need to bring the right skills in house or leave knowing
you tried to help the company but they have different priorities. In general
though you should try to help people not look down on them.

------
id122015
If you didnt give the example of what it means for them being incompetent, I
would not know. I think this is the world where people refer each other to
jobs and not employed based on competence. You just confirmed that what Ive
read on codding horror is true.

Hire me I would say, although I'm not sure its possible or best thing.

Leave as quickly as you can?

Have fun and let it crash ?!

------
thinbeige
Difficult decision. You can 1) stay and try to transform the team by training
them and/or switching the devs or 2) leave.

It's hard to give a recommendation without knowing the team. However, choosing
the first option is a long, tedious and draining process. You learn more about
management but will rather degenerate in general. So leaving and looking for a
better environment might be an option.

Maybe it is also good to just rely on your gut feeling.

