Last year, I was hired by the Stavanger based company Promineo to help develop their resource management software. Before that, I’ve worked in various industries: solar energy, security and surveillance, and shipping.
For all these projects, I’ve been part of an outsourced team. This comes with certain challenges, both from my side and yours. I have to gain your trust, and learn enough about the project, the code and the business to do the project justice. You have to lay the groundwork for me to do so.
Building this solid foundation should be your main goal in the beginning of the outsourcing project. I suggest you spend the first month doing the following three things for your new developers. If you do so, I can almost guarantee that everything will go a whole lot smoother.
1. Help the team understand the business domain
When you’re hired as part of an outsourced team, you’re hired to solve a problem.
Thankfully, Norwegians seem to understand this.
Hiring someone 8000 miles away to put a button where you tell them to put a button, is hardly a great use of resources. When I worked for a North American company, there was a culture of “I will tell you what to do, and you will do exactly that”. Norwegians are very different, and it’s not just their corporate culture. They genuinely care about our input.
To be able to give valuable input, though, we have to know the business domain, the mentality of the users, and what problems we’re trying to solve in the first place. The first month should have a focus on building a large knowledge base within the new team, which they can then draw on to solve tasks in a smarter way for the rest of the project.
When I was working for the oil business, I remember going to the Oil Museum in Stavanger. It taught me a lot about the industry and the product in detail – which was really helpful!
2. Let the new coders become familiar with the code base
In total, I’ve worked for 10 different teams around the globe, each with their own way of doing things. The code may not always be similar to the one you have in Norway – which means I have to get familiar with it. This way, I build the trust that I need to write good, complimentary code.
For Promineo, I spent the first few weeks fixing bugs, which is a great way to get to know the (10 year old) code base. It might take me just five minutes to figure out what’s wrong, but then I have to make sure the fix doesn’t compromise something else. Then, once I’ve fixed a few bugs, and know both the code base and the business better, I can start adding new features.
Start doing code review early, and keep it up throughout the project. For the first few days, the code review helps to make sure that the developers are practicing the project standard coding conventions and doing everything in the right way. If you have suggestions for changes, the earlier you share them, the earlier I can start to write the type of code you want.
When it comes to code quality, there’s pretty much no limit. If you keep looking, you’ll always find something new to improve. However, every project has a timeframe, so you need to find the sweet spot between quality and time.
I think it’s the developer’s responsibility to have a clear understanding of delivery deadlines, but long-term, this is easier when they also have a good understanding of the overarching business goals.
3. Get to know each other
When you outsource a project, you’re never only building software; you’re building a team. If you neglect this, you can never make great software. It’s not possible.
While having the right tools for video chat and detailed specifications helps, it’s still important to meet face to face. We worked four weeks for Promineo, then traveled to Norway for a real onboarding session. That’s the best way to minimize cultural differences and build real trust.
It’s a lot easier to talk freely when you’ve seen how the other party works, how they eat, how they live. When you’ve gone hiking together for a weekend or met your co-worker’s family, that helps build an image of the person in your head and not just a professional teammate. In my experience, that counts a lot.
When they say “I have to go pick up my child from school”, that makes a lot more sense when you know those parts of the culture.
Once you know each other better, it’s helpful to bring everyone together in a room to discuss complex, architectural decisions. You can do it over a monitor, but those initial intellectual discussions are easier when you’re in a room together.
Then, when we return home, we have the trust and the knowledge base needed to build really great software.