The Third Skillset by David Kershaw - HTML preview

Organizational Networks

Exploring communication in networks of team members and how the quality and content affects productivity

Section 1

Teams Are

Networks

In This Section

1.  Teams Are Networks

2.  What Is an Organizational Network?

3.  Is It a Social Network?

Teams Are Networks

Team members are connected in a network of relationships.  A  team network's relationships include:

•  Reporting lines

•  Accountability and authority

•  Alignments and assignments

•  Communication

•  Process participation

•  Skills, work experiences, interests and friendships

Team members and teams as a whole have similar relation- ships across an organization.

What Is an Organizational Network?

Organizational networks are defined by the set of relationships between people that result from how a team or an organization works.

Networks exist in abstract form with or without computer systems. But this chapter is only concerned with organizational net– work applications. Organizational network applications allow team members to build team structures within a system all members of the organization have access to.

An organizational network models team organization to provide an explicit framework for activities that would otherwise be done in an inefficient, opaque, and ad hoc way.

Teams that use organizational networks to manage the structure of their work should expect to see benefits that include:

•  Less interpersonal friction due to a clearer definition of goals, roles and processes

•  More participation due to better visibility of members' efforts

•  Faster and better decision-making due to more a regular process

•  Easier access to resources and information due to visibility into roles and responsibilities, skills and aligned work, as well as more systematic knowledge management

•  More effective communication due to standardized terminology.

•  Channeled collaboration based on tasks and responsibilities

The goal is to support structured work activities that are known to be effective. And to do it better than general purpose collabo- ration, groupware, HRIS and scheduling software do.

Is It a Social Network?

The answer is no.

In common usage, social networks are systems that manage sets of interpersonal relationships and informal largely unstruc- tured communications.

Social networks typically focus on:

•  Interests

•  Friendships and acquaintances

•  Questions

•  Streams of thought

The so called business social tools do much the same thing, but typically with an additional layer of marketing, customer in- teraction or idea generation.

Interests and friendships are part of work life too, of course. However, they do not define an organization or tell us anything about the structures that make organizations work. Rather, social activities co-exist with an organizational network, some- times mirroring it.

Organizational networks have similarities to, and overlap with, social networks. But they are not the same as social networks.

Section 2

The Problems of

Team Networks

In This Section

1.  Noise, Confusion and Waste

2.  Communications Overload

3.  Value Adding, Value Destroying

4.  Cognitive Limitations

5.  The Problem of Distance

6.  What Makes Us Communicate?

Noise, Confusion and Waste

Noise is extraneous information that degrades a communications channel. Teams are noisy in the sense that a radio signal can be noisy.

This section looks at well-known communications problems that contribute to noise. The goal is to highlight how an organiza- tional network can help. The last section of this chapter will offer more suggestions about how to reduce team noise.

Sources of noise include:

•  Overlapping communication

•  Drift in meanings and intentions

•  Distractions from outside the team

•  Duplicated information

•  Information that must be corrected

And on and on.

All of this noise generates confusion. Confusion creates questions and lots of avoidable little decisions. Questions and little decisions are more noise.

Noise is something teams need to avoid. The costs of noise add up quickly. They include:

•  Less time for meaningful conversation

•  Less free brainpower for innovative thinking and unexpected opportunities

•  Frustration due to incorrect or missing information

•  Frustration and negotiation due to lack of clarity around goals, roles and processes

•  Rework due to poor communication

As with the sources of noise, this list could go on and on.

To quote a savvy start-up CEO on this topic, “unstructured collaboration is unproductive.” The reason, he said, is because of the noise and general confusion it creates.

The other chapters of this book have discussed clarity in team structure and operations. Clearly an organizational network that makes these aspects of teamwork explicit and clear will cut down on noise and confusion.

Communications Overload

Networks of all kinds require more communication the more members they include. There are several equations that try to quantify how the volume of communication increases as a net- work grows.

In some cases an increasing number of possible communication channels is described as network value. In other cases, in- cluding this book, increasing the number of channels is de- scribed as a burden.

The most famous equation is Metcalfe's Law. The law states that the number of communication channels goes up propor- tional to the square of the network membership. In numeric terms it is:

•  Multiply n times (n - 1)

•  Divide by 2

What does that mean in practice? For example, if your team has eight members then the number of lines of communication is:

"       8 * (8 -1) ÷ 2 = 28

If you have nine members it goes up to:

"       9 * (9 -1) ÷ 2 = 36

And if your team grows to 12:

"       12 * (12 -1) ÷ 2 = 72

Although Metcalfe's Law is most often invoked to highlight the value of a network, in the context of teamwork you can see that this is not a trend that increases efficiency.

There are two main ways to counter the increasing amount of communications a growing team faces. They are:

•  Broadcast information rather than communicate person by person

•  Provide members with a way to pull the information they need, rather than pushing it to them

Both of these approaches can be enabled by something as simple as a whiteboard. But online systems do it better.

Organizational network systems are the most effective.  This is because they can remove at least one entire class of low-value communication.

Removing low-value communications makes room for more meaningful communications.

The class of communications that is removed is person-to- person communications about team structures. For example, rather than one member emailing another their role assignments they can enter that information into the system. Later, questions about roles can then be answered by the organizational network, rather then person to person.

This isn't to suggest that face to face discussions or two person collaboration shouldn't happen. Far from it!

What we are suggesting is that making team structures and processes clear and easily accessible in an organizational net- work reduces the number questions about those structures. And those savings add up fast.

Value Adding, Value Destroying

Metcalfe's Law is one way to measure a network. Another con- ceptually simple approach is Beckstrom's Law. Beckstrom's Law is also used to describe the value of a network. Like Met- calfe's Law it can be equally well seen as a measure of burden or communications overhead. The measure is:

•  Estimate the value of each possible pair of members

•  Sum the values

When you look at the implied negatives you are looking at:

•  Estimating the waste or value destroyed by each possible pair of members

•  Summing those values

Some people may have a gut reaction to this because they don't like to look on the negative side of things. That is quite reasonable. However, the waste due to poor or unnecessary communications is a fact of life. Typically teams accept it as a cost of doing business. Some don't even notice the loss because it is so woven into doing business as usual.

Back on the positive side of things, an organizational network can help by adding clarity through making team structures explicit. Removing communication negatives that way is adding value.

To repeat what we said above, an using an organizational net- work removes a class of communications about the structure of team goals, roles, assignments, alignments and processes. After the initial setup this information is available on a self-service basis.

Without this support, questions, complaints, negotiations, and office politics crowd out more valuable communications about the work the team was created to do.

Cognitive Limitations

Dunbar's Number is another useful concept for teams. The idea is that people can only maintain a relatively small number of meaningful relationships. The number is approximately 150.

At first glance, 150 relationships may sound like a lot, or any- way sufficient, especially for teams that are typically much smaller. However, there are two ways to look at this number that are more concerning. They are:

•  The 150 relationship limit applies to all relationships a person maintains, not just those within a given team, and

•  More worryingly, we can extrapolate that people can only manage a relative small of relationships of any category, not just person to person relationships

As we have highlighted in many ways in this book, teams are full of relationships. They include:

•  Relationships based on roles and responsibilities

•  Assignments and alignments

•  Decision-making relationships between people, and between causes and effects

•  And so forth

In that light, the number 150 feels terribly small.

Here again, the value of making relationships explicit in an or- ganizational network system is powerful. In this case, rather than removing communications directly, the system allows you to stop maintaining these relationships mentally.

Instead, the system maintains the relationship information and let's you refresh your memory as needed. This frees your men- tal energy to focus on the details of the work, not the structures of the team.

The Problem of Distance

There are many problems with working at a distance. Some of them include:

•  Time zones

•  The tendency to respond disproportionately to local activity rather than remote activity

•  Less ease of access to resources

And so on.

However, one of the most important considerations is less tangible. It is the Allen Curve.  The Allen Curve describes the exponential falloff in communications as distance increases. In short, the further away people are the more they disengage from one another. The exponential curve makes this a dramatic fact, but it also fits with common sense: you talk less to people you don't see.

Of course you can turn this around to say that the closer people are the more they communicate. Architects, facilities managers and HR professionals know this.  They have been using geography within buildings to encourage collaboration for a long time.

But many, if not most, teams are not 100% co-located today and can not change their geography. Keep in mind that even small companies with one location bring venders and consult- ants into their teams regularly. It is almost as uncommon to find a team with no significant distance between its members as it is to find a team that is not to some degree cross-functional.

Given that, the Allen Curve is important to most of us.

There is, however, another way to turn the Allen Curve around, at least in concept. What if you redraw the curve so that instead of measuring the decay in communications with distance, you show an increase in the frequency of communications?

Then the curve says that the apparent distance shrinks as the parties communicate more.  That is to say, their engagement is brought to a level that would be typical if they were physically closer. And indeed, that is what observations have shown.

What Makes Us Communicate?

Of course increasing communication is easier said than done. Many systems rollouts fail to get adoption. This is particularly true of enterprise social and collaborative systems. The path of least resistance for most people is to continue to do what they already are doing, not to collaborate or be social how and where they are told to.

Teams have an advantage in this area. Unlike the general population within an organization, a team is a new purpose-built structure where people know they are expected work together.

A team's structure can be used within an organizational network system to channel collaboration through goals, roles, responsibilities, tasks and processes. Those elements are fundamental to teamwork. They can be, and should be, fundamental to collaborative communication too.

In this way, an organizational network can be closer to an ERP system than to an enterprise social application.  That is to say, it can naturally become the system by which work gets done. Therefore it will tend to face less of an adoption challenge.

No purchasing manager would choose to not use a company's

ERP to make a purchase. In the same way, no team member would choose to assign a role without using the organizational network. There is no magic bullet. But some systems face fewer hurdles than others.

With adoption and constant use of the organizational network, the team gets on the right side of the Allen Curve. However much distance is between the members, the frequent communications tied to structural relationships will typically maintain a substantially higher level of engagement in the work.

One of the best answers to the question of what makes us communicate is simply the goal-oriented work we do together.

Section 3

Defining Your

Terms

In This Section

1.  The Language Problems

The Language Problems

Many teams face challenges around language. The four main types of language problems are:

•  Members being native speakers of different languages

•  Members understanding a common language differently for cultural or dialect reasons

•  Difficulties in learning and standardizing the words used for dealing with the work the team was created to do

•  Differences in dialect, for example Texan vs. London English, may not be picked up on early, and may be disregarded until after problems appear that might have been avoided

•  Dialects affect non-native speakers, compounding their com- munications effort. For example some Chinese speakers learn English from UK sources, not US English, due to his- toric ties

Teams often handle the third and fourth bullets using glossaries and in other ways normalizing their word choices early in the team's life.

Why Create a Domain Glossary?

Teams very often have difficulties learning and standardizing on a common set of words used in their work.

In part this is because the majority of teams include specialists from multiple domains with similar terms. For example two technologists may have very different definitions for the word “schema”.

The difficulty is also frequently caused by the main domain simply being difficult for non-specialists. An example of this is an MIS database administrator having a steep learning curve after joining a medical records project to work with medical informaticists and physicians.

In addition, some team members may become frustrated when the learning curve appears to be steeper for the main domain then for their domain. This often happens because their domain is less central to the work.

For example the database administrator we just mentioned may become frustrated because physicians are relatively unlikely to work hard at understanding the language, tools and techniques of DBAs.

The Challenges Glossaries Face

Both of these issues may be helped, in part, by creating a team glossary. However, glossary efforts are frequently started but of- ten die out.

The challenges to overcome in order to avoid this problem include:

•  Glossaries tend to be owned by a single person who must make time for it outside of other work

•  Team members need network access to the glossary for practical look-ups

•  It takes effort on the part of a team member to lookup words

•  Adding words to the glossary also takes effort

The first bullet may be the most difficult. A glossary that has just one person working on it sends a signal. In general it suggests nobody else feels the glossary is important enough for them to make time to help.

The second bullet is closely related to the first. If a glossary lives in an Excel or Word file members' access will be poor at best. When that is the case it is more likely that the glossary effort is limited to one person. The solution is to use a network application.

The next challenge may be most important over the long term. If a glossary takes significant effort to use, it will not be used. Team members will more often lookup words when it is trivial to do so.

Many applications and websites have demonstrated this by inte- grating dictionary or web search into context menus, reference links or text that shows when the user mouses over a word. But when this type of integration is not available glossary use will suffer, as will maintenance of the glossary.

Finally, if it is hard to contribute to a glossary members will not continue to help develop it. When the effort required to add a glossary term is low, more development and maintenance efforts are forthcoming.

In brief, glossaries are good for teams, but to be successful you must find a way do three things. They are:

•  Involve the whole team in the creation

•  Use a system everyone has access to that is productive for glossary creation

•  Use a system that allows team members to do as little as possible to get the benefits

These three requirements argue for a system that was purpose- built, at least in part, for glossary creation.

In the case that you can not achieve those three things your team may still find value in creating a glossary. But the effort is most likely to be worthwhile for teams that are:

•  Large or frequently changing

•  Doing relatively high risk work

•  Where leadership treats the effort as a first-class, planned in- vestment

Teams not meeting those criteria may want to find other ways to address standardizing their vocabulary.

Using Common Terms

Regardless of if your team creates a glossary, you still need to spend some effort to use the same words to mean the same things. As we said above, there are two areas to work on:

•  Words from the domain the team is doing work in

•  Worlds about how teams work

In both cases, most teams need to find ways to encourage members to use the same words. How this happens will de- pend on the team, its leadership and in some cases its management.

The second of these bullets may seem less important then the first. In fact, that is not always the case.

Smooth team operations depend on clear communications be- tween team members. Referring back to the GRPI chapter, team communications is a group of closely related processes. When processes work poorly, tensions rise.

That tension may be within the team or it may include a team's management. The managers with oversight of a team are important to team operations. They provide organizational support, external communications and other assistance.

If management receives unclear information about team operations it is common for the team to lose degrees of independ- ence. When that happens a team's internal structures will change in ways that may not be predictable or helpful.

As a common example, the terms “goal” and “objective” are frequently used together. They:

•  Are relatively hard to define clearly

•  Have dictionary definitions that tend to reference each other

•  Are likely to cause confusion that impacts members' actions

That confusion could be highly damaging to a team. The terms may be used interchangeably by some members or manage- ment, while others use “goal” and “objective” to distinguish be- tween less specific, less accountable targets and hard deliverables. This could reduce the alignment of goals, roles and responsibilities. A team with poor alignment will always have relatively poor performance, at minimum.

In the suggestions section of the chapter will will offer some more ideas on how teams can build common, well-understood vocabularies.

Section 4

Implementation

In This Section

1.  Some Suggestions

2.  Encourage a Team Dialect

3.  Add Controlled Vocabulary To a Role

4.  Make Your Tools Talk Like You

5.  Focus On Action

6.  Reduce, Reuse and Recycle

7.  Work In the Network

8.  Communicate Predictably

9.  Using MetaTeam

Some Suggestions

This chapter outlined some of the challenges of team communi- cations and the benefits of building the structure of teams explicitly in an organizational network.

In this last section we offer a few quick suggestions.

Encourage a Team Dialect

Close knit groups tend to have their own way of talking. This can be the result of the group being cohesive, but it can also help create cohesiveness.

Start by limiting the number of words you use for things, adopting shorthand terms, and defining simple words for common items and activities. This will help add consistency, and make the process of identifying and defining routine. It will also tend to generate some amount of slang.

In all likelihood the process will leave your hands to take on an informal life of its own, potentially leading to a more distinctive, and beneficial, team-speak. But if not, you will at least have added some amount of clarity.

Add Controlled Vocabulary To a Role

Those teams that decide to create a glossary need to avoid having only one person do all the glossary building. At the same time, you do want at least one champion to build momentum for a common vocabulary. Also a successful glossary generally re- quires some level of formal backing. Assigning the creation of common vocabulary or a glossary to a role will help do this.

Make Your Tools Talk Like You

Wherever possible a team's tools, particularly the organizational network, should be configured to use the same language as the team and organization.

For example, if your team uses the word “goal” rather then “objective”, ideally so should your tools.

The reason to adapt your tools to the language of the team and organization is to reduce mental load. It may not seem like much, but if team members are constantly translating terms in their heads, and verbally or in writing for other people in the organization, they are doing work that takes away from the work the team was created to do. Small efforts add up, and small negative productivities erode good feeling and performance.

Reduce Nuisance Communication

Reducing noise communication frees up time and energy for more substantial collaboration. In Section two we listed some of the sources of noise.

As we said, fully fleshed out team structures in an organizational network system will help cut down on the problem. Moreover, if members continually work to move information out of email and into the system, the system can progressively take more of the load.

The need to reduce noise and focus on more significant issues is the same reason mass-market product and services teams create FAQs. Some of the types of information are different, of course. Questions about the roles and responsibilities of team members would require better definitions, rather than simply adding a question and answer to the bottom of a FAQ. But the principle is the same.

Adopting this strategy requires two main things:

•  All team members help fill in parts of the organizational net- work when questions come up or things are unclear

•  Continually urging members to check the network first before asking questions or acting despite uncertainty

Either or both of these may cause some eye rolling at first, but the effort to build the habits is typically worthwhile over the long term.

Focus On Action

Observation has shown that teams, and especially virtual teams, tend to build trust and enthusiasm around explicit and limited tasks and task-oriented processes. Trust, enthusiasm and progress do a lot to drive communications. Frequent communications brings team members together, as we described. This is a virtuous circle you should seek.

In addition, team members are better able to prioritize task- oriented work with well-defined deliverables. Moreover, team members prioritize work for different teams in part based on the concreteness and do-ability of the effort.

Roles, responsibilities, decisions and even the team itself can be closely aligned with tightly defined goals and tasks. Even the name of the team can help set the expectations of a limited scope and definite outcome.

Reduce, Reuse and Recycle

You can often work to minimize noise by increasing predictability. Predictability tends to increase clarity, focus and efficiency. A way to achieve this is to reuse what has worked for the team in the past.

Wherever possible try to:

•  Rely on existing role conventions

•  Add new decisions to successful groups of decisions

•