Be careful techies, I'm Dutch!
/How should Dutch software project leads manage and run their outsourced software development?
This was a question that came up when we published our recent article about how Dutch software project leads are different than others (and why those differences are good). In today's article I will try answering that question based on our experience in working in software projects from the Netherlands for more than a decade.
Warn that you are Dutch (and you are direct)!
There is no denying it, you are likely to be perceived as difficult (or at best: different) when you use your natural directness. This perception can make things go wrong, and lead members of your offshore team start to think your sentiments as always negative. Software is all about collaboration and a perception like this will make collaborative work hard and result in a bad software.
As I argued in that other article, this directness is really your asset in a software project - so don't even think about changing (or "adapting" as some people may say, stretching the agile philosophy too much). To address the risk of a negative perception all you have to do is remind your team at the beginning (and then time to time) that you are Dutch and the Dutch are known to be direct - they don't usually mince words. You will find that your software team actually appreciates this directness - once they understand that this is how you are from a cultural context. Any good software team understands very well the need for constructive criticism of their work. And once the fear of negative emotion is gone it will make things simple. It has always been that way with all of our projects.
Beware of deadly high PDI
PDI is power distance index. Which, in the context of software development, can be explained as a measure of:
How unlikely is a junior programmer to tell a senior team member when he spots an obvious error in the latter's code?
High PDI means team members stay silent and don't speak up their concerns. PDI varies by nations. And it has been shown (and you really don't need data for this, you can feel it) that countries in South and South East Asia have high PDI. Which translates to the fact that your developers are less likely to speak out against you even if they know you are wrong. Check out our article about the risk of PDI in software projects.
This becomes an acute issue when you mix a Dutch person as the project lead/owner/client and an outsourcing team in a high PDI country. The Dutch person speaks out with directness that is her natural instinct, the high PDI "stricken" developers start to take her words as the law - so there is no debate, no arguments. A software cannot be made without debate (and we say even fights) - and the situation above removes those essential debates leading to bad design, bad technical decisions and thus bad software.
So what can you do? Difficult to answer this. You can of course hire a company who has a culture of speaking out (and thus low PDI), for example us (ahem!). Kaz Software does a lot of things to keep the PDI low (check out our article about this: Killing PDI ), and so does many other companies who recognize this threat. The other option is to create this awareness yourself within the team, particularly the team lead or the interface person. If the external team lead understands this she can then mitigate the risk within the team.
Insist on visibility of day to day workflows
This is important in any outsourced software project, but particularly so if you are Dutch. This visibility will give you data to act on, take corrective steps on a much granular level. This would reduce a lot of friction that are likely to happen if you see results after long periods.
Insist on making the task management/issue tracker available to you online. You should be a user in the system and be able to add/modify/comment just like any other team members.
There must be (as with any project) a build system that lets you build and use the software at its current state. A dev and a QA server should let you see and use the software at any time. And you should set aside dedicated time to play with the software regularly (ideally daily) and give feedback on what you see. This is a basic agile step, but also an important step to prevent friction.
If you have software people on your side, the code repository should be regularly used to compile the application being built independent of the build system that the dev team has. This will let you identify technical issues early in the process.
A weekly call is a must for any software project, but consider daily calls too if you can keep them short (otherwise they become detrimental to the workflow).
Break the ice
I've saved the easiest and the best for the last. Most of the time all you have to do is just create a good relationship with the team. If you can break the ice, everything else becomes that much easier to do.
If your budget permits visit the team, do some activity away from work together. Even a trip to the local food street and just hanging out with the team will do wonders. If a trip out is not possible then consider doing a video conference together with team and make it a non-work thing. It could be a simple introductions and sharing of stories. Tell a funny story, joke a bit and the rest becomes easy.
Distance makes human relationships seem rigid and artificial. Add to that the cultural difference and your infamous directness, things can seem very non-human-like. Break the ice, humanize the endeavor and you'll see that things are much simpler than it seems.
Before I leave: we are doing an ebook: "Guide to happy software outsourcing" where we will summarize all the little tips that we have been writing about. Leave your email address with us and we will email you when it's ready.
