Ask HN: I'm inheriting an incompetent dev team. What the hell do I do? | Hacker News Reader

Ask HN: I'm inheriting an incompetent dev team. What the hell do I do?

17 pointsthrowaway2k1726 comments

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

I don't feel right immediately leaving a new job, but I don't know how long I can surrounded by these guys without losing my mind.

View on HN

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.

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.

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.

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.

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.

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.

The thing with core computer science concepts like Big O is not that you need to know them, but that you typically don't realize how much better your code would be if you did know them (and applied them).

I personally have (what I would consider to be a bad) habit of writing a bunch of code with minimal planning upfront, but after it's working I'll review the expected performance of each function and try to optimize as I debug it. There have been times (especially when I'm writing in a new language) where I've written code that works, but missed a spot where it's inefficient and could be significantly improved with a small tweak. The code will run, and in the context of what it's doing it will complete, but it could be made much faster. This has important ramifications if your code is, for example, doing a lot of egress out of AWS, or doing a lot of parsing or data transformation.

In situations where the code is not obviously incorrect, it often happens that it's simply not as performant as it could be. It will stay that way, unless a peer reviews the code and spots the inefficiency, or the developer spots it themselves. For small portions of software these individual inefficiencies are not troubling. But there is a real revenue cost to these inefficiencies in production infrastructure if you're doing something more complex than gluing disparate libraries together.

I can sympathize with the OP because while I am a big believer in Everyone Gets Code Review (no exceptions), it can be painful for someone to constantly have to fix the same errors over and over again. If the devs on the team in question are motivated to change habits and learn, this won't be a problem. But it could quickly get exhausting to have to fix things on a team over and over again. What will happen if they do not understand e.g. Big O, is the code will work, and every issue will look different to them because they focus on examples, but from the CTO's perspective they'll all be manifestations of the same thing. One will see forest, the other will see trees, and the behavior will be hard to correct. It's also a recipe for low confidence and animosity.

I agree with you though that you often don't need this knowledge; i.e. you'll write functioning code without it, and you don't want to prematurely optimize. But you can output better software with fewer unknown unknowns, and Big O is one of them.

I agree that there's a balance between the two. My ideal team is probably a quarter that know core CS concepts and how/when to use them and the other three quarters devs can write good code whether or not they know core CS concepts.

The part that makes me frustrated enough to comment on this is that I've found that a lot easier to convince a dev who doesn't know Big O that they need to than it is to convince a dev that does know Big O that it's not always necessary. Convincing is significantly harder if the dev graduated from college in the past 3 years.

Big O notation doesn't come up explicitly in conversation often, but the principles come up constantly. You need a fundamental understanding of the time complexity of algorithms to write good software of non-trivial complexity in most domains.

I don't understand why this sentiment gets downvoted so often. The commenter didn't express anything rudely, and it doesn't seem controversial.

If you are writing software that is more complex than simply gluing libraries together; i.e. you have to think and plan the functionality out, then yes, the odds are that you will benefit from understanding time complexity at least once somewhere.

I feel that saying things related to algorithms invokes an anger towards unreasonable whiteboard interviews these days. No one is claiming you need to memorize algorithm and data structure implementations from scratch (although, for basic things like queues and linked lists you should probably be capable of writing one, even if it requires referencing wikipedia briefly...). We're just saying that a solid understanding of time complexity is generally and broadly very helpful.

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

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

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.

Considering that it's almost impossible to get past any whiteboard interview without an understanding of Big O, I think you're being a bit too harsh on OP here. It's literally CS 101.

I don't think I learned much Big O until about my junior year. Maybe some vague mentions sooner.

Looks like you're right. I didn't realize that most student don't get exposed to Big O until their first real algorithms course.

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.

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.

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.

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.

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

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.

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.

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.

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 ?!

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.

Reply on news.ycombinator.com