Tilting at Silos: Fostering Teamwork Between Insulated Groups

Don Quixote famously (and fictionally) attacked a series of windmills, trying to topple what he thought were monstrous giants so that he could rid the Earth of their evil breed and take their spoils to fund his quest for the hand of (not-so) fair Lady Dulcinea. While his intentions were good, he was, of course, unsuccessful; a spear and an old mare are not exactly proper weaponry to face off against a foul giant made of stone.

In the tech industry, we don’t have windmills or spears (unless you count toy lightsabers), but we do have silos. Sometimes silos can become so thick-walled that they pose a real threat to worker productivity and overall project success. It’s then that you need to start knocking them down—or at least chiseling them down enough so that employees in one can see eye to eye with those in another.

A silo, of course, refers to a generally close-knit team put together for a very specific purpose. That purpose might be the development of an isolated end-to-end project or maintenance of a highly active and important system: some goal that allows the team members to put their heads down and focus on an immediate task at hand. The problems begin when someone from another silo taps them on the shoulder, looking to interface with their system or to impose some new sort of process.

Then the silo approach backfires a bit. The things that help the silo members work so effectively—strong team relationships and isolation from distractions—start to become hindrances. When two closely knit teams are asked to work with each other, animosity can flare up quickly, leading to an “us versus them” mentality in both groups. That’s a problem when the overall success of a project or indeed an entire company depends on cooperation.

The specific problems leading to the animosity vary, depending on the situation, but the root cause usually is a communication breakdown at some level. Ultimately, it’s not surprising that two teams that are used to working closely within have a hard time reaching out to another group on the “outside,” especially with the potential extra work and extra stress at stake. It’s difficult to come to the table with an evenly balanced opinion about a person or group of people who ask impolite questions about why your system is failing, or who exhibit stubborn reluctance to implement the new standards you and your teammates devised.

There is a variety of strategies leaders turn to when these sorts of rifts begin to form. Unfortunately, many of the traditional ones just don’t work. Let’s look at some of the specific problems and some of those common solutions, along with some alternatives.

Minimizing Miscommunication

Often, problems stem from a lack of understanding of how a given team’s systems work. This is particularly an issue in software engineering. One common recipe for conflict is a team being called upon to deliver a set of data to another team’s system. If that data set is not formatted or delivered correctly, and if it causes problems downstream, all sorts of fireworks can go off. Usually the upstream team takes the heat—even if it was ultimately the poor documentation or frailty of the receiving system that led to the problem.

A common solution here is to set up lengthy information-exchange sessions long before the integration. The intent is for each team to teach the other all it needs to know before it needs to know it. Members of both teams lock themselves in a conference room for hours or days. They try to stay awake through endless PowerPoint slides and technical discussions.

These sessions can be effective, but too often they’re unproductive. It’s just too easy to lose focus during these things, especially when they happen early as part of the design or even requirements-gathering phases of a project, long before any of this knowledge can be applied. By the time anyone sits down to do the work, whatever was learned has long since been forgotten.

A better way to prevent integration problems is simply to enforce good documentation. If the docs are good, miscommunications will be minimized—if only because all communication is minimized.

That doesn’t mean more documentation; it means better documentation. Over the years, as a system is maintained and enhanced, the tendency is to create reams of documentation that’s quickly out of date and rarely has solid focus. What’s needed is currency and terseness. On the software engineering side, for close integration there’s no excuse for not having up-to-date API-level documentation, whether you’re using Javadoc for Java apps, NDoc for .NET development, or Doxygen for a variety of other platforms like C/C++ and Python. Likewise, if you’re talking via Web services, WSDL files certainly have adequate provisions for documentation.

For data integration, documenting things can get a bit more complicated. If it’s XML, your job is relatively easy. A strong and detailed schema annotated via something like xsddoc along with a few example files goes a long way toward avoiding confusion, particularly if the schema is well structured. If you’re using less-structured data, such as CSVs or proprietary file types, things tend to become much more difficult. Lengthy and detailed external documentation with numerous examples will be required—yet another reason to move to XML.

Accurate and terse documentation plus a short, focused discussion should get the two teams 90 percent of the way toward efficient interaction. However, even good documentation isn’t always enough. If one team is publishing an interface of some sort, it’s important that it be a strong one. OO programming guru and author Scott Meyers summed it up nicely when he said that “interfaces should be easy to use correctly and hard to use incorrectly.” If one team is asked to use an interface that doesn’t meet this criteria, problems will occur, and that interface should be revised before they do. Thankfully, Scott also has some suggestions on how to do so. His article relates to programmatic interfaces, but the concepts can certainly be extended elsewhere.

Turning “They” into “We”

It’s one thing to minimize miscommunications and streamline integrations with good documentation and processes. But while those steps can avoid animosity in the long run, ultimately they don’t do anything to help bring the teams closer together or to get them working together effectively instead of begrudgingly. It’s all too easy for one team to form an opinion of another as a hindrance or an annoyance. Breaking that opinion is much more difficult.

Often, companies turn to morale-building events in this sort of situation, encouraging workers to let their hair down a little and establish personal connections with members of that other team. If managers can actually get their workers to sit down and talk with that other team at these sorts of events, they’re doing well. Thinking that the team-bonding will carry back over to the office is expecting too much.

If the problem exists in the workplace, it should be addressed there, where workers are under the same stress and pressure that adds to this animosity in the first place. The best way to bring the teams together is to get them to a point where they’re helping each other to reduce that stress and pressure.

For coders, try cross-team pair programming. Pick one developer from each team and have them alternate sitting with each other (either physically or virtually), acting as brainstorm partners as they track bugs or implement enhancements. You need the right personalities for this to work, but it can be a very good experience and is a much better option than something drastic like a cross-team job rotation, a switch that rarely leaves all parties involved feeling particularly motivated.

Another great option is to send the teams away to training together or, if possible, to bring a trainer in-house and design a course on some technology or technique that can be beneficial to both groups. Have the trainer tailor the course to focus on applying the training to the problems the team members deal with on a day-to-day basis. Get the whole group working together to solve the sorts of problems that plague its members in their daily jobs. Once they go back to the grind, they might just keep that camaraderie.

Physical proximity within an office is, it seems, accessible to few teams these days, but it can be a big help when it’s possible. If two teams need to work closely together, moving them so that they’re adjacent to each other makes things easier—if it’s done right. When it’s poorly implemented, one team is uprooted and dropped next to the other, or pulled from its roomy location and sent to the basement. These changes hardly get relationships off on the right foot. So, when moving teams around, tread carefully.

Come Together

Sometimes all that siloed workers need is the occasional reminder about how their interaction with others will help the business as a whole, and they’ll begin to open up a bit. However, things usually aren’t that easy. Hopefully you and your teams will find success with the above tactics. If all else fails, you could always just force the issue and merge the teams, though that move might prove to be somewhat…quixotic.

Tim Stevens is a part-time freelance writer as well as a component architect at TopCoder, where the focus is on optimizing methodologies and driving software re-use. He has written hundreds of articles, on everything from Ajax to the Xbox, and has honed his engineering skills in both small startups and large international corporations.