Offshore Inspiration

I’ve been working with our offshore team for the past 20 months, it’s been an interesting experience, and I would say of mixed success, and I mean that by my standards of success.

The project started by getting new developers on the team back in Shanghai, and of course a few training weeks, a few trips for face to face sessions, and another set of trips to move releases along when they start to run a bit late… I’ll most definitely write another post some time about the whole setting up an offshore team. Now 18 months later, we have had 3 succesful releases out, all of them on time, feature complete, delivered to the customers, so a success by any “external” measure, and I take pride on that .

With my past teams though, pride and ownership of the code has taken place, usually after a few months working together, maybe a succesulf release or two, maybe after working on a particularly hard problem, maybe after praise from the rest of the company, maybe just a combination of all.

This ownership and pride, usually comes in the way of:

• Taking care of the code, keep a clean code base. For example fixing those deprecated calls, and not just the one that you happen to find, but see if it’s used somewhere else.
• Checking out what other are doing, it is “our application” not just my lines in that application
• Refactoring as needed instead of copy/paste small pieces of code here and there
• Doing some “backburner” projects (Hey, what if I change this ? maybe I can get some more performance out of it)
• Enhancing the “misc” “util” kind of classes, so other benefit from commonly used tools.

With the current team, these actions usually take place propted by myself or Mr C. (another senior engineer based on the US). One of the common tasks for myseld and Mr C. is the code review, checking in what was checked into source control by the offshore team, and provide feedback and recommendations on the implementation, we have noticed how the team has grown, we’ve stopped sending the same feedback time and again, and usually later feedback goes more on the design and clarity of the code, so we know that they can take the feedback and make it part of the standard development, however the other part of the feedback goes into the ether, when we say, maybe that should be refactored to support the new xxxx or make a utility class thta can be used from X and Y… that’s the feedback that I believe is more about inspiring the team to make things better, not just make them work, and that’s the one where we have not been so succesful so far…

 Of course I’d be curious to hear your experience and how have you managed to inspire your remote teams, or if you are on the remote side, how have you been inspired to do so, to take ownership and pride on the product being developed.