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

It will be difficult and frustrating, but can be also fun and rewarding in addition. Here are some pracoval tips that worked for me in similar situations.

Treat everyone with respect - everyone has a story and being competent developer is not the only metric for human beings.

Reduce scope - better deliver few solid features than many half baked. You will need to get heavily involved in implementing those features so better not spread yourself too thin.

Start with authoritative management style - it's ok to say "do this and do it like this". Particularity with hierarchy based cultures, this could be even expected. At the beginning it can be uncomfortable as Western developers are often used to servant leadership style that supports freedom, outlet for developer creativity and individual autonomy.

Set precise rules - people are usually able to follow checklists and step by step guides. Have process ready and thought through, but tailor it to the situation on the ground. An example could be: implement task, write unit test with 80% coverage, build and run test locally with no tests failing, send for review.

Don't expect creativity - be as precise as possible specifying the tasks. Include design in the description, any names of the classes you want to have. Ideally have a pointer to code or example on internet that can be copy paste and modified. Specifying tasks this way is doubles the work it usually takes but otherwise you get into endless reworks and headaches. The level of detail needs you to be very well prepared in the technology, design and domain knowledge. Read up ahead on the stack they are using, patterns used for the type of app you are building, look at the code and get familiar with the domain.

Use the hierarchy - identify the one or two promising team members and with with them. Let all other team members consult them first and only then approach you. It's easier to work in depth with two people than get drowned in random questions from five or six.

Expect to get your hands dirty - you will still need to do lot of individual contributor low level implementation work to set standards and so that others have place to copy from. Your code needs to be near perfect the first time as it will get copied over many times. This is painful, but make it work now and refactor later often doesn't with great, when there are 5 people multiplying the work that needs to be refactored.

Distinguish the work from the person - it keeps amazing me how much I like some people on personal level yet hate their work output.

On the other hand this can be a great adventure, getting to know new people and country while working on a common goal. Crisis often bonds people together anyway.

Hope that helps and keeping fingers crossed for you.

I doubt there's been any real code reviews. If there were code reviews, they were probably treated as formalities.

(Without really understanding the context,) one thing to do is just emphasize code reviews. There are many ways to do it. In 1-1s with team members, set expectations for code reviews. (Read through every change, question anything that looks odd, you're supposed to request changes.) In team meetings, pull up an open pull request and start asking questions.

I've worked with a lot of people who come into my team assuming that the code review is a formality. Some team members adjust, and others leave for more sloppy assignments.

This is a people problem. Not a technology problem. First really listen to them. Understand their culture. How they think. Why they do what they do. If you don't you will fail.

This is very good advice.

Id highlight the part of asking a person who is from or grew up in the culture as opposed to an expat with a only few years experience (who you'll likely find easier to meet once there).