Ask HN: Going to lead a struggling dev team in a different culture, now what?
78 comments
"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!
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!
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.
You almost certainly will find some people who already long for what you're going to advocate.
IMO this would be best. Don't go gungho and fix everything when you first join in OP.
this.
I've seen so many "senior leaders" jump into a project and try to implement these types of "textbook processes" when in fact they don't solve any of the issues at all.
The project just gets dragged out, etc.
I've seen so many "senior leaders" jump into a project and try to implement these types of "textbook processes" when in fact they don't solve any of the issues at all.
The project just gets dragged out, etc.
Great suggestions (and book suggestions)!
Maybe start introduction with your pull requests, not destructive criticism?
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.
(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.
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.
> 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.
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.
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.
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.
This. Unless there's a competant project manager already in place and they are asking for a good technical lead to be put in place, it's highly likely a last ditch attempt to pull something magical off. If there's no PM then that's what the company needs, not a technical lead. As others have said, the teams under stress and the delivery date is coming up, so the only thing to really change is the scope and project tracking.
Yea, that was my first thought: where on earth is the project manager in all of this?? You’re not going to get back on schedule by preaching the good word of “best practices” this late in the game. That ship has already sailed.
Absolutely this. OP has a Messiah complex it seems. OP don't be their Martyr too!
I think you are setting yourself up for failure:
Is the goal to ship the project on time, or reform the team to OPs ideal of a high performing team, and maybe deliver something someday? I wager the CEO wants the project delivered pronto.
Otherwise, cut scope relentlessly. If delivery is the goal, deliver something, then iterate.
I think you are setting yourself up for failure:
Is the goal to ship the project on time, or reform the team to OPs ideal of a high performing team, and maybe deliver something someday? I wager the CEO wants the project delivered pronto.
Otherwise, cut scope relentlessly. If delivery is the goal, deliver something, then iterate.
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.
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.
This
Firstly this is not about the team. It's never about the team. Even if these guys are incompetent and flailing, a competent upper management would have seen it and dealt with it ages ago - long before this hail mary pass you are being handed.
So that means upper management are not up to the job. They could not spot a three-ring disaster, so they won't spot brilliant effort from you.
Now if you are not looking at the team but at the project management the questions become very different - forget code reviews, start asking
- what is the business value for the project - who pays for the project, who gets the benefits of the project, - and what are the utter core deliverables that will get them that value
If you don't know this you should not get on the plane
Next, those people identified above (presumably the CEO and his stakeholders) have three options - chnage the team, chnage the scope, increase the timelines
if you fly out to become the team, you will get changed when you cannot deliver
So pick your battle very carefully and be very sure the CEO or other stakeholder is fully onboard with cutting scope and extending time to get it over the line.
Firstly this is not about the team. It's never about the team. Even if these guys are incompetent and flailing, a competent upper management would have seen it and dealt with it ages ago - long before this hail mary pass you are being handed.
So that means upper management are not up to the job. They could not spot a three-ring disaster, so they won't spot brilliant effort from you.
Now if you are not looking at the team but at the project management the questions become very different - forget code reviews, start asking
- what is the business value for the project - who pays for the project, who gets the benefits of the project, - and what are the utter core deliverables that will get them that value
If you don't know this you should not get on the plane
Next, those people identified above (presumably the CEO and his stakeholders) have three options - chnage the team, chnage the scope, increase the timelines
if you fly out to become the team, you will get changed when you cannot deliver
So pick your battle very carefully and be very sure the CEO or other stakeholder is fully onboard with cutting scope and extending time to get it over the line.
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.
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.
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.
If you're going to fail though, this is a setup for a spectacular explosion!
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.
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.
#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)".
#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)".
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.
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.
This is an outstanding list and should be required learning on every software manager's todo.
I can't tell you how important 3. is.
I can't tell you how important 3. is.
My personal feeling is actually quite different. I tend to respect a leader much more as a professional and as a person if they are able to deliver really great work within sensible working hours, leading by example with effective and sustainable work habits.
I differ, OP is a foreign gun entering a company already in crisis. They will undoubtedly be paid much more than the local developers, and absolutely cannot be thought to work less than any of the team they hope to lead.
Things are certainly different if you are an established leader building your own team in a stable company.
Things are certainly different if you are an established leader building your own team in a stable company.
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.
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.
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
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
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.
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.
>>> 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.
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.
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.
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.
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...
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...
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.
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.
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
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.
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, 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.
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.
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.
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.
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"
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"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
^ 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
"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
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).
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).
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.
I wish you luck but don’t beat yourself up if this doesn’t work out. This sounds like you’re setup to fail.
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.
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.
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.
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.
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.
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.
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...
1. https://www.goodreads.com/book/show/16305347-smart-leaders-s...
1. https://www.goodreads.com/book/show/16305347-smart-leaders-s...
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.
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'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.
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.
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.
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.
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.
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.
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.
[deleted]
[deleted]
You may get some inspiration from https://www.codesimplicity.com/post/how-to-handle-code-compl...
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
"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.
[deleted]
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.
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...
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
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
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.
> 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.
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.
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.
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.
They're also a good way to learn when your suspicions about bad code are wrong.
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.
> What first steps would you take ?
Quitting the job immediately.
Quitting the job immediately.
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 :)
- 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 :)
Can you fire people? can you reorganize the team?
[deleted]
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.
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.
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:
My solutions for this:
How would you handle this situation ? What first steps would you take ?