Ask HN: How do I lead a team in whom I have no confidence?

Walk away

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

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.

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?

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.

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.

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.

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.

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)

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.

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.

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.

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

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.