Swarming and the Management of Remote Teams

NY2TX's picture

I'm interested in what people know or think about the concepts embodied in swarm intelligence and their application(s) to management of distributed work forces.

One of the foundational papers on the subject was written in 2001 (or at least published in the May 2001 issue of the Harvard Business Review) by Eric Bonabeau and Christopher Meyer, Swarm Intelligence: A Whole New Way to Think About Business.

I first became interested in it when I met a man who had previously been quoted in the article (he's currently the CoB of my company), and recommended that I read the article. Jim Donehey, former CIO of Capital One, used four rules to help ensure everyone in his organization was working toward the same shared goals: always align IT activities with the business, use good economic judgment, be flexible, and have empathy for others in the organization. Within the 4 rules, innovation did occur. What was created was an IT department that thought for itself in a very volatile business environment, but also one that understood boundaries of responsible business management. There is nothing rigid in this approach. The rules are meant to be bent (or broken given consensus or an obvious need for a change).

The point of all of this is that I'm in the process of completing a gov't contract in which my company has six subcontractors, including 3 national labs, dispersed around the country; my engineer is located close to where I (used to) live, on Long Island, and I am the only one in my company in San Antonio (or Texas - or south of Virginia for that matter).

In all fairness, while I use a few of the concepts, modified for my own management style and requirements, at least one of my management team believes that "swarm" is pure BS. It is a matter of opinion as in all else, this one gentlemen rarely disagrees with the strategy at hand.

Comments

NY2TX's picture

Isn't distributed work force

Isn't distributed work force characteristic of software development?

softwarejanitor's picture

Not necessarily.

Not necessarily. Distributed work forces can often be a bad thing because they can be an impediment to teamwork. Many things that are important to success in software development such as conforming to consistent design and coding standards, cross training, etc. all can become more difficult when developers and other team members are geographically or culturally isolated from each other. There are technical tools such as video conferencing and online collaboration systems which can help mitigate these things up to a point, but they don't come without cost and their own potential pitfalls either. All in all, I still think it is usually best when software developers, designers, etc. are closely integrated with the people who are using the software and share the same culture, etc.

NY2TX's picture

It would be function of

It would be function of setting the rules of engagement and defining expectations. To start with, each of the parts must understand the overall work to be performed and understand their individual roles. Then the standards of required communication are implemented. In my particular case the team was as follows:

- Program management and prime contractor in San Antonio
- Systems engineering and program technical lead on Long Island

Subcontractors:

- Idaho
- Tennessee
- Southern California
- Atlanta
- New Jersey
- Long Island

Customer in DC.

Complex technical issues, distributed workforce, mixture of research and commercial, 4 time zones.

softwarejanitor's picture

I'm not saying it can't be

I'm not saying it can't be done, or even done well, I'm just saying that distributed workforces face a lot of issues that a localized one doesn't. I'm familiar with the kind of thing you are talking about, my current employer has employees spread across several locations (US, Europe and India) and we are currently going through a merger which will add several more. Our customers (healthcare) are in all 50 states and for some other divisions (banking) are worldwide.

NY2TX's picture

"Rules is rules." To make

"Rules is rules."

To make something work, in almost any form or forum, the rules of engagement (or interaction) need to be set and enforced.

softwarejanitor's picture

That is true, but rules are

That is true, but rules are easier to agree upon and enforce in an environment where everyone knows everyone else and shares the same culture.

I could tell you some horror stories about how things can go wrong with communications in a widely dispersed environment, but I don't want to air all that dirty laundry on this forum right now.

NY2TX's picture

Somethings aren't meant for

Somethings aren't meant for open discussion. But I do look forward to sharing the "war stories" at an appropriate time and place. My situation was maybe unique, and maybe we got lucky. Not sure.