necessary but not sufficient

This is an old list I wrote out, on what is necessary for a successful offshore partnership.

  1. Dedicated on-shore resources
  2. Investment, not quick fix
  3. Additional hardware and bandwidth, by resource
  4. Formalized KT plan, both sides.
  5. Formalized communication plan, both sides.
  6. External oversight and goals.
  7. Documented criteria for success.
  8. Face time (both ways)
  9. Start a wiki
  10. Have the infrastructure in place
  11. Have escalation plans in place (24X5)
  12. Interview the leads.
  13. Hire high on the food chain

Self Funding

So, I had an idea the other day – It may in fact have been given to me, but it’s hard to say. Me and one of my guys were talking about a way to build a contract, where we got a pro-rated discount, to be credited at the end of a billing cycle, so if you had 50 people on staff, you’d pay $x, and if you got to 60 people, the vendor would give you a credit for the next month, of, say $12,000. 80 people gets you $25,000, etc. It comes in as a credit.

The clever bit is that you can use this to build an incentive structure for your global sourcing team – the guys who run the program. If you set up the vendor partnerships with this in mind, you can create a system that self-funds growth. The lines of business will pay a set cost, get labor arbitrage, and all the goodness of the “program”, and the program folks will have incentive to grow the team, in order to get more discount funding, so they can implement new programs. You’d probably have to give the program seed money, but you could get scale that would spin off “profit” internally, and use it to fund more global heads, fund more programs, pay T&E, etc., or eventually, spin discounts back into the business.

It’s perverse, but big corporations breed perversity, so it’s really just a clever adaptation to a perverse environment.



In working through the details of a "best practices" program I'm implementing with my team, I had an "Eventual Master of the Obvious" moment this week.

In the phrase I manage a remote team, the emphatic break down is like this:

Manage: 80 %
Remote Team: 20%

I drew a nice chart, that looks like pac-man. (I'll see if I can do it electronically and post it here some time soon...)

This is simple, but is a profound key to the problems I've been trying to resolve with management of remote teams. The place where most remote teams, and most outsourced efforts fail is in management. When I look back to all the failed projects and failed partnerships I've picked apart over the years, the common thread is bad management, not bad staff, bad partners, or bad engineers.

Years ago, The Mythical Man Month talked about the common problem in our industry - promotion of talented individual contributors into management positions. Skills writing code or designing product are not in the least predictive of skills in managing other people who do the same thing.

Many of the remote teams I've put together through time have been managed by people who were great individual contributors, but who hadn't mastered the 80th percentile of their job -- effectively managing.

Most of the "best practices" I've been pushing are in point of fact "management" best practices.

In the 20% of stuff that changes because of remote or outsourced staff, it probably breaks down equally along cultural differences (10%) and practical differences (10%). But it's not the major part of the job, and if you're in charge of remote teams, you shouldn't act as if it is...