​​








I 
​I had the opportunity to listen to Mark Mortensen and Heidi Garner at a Harvard Business Review event a few weeks back.

Mark focuses on team level collaboration and suggests doing this effectively, especially in ‘4D’ (diverse, dispersed, digital and dynamic), ie more networked, teams is about have a compelling direction, a strong structure, a supportive context and a critical fourth condition: a shared mindset. This last condition is required in order to avoid two corrosive problems—‘us versus them’ thinking and incomplete information. In these 4D teams, team members tend not to perceive themselves as one cohesive group but as several smaller subgroups. We need a shared mindset to avoid seeing our own subgroup more positively than others.

Geographically dispersed teams have particular issues and Mortensen suggests that when two geographically distant groups are unequal in number, the smaller group can be disadvantaged.

However, when just one of the team members were located away from the rest of the team, their role seemed to promote better cooperation, better communication, and better outcomes across the team.

Mark also studies multi team membership which formed much of the context for the HBR event.

We had a conversation about whether managing this should be a line manager or individual responsibility, and later I chatted to Herminia Ibarra who suggested systems like 360 degree feedback could help. For me, it’s about implementing communities alongside projects, so that people have a home, and somewhere to discuss these sorts of problems. But of course, that has the potential just to add over commitment too. ​

Yesterday I attended my fourth year of the Peter Drucker Forum conference in Vienna, again via the live stream. The most interesting of the morning’s sessions for me was from John Hagel at Delotte’s Centre for the Edge, talking about the need to redefine work. If jobs are just about processing tasks then this can be done better my machines. Instead, work should be about identifying and addressing unseen opportunities to create more value.

Hagel mentioned one consequence of this needs to be a focus from business process reengineering to business practice design, and I’ve been reviewing some of their recent articles on this.

Their suggestion is that this offers more opportunity than business process design because much of the most important work of many organizations today is no longer routine or even predictable. When conditions and requirements shift constantly, processes fail. So we need to move beyond process.

In this environment, frontline workers could have to work together in order to address them, since an individual alone will be less likely to effectively solve an issue or develop an opportunity: “Any one individual will typically be less effective at developing and delivering creative solutions to address them than a small group working together in deep, trust-based relationships. And while informal collaboration can still be valuable, the imperative to learn faster will likely drive workers toward more sustained collaboration over time.”

Therefore, instead of processes, Deloitte recommend focusing on the work practices of frontline workgroups:
“A practice is the way work actually gets done, the activity involved in accomplishing a particular job. Practices are not typically codified. They are mostly tacit and emerge through action—for instance, there’s no learning to ride a bike except through the act of trying. Practices tend to be context-specific and are constantly evolving—much like today’s business opportunities. They can be difficult to articulate; they don’t translate into a practice manual.”

“A workgroup pulls together three to 15 people working interdependently to deliver a shared outcome that could not be achieved without all members working on it together. The members spend the significant majority of their time interacting with each other, formally and informally, on tasks that cannot be highly specified or sequenced in advance.”
Deloitte also suggest nine workgroup practices which accelerate performance improvement:

• Frame a powerful question
• Seek new contexts
• Cultivate friction
• Commit to a shared outcome
• Bias towards action
• Prioritise performance trajectory
• Maximise potential for friction
• Eliminate unproductive friction
• Reflect more to learn faster.

​These groups aren’t the same groups as high performing teams: “The organizations that learn how to get on an accelerating performance trajectory—where they continuously develop new and better ways to deliver new value rather than becoming more efficient at delivering the same value—could be the ones that thrive in an increasingly unpredictable world, one in which a strength can rapidly turn into a vulnerability. The practices that aim to generate high performance as typically defined within an organization—delivering the results that leaders expect—are unlikely to generate accelerating performance improvement and may actually hinder it.”

Deloitte describes them as ‘edge workgroups': “frontline workgroups that are pushing the boundaries and limits of performance improvement to accelerate performance improvement while addressing unanticipated challenges or opportunities. Edge workgroups focus on their performance over time and might sacrifice short-term efficiency to achieve higher performance over time. They attract people who are committed to learning how to make more and more of an impact. Edge workgroups are characterized by deep, trust-based relationships and mutual accountability. While few are today, all frontline workgroups could eventually become edge workgroups.”

I’d also suggest that they are decreasingly likely not to be teams, and increasingly are going to be networks or communities of performance. Deloitte note the need to move from silos to networks but suggest “this may require organizations to support practices that let individuals be much more networked across workgroups and across organizations so that workgroups can engage with each other to help accelerate performance improvement.” I think the workgroups will increasingly act as communities and networks too.
In fact, this is played out in Deloitte’s case studies:

The Performance Network
Royal Caribbean Cruises Newbuilding & Innovation workgroup focuses on structural design elements of new ships. The activities of the workgroup members are interdependent and the ship / its experience is an output of the entire group. However the group’s work is not about proposing all the designs or implementing them but ensuring the coordination of everything that is agreed, challenging each other and collectively pushing boundaries: “The group uses the shared outcome to define ambitious ends but not the means. Members don’t micromanage or focus much on key performance indicators in the day-to-day work.”

In terms of membership, the workgroup consists of 12 employees, including architectural designers, architects, naval architects, technical experts, financial specialists, and program and project managers, but also 5 design consultants, 12 members of other firms (providing 60-75% of their time) and executives, so over 30 people in total. This is a large team (double the maximum for a true work team according to Deloitte) though I think it could be considered to be a small network too, with the small size allowing all network members to know each other and behave almost as a team.

The group works across many tight deadlines, global operations, multiple time zones, cultural differences, and vacation schedules, with people working mainly remotely except for during their ‘charrettes’—“intense periods of collaborative design rooted in the culture of architecture. In a charrette, all workgroup members gather in a conference room at headquarters until they’ve made sufficient progress.” I think that outside of these times, group members are working mainly independently, co-ordinating their work, but probably collaborating mainly with others within their own functions. Work also spans multiple ship building projects so if this is a team it is a process based team not a project based on. But the case study is supposed to be demonstrating practices not processes, so I don’t think it is a process based team either.

Another reason I think the group is a network is that its key objective is to bring people together to steer the work, not get a set piece of work done by certain people: “The group attracts, and actively recruits, a particular type of RCL employee: dreamers who are also drivers. Passion and a growth mind-set are qualities they seek because members need to challenge each other and collectively push boundaries to achieve innovation in ship design. We’re looking for candidates who want to grow and develop with us. To work in an environment where they’ll be challenged to take things to the next level, where there’s an opportunity for their voices to be heard.”

They also “bring in designers across a range of design backgrounds, as well as futurists and trend forecasters, who challenge members to rethink their assumptions and expand their sense of the possible. For inspiration on assembly practices, for example, group members have turned to engineers in the auto industry. For cabin design inspiration, they’ve tapped the work of airline designers who deal with even more confined spaces.”

So their focus is outside of the group, bringing in new ideas from outside of the organisation, combining them creatively across disciplines, and providing the basis for work in the rest of the organisation. “Workgroup members are constantly expanding their influences to gather inspiration for new ship designs. They spend a significant amount of time in new and stimulating environments, both within and outside the cruise industry.”

And “To help push members’ thinking, the workgroup also looks outside, aiming to bring in outside perspectives from others along the value chain as well as others at the forefront of fields not directly connected to the cruise industry. Engaging with external perspectives tends to help the entire workgroup learn faster. Partnering with industry leaders, designers, and consultants in various geographical locations and time zones across the world can pose challenges, but the group credits combining these talents and skills as core to their evolution and success.”
So for me, this is either a network, or a team at the centre of / pulling together a network that spans across the company’s mainly functional organisation structure.

The Performance Community
Southwest Airlines Network Operations Control (NOC) Field Tech workgroup is a specialized unit of aircraft mechanics. Members try to fix what no one else can—repairing planes after mechanics in maintenance units have failed to fix them after three attempts.
The Field Tech workgroup comprises 14 employees working at 10 airports, or nodes, in Southwest’s network and who are assigned to the workgroup full time. “They spend their days fixing issues on aircraft and leveraging the resources of local maintenance crews, as well as working with other Field Techs to help troubleshoot and resolve issues on planes at other sites. Thanks in part to members’ distribution across time zones, the workgroup operates 24/7. In an eight-hour shift, a single technician might work on 12 different planes, both at his node and remotely.”

“Although its members are geographically distributed and there may be only one Field Tech physically with any given plane, they are often in contact with each other throughout the day. Around 25 percent of the aircraft the workgroup touches each day require the Field Techs to work collaboratively, and often interdependently, to develop solutions to new and challenging problems. Much of this is done using audio and video chat, as well as logs, allowing members to build upon each other’s skills, insights, and ideas to get planes back in service.”
So this group does do some teaming, but in the main they’re not working with each other, they’re sharing their insights about different planes, so that the most locally based group member can fix a particular plane most effectively. In fact, they’re a community. But they’re not just a community of practice. They’re not there just to learn, though this is certainly part of what they need to do. They’re there to make a real business contribution. They’re a community of performance.

As with Royal Caribbean, the key objective is to allocate work to the people, not the people to the work, and on learning not efficiency. “Over time, workgroup members have learned to play to each other’s strengths, creating an environment in which each can give his best in service of a shared outcome, and finding opportunities for others to succeed. For example, when members saw that a technician in Chicago enjoyed working on pneumatic problems, they sent him planes with such problems.”

And “The workgroup doesn’t look for technicians who fit a set mold or profile—quite the opposite. If you had a cookie cutter, it certainly wouldn’t apply. No two technicians are the same: Workgroup members vary in working styles, personality, professional background and more. So what do they look for? Hard work, creativity, stubbornness. A love of challenges. A commitment to getting the job done, by any means necessary.

The community also sits within a broader functional network, transferring learning outside the community: “The group’s ‘Teach me, watch me, watch me teach someone else’ approach takes a long-term view, placing group and maintenance crew capabilities and effectiveness over the short-term efficiency of just getting a task done. As members pick up new skills, they share those capabilities and lessons learned with other members and, in parallel, the line maintenance crews. observations, and possibly tinkering with how the task is completed or the problem is solved. This accelerates the workgroup’s learning even as the regular opportunities to teach each other, and the line maintenance crews themselves, also accelerate individual Field Tech members’ learning. Members value what they see as an opportunity to learn and gain experience faster: ‘Working as a Field Tech for two years can produce an experience level that it might take 10 years to attain otherwise.’ ”

Note also that “relationships are paramount; you have to trust the person working next to you. Field Tech tends to promote people who have built up trusted relationships at a given airport.”

Most of the other case studies are fairly straight forward team based examples. There is one other interesting example though. SWA’s Baker workgroup, which aims to improve decision-making around unanticipated operational and weather-related events, is described in networking terms - making network based decisions - which I think applies more broadly than just the air route network. However this isn’t a network based workgroup as it’s a group of people responding to task requirements, rather than a group of people who then generate the work. Instead it is a new functional grouping which spans across existing departments and locations in a 3d matrix.

Finally, I also like Deloite’s suggestion that we’ve tended to overlook the opportunity to create these edge workgroups because whilst we may recognise their importance, few companies track performance at the workgroup level, much less track how these workgroups are doing over time.

I just wouldn’t call this business practice design - it isn’t the practices which are important, it’s the use of the various groups - teams plus communities and networks, and the practices used by the groups are part of the group design. And, as suggested above, I’d broaden out Deloitte’s definition of group to include communities and networks too.
And as I suggest in The Social Organization, we need to pay more attention to all the various groups and networks that contribute to performance in today’s business world.

I think one of the best recent books on social capital related topics is Extreme Teaming by Amy Edmondson, who I note in The Social Organization has previously introduced the ideas of teaming and psychological safety.

​Teaming is about the idea that people join and form teams increasingly frequently, and therefore the team (the noun) starts to become less important than the ability to team (the verb).

Psychological Safety is the trust people have that others in their team (and I would argue, other types of group) have to have that others have their back, ie that they will be supported when they take a risk.

The idea of Extreme Teaming in the new book extends the idea to complex, cross sector and cross organisation situations. This builds on Edmondson’s earlier book on Big Teaming which dealt with a slightly simpler, if still complex, environment of cross discipline, but still intra organisational teaming.

I particularly like Edmondson’s articulation of the well known idea that teaming is required because of the demands to match increasing specialisation with increasingly complex challenges. “The so called knowledge explosion leads to narrower and deeper areas of specialisation. Fields this span subfields.” “On the other hand concurrent with the rise of narrow and deep expertise, the problems facing organisations and society have not of course narrowed accordingly. Instead they are increasingly complex and multifaceted. Addressing them requires multi-disciplinary approaches.” “This, to solve complex problems and innovate in ways that reflect the increasing rate of change, today’s organisations must take advantage of deep specialised knowledge and manage knowledge integration across these domains of expertise at the same time. These two opposing challenges create the need for organisations to master extreme teaming.”

Edmondson also notes GE’s claim that “today’s problems are too big for them to solve alone and that to do so they need to collaborate like they never have before.”

I also like the case studies in the book. However the important thing for me isn’t that these examples are cross organisational as well as cross discipline, it’s that they’re so complex that they can’t be dealt with in a normal team.

Some of the example (projects Fiona and Sofia) are therefore fairly traditional, a bit like the smart cities case study in Edmondson’s earlier book, or Paul Sparrow’s examples of collaborative HR. I’ve already suggested that teams, communities and networks actually need more than psychological safety and it’s interesting that it’s Project Fiona which is used to demonstrate the need for psychological safety, not one of projects Bianca or Willa which are much more complex.

This It is this complexity which I think means that human ingenuity rather than management of the project becomes the most important factor. People rather than tasks.

Edmondson also reviews the response to the Chilean mine disaster: “An extraordinary cross-industry teaming effort by hundreds of individuals spanning physical, organisational, cultural, geographic, and professional boundaries. Engineers, geologists, drilling specialists, and more came together from different organisations, sectors and nations to work on the immensely challenging technical problem of locating, reaching and extracting the trapped miners.”
Responding to this challenge included a relatively clear objective but little clarity in how the objective could be achieved. It involved three parallel ‘teaming efforts’, with different clusters of experts coming up with complementary pieces of the solution and roles emerging and shifting as the teaming went on. “Leaders of different subgrouping met routinely every morning and called for additional quick meetings on an as-needed basis.”

Edmondson may call these examples of extreme teaming but they don’t display many of the traditional traits of teams. Eg comparing the Chilean mine challenge vs Hackman’s conditions for a team:

• Compelling direction - yes
• Clarity of boundaries and task membership - absolutely not
• Enabling structure with adequate norms and task relevant resources - only the highest priority
• Supportive organisational context - supportive yes, but there wasn’t really an organisation
• Expert coaching - no.

This leadership group was potentially a team, and they did have an agreed approach to working together, if not for solving the challenge itself. However, most of the people working on the challenge didn’t know each other, and weren’t working with each other as they would in a team.

I guess these differences are why Edmondson calls the examples extreme rather than just big. But for me, they’re just not teaming at all. They’re networking.

In fact they are examples of what, in The Social Organization, I call Performance Networking. They’re the use of networks, not just in the informal, tactical, communication oriented way these have traditionally been associated with, but to achieve really important contributions. Formal, strategic, performance oriented networks. Flash networks not flash teams.
Perhaps this shouldn’t be a surprise. Edmondson suggests that teams are the performance unit per excellence for innovation. But I think it’s generally understood that this isn’t teams, it’s networks. Or it depends on what the innovation demand is about. Executing innovative ideas tends to be best performed by teams, but creating the innovative breakthrough is best achieved through networks. So performance networks beat teams when the creation is the critical requirement vs just the execution.

Finally, I also like the explanations on the problems, functions and benefits of extreme teaming / performance networking.

The problems focus on communication failures at the boundaries between professions, organisations and industries (or across the network): “As individuals bring diverse expertise, skills, perspectives, and goals together in unique configurations to accomplish challenging goals, they must overcome subtle and not-so-subtle challenges of communicating across boundaries. Some boundaries are obvious - being in different countries with different time zones, for example. Others are subtle, such as when two engineers working for the same company in different facilities unknowingly bring different taken-for-granted assumptions about how to carry out this or that technical procedure to collaboration.” (ie a lack of shared norms as in traditional high performing teams.)

This is compounded by interpersonal challenges around people’s emotions and relationships, ensuring others are seen as in the same ‘in group’ and developing relational co-ordination.

The four functions Edmondson suggests are building an engaging vision, cultivating psychological safety (I’d suggest psychological curiosity is what really powers performance networks), developing shared mental models and empowering agile execution .

​Shared mental models, which includes diagnosing interfaces for knowledge sharing and leveraging boundary objects is demonstrated very well through Project Willa, a collaborative effort involving more than 80 individuals from four organisations, 20 disciplines and 4 countries. “Immense diversity of technical expertise had to be accommodated by collaborators who shared neither mother tongue nor time zone.”

• The group adopted a strategy for interface management that divided the project into modules based on physical and time attributes. “Each model was owned by a sub team. An interface existed when anything touched or crossed a boundary. Regular interface coordination meetings were help to manage physical, functional, contractual, and operational boundaries. Through disciplines documentation, and care, the project avoided costly mistakes that might otherwise occur at boundaries.” (a bit like the ‘cadence’ of meetings described in Teams of Teams, which of course is also about networks).
• The group also organised strategic cross-boundary encounters where participants could work on problems together, face to face. “Custom developed scripts and tools were employed to bring various disciplines together and develop the overall model and design drawings.”

Agile execution, which includes providing room to manoeuvre and enabling expert decision clusters is supported by Project Bianca, involving 10 global 500 companies from several sectors plus government agencies and a handful of startups.

• Decision rights were distributed (not just decentralised as in a traditional team): “The project’s multi-organisational composition made decision making challenging. This required the design of mechanisms to ensure that everyone’s input and interests were taken into consideration, without becoming overly bureaucratic or bogged down by excess meetings or conflicts. A thoughtful multi-layered structure emerged that was highly effective in ensuring coordination and creativity. Some decisions were made at monthly meetings - meetings that included all 10 industrial partners in the consortium.” However, to help ensure agile execution, not all decisions were made in this manner. Instead some specific aspects of the project were associated with the individuals best suited to manage them.
• In addition, the project leader organised aspects of the project into subgroups in which domain experts, who had planned to interact relatively informally, could more fully exercise their expertise. Mostly focused on technical issues crucial to the project, the subgroups also fostered a sense of community. One partner was chosen to lead each subgroup. All partners could contribute to and assist with the work of any subgroup. All partners could contribute to and assist with the work of any subgroup, but the designated partners were responsible for the outcomes of their subgroups.

The benefits of the approach include helping tap the potential provided by group diversity. This takes place through group learning behaviours / processes which include “asking questions, seeking feedback, experimenting, reflecting on results, and discussing errors or unexpected outcomes of actions.”

​Jon Ingham.