Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: How do I lead a team in whom I have no confidence?
81 points by toqti on July 15, 2022 | hide | past | favorite | 100 comments
I'm lead on a small team of web developers.

The other members consist of:

A Maverick who insists they know what they are doing but clearly don't and won't admit it. Going so far as to add concepts to the code that don't belong (or work for that matter), applying shiny new ideas from stackoverflow that bog down the system where a simple line will suffice.

Hour long tasks for them take a whol work week because of back and forth with PR comments.

The other member is a copy paster who will grab anything from anywhere (old projects, the web) and paste it in and expect something to happen (it doesn't).

I'm going on vacation and all PR's require my approval. I dread the mess I will have to sift through when I get back, could push the project back weeks.

What can I do in this situation?

I'm sure there are many thoughts going through your mind regarding the team and perhaps my lack of managment skills but I am only lead on the project, I don't manage people.

My boss trusts my judgement and is aware of the situation but he is not technical enough to take over the code reviews.

Is there a possible solution to this without adversely affecting the porject?

Thanks



I know this is going to be an unpopular opinion, but you’re failing your team.

Code that doesn’t work is an obvious problem; there needs to be a culture of reviewing your own work before it goes out for review. You also need to be more patient: I’m sure you write bugs, too.

But if _everyone but you_ isn’t comfortable working in a system, I don’t think that’s a problem with with those people, I think it’s a problem with that system.

It’s easy to get frustrated and say “eh, these people suck, let’s find new ones,“ but just like how it’s your job to solve the hard engineering problems, it’s also your job to get over it and find a way to actually work with these people.

If it _actually_ takes a week of back and forth for PRs to get merged, that means that there’s a massive problem with your review process. I’m going to guess that most of the time, this means that your comments are indirect, or worse. It’s your job to enable your colleagues to work faster, and if you don’t like that, you probably shouldn’t be a leader.


I don't agree with you.

You can't fix people who cannot learn because of their belief that they already know everything. They will take anything personally that goes in the way of their ego.

For examle, take a react web developer - that only knows React, who think that the React way is the only way, read some blogs written by a junior programmer - and take it as a truth.

2015 : Class components is the React way 2016 : Functional component is the React way - don't use context 2017 : Use Context - that's the React way 2018 : Write CSS in Javascript ... and the list goes on.

Now, good luck explaining to that dev that he basically doesn't knows how to think by himself, and because he thinks that he already knows EVERYTHING - he won't listen - or even learn by his own critical and common sense judgment.

Those type of developers are very toxic, they are VERY vocal about how exceptional they think they are, and they will discard the opinion of anyone better than them - just because it doesn't fit their opinion of themself.

They will stay mediocre - no matter what.

Drop The team, fire everyone, and instead of replacing them with same crap, hire a 5x dev.

So let's say you have 5 crap shit toxic dev, producing spaguetti technical debt - paid 100k/year.

Fire them all, and hire 2 real senior devs at 250k$/y each. And Rewrite the whole stack. It will be faster on the long term.

Also, there is nothing worse for a good dev to work with existing shit code - spend 3 months trying to refactor the code - introduce regression bugs while doing it - and deal with poor technical choices - while at the same time they could rewrite the whole project in a more elegant and stable way in the same amount of time.


> For examle, take a react web developer - that only knows React, who think that the React way is the only way, read some blogs written by a junior programmer - and take it as a truth.

At least they read blog posts and spend some time learning. They might be better material that senior that did 10 years of same Java Spring.

> Fire them all, and hire 2 real senior devs at 250k$/y each. And Rewrite the whole stack. It will be faster on the long term.

It is not easy to find two good senior developers.

> For examle, take a react web developer - that only knows React, who think that the React way is the only way, read some blogs written by a junior programmer - and take it as a truth.

If they know react that, great. Well done, ts react codebase can absorb take a lot of shitty code.

> You can't fix people who cannot learn because of their belief that they already know everything. They will take anything personally that goes in the way of their ego.

You can do a lot. You can mentor junior people, you can setup CI/CD with a lot of automatic checks, you can hire QA person, you can lead by example.

In my current role, I introduced typescript, jest unit testing, helped with cypress e2e, refactored a lot of code and did a lot of work on CI/CD. With a few Senior devs, we can still onboard new devs and push new features.


A sucky team will make everything fail. that a team is like some kind of vat of raw potential waiting for a leader with the right incantation to unlock it, is wonderful, hopeful and — much of the time — wrong.


https://www.youtube.com/watch?v=ljqra3BcqWM

Read his book extreme ownership. I highly recommend it.


I disagree. I would drop this team immediately.

Hiring is hard. That's why interview processes take weeks and recruiters get paid tens of thousands of dollars for successful placements. The OP got stuck with a bunch of mediocre, and worse yet, arrogant, engineers.


> _everyone but you_

In this case "everyone but you" seems to be two people.

> If it _actually_ takes a week of back and forth for PRs to get merged

And it seems like this is just the "maverick"


Cultural change - you need to introduce a engineering culture, which happens to appear when people discuss a projects internal in peaceful code-reviews, contract-first (not into too much depth). You need to encourage a culture of engineering conversations, which also means that you need to kick everyone politicizing those conversation from the conversation. Project leads, scrum masters, etc. are out of the door for this.

They need to loose the fear of talking about the techstack with one another, which also means that somebody has to embarass themselves publicly and repeatetly to take that fear. Code-review your own repository first and talk openly about your mistakes. Remove the "smartest man in the building" dick measuring contest. Make it a habbit, that everyones code repository can be "visited" by the whole team. Make those visits constructive and something people will look forward too and even collect "large scale problems" for.

Actually manage this instead of just managing.

Also if your projects grind, do not expect smart people. Grind turns every great hire into an idiot, which then again turns every project into grind.


So... I don't know how much other experience you have leading, in the sense that it requires negative feedback to team members, changing existing patterns and such.

Assuming this is relatively new to you, my advice is to focus time (2-4 weeks perhaps) on how the team/people operate. Worry less about the task, more any about the team... for that period. Break bad habits and form better ones. Realise that negative feedback is tough, and treat it as your current problem. Like other hard tasks, it can't be done well while other things are getting top priority.

There are people who can't really perform at a job. It probably doesn't matter what you do in these cases. More commonly, these are bad patterns.

In all honesty, a lot (most?) jobs are about putting the ball in another's court, having a talking point ready for the daily standup and such. Relatively few jobs are about "genuine work." That's not going to change if you work for CitiBank. A peppy team lead won't change that (for long). It's how the process of incentives and culture work at a proverbial Citibank.

Last... The truth is a lot of employees really suck. It takes some experience to tell a from b from c... so don't jump to conclusuons. If that's the reality, realise it.

Programming is one of the most unprofessional professions, culturally. People pretend to know more than they do. "I can figure it out" counts as "I know." That leaves a lot of unacknowledged lies in the game.

It's very possible that members of your team are missing crucial knowledge/understanding and hiding it, like a fox hides an injury.


If I was in that situation I would take the time to plan out in as fine detail as possible a task list for each day for each person. There are several benefits to doing this:

- They know exactly what needs to be done and are expected to do, so even the Maverick is placed on a leash.

- You are probably going to return to a mess anyway, but this way you (and your boss) have the task lists to point to as evidence when reprimanding or even removing people from the team down the line.

- You're covering yourself if the project does get delayed. You did everything you could to help the team while you weren't there.

Your boss may not be technical, but if he has these task lists for each person and you sit down and go through them with him before you leave, he can do daily checks to keep them on track.

Finally, switch off and enjoy your vacation. There is nothing you can do while you are away and probably a lot you will have to do when you return, so throw yourself into the break and enjoy it as much as possible.


With a side benefit of demotivating both staff so much they'll probably leave as well. Very clever!


If a team is in a messy state or firefighting mode, an authoritarian and micro-managery leadership style can work very well, and even be appreciated by the team.


Nah, you sort out free spirits and free thinkers and leave behind cooperate bedrock bureacrat coders. But then again, this is the reason why we have startup culture, cause this works so well, the grinders have to pay to get innovation externally.


Wouldn't be a huge loss to be honest.


easier than firing them atleast


>back and forth with PR comments

In one company I was one of these people who was causing this to happen. For any bigger change the TL would leave close to a hundred comments.

The problem here was that the TL had a certain vision on how to approach the task. Vision that he wouldn't share until code has been written. Then he'd write these comments, telling us to redesign this or that or to use a certain library. We'd challenge him from time to time to which he'd respond that we talked about this in the past on some meeting ages ago and that we were supposed to "take notes". At the same time he refused to formalize the process and set up any sort of a coding standard.

We literally had to guess what he expects of us. I couldn't even ask to clarify because there was no telling what might become unacceptable to him. So the standard has become "anything that went through the review process in the past", which leads to an another pattern that you've mentioned being a "copy paster". Even this stopped being a safety net at some point. I'd set something up exactly as it was for an another project - a project that was completed merely 4 months ago - only to hear that it's all wrong and that "we don't do it like this anymore". Naturally he didn't even bother to notify us. Stuff like these kept on piling up until it became so ridiculous that I've left the company.

So my advice would be to set up clear expectations and standardize things as much as possible.


> The problem here was that the TL had a certain vision on how to approach the task. Vision that he wouldn't share until code has been written.

I run into this exact problem fairly often, and I have run out of strategies to "manage up" or prevent this problem from happening. Would love to hear more on this.


It was more of a communication problem on his part, as well as picking up some really quirky bits of knowledge and insisting on using them even though it didn't make much sense.

An example can be when he made a fuss of us not using the .NET IOptions pattern. In one PR he took great offense to this, stated that he said we're supposed to use this pattern ages ago, even though nothing like this happened and said he won't accept it before it was rewritten. Then he ignored all of the comments stating that this makes no sense and is no different from just using a regular object, especially since IOptions is more about dealing with config files while we were getting these values from somewhere else. He told us to "just make it work" and that "he can't make all the thinking for us". I did manage to get it working the way he wanted but in the end I had to throw out a solution that was already working and was commonly used across plethora of other projects to accommodate for something new that made zero difference in the end.

There were tons of situations like these. He would tell me to use a tool/library that he never used, I'd come back to him half a day later with proof that this doesn't work the way he thinks it does, he would dismiss me by flat out saying that I'm wrong, I'd come back the next day saying the exact same thing and only then I'd finally get through to him. An interaction that should have took 5 minutes tops would take a day and a half because he refused to acknowledge that his vision was wrong.

A better, more positive example was when he provided a design on his own and had us implement it. It ended up with some minor adjustments and was quickly accepted, I was surprised it went that well.


I don’t agree with all these comments saying fire people or quit or whatever. These days I try give people the opportunity to develop, give honest feedback and if the results aren’t happening then reconsider things.

Is there anyone else in the organisation who you trust that could cover code reviews for a week? When you get back your boss will have two voices stating clearly that the team is not up to scratch.

Then your boss needs to start performance reviewing the engineers more closely with your input and make it very clear what behaviours need to change and see those behaviour changes or they need to reconsider their position.

Management is hard and your boss might not be up to the job(I only say this based on where the team is currently at), if your not seeing the results you want, then it’s time to reconsider your own position.


It's probably too late to make a difference to your vacation, but it sounds like these folks need active coaching. Rather than doing your PRs asynchronously, have you considered sitting down with one or both of them to do the PR review? Pull the code up in your editor and refactor as you go (and teach them how to refactor). Get the code to a good state and commit/approve it right there.

As for your vacation, I agree with the commenter who suggested having them pair while you're gone. In fact, pairing or mobbing might be just what this team needs. You'll be a much more effective coach if you work with them directly rather than "seagulling" [1] PRs.

[1] Seagull coaching: Fly in, shit all over everything, fly out.


Tell your boss what everyone knows: This team sucks and it's the boss's fault for building a shitty team. This is a classic pattern, where you have a team in full dysfunction with a lead who is not empowered and a boss who is not aware.

It is not acceptable to divide the leadership that way. You either need the ability to hire/fire and fix that team, or you have to quit.


The Maverick is a bad actor. The copy-paster is a bad actor. The boss is a bad actor. Is it easier to turn this tide or get a better job?


It's always easier to drop everything and find better pastures when shit gets hard and/or bad.

But is it best for your long-term growth? If you're already in a difficult place mentally, it probably is best to leave. But if you're in a good place generally, and up for a challenge, you learn a ton more when you go from hard/bad to easy/good, and those skills are very sought after in the market place.

So if you can gain those skills, I'd go for doing just that. But again, that's not for everyone.


Framed another way: is it better for your long term growth to work with colleagues who can teach you new skills, or to try to wrangle a dysfunctional team?

IMO it depends on what you want to learn. If you want to develop your technical skills, it's definitely good to go somewhere that you're not the best dev in the room. Wrangling a team is more management / soft skills.


> is it better for your long term growth to work with colleagues who can teach you new skills, or to try to wrangle a dysfunctional team?

Good point, although I'd consider "wrangle a dysfunctional team" as a skill, granted the team is only dysfunctional because of good management, not if they are inherently bad programmers, too big egos or whatever.

> IMO it depends on what you want to learn

Yeah, that's a good point. That nuance in my comment was missing to thanks for adding that.


Thank you, I am being as positive as I can!


I can tell, and this is a familiar situation to me. It's hard to remember what a good environment is like when you have been exposed to dysfunction for a long time. I advocate good organizational health, and I can't do that independently if I stay in bad organizations for too long.


How is the boss a bad actor? The OP is being relied on by the boss because the boss admitted he trusts the OP and cannot judge technical talent.

If the CEO of a small company hires bad programmers, then brings in a CTO, and the CTO complains about the team it's no longer the CEO's fault. The lead seems to be listened to.


The boss is a bad actor because they have delegated leadership duties without any authority to make necessary changes. The boss is not able to judge technical talent.


That's not how I read the post. It seemed like he was given authority and is wrestling with how to deploy it.


I did not read that he was given authority to alter the team composition. I hope I'm just wrong, because that's a poor circumstance.


>You either need the ability to hire/fire and fix that team, or you have to quit.

Giving responsibility without the associated authority and power is way too common. If your situation is what I just mentioned, you have only 2 options: either put up with it or quit.


My first tech job was in a very small company which was able to survive only because it could navigate such situations. I was the maverick in this scenario BTW.

At the moment there's not a lot you can do, considering you're going on vacation - try not to think about work during your time off.

But what you can do in the long run is to figure out their motivations. Here's my assessment of the situation:

Problem 1: The maverick thinks they're too good for this job and they'll show you all and whatnot.

Solution: show them that there's more to this job than leet coding and picking up the new shiny.

Divide their tasks into the smallest chunks possible - ideally ones which can be finished in a day.

Schedule regular updates(ideally daily) during which they will tell you what they've accomplished in terms of value to the user.

They'll protest all that, in which case remind them that you're all here for the users - that's the priority.

Also really - if they're as good as they think then surely they can deliver multiple small tasks?

---

Problem 2: the copy-paster just needs to keep this job and thus focuses on delivering whatever to, in their view, appease their superiors.

Start off by making them feel safe and stopping this unnecessary theater - at least in front of you.

Then give them something to learn - something which requires going through documentation and actually understanding the problem. Something that they can't copy-paste from somewhere else.

BTW how does the maverick judge the copy-paster's work?


"BTW how does the maverick judge the copy-paster's work?"

Maverick either does it for them or finds something online for them to copy.


They're cooperating! The maverick is helpful! This is good, this is all very good!

Make the maverick produce APIs and the copy-paster consume them. This way the former can work closely with their users(their teammate) and the latter can't wing it by copy-pasting, since there's no example online. Also the copy-paster can be productive this way with minimal effort, which is their aim.

I've been in a team of 11 where there were was one lead, two mavericks and the rest copy-pasters. Also there was me, disgruntled with my role. The lead and his lackeys produced a component set, and the rest was just writing configurations in JSON and were happy to do so. I wasn't, so I quit. It was a bad case of NIH, but it worked for them.


My advice:

Tell the teammates that you want to see them grow to become code reviewers. At first require PRs to be approved by two people: first someone else reviews it. once they LGTM, then you review it for final approval. Do this for a while, until you start noticing like you have little to add. And then grant the relevant reviewer the privilege to review in a single pass. Bus factor += 1, and better knowledge transfer.

That is the process you'll have when you get back. But in the short term, it's probably fine to let them approve each others code while you're gone. Yes they might they break something.. but you can always roll back (I hope). Blocking all PR merging until you return sounds a little overkill to me, but there might be some reason the stakes are so high that I'm missing.


> I am only lead on the project, I don't manage people.

responsibility without power

>My boss trusts my judgement

looks like classic "delegation", ie. the boss delegated responsibility while kept the power (you only fall for such "delegation" the first 5-10 years in the industry).

One can guess who is going to get ultimately blame assigned :)

>Is there a possible solution to this without adversely affecting the project?

With only 2 people it is actually much simpler to do their job for them. Just send them on a long trip - like some very important future architectural R&D without any need to commit anything in the near term. Doing very important architectural thing they also may get promoted so you wouldn't have to deal with their code :) Best course of action though - just leave this project or this company.


> I'm sure there are many thoughts going through your mind regarding the team and perhaps my lack of managment skills but I am only lead on the project, I don't manage people.

If you're lead on the project you do manage people. It might not be in your job description but that's part of seniority. And if you want the projects you work on to be delivered you're going to have to step up and be that leader.

I've managed a copy paster successfully before. I set clear tickets with success criteria so it was obvious when their copy & paste didn't work. And as it was their ticket, assigned to them it was their responsibility to make it work. When enough of those built up they got the message and we wrote up a performance improvement plan. I mentored them through solving a couple. Then they started to do it. Enough to keep their job.

I've managed and worked with mavericks before. I have never found a successful strategy. The worst quit within 2 weeks because their new and unasked for contributions (e.g. rewriting a system unrelated to the project because "they could do it better") get called out quickly and stopped. The others burn me out.


> The worst quit within 2 weeks

> The others burn me out

It sounds like "the worst" wasn't actually the worst, "the others" were the worst, as they actually impacted others in a more significant way.


Heh not quite. The worst would also swear at teammates, and called out every piece of our code as sh*t in front of the entire 20 employees (not good when the CTO is there who wrote most of it - and it wasn't that bad). It was 2 weeks where we hardly got any work done.

The current maverick and the previous ones like him don't affect the other employees much, just me who has to lead the project he's on and try and manage him.


> but I am only lead on the project, I don't manage people.

I think thats the main problem. They, the team - and probably you, as you are part of the team - need management.

Clear goals. Intensive training. Clear modus operandi. Clear consequences (pos/neg).

Additional you as a team lead see your real "Handlungsspielraum". As a not manager you might not be able to fire them, but you can define what to do, what not to do and how to do it.

As the old way of doing things did not work, over your vacation try something new. A new way of doing things. And then go on vacation and do t check your work email.


I wonder what would happen if you got them pair programming, by the way.

First with you, and then together. Maybe they can learn, and it would at least save all the time lost on the pull requests.

Of course this doesn't help with the immediate problem of your vacation.


Thats a great idea, I didn't think of this because the team is so small I thought it might use up a lot of time but I suppose in the long run it would be a benefit.


I was in a situation where I was managing a junior developer and felt like I didn't have time to properly train him, so instead I was leaving tons of comments on merge requests in GitLab with explicit instructions on what to change (often literally "Change this line to say this instead" with a brief explanation why).

In hindsight, I think I would've been much better off in the long run if I spent the first few months doing a ton of pair programming. Your situation seems a bit different, but I'd say it's at least worth a shot.


Short term:

- Make sure only you can merge to main

- demand all PRs be small and focused so you can sort thru what they do while you're gone

- also demand descent test coverage

Medium term:

- build evidence proving the teams issues

- present to boss and hope they listen.

Long term:

Look for another job. From your other comments it sounds like their decisions have ensured failure.


Normally I'd start with the PR comments, since this can be improved the quickest (a month or so) with strong coaching, and will give your team better velocity.

But since your team consists solely of a maverick and a copy-paster, you're in trouble. Normally you'd fire the copy-paster and mentor the maverick (or fire him too if his ego is too big to handle).

Getting into a situation where you have to be the one to approve all PRs is a bad sign, because it shows that you have no trust in the team members. Regardless of the validity of your reasons, this is not good because you become a bottleneck.

Another option would be to look elsewhere.


Life's too short: have an honest conversation with your boss about it. If he's receptive => implement the changes you agree on, if he's deflective => look for a new job


Walk away


This is the right answer. Life's too short, especially when it's not your company.


"If you're the smartest person in the room, you're in the wrong room."


This advice can't used by everyone as there will be a smartest person in any room.


Yes, a good team is one in which members are all intelligent in different domains. For example I’m very good at coding HTML buttons and some of my coworkers are much better at selling them.


You should be transparent about what you do not appreciate (e.g. randomly copying code from unknown sources). About back and forth PR comments, just sit next to them (or call, if remote). I rarely leave a lot comments on pull requests, if the issues is not simple.

Also you should be upfront with the management about the quality of the developers.

In the end I suppose it's more about being afraid yourself of confrontation. There is absolutely no reasons to dread your work (pull request or anything else)


Oh god. I'm afraid to say this sounds kind of...hopeless. I don't think it's a lack of management ability on your end. It's that it sounds like they don't even have good intentions. If they had good intentions, you could at least work with them to improve their skills. But if they don't or have some ego issues, what can you do? That's not really in your power to fix.

Can you find new team members? And in the meantime, perhaps do more coding yourself?


I'm doing as much coding as I can but the project management stuff takes time. I'm keeping the critical system coding for myself.

Can't find a new team, manager says this is it and no time/budget to get others.

You're right there is nothing I can do. I'm thinking of keeping the project locked down until I come back. They can still make feature branches in the mean time.


Give your subordinates clear and specific written instructions, eg: "Don't use x technique here, it is unnecessary.". You are the lead, part of your job is to overrule people sometimes.

If they ignore you, or fight with you, that is a different problem.

What this could be is a teaching moment, or series of them, depending on how cooperative or not the team members are.


I get fought and ignored a lot of the time. Hence the back and forth on the PRs. They'd rather show off some cool thing they saw on stackoverflow, having no idea what it does, than learn to do it properly.


Some thoughts based on my limited perspective on things, but just wanting to share.

The business cares, first and foremost, in terms of their perspective of your role, on delivery. You have been identified as a gatekeeper, and they depend on you to shepherd this work to the realization of management targets and higher-level goals.

Questioning hires is a no-go, mostly because I lack personnel experience and sometimes folks come as a group package. Then you're questioning B2B practices and thus high-level folks as an IC...

As for the team, the maverick has a sharp mind for identifying inconsistencies and "holes for ideas." Fill that space with guardrails with your internal framework [1]. Praise the change, yet ask to defer, certain code changes in lieu of more conservative ones. Promise in tiny drips, and point to future stories where you show a roadmap for shiny spikes.

The copy-pasters are self-motivated seekers. This is good! They can identify potential solutions quickly. Guardrails with GitHub Actions automation (linting, etc) help here.

Teach them what you know. Share ideas and concepts. Try recording some training videos.

Schedule a daily group session where you look at everyone's PRs and discuss them. Review comments are softened by a live reading.

[1] And refactor later to something less internal.


There is a short book called something like "Leadership and the One Minute Manager" that talks about 4 different kinds (maturity levels) of reports, and the different treatment each needs, depending on their high or low levels of confidence and competence. (Maybe "the one minute manager" is good also; some recommend it but I haven't read it yet.)

And maybe the realization that everyone is in a different place, for different reasons (a different combination of experiences and choices made), so what helps or doesn't help them could vary.

(I've put some things about social development, including how to work with people, such as when trust matters, etc., at my web site, and have more content to add if interested. Simple; feedback welcome; nothing for sale.)

ps: I commented some about balancing positive/negative feedback, to maintain the working relationship in a way that they won't just start ignoring what one says: https://news.ycombinator.com/item?id=29323685

When people know that you care about them as a human being first, it goes a long way toward ... everything.


If I was your boss, I would be asking you the following questions:

1. Who is covering your role while you are on vacation? Hint, it's not your boss. 2. You are the lead dealing with a maverick. Are you sure that you are right on the technical points? 3. Have you documented your observations and team assessments? 4. If neither of these individuals are working out, what are the characteristics of the individuals you think the project needs? Are they within the company?

I'm assuming this is perhaps your first lead assignment? Your role is to bring in the project within time and budget and with acceptable quality. Your role is not to make all the decisions or write all the code.

Moving to a lead role is challenging, more difficult for some than others.

Bottom line is that if I were your manager, I would expect you to lay out the big picture, apprise me potential issues/delays, etc. If you don't do that, the project's failure is on you and you alone. Once you miss the deadline, run over budget, etc., I wouldn't care about your comments on the maverick, the copy guy, etc. Everything would be your fault at that point.


It strikes me that you're very clear on the problems with each person. That's a good place to start. You're not confused as to the problems. I would have coffee with each of them, and give each person concrete examples of where you think they failed the mission, and why. Speaking of mission, does your team have a mission statement? I know this sounds like it doesn't matter, but they're truly amazing. Get everyone together to come up with a mission statement, keep repeating it, and let everyone know that everything they do every day has to contribute to the core mission. If it doesn't add anything to the core mission, then don't do it. There are so, so many distractions. I don't know how anyone in Gen Z gets any work done, frankly. I'm in middle age, and our brains are wired in a quieter, pre-social media fashion that allows for more clarity of thought. I am not saying this brag, but really to say it's something that needs to be studied now that Gen Z are taking critical positions in the workforce.


Some people like the challenge of fixing dysfunctional teams like this. It’s the core difference between ‘leadership’ and ‘managing’. If that’s something that interests you, check out stuff like David Marquet’s book, but from personal experience also set some sort of timebox (3 months) on on when to reassess and see where things are at and if you want to continue.


> I'm sure there are many thoughts going through your mind regarding the team and perhaps my lack of management skills but I am only lead on the project, I don't manage people.

No, you almost hit the nail on the head. This is not about management, it is about leadership and it sounds like a lack of leadership skills. Mentoring people to point out why their behaviors have a negative impact and how to grow to more productive habits is leadership. It is the role of a team lead. Communicating these concerns to them in a way that is productive and not combative is a skill you need to learn.

We all were unskilled once. And probably still are in various ways. We grow by having people guide us. Be that guide.

As far as adversely affecting the project, which will be a worse result? Quietly grumbling and not bringing change? Or putting up with some difficult conversations and improving the team?


This seems pretty straight forward, reject the PR's with detailed responses until they are of acceptable quality. Doing so might slow momentum with the project in the short term but should overall make everything faster. Just be clear about WHY you are rejecting the PR's and the quality you expect.


Merge them into one person.

The copypaster has the humility to poke around for answers and probably a more routine oriented perspective.

The maverick has the drive and fresh ideas to keep things interesting.

When they have to share with each their weaknesses they can probably grow together. Doing teamwork in person would help because its easy to dodge or delay difficult work online.

If neither has the nous or skill to actually do the task, you're not going to fix it before you go on holiday. Dump all the resources they might need in a handy location for them to stumble into when it goes wrong.

They won't use the resources, but you will have peace of mind they could theoretically solve the problems.

Put some backups offsite. Somewhere your boss could access if necessary.

If they are as slow as you say (hr long jobs done in a week), you'll only have three hours of mess to catch up on when you get back, right?


Make a tag where code is before you go out of office, for emergency restore.

I'd make it clear that everyone is responsible that their own changes work, regardless of what came into the system before it, there are no excuses.

Forbid merge commits (because that's more complex than they can handle).

When a dev wants to submit their code, they have to rebase it first, tough luck, and they have to get it to work again, if anything breaks, their own stuff or what came before, it's their problem, they fix it before submitting.

All tests must pass before code is submitted.

If someone must drive standups while you're away, pick the least technically competent person for that job, because they will then spend some time not doing damage and you don't want the hotshot maverick setting the direction.

Go enjoy your holiday.

Go figure why I'm not in management ;)


The only solution is to train your team. Put them in workshops and try to find out with what they are struggling the most. You cannot do it yourself at some point, the workload will be too much. There is no 10x developer outside of quick prototyping, especially if you are also managing people or projects and do software maintenance.

Very often work gets slow when goals are not precisely defined and developers have to improvise on the requirements. Micro-managing is bad but maybe their responsibilities need to be a bit stricter at first. With experience the railings can be removed.

Some suggest hire and fire, but if you don't put an effort into training you very likely will not find highly qualified developers or you have to pay extra.


A few ideas to consider:

Do you mandate working tests and reasonable test coverage as part of your checkins? That could help, but it if you don't currently do that, productivity will drop further before it picks up. But that's the nature of any impactful change.

When there absurd back and forth on PRs, step-in and mediate a resolution. Pull the people into a room and require a resolution before anyone can leave--drastic, but soon people will realize that they pay more for pointless whinging. It's not doing the company any good for pointless bickering, and it's not improving the product either.

Considering using an external code-review as a service like PullRequest while you are gone. And maybe keep them if it works well.


It sounds like a tough problem that you are not going to resolve before you leave.

First realise that there won't be a lot to do when you get back. They are not that quick as you say.

Second discuss with the team the problem: If you need to correct all their work when you get back the project will get delayed and hell will be paid/management will be displeased (depending on management culture). So you expect them to do minimale code changes and spend extra time testing. In your absence review each others code changes so you won't have to spend too much time approving when you get back. Empower them.

Third, but long term: If you are the most competent person in the room look for another.


One thing I haven’t seen suggested elsewhere, at least from a quick scan through, is that you need to get more help from your boss. Your coworkers need to improve and your manager needs to help you with that by holding your coworkers accountable and dealing with them if they don’t improve. You can help define what “improve” looks like but without the authority to fire someone who doesn’t make it there’s no incentive to improve.

If your boss doesn’t want to help try talking to their boss, and so on. Presumably someone somewhere wants this business to succeed and can be convinced to care.

If that doesn’t work it might be time to find a new job.


Share your evidance-based expectations with your director/manager. If you surprise them with failure or delays that you knew were likely, it'll be your fault. On the other hand, if you deliver ahead of a previously-broadcast delay because you manage to improve on this situation, you'll be (rightly) recognized for effective leadership.

As for strategies to do that: consider (provisionally) lowering the overall code quality standard, as your team is clearly not up to yours. This is an important practical concession when working with average engineers -- otherwise you'll have an effective bus number of 1.


With limited knowledge about the project and the team, here are my two cents: project management.

For example, ask your team to break down the tasks and provide a schedule for each task, and try to help them follow the schedule. If a task is taking way too long, ask them to break down it again. Remember to ask them to explain why they plan it like that.

Make sure you and your team have enough communication so you all know what need to do and what NOT to do. If your teammate is doing thing that is not in the scope, discuss with them and make the decision whether to support them or ask them to follow your request.

Rinse and repeat.


First thing is that it doesn’t sound like you have a common goal. If Maverick’s goal is “build the coolest thing” and Copy-Paster’s goal is “generate code as quickly as possible”, you need to find a way to generate a shared understanding of what you are doing as a team. That could take the form of a set of principles, a set of metrics, or a cool team name. Somehow, you need to focus the team on a higher level goal than the fragmented set you have now. You also need to find someone who the Maverick respects. If it’s not you, is it your boss or a senior dev in another team?


A lot of good suggestions in this thread, I am left with one question that I haven't seen asked yet, where are story/time estimations in this? Someone working on a 1 point task for an entire week should be a metric that your boss can do something with. This together with highly specific written out stories like someone else suggested should at least remove a lot of unneeded discussion

Other than that, maybe set a time limit of a few months for yourself, if you haven't been able to improve things, it's time to move on.


No PRs at all while you're away. No new code. Not so much as a spelling tweak.

Get them to make a branch each, and work through the whole thing line-by-line, documenting what they think is going on. Ideally, get them to work on each other's code. Given what you've said about their coding style and techniques, there ought to be plenty for them to figure out.

You sound like you're due a cleaning of the stables that'd give Hercules the fear, and you must play the role of Eurystheus.


Since you don't own the business but are an employee yourself you don't have to shoulder all responsibility for the business' bad decision.

If you can't fix things on your own, escalate the problem. Document and share with the team and upwards the consequences of your vacation:

1. You are not reachable during vacation 2. If they choose to deploy and break production, they need to firefight themselves 3. The team is not resilient since you're obviously the single point of failure.


Compromise a bit, give more detailed guidance than usual for a reduced number of tasks while you're away, accept that the result won't be up to your usual standards and might need to be revisited later. Can anyone else pop their head in to offer guidance while you're away even informally. While you're on vacation use the headspace to plan how to make things better for next year.


How does task assignment work in the team. Does your manager assign tasks to individuals in the team, do you assign tasks or are you running a more agile style where the developers choose which task they'll work on next?

If it's either of the first two then you could always find them some tasks that they're more likely to get right and make sure they're the ones worked on while you're away.


Add linters, to start. You can’t argue with that. Linting is extremely powerful. I had a team member flip out on me and slam their hands down like a man child. But hey, that reflects more on them. Use precommit hooks so they don’t get too frustrated. You can lint CSS. Just take control and sometimes just push the code you’re the lead. Pull off the bandaid or I’d look for something else.


Before PRs queue up and you and your team have to untangle the mess after your vacation, give them only one task while you are away: Complete programming lectures xyz and hand in each lecture’s homework as proof. You can assign your team members different lectures so the copy-paster learns the basics and the maverick learns how to apply solutions that don’t bog down the project.


Work on building up the skills they are missing, whether its technical or soft skills? Being a lead sometimes means you have to prioritize team growth/output over your own for the medium to long term.

If you're in a startup that needs to produce a product yesterday then you may need to walk away as the company hired wrong, but if you are in charge of just a team in a company then its time to grow them.

When I have been in this situation the first step I take is to articulate where I want my team members to be, then deciding on the plan to get them there. It is an easy trap to fall into, to just complain about the current talent you have, but that will just build resentment and not create any improvement.

You should define what behaviors you want them to exhibit first. Then build a plan on how to get them from where they are, to where you want them to be, then start working with them to implement that plan.

Your 2 major possible impediments are going to be

1) having a boss who wants no change to the situation, in case you have been set up to fail and should look for a new job

2) an employee who accepted the job under certain terms that you are now changing. That is not their fault, but is one of those situations HR likes to describe as needing "managerial courage", where you either need to move the person on to their next role(most places this means shitcanning, but the moral choice is to tap your network and help them find a better suited role) or help them get with the program

The absolute worst choice is to just accept whats going on and let everyone deal with a shitty situation that breeds resentment until someone or everyone blows up and the whole team turns over.

Edit: I wrote that up somehow having glossed over your comment that you don't manage people and your boss isn't technical.

You have been set up to fail

If you have no control over people on a team but are responsible for their output you are the software equivalent of a supervisor at McDonalds. Either don't rock the boat and just collect a paycheck, or find a new job if it bothers you on a deep level. There is no solution to this situation. If your boss is not technical and already realized his deficiencies he would have empowered you. Being responsible for a team without the power to manage them means you are just a meat shield for the first time something goes wrong.


> I'm going on vacation and all PR's require my approval.

Agreeing to that was idiotic. :) You seem to have put yourself in a bad spot by taking on a lot of responsibility without much authority or enough salary. If you have no faith in your colleagues you should jump ship or see if they can be replaced.


I was in a very similar situation. I left on vacation and let the team merge their code without my review.

On my return, nothing was working as intended, although the codebase grew by 5,000 LOCs. I made it clear to everyone that they failed and a couple of weeks later I was gently asked to quit, which I happily did.


Isn't that what the code review process is for? 40 comments come in the first time, then 20 and then 5. It is difficult to communicate with some people, yes, but areas such as code review exist for this very topic. If you don't like it, feel free to point it out.


The only reliable solution is to fire bad people and hire good ones, and you have to interview them yourself.

You can’t possibly be a good leader with a bad team that you don’t even trust.

But you will be blamed for all the troubles the team caused.

This is why hiring people is a #1 skill any decent leader has to have.


You can't fix the team, at least, not in the short term.

You say your boss is aware of the situation. Make sure this is formally documented.

Ultimately, if management are aware that this team doesn't function well but won't do anything about it, find another role.


Why are you reviewing code that doesn’t work? At least set the basic expectation that the code has to work before you even look at it.

Other possibility since you’re obviously just sharing one side of the story is you yourself don’t understand their code.


People should review each other's code: you shouldn't be the bottleneck. Try that while you're gone. Focus on working code. Forget about nit picks like style and formatting.


For starters, you need to explain what you want and explain the problems with their code. Also explain the reasons for those rules.

Then, if they keep trying to merge junk, just reject their PRs


> Is there a possible solution to this without adversely affecting the porject?

No. This is a doomed project and team. Leave now.


If you don't let things go wrong, management will think everything is ok. Go on vacation, let the place burn.


Replace the members else get a new Job. Life is too short to try to fix what you won't be able to fix.


Sounds like the project is doomed and you need saving? Maybe don’t return from vacation ;)


over-engineering or copy-pasting are not unique to your team.

stop trying to be perfect. remember the 80/20 rule.

focus your time on what matters.

if there is a serious problem, then it's your responsibility as the lead to deal with it, if needed.


Easier to leave. They can pay consultants to fix it. They caused it.


Who does manage the people? Have you spoken with them, yet?


Do everything yourself to show them how things should be done.


shake them up.

change all their roles and tasks to thing that they dont normally do, but if they try hard they could rise to the challenge.

get them out of their comfort zones.


By example


I think you have to set a good example of what you expect from everyone to do or assign some tasks to them and regularly do meetings to assess every progress that the team makes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: