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

I see another poster talking about expectations. You need to be clear with the executive team on whether this team can be successful given the expectations placed upon them. Most underperforming teams I've seen have been more the result of unrealistic client/ownership expectations.

I suspect that you are young. Only a young/naive person would take a job on these points. From my perspective from a 40+yo (with 20+ years exp), this is very foolish.

> They are struggling with a project and the deadline is close.

You should really tell us the backstory. Unwittingly, you have made yourself the fall-guy. Now your "boss" can surely put the blame on YOU when this goes south.

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

I hate to use the word incompetent. But lets call a spade a spade shall we? In the little to no time you have, you cannot expect to work miracles overnight. Especially when you are so new to being a software lead.

Talk to the wrong person, in the wrong way and it's all over. Depending on where you are going. Losing face is quite serious in some places of the world.

What happens if you get into a situation where they cannot say no. So instead they say, not now or maybe it isn't the right time to implement X. Now you've stalled and the project fails.

Honestly, my advice would be to walk back this situation as best as you can. You want your first project lead to be a simple project that can be controlled and taken from conception to shipping with the least amount of issues.

Not this baptism of fire, which you WILL get burned. There are so many variables in play that you won't be able to control ANY of them!

> How would you handle this situation ?

Very simple. Talk to whomever gave you this assignment and tell them you have thought about it/taken outside council and it was foolish of you to accept.

Let the project fail. Let it fail very hard. Let the project owner bask in it's failure.

Only when you are asked to rescue the project, then you can submit a document detailing how it could be rescued. How long it may take to do so, the budget, the team members you need, etc, etc. You make it clear that it's only an estimate since you have not seen the codebase.

Then and only when you get the codebase and do a thorough examination of it, then you submit a revised proposal.

If you are successful in a bid to rescue it. Once you have control of the project you can implement your dream wish list, etc.

If you are unsuccessful in getting the project. Well, let it burn. It's not your head on the chopping block. Move on, that project lead will come some day.

The other factor to be aware of is when people's income and livelihood is at stake they will fight tooth and nail about everything. If you give the team ownership in creating the solution and make it about co-creating the product you might have better long term success.

However, if the deadline doesn't permit that, then the short term solution is to map out a process like you described and find out who's on board and who's not. Remove those who offer resistance from the team because an anti-team player is death for a deadline.

Feel free to pm me if you have more questions

List of issues I can think of...

1- In some cases, people in developing countries usually have a short term thought/goal. Like myself. I'm just here until I can apply for Masters in xyz country or immigration to lala-land and get out of here. Brain drain is very very real and very very obvious. People change far too quickly. And because there is no handover/software dev process. A lot of stuff is re-done.

2- We just have never ever seen good practise/experience to know any better. In the UK, there were people next to me who had been engineering for 20+ years! I didn't have access to that level of engineering/experience. I'm talking about Engineering, 20 years of coding/design experience of building/shipping stuff. The senior guys are still there. They just drift to management as engineering is dirt cheap.

3- I'd recommend listening a lot at first. There will be one or two good people who others in that team will be looking up to. Focus on those guys and explain your changes to them. They'll explain it to their fellows in their language. And there will be quiet people mostly because of language barriers.

4- Take baby steps. (or one big drastic step)

5- We don't think in English. That becomes a problem at times because people in English speaking countries think in English, learn code in English, speak in English etc. We might know English. And we write text/code in English. But we actually think in our own Mother tongue. Hence the focus on convincing a few key people who others are looking up to. And then they can talk in their language.

6- Build trust

7- Sometimes the gentle approach doesn't work and you need to use the stick approach. This is how its going to be done. The CI system is going to enforce this policy. I'll do all merges and this is the list of things you need to make sure work before sending a PR.

8- Establish your role with the CEO and make sure the CEO communicates everything to the team. Including the fact that there will be some time invested in improving software methodology itself. Otherwise, you'll be in a constant battle for justifying things.

9- In the developing countries, overall, people are in a higher stress state. It can be any number of things most commonly financial stress, family social issues, marriage issues.

10- Age matters here. Not technical/expertise. And if a bunch of people came from one University and another bunch from another, it matters.

11- Notice who eats lunch with who.

12- Build trust. Learn a few words of the local language. Try to say a few words. This usually results in a bout of laughter though.

I can probably go on n on. But I think you have enough