How to Build Distrust and Turn Off Your Team

Two Fundamentally Great Ways!

Team Turnoff

First, the use of the word "team" is a huge turnoff for many workers. For too many workers, the phrase, "I want you to be on my team" is just management-speak for "shut up and do it my way." Note recent media articles in which surveyed workers resent management-speak, even if the manager is telling the truth!

I Really Distrust You

The mere use of management-speak is so off-putting that many employees will distrust anything the managers say simply because they are using management-speak instead of plain English (or substitute the language of your choice).

It's a bit like the old joke, "How can you tell when a politician is lying? When you see his lips moving." Ditto with management-speak.

Second, the reference to "siloed groups" is telling.

Ultimately, the sheer existence of siloed groups creates a huge impediment to any group of people working together. One definition of a siloed group is "a group of people pursuing the goals of the silo." Typical silos in the software development arena are the programmers, the tech writers, the QA people, the technical support people, the salespeople, the marketing people, and so on. Each of these groups has its own agenda, which is never the agenda that the customer needs.

In essence, by building a company that is "siloed," you have empowered each group to pursue its personal agenda.

The only solution is to abolish silos.

This will be very unpopular because (1) most people think in terms of silos and can't imagine life otherwise, and (2) people who are "empire-builders" want the company divided into silos so that they can build their little empires in their own spaces.

Abolish the silos and bring each skill into a single group whose only focus is solving the customer's problem. Yes, have a product manager who "owns" the product; assistant product managers who do the product design, write the first drafts (at least) of the marketing collateral, do the system-level QA, and provide the level 2 product support; and programmers who write the program design and the code, do the unit testing, and provide level 3 support. Even though some functions are still outside this group (sales and level 1 support, for example), the fact is that you have now created a group of people who all report to a single manager, who should be empowered to solve most problems that users of the product will face.

Consider the very common issue in most organizations of the phone support people being overwhelmed because the programmers either didn't bother checking for certain error conditions or put in such cryptic messages that the customer is forced to call to get an answer. In most organizations, the CSR complains to the CSR manager, who complains to the Call Center Director, who complains to the Vice President of Customer Services, who complains to the President, who neither knows nor cares what the problem is. But in our new organization, the level-2 CSRs (the associate product managers) work for the same manager as the programmers. He/she calls the parties in, makes a decision, and solves the problem. It is a marvelous example of the decentralization or "pushing down" of decision-making that Tom Peters talks about, but one that most organizational structures are incapable of achieving.

Asking people to work together when, over the long run, they have different agendas, is simply an exercise in futility. If you find this odd, think about the military. When you have a squad of soldiers, you might have some riflemen, a demolitions guy, a medic, a mortar crew, and so on. Imagine if they belonged to different silos. All of the riflemen in the company belong in one silo, all the demolitions guys in another, all the medics in another, and so on. It would be chaos. And on a macro scale, you can see this happening when the Army, Navy, and Air Force compete for their own agendas. (Talk about the ultimate silos!) But within the squad or platoon, there is a clear squad or platoon leader, his/her seconds-in-command, and everybody else. The only thing that matters is the mission, not finger-pointing between different groups of soldiers.

So I would encourage the questioner to stop trying to band-aid the problem. Instead, work toward an environment where people work together under a single, local, empowered leader. Or, go find a company that actually means it when it proclaims that "we have the best people and we empower them!"

About the Author:

Bill McCalpin (EDP, CDIA, MIT, LIT) is a former VP of a public software company and CEO of an international trade association. Currently he is principal at MHE, the print2image2Internet consultants (http://www.mhe-consulting.com).

Contact Information:

Bill can be reached at mccalpin@mhe-consulting.com, +1-972-231-3660 (voice), or +1-972-690-4521 (fax).