
Ask HN: Going to lead a struggling dev team in a different culture, now what? - charlesfleche
I&#x27;m flying in a few days to a developing country to lead a team of software developers. They are struggling with a project and the deadline is close. I accepted this contract because I like the country, the CEO and want to push myself to a first experience software lead.<p>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.<p>On the cultural aspect, the team is certainly stressed and I wouldn&#x27;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&#x27;m either the boss, am respected by default or another team member with no authority <i>at all</i> and can&#x27;t rely on status to move things forward. Hierarchy is extremely important to this culture.<p>I can&#x27;t just impose things: I need to sell good practices to the team so it becomes the natural next step to implement them.<p>It&#x27;s going to be hard to implement a full software dev pipeline in such a small timeframe but I&#x27;d want them reach the point where:<p><pre><code>  - 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
</code></pre>
My solutions for this:<p><pre><code>  - 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
</code></pre>
How would you handle this situation ? What first steps would you take ?
======
herval
"no test, a single staging dev server (no local dev env), no doc, inconsistent
function and variable naming" \--> none of these things prevent code from
shipping, per se. I know it's convenient, as a first time leader, to focus on
the technical aspects, but from your description, it seems there's underlying
_non-technical_ issues you might want to get familiar with first.

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!

~~~
charlieflowers
The first thing that crossed my mind was "Seek first to understand, then to be
understood."

You almost certainly will find some people who already long for what you're
going to advocate.

~~~
faizmokhtar
IMO this would be best. Don't go gungho and fix everything when you first join
in OP.

------
rsyring
I think you are setting yourself up for failure:

> Depending on how the CEO will introduce me to the team

I'd resolve that NOW, before you fly out. If the culture is hierarchical, and
you are supposed to be the "lead", but you aren't introduced as such, you are
dead in the water IMO.

> They are struggling with a project and the deadline is close...I need to
> sell good practices to the team so it becomes the natural next step to
> implement them.

This is an awful combination. You are going to try to implement best
practices, on a team that has little/none, who may not even believe in them as
beneficial, while they are under stress to hit a deadline?

> I'm flying in a few days to a developing country

I'm sure there is more context to this situation than what can get in a
summary. But honestly, if you summarized it well, I'd cancel the ticket and
find something else to do. The way you have described it, I think you are in a
no-win situation.

~~~
kpil
I agree, it's tough.

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.

~~~
winrid
This! Don't introduce new "best practices" in crunch time when you still don't
have context yet. Give it 6-12 months and start by asking what the Dev team
itself wants to change, not you.

------
mikestew
As an experienced manager, I shudder at the thought of pulling this off.
But...

 _and want to push myself to a first experience software lead._

Am I to take this to mean this is your first experience leading a team? If
that is the case, you are being set up for failure so that the CEO doesn't
have to take the heat. "I brought in a high-dollar contractor, she was
supposed to be good, but I guess not." If what you describe is accurate, and
I'll bet there is a _lot_ you're not being told, Jesus Christ himself would
look at this situation and say, "Sure, I can raise the dead, but this project,
I dunno..." An inexperienced manager in a new culture in a different country?
Yeah, you might want to cancel that plane ticket.

If I'm misreading your situation, feel free to ignore all of the above. But
even if you're experienced, mmmm, I personally wouldn't do it.

~~~
ObsoleteNerd
Couldn't agree more. If the situation is as reads, OP is being set up as a
scapegoat. Maybe not maliciously, but it stinks of last ditched efforts to
avoid personal failure by the higher ups.

I wouldn't take this job and I absolutely love a challenge.

You don't send a first time manager to save a failing project at the last
minute. You'd send an experienced one and use the first timer to fill in gaps
on easier projects if needs be.

I really hope you rethink this OP, there's lots of good comments here.

Again, there might be more to the story so insert disclaimers here.

~~~
alexandercrohde
Also, remote teams can be a world of difference. Even if you're pure of spirit
and think countries are just lines on maps it's really unlikely that they see
it that way too.

------
dahdum
I'd go about it like so.

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.

~~~
blunte
#3 - in some cultures a subordinate worker will almost always choose to leave
after their superior. This is probably not the outcome you want/expect.

#8 - you need to find a balance between crediting your team and making it
absolutely clear to management that your contribution was critical. Obviously
you do want to avoid the latter in front of "your team"; but in closed doors
or in management-only meetings, you should not sell yourself short... which
means sometimes you need to just boldly say, "I recognized X and chose to
guide the team to do Y, and that resulted in Z (a good outcome)".

~~~
dahdum
For #3, my thought would be working from home and on the weekend. Committing
code, updating tickets, emailing outside of work hours. Management type tasks
are easy to handle off hours like this.

As for credit, yes totally agree. In a group setting, they should be the first
to take blame and the last to take credit though.

------
dirtyaura
You are going to a war-time scenario (desperate crunch mode to ship a
product), don’t start to establish peace-time practices like code quality at
the same time.

First, make sure that the situation is a war-time scenario: hard deadline
(they rarely are) and shipping something (that enables sales, financing round
or collecting customer feedback) is more important than shipping the right
product.

In the war-time scenario focus is the key: reduce scope and ship only the bare
minimum. This is as much managing up as managing down.

Get to know the team quickly, understand each members strengths and
weaknesses. You likely need them all to succeed.

Daily task management and follow-up is essential. In the war-time you lead by
asking questions and making orders. Prefer former, do latter when needed. Many
(but not all) people like structure when under stress, so set it up if it
doesn’t exist, but don’t let it restrict them to perform. Get people excited
about shipping: even if you know the product is not great when the team will
ship it, try to have a few shining parts there that everyone can be proud of,
even if there are tons of ugly parts.

------
liquidcool
Hi Charles, what you are describing is what I specialize in
(outsourced/offshore software project rescue). I run a 4-part
audit/assessment:

1\. Client education, AKA managing expectations. Educating the client on the
_principles_ and challenges of software development. Most know very little
about this and it makes their job very frustrating. Every failure of
consulting is really a failure to manage expectations.

2\. Communication. How are they communicating, what are the problems? This is
the most important thing in software development (and business in general).

3\. Methodology review. How are they managing the project? What methods and
tools are they using? Are the tools configured, integrated, and automated
correctly?

4\. Developer practices. Mostly based on my programmer productivity talk.

You are focused on #4 (and some of #3), which is important, but I find the
first 3 way more important for "success." #2 sounds like your biggest problem.
When I hire developers (always 100% remote) I prioritize two things:
communication skills and discipline.

I'll give you one tip: static code analysis tools. This way the tool is
criticizing the code instead of you (of course, I agree with code reviews).
When I realized how useful this is I started giving talks on it.

Also, Gerald Weinberg's The Secrets of Consulting is gold:
[https://amzn.to/2JvDZnx](https://amzn.to/2JvDZnx)

------
SatvikBeri
The main thing to realize is that this is primarily a people-based challenge,
not a technical challenge. There's actually a good chance that some of the
team members know better practices but feel like they don't have time to
implement them.

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.

~~~
user5994461
>>> The main thing to realize is that this is primarily a people-based
challenge, not a technical challenge. There's actually a good chance that some
of the team members know better practices but feel like they don't have time
to implement them.

Not necessarily in this context. The project was outsourced abroad, probably
to the lowest bidder. It's possible that contractors were sold as developers
but have never developed anything before and don't know any good practice.

------
tmpz22
You're probably getting hired just to get this thing out the door, not to
spend sixth months training a team in agile development processes.

The fact that you're making this post at all indicated you're assuming a lot
of what the CEO requires/desires of you. Make sure you didn't make a gross
misjudgment of that. And hopefully you're getting paid a lot.

------
evadne
Cancel the gig.

You can not fix prior mismanagement with technical means and definitely not by
bringing in an outsider who probably also does not speak the local language.

In addition you will be limited in who you can hire locally if this is the
first time you are moving to a particular country. You will not have
connections that are necessary for identifying and retaining high quality
staff, should it be found that there has been some sort of acrimonious
interactions between the CEO and his/her local team which has impacted morale,
which essentially requires you to replace the entire team in order to fix.

So in your situation, you might be forced to try to fix the local team which
is a coin-tosser (50/50 chance of this working out), and entirely not
acceptable if an artificial deadline has been established.

Cancel the gig. Save the money you would otherwise have spent, and go on a
vacation in the same country if you must.

Now, if you’re mad and still want to proceed, you might do well reading
[https://www.marshallcavendish.com/marshallcavendish/genref/T...](https://www.marshallcavendish.com/marshallcavendish/genref/The-
FirstTime-Manager-in-Asia-revised-edi_B978_Singapore.aspx)

------
edmundhuber
I think it depends on what the CEO is really hiring you to do. Is it to turn
this team around, so that it can take on projects in the future without
stalling out? Is it to finish the project in as quickly as possible? I would
recommend talking to the CEO first to figure out exactly what he's expecting
from you, especially given that it's a hierarchy-oriented team/culture.

In my (and others', from reading other comments) experience, it is pretty
unrealistic to swoop in and fix everything at once. You need to establish what
you are being asked to do, and then make a reasonable step by step plan.
Changing attitudes about software development is very difficult and you need
to have a plan.

------
blackadder
I've been in similar situations in the past a few times and did a talk on how
I did it.

Video :
[https://www.youtube.com/watch?v=eYzk2BKeG9s](https://www.youtube.com/watch?v=eYzk2BKeG9s)

Blog Post :[https://www.hibri.net/2016/06/18/continuous-delivery-rags-
to...](https://www.hibri.net/2016/06/18/continuous-delivery-rags-to-riches/)

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.

~~~
bjelkeman-again
Also, don’t be surprised if the team was given a project which was really hard
to deliver with the team’s capabilities, and the CEO or his team leader,
should have recognised that in the first place, and they (CEO etc) will be
hard to convince that they are part of the issue.

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.

~~~
blackadder
There is a fine line to tread to make these changes whilst delivering. There
was never a point were we stopped everything to make all these changes. The
changes have to happen gradually, and they do take a long time, many months.
It involves changing people, teaching them new habits and helping them do it.
The habits have to be sustainable.

Limiting work in progress, forces the issue upstream. Managers are forced to
realise how much of a precious resource the team is, and why they are
struggling. Throwing more work at a struggling team makes it even worse.

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

You really shouldn't sign any contract without knowing your compensation,
role, goals[1], and position. It sounds like you really don't have a handle of
what your exact position is and the role you will play is really dependent on
that item. It might be impossible to achieve if you are relying on making a
logical argument to carry the day.

1) some folks would rather say "deliverables"

------
j45
Some things that have helped me manage teams and projects going sideways:

Learn about their positive and negative experiences before changing anything.
People are rarely as dumb as you think and often have to follow the
instructions of their former dumb managers. Don't be another assumptive
manager. Anonymous feedback forms during meetings are great for questions.

Position yourself as not their boss but being there to serve their needs, find
how to support them and ultimately have the project succeed. Many employees
are used to being mistreated overseas, some may not be able to handle this as
they don't get moving until yelled at, others will cry out of happiness of
dignity and respect. Strong emotional breakthrus are needed for turning around
a project and for trust to form.

Make change plans together so the change is managed and there is an ownership
in continuous improvement.

Create a culture of learning together and providing lots of mentoring and
training that they didn't get in the past.

Reduce the culture of fearing mistakes and introduce one of learning. Lunch
and learns are helpful to say this week I messed X up and learned Y from it.
Do it yourself too.

Get lots of resources to help them learn in their own time. Lynda.com,etc.
Make it clear your are here to help their personal and professional
development first because that will get everyone positive results on the
project.

Set the bar for work ethic. Nothing will move unless you do. You will find
people who align with your message, or those who don't, and it may be required
to replace some folks.

Rather than get into painting the sky magical colors, if your remaining
project scope is known, implement a ticketing system like Jira with a basic
workflow to teach the team how to record and build the defects. That will
likely get more done to start a change that you can layer agile, etc with in
the future.

------
headcanon
A lot of good points here, so I'll try not to be redunant. A lot of the best
practices you have listed are longer-term investments and culture changes. If
you just need to ship a project, then you and your team will need to figure
out how to make that happen, even if its full of ugly hacks. After its
shipped, then you'll have more leeway to start fixing bugs one at a time.

It also sounds like there's a huge political element here too, so of course be
aware of that. Definitely don't try to rock the boat too much at first until
you understand specifics of what is wrong. Overprescribing can be
demoralizing, and if the project still goes south then you're the one to be
blamed, since it was your idea to "change things". Not to say you should do
nothing, its a delicate balance, and one I would certainly struggle with
myself. Best of luck.

------
everdev
It sounds like you already have the problem and solution in your mind before
you land. Even if you end up being right it might be good to approach the
problem with a black slate and do discovery as if you know nothing rather than
with an agenda.

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.

------
TheMog
Personally, unless you're paid well enough to be a very comfortable
sacrificial lamb in this situation, I would walk away from it. This has "fall
guy" written all over it.

If hierarchy is important in that culture and you're not introduced as the new
boss, you're pretty much dead in the water from day one.

As other posters have said, until you figure out why the project is late (bad
project management, unrealistic deadlines from the start, not the right
people, trying to hit a moving target), going in an prescribing a cure without
understanding the nature of the problem isn't going to get you anywhere.

------
oliwarner
You have to be conscious of what has _caused_ the lack of these things, things
like tests and staging rules that you might normally implement at day-zero.

It sounds like they've been poorly managed, not necessarily just in getting
people productive, but in pushing back. A manager who serially misses agreed
to timelines is usually a yes-man. Might just be a character flaw, but some
cultures —especially in parts of Asia— are taught to be yes-men. Doesn't
matter if it's a lie, make the sale, fix problems tomorrow. And that's an
important issue when you're dealing with remote engineering, which is often
twice as hard to scope out anyway.

So whatever your goal to befriend or get respect from these developers, you
_have to_ work out how realistic their estimates are. You might actually be
nowhere near a product.

It may be that by the time you've worked out the situation, the actual
capacity of your developers, you need to have a candid conversation with
management to pull the plug. If you can do that efficiently and escape with
_something_ , awesome.

If they're competent but just historically over-stretched by their ex-manager
agreeing to crap they could never complete in time, you have a lot of carrot
to offer them. Better working conditions. Better education. Opportunity to
stuff their CVs with value, instead of continuing to work bug to bug to get a
job done.

But yeah, attempting to deliver without fixing any of this would be a tough
one for me. I'd have so little confidence in the code before handing it off to
QA. I fear the idealist in me would make it my first job to set realistic
expectations with upper management and push these deadlines until you're up
and rolling.

------
sopooneo
The first thing I would do is check your own personal network to see if you
know anyone that grew up in the culture of whatever country this dev team is
in.

In my experience, as far as culture, you really don't know what you don't
know. So it could be very helpful to get a brain dump of advice. Even if they
the person that advises you is not technical they could likely offer a lot.

~~~
svilen_dobrev
^ this.

"find a friend to be your senses" is my wording of it (from long ago).. And do
this in all possible aspects (of culture or else) - common-people,
company/companies, devs, management.. and once and again.

Technical stuff might be in dire state but is usualy fixable... unless
people/culture simply prevents it. So beware.. esp. of things you are not
told, like why these devs, why this project, why finish it, why now, .. why
you?

Fish starts smelling from the head first.

and... Westerners might not be too welcome everywhere. Watch and Listen..
before doing anything. YMMV

------
bm1362
I think this is an unwinnable position. Software projects are multi-faceted
and you’ve taken on the role as the savior- it’s not just lack of tests
bringing this team down.

I wish you luck but don’t beat yourself up if this doesn’t work out. This
sounds like you’re setup to fail.

------
ian0
Im afraid I have to agree with the negative comments, chances are its going to
be a complete disaster. But I ignored similar advice once and had a great
time! :D

My suggestions (SEA exp):

\- Brief your CEO on how she should introduce you. She should big up your
background, your skills, your accomplishment. Make it clear your here to help.
And if she is good she will pitch it in a way where your not appearing as a
firefighter or saviour.

\- _Start by telling everyone how unbelievably good they were to get as far as
they did._ Its likely they were working their asses off at bad salaries and
poor communications. The last thing they need to hear is how wrong they are
getting it.

\- The things you mention about hierarchy is ridiculously dependant on
geography. The right thing to do in Bangladesh could be the absolute worst
thing you could do in Indonesia. Both are hierarchical, but in extremely
different ways. You need location specific advice!

\- On the actual improvements just do whatever is practical to ship the
product. Try to see why they were tripping up on the basics and help them sort
it. If its extremely poor skills get your CEO to cough up and start bringing
on good guys to help teach. If its because people are pissed ease off the
pressure and improve the working environment.

A final note. Of the dozens of foreign owned companies in developing countries
I have encountered - I cant remember a single time a bad dev team was not as
the result of poor management. Typically from the foreign component or their
direct reports. Skills can be improved but only in the right environment.

------
BrandoElFollito
25 years ago I was given a similar possibility. Building a large team from
scratch in an emerging country.

There was a huge difference though : the company was international, had plenty
of money to burn and I could fail without consequences (as I see it now).

And boy, I failed. A few times.

The experience was extraordinary and it forged my future. I am today in a
position I would not be in if not these years and other similar opportunities
all over the world.

Let me please emphasize two thingd:

\- I was allowed to fail (it was somehow expected)

\- and I failed.

You have no experience in management, and especially not in international
management. Therefore you will fail. And learn a LOT.

If you are going there to learn AND fail - do it. It will be an invaluable
experience.

If you plan to succeeded, or at least may be impacted by failing, do not go.
Get dome eaqier experience first.

Having important work to deliver + problematic team + other culture +
inexperienced leader = disaster. Yhis means either clueless company or a need
for a burnout manager to sacrifice.

------
josario
Read The Phoenix Project book in the while you have to go there, and all of
your questions will become clear.

~~~
rutthenut
Great suggestion. No quick fix in there but does help set the context...

------
kaspm
I didn't see this mentioned elsewhere but I would also start by getting a
handle on all the outstanding tasks:

If there are tickets, read and understand all the tickets, organize them in a
way you can manage day-to-day.

If you're working off some other spec, start breaking it up into individual
tasks that can be managed on a spreadsheet or in a ticketing system.

If you're working off general guidelines without documentation (and you can't
run!), start by writing out all the tasks that need to be accomplished to
finish the project. Even if they are brief.

Now take the list of tasks and organize them into 2 "types"

Stories: Tasks that deliver value to the end user

Tasks: Tasks that are required or nice to have to enable 1 (Tasks or Chores)

Now prioritize those into different buckets

1\. MVP: if we don't ship this, the project will fail

2\. Nice to Have: Someone _really_ wants this but it's not MVP

3\. Phase 2

The more scope you can put into bucket 3 the more likely you'll be able to
deliver _a_ working, functional project on time. You will get more credit for
delivering something _good_ than failing to deliver the perfect project.

Your team will also thank you for taking significant stress off their plate
and for making them a success.

------
satran
Focus on results. I'm leading a team that wasn't delivering for quite some
months. We had couple of sessions on why we didn't achieve our results. We
used the 5 why method to find the root cause of problems. Once we tracked the
root of the issue, long pull requests became more manageable, we started
communicating better. We focussed on what we produce and eventually were able
to achieve our goals. Smart Leaders, Smarter Teams[1] is a good book to read.
His white paper is a shorter read with similar topics:
[https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Ei...](https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Eight-
Behaviors-for-Smarter-Teams-2.pdf)

1\. [https://www.goodreads.com/book/show/16305347-smart-
leaders-s...](https://www.goodreads.com/book/show/16305347-smart-leaders-
smarter-teams)

------
poulsbohemian
Do you speak the language / know the culture like a native? That is bound to
help you.

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.

------
amorphid
I've hosted a 30+ of couch surfers over the past year. They crash on an air
mattress in my studio apartment, so it's a tight space. Even though they are
grateful for a free place to stay here in San Francisco, it's easy for me to
say a very western things that my guests misinterpret.

For example, the word asshole. To me, asshole does not, and never really did,
mean the hole in one's butt. Asshole means jerk. At least it did until I
hosted someone from South Africa. He told me that in South Africa, my language
would be considered very profane profane. To him, asshole ONLY meant (still
means?) butthole. There was no overlap in how we understood the word.

So I recommend keeping your language as neutral as possible, relying on as
little idiomatic wording as you can. Say jerk, not asshole. Say it's raining
quite harc, not it' raining cats and dogs, etc.

------
trevor-e
It sounds way too late at this point to worry about stuff like modularization
and refactoring. Many of the things you mentioned are certainly important for
long-term success, but it sounds like you were hired to impact the nearing
release so I'd focus on that first.

I would start with the infrastructure stuff like you said, a staging server
and CI. If every dev has been relying on local builds, this will probably find
a bunch of issues right off the bat.

After a stable build environment is established, I would go over the
bottlenecks they currently face and work on freeing those up so they can work
more efficiently. Since you're so late to the game, you should focus on
enabling them to work faster to hit the deadline. All the other methodology
and code quality stuff you mentioned can come after that.

------
madrox
There's a lot of unknowns here, but here's what I'd do. It reflects some of
the top comments:

1\. Know your goal. If it's to meet a deadline, then documentation,
refactoring, or any other quality of life tasks won't move you closer. If
anything, it will sow confusion and make the team more stressed. Leave that
for post-deadline.

2\. Focus on the stress. Spend time with each team member 1:1 to figure out
what their stresses are. Come up with a plan together on how they'll address
it. Make sure they feel it's the right plan.

3\. Leadership isn't something that comes from title. You earn it by being the
person the team looks up to. Teams look up to the person that sticks up for
them and makes them feel powerful. In my experience, that transcends culture.

------
tynpeddler
There's lots of great advice here, one more thing I would add is make it clear
to the CEO up front that the deadline will slip. I would make this an absolute
and get the new deadline in writing, because if you use weasel words then the
CEO may claim that they misunderstood. Make it clear that even this new
deadline may change as your understanding of the situation develops. You
should also be the one to deliver the good news about the moved deadline to
the team. If the CEO is unwilling to accept this, then you should probably
walk away, because it suggests that they're still in denial about what is
happening.

------
atsaloli
You may get some inspiration from [https://www.codesimplicity.com/post/how-to-
handle-code-compl...](https://www.codesimplicity.com/post/how-to-handle-code-
complexity/)

Excerpt:

> It’s very tempting, if you’re a software engineering manager, to propose
> broad, sweeping solutions to problems that affect large areas. ... > > So
> what can you do as a manager...? Well, the trick is to get the data from the
> individual contributors and then work with them to help them resolve the
> issues.

------
royalghost
I would suggest that despite the country or the company or the culture you are
working, you have to lead by example that means first you have to work hard to
prove to the team that you are capable to lead them, both technical and
leadership.

When you lead by example, you set the standard for code, design patterns,
documentation, etc. and as you go along build the tools, infrastructure,
processes and culture.

Don't expect to change everything overnight, it will take time, be patience
and you have to trust people you will be working with.

------
hluska
If this is a hierarchical culture, I worry that the changes you propose will
be seen as a slight to whoever was in charge before you. Consequently, if I
were you, I'd go in as a teammate and get something out the door to build
camaraderie. Then, have an open meeting where everyone talks about the
project, what is working well and what isn't working very well. I'd frame it
as if there is nothing wrong, but that you could work together to improve
things.

------
asdfjslakdfj
You haven't even landed and you already have a solution in mind? The things
you list are long term goals and very cookie-cutter approach to running a
team. This might not go well for you if you expect to project your ideals onto
other people on the first day; especially a team that is already burnt out. I
would seek to understand the situation first from the team because from you
description, it seems like everything you know about the team came from the
CEO.

------
pan69
Reading through the comments already made, a grim picture is painted for you.
I agree with what @mikestew wrote. If you do happen to go forward with this
then I would suggest; focus on helping the team ship the product, not changing
the process (it seems to be to late in the process to make fundamental changes
to mindset). After you've shipped, then you can discuses best practises and
whatever in a retro and probably plan a refactor of some sort.

------
dasil003
Can you fix the formatting for this to not include code block formatting for
the lists, especially the second one? The side-scroll is unbearably long even
on a PC.

------
bsg75
> or another team member with no authority at all

"Responsibility without authority is like being up a creek without a paddle."

If you are expected to make improvements, you must be granted to power to make
changes. Otherwise neither your needs nor the company's will be met.

The current situation is apparently not working, and simply throwing bodies at
the problem is likely to make it worse. Insist on a level of control minimally
equal to the things you must deliver.

------
helloiloveyou
That seems like a very nice experience! You'll have to manage your personality
to not come off as know-it-all type of guy. The best I can tell you is to try
to understand each one of the developers as a person with feelings and explain
everything with love. That never fails. Also How to win friends and Influence
people is a book that couldn't be more special to this situation.

------
tnolet
Please, please, please pick up the book Peopleware if you haven’t read it.
It’s a classic for a reason [https://www.amazon.com/Peopleware-Productive-
Projects-Tom-De...](https://www.amazon.com/Peopleware-Productive-Projects-Tom-
DeMarco/dp/0932633439)

------
zubairlk
I moved from a developing country (where I worked 1 year in a software dev
environment you describe) to the UK. So I know exactly what you are talking
about.

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

~~~
cambalache
Be careful of not generalizing, I have lived in several "developing" countries
and at least half your points wouldnt make sense there. I would say treat them
as you treat an american team with some allowance for language/culture
differences.But that's it.

------
no1youknowz
> I accepted this contract because I like the country, the CEO and want to
> push myself to a first experience software lead.

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.

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

------
gwbas1c
One thing to consider: If there's an area of code you think is suspect, hold
review meetings. Keep the meeting to 3-4 people.

They're also a good way to learn when your suspicions about bad code are
wrong.

------
ryanwaggoner
Meta: these posts are a LOT more interesting if the person asking the question
bothers to stick around to clarify, discuss the answers they’re getting, say
thanks, etc.

------
lol_jono
> What first steps would you take ?

Quitting the job immediately.

------
marcus_holmes
I've just finished leading a company in SE Asia, so assuming you're somewhere
near there, this is what I'd say from my experience:

\- don't worry about the usual western alpha-coder crap or any defiance.
You'll be respected because the boss says so. They won't give you any of the
shit that a western dev team would do while they work out the pecking order -
the hierarchy is the pecking order. BUT... no-one will tell you the truth,
they will always tell you what they think you want to hear. Only ask open
questions (if they can say yes they will), don't ask for opinions (you'll get
whatever they think you want to hear). If you tell them to do something
stupid, they will never tell you they think it's stupid. They might not go and
do it, and hope you don't notice, or if you do notice that you will realise
that what you told them to do was stupid and you're not going to lose face by
mentioning it.

\- Authority and hierarchy are massively more important and more rigid than in
the west. I can't overstate this enough.

\- you will constantly run into communication problems. They won't tell you
when they don't understand you, but will nod and say yes boss and then go do
their best to guess what they think you said. Ask if they understand often,
and do that by the patronising-sounding "what did I just say?" or "what did I
just tell you to do?". It's difficult, because we only do this with children
in western culture, but it's necessary.

\- Use email and written comms waaaay more than you would with a western team.
It's easier for them to understand written english, and they can take their
time over puzzling it out. And you have a audit trail of what you said (yes,
they'll happily do the "you told me to do this" if they think they can get
away with it).

\- You will get automatic respect for being western (assuming you're white
that is - racism is real here). So I wouldn't worry so much about
demonstrating that the practices you want to introduce have actual value. That
will be taken for granted because they're western practices. Instead make sure
they're understood. That will be hard.

\- If your boss is not western, they will expect total and complete obedience
to their authority. Don't ever question them, contradict them, suggest
alternative ideas, or tell them what they just told you won't work, at least
in public and probably in private too. You will have to learn how to allow
your boss to keep face while getting the right result.

\- listen a lot more than you think you will have to. If something's not
working, there's probably a cultural reason for the fail that you're not
seeing. Listen harder and you'll discover it. Often it's easier to let them do
things their way even if it's slower and less efficient, because trying to get
them to do things the western way is too alien to their way of thinking. It's
surprising how often this is the case.

that'll do... you'll learn the rest as you go. Good luck :)

------
GoToRO
Can you fire people? can you reorganize the team?

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

