Managing distributed teams (Part1)

We live in a world of outsourcing.

I wake up in the morning and brush my teeth with a Chinese manufactured toothbursh - which I bought in Walgreens - whose entire real-time accounting system sits in India. If I have a problem with my credit card payment for the damn toothbrush, I call a team in Bangalore!

Generally these disparately located teams are managed by some team in the US. But, I use the word “managed” in a very loose sense - what exactly do we manage?

The people? - They’re sitting 7000 miles away!

The process? - You can define the process all you like but in the end a locations culture overrides the documented process

The Requirements - YES! - this aspect of development we would definitely exercise some control over, but, for one to provide detailed requirements at any given time is extremely difficult and you cannot scale this logic to a large project where it would be impossible to have a list of requirements ready to chuck over the wall in the beginning. So what is the solution?

I feel it is imperative that managers of these projects be extremely talented technical people (engineers over psychologists - not because I am biased) just beacause one needs to:

1 have a clear understanding of decomposition and how that would effect the output at any given time

2 have an understanding of conceptual integrity and at the same time architectural flexibility

3 finally have a very firm understanding of the Problem Domain

My belief is that one can attempt to monitor and control these projects to the nth degree (fancy spreadsheets, amazingly complex statistical tools, scope matrices, doneness matrices and other perverse forms of wastage in software development) but if the managers do not get it then you will get nonsensical outputs that are delayed and over budget.