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

One reason to bring me in is to implement good software development practices to the team. They are seriously lacking on this aspect: no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming, the list goes on.

On the cultural aspect, the team is certainly stressed and I wouldn't be surprised if a few members will be defiant about seeing a Westerner joining the team that late in the project. Depending on how the CEO will introduce me to the team, I'm either the boss, am respected by default or another team member with no authority at all and can't rely on status to move things forward. Hierarchy is extremely important to this culture.

I can't just impose things: I need to sell good practices to the team so it becomes the natural next step to implement them.

It's going to be hard to implement a full software dev pipeline in such a small timeframe but I'd want them reach the point where:

  - the project is shipped
  - they understand why naming is important
  - they modularize their code
  - they do stuff for a reason (no meaningless SO paste)
  - refactoring becomes a reflex

  - mandatory code reviews, especially my own code. It seems to me like a good way to show the team how you refactor code properly, will make me meet and talk closely to the devs and will, hopefully, inject a sense of collective code ownership.
  - making it very clear from the very beginning that *I* will be the one to make efforts to make myself understood: I know that some of them have a below average English level and are not comfortable to speak to foreigners

Video : https://www.youtube.com/watch?v=eYzk2BKeG9s

Blog Post :https://www.hibri.net/2016/06/18/continuous-delivery-rags-to...

There is no one way, every team has been different (for me), it what technique you use depends on context. They key themes that stand out for me are

1. Limiting Work in Progress (focus on delivering one thing at a time), creates slack time, to learn new practices and start writing tests.

2. Focus on learning, don't expect everything to fall in place pretty good ( it took us about 3 months to even to get to a good starting point)

3. Pair and help them out.

Also your list of things look like something that would take a rather long time to implement (many months), especially if you have a late project to deliver on at the same time.

On the technical side, I recommend _listening_ a lot before making any suggestions. _Maybe_ it's all backwards, and there's _always_ a better way to do it, but showing them you understand how they work _first_, then help them push something - even a small win - out of the door _first_ will get you a lot more "street cred" than trying to mandate things out of the gate.

If you're looking for some literature, "Five Disfunctions of a Team" and "Culture Code" are good starting points on how to tackle cultural aspects (and how to be accepted as a newcomer "playing the boss", which will also be your case).

Other than that - leading teams is difficult, leading teams _well_ is an incredibly frustrating/counterintuitive exercise, but a huge growth position :-) Good luck!