This chapter is from the book
This chapter is from the book
This chapter is from the book
Teams as Ecosystems
A software project sets up a small ecosystem made up of personalities from diverse cultures. We have seen some elements of the ecosystem, including
Walls acting as barriers and open spaces acting as conduits
People in their professional specialties acting as interacting subspecies
Individuals with strong personalities changing the way in which the ecosystem works
Everything affects everything: the chairs, the seating, the shape of the building, whether people share a native language, even the air conditioning.
Lizards and Penguins
At one company, moving from our old building to a new one nearly caused fights.
In the old building, we each had a private office, and each office had its own thermostat. In the new building, we would still have private offices, but there was only going to be one thermostat for every two offices. Each adjacent office pair had to use the same temperature setting.
Suddenly, the workforce polarized into those who liked warm offices (the "lizards") and those who liked cold offices (the "penguins"). People were jockeying for positions so they could share the thermostat with someone of similar temperature preferences.
Every job role and every person affects every other. Key individuals play a more significant role in shaping the ecosystem than others. They focus or, more frequently, block conversations. When they leave, the entire network of relationships changes.
Each project's ecosystem is unique. In principle, it should be impossible to say anything concrete and substantive about all teams' ecosystems.
It is.
Only the people on the team can deduce and decide what will work in that particular environment and tune the environment to support them.
If the people on the team understand some key characteristics of humans and of methodologies, they can look around, introspect about what they observe, and construct a best first guess as to what conventions and policies might work well for them, suiting their own strengths and weaknesses.
The people on the teams will naturally reexamine and adjust their conventions over time, periodically or whenever a major event changes their ecosystem (as when a particularly influential individual joins or leaves the organization).
The set of conventions and policies I refer to as the team's methodology. As we will see in the next chapter, a methodology is a personal thing—"a social construction," to quote Ralph Hodgson of IBM.
Considering the methodology as the team's own social construction is useful. It highlights the idea that no methodology will work "straight out of the box." The team members will have to adapt both themselves and the methodology to work together to create their own, local, effective ecosystem.
Ecosystems and methodologies have this interesting characteristic in common: If the team members construct many complicated rules for themselves, they tie themselves to a narrow ecological niche.
However, narrow ecological niches are notoriously fragile, and the market has a nasty habit of changing the terrain around a company. The many rules that ensure effective behavior in one ecological setting are ill suited for use in another.
In biology, we use the phrase "become extinct." In business, the phrase is "go out of business."
If, on the other hand, the team creates and periodically updates a few well-placed guidelines, it can draw on the intelligence, pride-in-contribution, communication, and spontaneity of its members. The people will adapt those guidelines to the situation at hand, achieving robust behavior in the face of technological, social, and market surprises. Dee Hock, designer of the highly decentralized VISA system in the 1960s and 1970s, said this:
"Simple, clear purpose and principles give rise to complex, intelligent behavior.
"Complex rules and regulations give rise to simple, stupid behavior."