Solving the Problem of Siloed IT in Organizations

A CEO of a real estate services company came to us recently with a problem. The whole company was waiting anxiously for a new system that the technology team had been working on for over a year. The CEO lamented that the team now needed to do a complete rewrite with a different technology — pushing the project out at least another six months and putting the company further behind its competition.

I could predict the answer to my next questions, but I asked the CEO anyway: What was the IT team’s explanation for the rewrite? Why was it needed now, and what alternatives were there?

“I have no idea,” came the reply. “And I couldn’t possibly ask them — I’m a business leader, not a coder!”

The company was in trouble, and the CEO was falling into an all-too-common trap. In fact, this conversation happens so often in our consulting practice that we have a name for the pattern that underlies it: the technology walled garden.

Keeping the technologists in this comfortable silo can wreak havoc on strategic priorities and trigger a cascade of effects throughout different parts of the organization:

• Software engineers are very busy within the garden itself — polishing and perfecting their software, fixing bugs, and refactoring code.
• Technology leaders are very busy defending the garden — that is, protecting engineers and technologists from outside interference and defining best practices.
• Customer-facing staff members are living a nightmare outside of the garden walls, with angry users demanding fixes and features that never seem to appear and new sales initiatives stalled for lack of product support.
• Business leaders, like the CEO, may feel like outsiders in the technology discussion, where terminology and approaches are beyond their expert purview, and they are therefore less inclined to intervene. This often forces a level of blind trust in their technology leaders and teams.

There are two singular features of this anti-pattern we’ve noticed. First, it occurs in the most backward and the most cutting-edge organizations with equal frequency. Whether a company is using Agile or DevOps methods, has adopted the latest technical tools and programming languages, or has developed highly skilled leaders within and outside of the technology group, none of these advantages stops our clients from having siloed IT.

The second distinct feature of the walled garden is that it is remarkably soundproof: Engineers inside the tech organization are often unaware of the cascading problems unfolding around them from delayed technology rollouts and a lack of communication. On the other side of the wall, nontechnical stakeholders, such as business development, marketing, and customer service, may be feeling the pressure to address issues but feel too intimidated to object or to act because they lack the technical expertise to go toe-to-toe with the engineers. As a result, the walls stay up, and productivity and morale plummet.

In many cases, the eventual result is not good for companies: The project fails, the technical leadership gets reassigned, or perhaps the whole IT function is outsourced. In order to avoid such scenarios, it’s important to understand how organizations come to be so dependent on an opaque group with specialized knowledge and minimal communication links. We also need to know how to break down walls within organizations to bring technology teams and business leaders closer together. To address both issues, companies and managers need to have a better understanding of the critical questions and conversations that must take place next.

Understanding How Walls Go Up

In the past decade, the growing understanding of the importance of technology to business has led to a surge in business transformations — whether the flavor is digital, DevOps, Lean, or Agile, the aim is to speed up software development by boosting cross-functional collaboration to deliver innovations. How, then, do we end up with so many walls and so little communication?

When we work with clients during their transformation efforts, we often see good compliance with standard Agile processes, with ceremonies like backlog grooming or morning stand-ups. But when we talk to both the technical and nontechnical leaders, we hear strikingly similar, unproductive messages that contradict the collaboration these rituals are supposed to reaffirm:

• “I don’t understand the engineers’ reasons for acting as they do, and I don’t care.”
• “I know the best way; we just have to convince them to go along.”
• “They don’t need to know why we need this; they just need to follow.”

Noted social scientist Chris Argyris identified the mindset behind these statements as the Model I theory of action, which is characterized by the wish to save face, appear rational, and win the argument.1 This type of thinking shuts down curiosity and transparency, preventing new ideas from emerging. Argyris contrasted this theory with Model II, where the focus is on learning, generating the most information and options from everyone in the room, and finding the best possible decision rather than winning. This type of thinking clearly supports productive collaboration. In Argyris’s work with over 10,000 people around the world, people consistently claimed to agree with and advocate for Model II — but their actual behavior overwhelmingly embodied Model I, especially when they cared deeply about the decision being made.2

Often, when organizations are suffering from strained communication, their walled gardens are the result of technology leaders — frequently either newly recruited or newly empowered — acting in good faith to create a better process for software development. They attempt to create an environment in which the unresolved conflicts in organizational alignment are excluded so that software can be created. The problem here is a symptom of larger cultural issues that have been left unaddressed during the alleged transformation. In our opinion, this is one of the most significant factors leading to digital transformation failure: Simply aping the behaviors of successful teams does not magically create the culture and mindset needed to overcome Model I thinking.

Typically, all parties have positive intentions and work hard to achieve them — the engineers, who are aiming to produce high-quality software that works well, and the nontechnical team members, who are deferring to the technical experts and hoping all will be right in the end. But despite their best efforts, the consequences are all too often disastrous. No wonder Argyris called this phenomenon of effortlessly creating the opposite of your intended result “skilled incompetence.”3 How can we avoid this fate? How can we keep IT involved and not locked behind the Model I wall?

Conversations Replace Walls

We find consistently that Argyris’s conversational analysis methods are successful in helping companies break out of the walled garden.4 These techniques take conversations as the unit of learning and improvement and make them the objects of study by all members of the organization (technical and nontechnical alike). By implementing the four R’s — recording, reflecting, revising, and role-playing — in their conversations, participants learn to adopt a transparent, curious, Model II approach and begin to build trust and a generative culture.5

As an example, we’ll walk through the conversation of Elijah, a senior executive, and Umar, a technical leader. In this case, Elijah recorded how he thought and felt during the conversation and what each participant said.

Elijah: “We need to start installing the new devices in the pilot lab by the 20th.”

What Elijah thought: I’m so frustrated. We have to give the client some tangible progress or they’ll walk, and then where will we be?

Umar: “No way. The high-level and low-level designs don’t match yet, and we need at least a month of replanning before we can even start working with their APIs.”

What Elijah thought: Why can’t you see how critical this is? Forget the designs — we’re going to be designing a layoff plan if we lose this deal.

Elijah reflected on this conversation by locating question marks (indicators of curiosity) and unshared thoughts and feelings (indicators of a lack of transparency). From there, he revised the conversation to move closer to a more open, generative approach and then role-played the changed conversation with a coach before trying again with Umar, who had himself been working on improving his communication through similar analyses. As a result, Elijah found that he could share his concerns and ask genuine questions of Umar about deadlines and options; likewise, Umar and his team learned to respond not in dismissive tech-speak but with meaningful empathy for stakeholders and their concerns.

The above conversation is based on one analyzed by the CEO and the vice president of engineering at a health care client we worked with whose siloed IT staff routinely took six months or more to make the simplest changes. After improving their conversations and building trust, the two leaders discovered that the main barrier to faster delivery was the fear of a patient safety incident, leading to extreme caution and a massive overdesign of solutions. Once they had used better communication to build coherence and chart their concerns, they took the time to validate whether they were accurate. What they learned was that there was significantly more flexibility in the requirements than anyone expected; it turned out that much-less-involved quality-control methods were perfectly acceptable and safe if they were well documented and controlled, and the company found that it was able to make software changes every two weeks after adopting the new techniques.

These examples illustrate how holding difficult conversations that build trust and reduce fear help organizations emerge from siloed environments. We also find that analyzing and improving conversations assists in three more key areas: defining a clear purpose, learning to commit effectively, and creating two-way accountability.6 Companies whose staffs have mastered the art of difficult conversations and techniques for continually improving them find not only that collaboration with IT is simpler and more satisfying but that they also increase revenue and market share as all parties discover options and solutions previously hidden. The walled garden is beautiful but destructive; bulldozing it unlocks a real cultural transformation.