It never ceases to amaze me how organizations kick themselves in the ass by making teamwork almost impossible.

John from Sales, Edna from Product Marketing and Paco from Customer Service are at one another’s’ throats. They were summoned into the big boss’ room and told to “get their act together and act like a team”. John has been promoting products that do not exist; Edna has been accused of ignoring customers’ unique needs (especially in low cost markets and the Japanese market)  in her product road map and Paco keeps telling his customers that he will ask a design engineer  from R&D to fix bugs, because his own department lacks the needed documentation and some of the features are “immature”. Customers have complained to the big boss that “no one in your organization gives the same answer”.

Thus the boss stressed the need for team work; however, he ain’t gonna get what he asked for.

The standard definition of a team is a group of people with shared common goals, mutual dependencies and a feeling of partnership. However, this definition is very misleading. Indeed mutual dependencies may exist, but these dependencies may not be acknowledged due to the very way that an organization is designed. As a result of poor design and the wrong assumptions, infighting, finger pointing, endless email threads and inter-departmental warfare predominate-not team work.

Back to the gang of 3. John, Edna and Paco are not a team. Indeed they may have a common goal, mutual dependencies and a feeling of partnership as expressed by some nebulous commitment to the company’s vision, but when the rubber hits the road, not only are their goals not aligned, but their mutual dependencies are unacknowledged. John needs to sell, Edna needs to produce a coherent product road map, and Paco needs to fix what does not work, or cool off the customer until a new fix is available. And above all, Paco, John and Edna need to make their respective  bosses (not one another)  look good.

The integration of the organizational system for which John, Edna and Paco work has not been downloaded to these three players; it is a matter of organizational design, prevention of sub system maximization, and allowing integration and trade-offs to be made at the lowest possible level. Example: John will sell only from the product road map, Edna will make this road map more flexible and Paco will ensure that his service agents have more product knowledge.

But this won’t happen, because the organization does not want it to happen. The basic assumption guiding the present dysfunction is that if John, Edna and Paco do their very best and over-perform in their specific areas, the organization will succeed. Nothing is farther from the truth.

The Boston based AI division of an Nasdaq traded company acquired a start up based in Paris and Tel Aviv. Due to faulty due diligence, the decision to retain the founders of the start up as joint CTO’s (chief technology officers) was abandoned and they were asked to leave the company. As a result, a massive rupture of trust occurred between Boston HQ and the brain power in France and Tel Aviv.

Marvin Duvalier was hired to integrate the acquired start up into HQ. Marvin had perfect credentials: he had vast experience in M&A activity, he spoke English and French as native languages, his wife is Israeli so he had an amazing  understanding of Hebrew, although he could not speak well. He also had vast domain expertise in AI.

Two months after he was hired, Boston acquired another start up in Moscow, which had competed with the French Israeli start up. Marvin was tasked with “putting this all together into one working unit”.

Six months into his role, Marvin is seen as a “failure”. In his initial performance review, he was told that he was seen as untrustworthy, manipulative and a professional bull-shitter, trying to please all of the people all of the time.

Marvin was asked to hire a coach, to hone his trust building skills. Marvin hired a coach as requested, and immediately started looking for a job, which he found after two months.

“Those fuckers in HQ make decisions based on excel sheets, faulty due diligence, and revenue scenarios crunched out by hacks, and then assign me a coach!”, he told the recruiter who found him his next job.

The Head of Business Development who recommended these failed  acquisitions and the CEO of the AI unit, are very close friends from their days in university. Three years down the road, the AI Boston based  Business Unit’s entire management team was replaced. Moscow was closed down; the French team could not be downsized due to labour law and drained huge financial resources. In Tel Aviv’s hot high tech market, the company got a bad name and talent walked out. It was a veritable disaster, which the coach did not prevent.

Coaching is often used to frame individuals as “guilty” of individual incompetence,  thus evading focusing attention on the real  system problems. 

“How will we know that the service that we are purchasing is effective? How can we measure the results”, are questions posed by clients at the outset of an Organization Development project. These queries are posed either due to the need to justify the expense, or out of ignorance, or in order to gain control of the vendor. At times, perhaps, they are asked naively.

What’s the answer to such a question? Let me start with two stories that I have shared with potential clients.

An organization providing product X decides to measure customer satisfaction by discovering how many times the phone rings before it is answered, and how many complaints are received about poor service per customer service agent. Software is purchased and an OD vendor is commissioned to implement that change. Immediately, customer service agents beginning answering calls immediately and saying “please hold”, and when they identify themselves, they mumble their name so that it’s hard to complain about someone specific. Later on the consultant learns that product X itself is faulty and its non functional features were, and are still, over promoted.

Another client wants to enhance the long term commitment of the ultra-skilled staff, and hires a consultant to enhance their engagement. Over time, it becomes clear that this very staff has become a monopoly of knowledge, systematically keeping new recruits in the dark for years, making their experience into a power bloc that makes incredulous pecuniary demands.

OD, I explain, deals with the “underworld”, the subterfuge that prevents change from happening effectively. And up front, it is very hard to define exactly what success will look like. The “success” we strive for changes constantly. OD is often initially commissioned for the wrong reason, or the intervention is aimed at the wrong people. It is ever so rare that OD deals with the problem that it was initially commissioned to deal with.

So the answer is that success cannot be defined a priori. It can be initially defined every few weeks, and each definition will be vague and not binding. Success is not even progress, because in the initial stages, things get worse, or much worse. If the client shies from this truth, it can be likened to planting a flower bed in the wrong direction with no/too much water. It’s not going to work. And it’s best to make this clear as early as possible, as early as possible.