Ask HN: Going to lead a struggling dev team in a different culture, now what?

1. Start on a high note, take the team out to lunch / dinner and start to get to know them.

2. Don't force any changes, they will likely resist and you'll lose any budding support. Forcing a code review workflow is likely to demoralize them, and will be perceived to be slowing down dev that's already behind.

3. Work longer hours than anyone. You need to earn their respect, being seen to work insane hours is the fastest way to prove your commitment.

4. Do one on one interviews with everyone, and listen listen listen. They know what's going wrong.

5. Strive for consensus, and become their champion in relation to upper management.

6. Never denigrate any member of the team, even if they are exceedingly incompetent. Work with them to assign tasks they can complete.

7. Heap praise on every good process and success you see.

8. Never claim any credit for yourself, ever. Make sure the CEO understands this, and doesn't praise anything you do in front of them.

Not much to do really, but if I would do this, I'd stay away from changing the methodology and the code, and make it clear that it will be tough to make this fly.

Focus on:

Reduce scope. Make sure only the important features are built. Set up periodic meetings with all stakeholders to prioritize (down) features and subfeatures.

Get a grip on what's built and what's left. Make a realistic prognosis and make sure to anchor the new realistic target date with the stakeholders.

Make sure bugs and tasks are tracked. Set up manual testing routines with some experienced testers. A big team if the automatic tests are of low quality. Iterate and prioritize this list constantly.

I would start by having one-on-one conversations with each member of the team to understand what they think the current problems are, what they think solutions might be, and what they think the team's current strengths are.

Then if you want to implement a solution, you can speak to things team members specifically told you. For example, if several people complain that they feel like they don't know what changes other people are making – that's a great time for code reviews.

The root causes for those problems can come from other teams as well. I once led a team that had a terrible codebase. Upon talking to the engineers, they had a pretty good idea of how to write good code, but were stuck with a legacy codebase and management would never let them take time to refactor. So I went to the CEO with a description of refactoring projects, how long I expected them to take, and how much time I expected them to save. Translating it into dollar terms made it much easier to get his agreement.

Above all, remember your employees are smart and probably have good ideas for any "obvious" problems – so you'll have to dig a bit to find the non-obvious root issues.