When Randy was hired as CIO, he inherited a leadership team populated with seasoned executives who were technically qualified, generally liked by their staff, and pleasant people.

One little detail: They didn't team.

Sure, they talked with one another and cooperated on organizational decisions like policies and plans. But each ran his/her own shop as an independent department -- a "stovepipe" -- with minimal collaboration on projects and services.

It didn't take a rocket scientist to figure out that this was costing the company money. Many skills were replicated across departments, and people were spread thinly which hurt their productivity.

Another consequence was that people managed functions outside their primary expertise. For example, applications developers ran their own development server (without much in the way of security, continuity planning, or even back-ups). Meanwhile, the infrastructure group (adept at running servers) had its own applications development team for its billing system.

Each department had its own support functions, like procurement, budgeting, and administration. There were two infrastructure control centers: one for the computers, and another for the network. There were even three different help desks: one for desktop computers and infrastructure, another for applications, and still another for telecommunications. How was a client supposed to know which to call when his/her PC couldn't access an application via the network!?

For lack of teamwork, hand-offs were rough. When an application was ready for production, there were often delays due to poor coordination between the developers and the infrastructure staff who managed change control.

Perhaps most embarrassing to Randy, each department had its own client liaison function. IT looked foolish when clients got different, sometimes conflicting, answers from different "single points of contact," and when one hand didn't know what the other hand was doing.

Just one month after taking the job, Randy was mortified when clients were exposed to internal finger-pointing after a project missed its deadline. This was the last straw. Randy took on teamwork as one of his primary challenges on the job.

Team-building

First, Randy hired a consultant to do a seminar on teamwork. She took the leadership team off campus for a day and talked about the importance of teamwork, team problem solving techniques, and effective communications skills.

Everyone agreed with everything the consultant said; but back on the job, nothing changed.

Next, Randy hired another consultant to do a teambuilding process. This time, the leadership team spent three days at a resort playing team games that required mutual trust, talking about how they felt about one another and their interdependencies, and playing golf.

They spent every waking hour together, got to know one another better at the personal level, and everyone had a great time; but back on the job, nothing changed.

Randy's next solution was ITIL and Lean-Six Sigma. For service-management processes, he paid a vendor large sums of money to train his staff and implement ITIL processes and systems. For other processes, he chartered teams to document and redesign workflows that spanned the IT organization.

Unfortunately, many months (and dollars) later, few of the new processes were actually implemented. And for those that were, it seemed that the departments only added staff to coordinate the hand-off points. This was going in the wrong direction!

Randy's next attack on the problem was a reorganization. He mandated the consolidation of the three help desks, moved the development server into the computer center, and set up a single Client Liaison group reporting directly to him.

Of course, this resulted in utter chaos for a while. But after a few months, things settled down. The unified help desk did a fine job of transferring calls to the three "level-two" help desks. The development server ran flawlessly in the computer center, though it wasn't used as much since the applications developers found a few small servers in their own area that they preferred. And the new Client Liaison group did a great job of coordinating communications with each of the three departmental "entry points."

Can you see through the smoke? Nothing changed.

At this point, Randy started to get desperate. As a last resort, he tried some job swapping. The head of the infrastructure group took on applications development. The head of the applications group went to client support. And the head of support moved over to the infrastructure group.

Now, everybody had a lot of empathy for their peers; but still nothing changed. Funny.... Where you stand depends on where you sit. It wasn't long before the former head of infrastructure, now leading the applications group, was asking for more budget to upgrade his development server. Meanwhile, the new head of infrastructure fiercely defended his need for his own billing systems developers.

The rotation lasted about two months, at which time Randy put everyone back -- just moments before the entire organization collapsed from leaders who knew nothing about the functions they managed. The Dilbert fans among the staff got a good laugh at this whole experiment.

Root Causes

What made it so tough for Randy to develop effective cross-boundary teamwork?

Randy's frustrations stemmed from a simple mistake: He treated symptoms, not root causes.

His department leaders weren't stupid or malicious people, and it's not that they didn't get along with one another. There were good reasons why they didn't work as a team, reasons imbedded in the organizational ecosystem.

The four most common obstacles to teamwork -- the real reasons why teamwork doesn't happen in many organizations -- are the following:

Real Reason 1: Incentives

Incentives may be designed to block teamwork. Many organizations still use a job-grading system that decides people's titles and salaries based on the size of the group they manage, ie, their headcount and budget. People are paid to build empires!

When this is the case, any sensible person would rather hire an employee to do it within his/her department than seek help from a peer.

While this alone is not generally the major reason for resisting teamwork, it's on everyone's minds and sets up a bias against teaming.

Real Reason 2: Culture

Culture is "the way we work around here" -- the practices common throughout an organization. And many organizations have bad habits ingrained in their cultures that undermine teamwork.

Two common examples are:

1) We make commitments to our customers, and then attempt to arrange teams to fulfill them.

Of course, there's no guarantee that peers will have the resources available to meet that commitment within the promised time-frame. When they don't, people find a way to meet their commitments on their own (by replicating others' skills and building their own resources).

A better practice is: We line up our team members before we commit to a customer.

2) In the spirit of customer focus, people feel that it's okay to break promises to peers in order to satisfy a client.

After all, we've got to be responsive to the business! As a result, staff learn not to trust one another.

A better practice is: We respect commitments to (contracts with) peers just as much as those to clients.

Contrary to popular opinion, culture is one of the easier dimensions of an organization to fix. The key is to focus on practices, not values. Note that in this case, it's easy for Randy's leaders to say they value teamwork, but that doesn't mean their staff know how to behave.

Examples of clearly worded behaviors illustrate how to build a culture of teamwork quickly.

Real Reason 3: Structure

Another common root cause is structure. People think that the only way to get staff to work together is to put them under a common boss. Thus, it's common to find support groups reporting to one of their internal "customers" and unavailable to the rest of the IT team.

A common example is infrastructure engineering, often placed within the infrastructure operations group. Of course, server and network engineers are needed on applications projects. But because of their position in the structure, they typically think of the operations group as their only customer and thus they aren't readily available to applications development teams.

The key to overcoming this obstacle is internal customer-supplier relationships. When staff treat peers throughout IT as customers, just as they treat business-unit clients as customers, cross-boundary teamwork gets a lot easier.

Real Reason 4: Resources

Saving the best for last, the fourth obstacle to teamwork is the most common and the most powerful: resources. Often, managers are willing to help one another, but their staff's time and their budgets are fully committed to their own priorities.

This occurs when managers have their own budgets, and are expected to satisfy their customers' demands as best they can with the resources they've been given. Each manager sets his/her own priorities for his/her resources, and one manager's highest priority may very well be another's lowest priority. That, alone, is enough to kill teamwork.

The alternative is to think of IT as a business within a business, and its budget as a "pre-paid account" -- money put on deposit at the beginning of the year for clients to use to buy IT products and services throughout the year. Clients own this checkbook, not IT managers.

When clients use this pre-paid account to buy something, they must fund the entire project or service -- the "prime contractor" and all the internal sub-contractors (team members).

This approach treats resource-governance processes as an internal economy, not just as accounting and financial controls. This economics-based approach ensures that the entire IT organization is aligned with a single set of priorities coming from the business.

Hope for Randy

Randy focused on a critical problem. But as we so often find in life, short-cuts cost more than they're worth.

Poor teamwork is rarely a matter of interpersonal difficulties, or a lack of knowledge of how to work together. This is why so many teambuilding efforts produce sparse results.

The right way to build high-performance, cross-boundary teamwork is to get to fundamentals. Find out why the nice people in your organization don't team, and then address the root causes of incentives, culture, structure, and the internal economy.

Or for a method of team formation that is the foundation of high-performance teamwork, click here.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....