Not all classes are sets, and not all groups of entities with agency are teams. So when is a group of agents a team? The short answer is, of course, when they are more than the sum of the parts. Teaming is a topic dear to us at Barnstorm for two good reasons: first because a main objective of our research is to make autonomous agents act like a team; and second, since we ourselves need to act as a team to achieve our research goals, we are constantly looking for ways to work together better.
Our research focus is on teams of agents that have limited connectivity. And coincidentally we ourselves have chosen to work as a geographically diverse team, foregoing some of the fast communications that come with sharing a common office. Granted, the distance crushing communication power of the modern internet, we can work similarly but not quite the same as traditional co-located teams. Both in our research, as in our work habits we have realized that new ways of collaborating are needed.
The 18F group, the software development skunkworks of the GSA, has also decided to operate in part as a distributed team. And they have made a great job in codifying and explaining the best practices they have discovered. Their blog is a great resource that we leverage constantly. See for example Making a distributed team work for a great take on the topic of this post. Here’s our version of their team picture:
It is very illuminating to live the problem you are trying to solve. It’s a sure way of coming up with fresh insights that can quickly be reduced to practice. The difference between classes and sets was introduced to solve paradoxes that arose from the old thinking. At Barnstorm we are introducing new ways to define and compute plans to solve problems that arise when extending old thinking about centralized planning into strictly distributed teams.
If understanding the fundamental rules of teaming, and making it happen for machines and people alike, think about joining us, wherever you are. (Drop us an email at email@example.com)