Ask HN: Going to lead a struggling dev team in a different culture, now what?
One reason to bring me in is to implement good software development practices to the team. They are seriously lacking on this aspect: no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming, the list goes on.
On the cultural aspect, the team is certainly stressed and I wouldn't be surprised if a few members will be defiant about seeing a Westerner joining the team that late in the project. Depending on how the CEO will introduce me to the team, I'm either the boss, am respected by default or another team member with no authority at all and can't rely on status to move things forward. Hierarchy is extremely important to this culture.
I can't just impose things: I need to sell good practices to the team so it becomes the natural next step to implement them.
It's going to be hard to implement a full software dev pipeline in such a small timeframe but I'd want them reach the point where:
- the project is shipped
- they understand why naming is important
- they modularize their code
- they do stuff for a reason (no meaningless SO paste)
- refactoring becomes a reflex
- mandatory code reviews, especially my own code. It seems to me like a good way to show the team how you refactor code properly, will make me meet and talk closely to the devs and will, hopefully, inject a sense of collective code ownership.
- making it very clear from the very beginning that *I* will be the one to make efforts to make myself understood: I know that some of them have a below average English level and are not comfortable to speak to foreigners
78 comments
[ 4.3 ms ] story [ 145 ms ] threadVideo : https://www.youtube.com/watch?v=eYzk2BKeG9s
Blog Post :https://www.hibri.net/2016/06/18/continuous-delivery-rags-to...
There is no one way, every team has been different (for me), it what technique you use depends on context. They key themes that stand out for me are
1. Limiting Work in Progress (focus on delivering one thing at a time), creates slack time, to learn new practices and start writing tests.
2. Focus on learning, don't expect everything to fall in place pretty good ( it took us about 3 months to even to get to a good starting point)
3. Pair and help them out.
Also your list of things look like something that would take a rather long time to implement (many months), especially if you have a late project to deliver on at the same time.
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.
I wish you luck but don’t beat yourself up if this doesn’t work out. This sounds like you’re setup to fail.
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!
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.
You almost certainly will find some people who already long for what you're going to advocate.
(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.
> 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 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.
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.
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.
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.
"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
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).
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 suspect that you are young. Only a young/naive person would take a job on these points. From my perspective from a 40+yo (with 20+ years exp), this is very foolish.
> They are struggling with a project and the deadline is close.
You should really tell us the backstory. Unwittingly, you have made yourself the fall-guy. Now your "boss" can surely put the blame on YOU when this goes south.
> They are seriously lacking on this aspect: no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming, the list goes on.
I hate to use the word incompetent. But lets call a spade a spade shall we? In the little to no time you have, you cannot expect to work miracles overnight. Especially when you are so new to being a software lead.
Talk to the wrong person, in the wrong way and it's all over. Depending on where you are going. Losing face is quite serious in some places of the world.
What happens if you get into a situation where they cannot say no. So instead they say, not now or maybe it isn't the right time to implement X. Now you've stalled and the project fails.
Honestly, my advice would be to walk back this situation as best as you can. You want your first project lead to be a simple project that can be controlled and taken from conception to shipping with the least amount of issues.
Not this baptism of fire, which you WILL get burned. There are so many variables in play that you won't be able to control ANY of them!
> How would you handle this situation ?
Very simple. Talk to whomever gave you this assignment and tell them you have thought about it/taken outside council and it was foolish of you to accept.
Let the project fail. Let it fail very hard. Let the project owner bask in it's failure.
Only when you are asked to rescue the project, then you can submit a document detailing how it could be rescued. How long it may take to do so, the budget, the team members you need, etc, etc. You make it clear that it's only an estimate since you have not seen the codebase.
Then and only when you get the codebase and do a thorough examination of it, then you submit a revised proposal.
If you are successful in a bid to rescue it. Once you have control of the project you can implement your dream wish list, etc.
If you are unsuccessful in getting the project. Well, let it burn. It's not your head on the chopping block. Move on, that project lead will come some day.
The 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 other factor to be aware of is when people's income and livelihood is at stake they will fight tooth and nail about everything. If you give the team ownership in creating the solution and make it about co-creating the product you might have better long term success.
However, if the deadline doesn't permit that, then the short term solution is to map out a process like you described and find out who's on board and who's not. Remove those who offer resistance from the team because an anti-team player is death for a deadline.
Feel free to pm me if you have more questions
List of issues I can think of...
1- In some cases, people in developing countries usually have a short term thought/goal. Like myself. I'm just here until I can apply for Masters in xyz country or immigration to lala-land and get out of here. Brain drain is very very real and very very obvious. People change far too quickly. And because there is no handover/software dev process. A lot of stuff is re-done.
2- We just have never ever seen good practise/experience to know any better. In the UK, there were people next to me who had been engineering for 20+ years! I didn't have access to that level of engineering/experience. I'm talking about Engineering, 20 years of coding/design experience of building/shipping stuff. The senior guys are still there. They just drift to management as engineering is dirt cheap.
3- I'd recommend listening a lot at first. There will be one or two good people who others in that team will be looking up to. Focus on those guys and explain your changes to them. They'll explain it to their fellows in their language. And there will be quiet people mostly because of language barriers.
4- Take baby steps. (or one big drastic step)
5- We don't think in English. That becomes a problem at times because people in English speaking countries think in English, learn code in English, speak in English etc. We might know English. And we write text/code in English. But we actually think in our own Mother tongue. Hence the focus on convincing a few key people who others are looking up to. And then they can talk in their language.
6- Build trust
7- Sometimes the gentle approach doesn't work and you need to use the stick approach. This is how its going to be done. The CI system is going to enforce this policy. I'll do all merges and this is the list of things you need to make sure work before sending a PR.
8- Establish your role with the CEO and make sure the CEO communicates everything to the team. Including the fact that there will be some time invested in improving software methodology itself. Otherwise, you'll be in a constant battle for justifying things.
9- In the developing countries, overall, people are in a higher stress state. It can be any number of things most commonly financial stress, family social issues, marriage issues.
10- Age matters here. Not technical/expertise. And if a bunch of people came from one University and another bunch from another, it matters.
11- Notice who eats lunch with who.
12- Build trust. Learn a few words of the local language. Try to say a few words. This usually results in a bout of laughter though.
I can probably go on n on. But I think you have enough
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"
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.
I can't tell you how important 3. is.
Things are certainly different if you are an established leader building your own team in a stable company.
#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)".
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.
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.
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.
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 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.
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.
1. https://www.goodreads.com/book/show/16305347-smart-leaders-s...
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.
"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.
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.
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.
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.