Over a million developers have joined DZone.

On foxholes and corporate silos

DZone's Guide to

On foxholes and corporate silos

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

The existence of silos in large companies is fairly common. Employees frequently bemoan the misalignment that exists across functional teams and organizational entities whose primary connection seems limited to the logo under which they exist. The larger the company, the looser the coupling of different silos. That said, large companies certainly do not have a monopoly on silos or their ill effects.

But simply knowing that silos exist doesn’t help too much. The operable question for everyone operating in these environments is: What can I do to remove unnecessary silos?

Process as an answer

Almost invariably, companies that correctly diagnose the silo problem lean first to process. You tend to notice silos when information is not freely flowing between groups that have some dependency between them. Either something gets dropped, as in the case of misaligned priorities, or sometimes there is overlapping work where more than one team is executing against the same basic deliverable.

Whatever the case, the root of the problem typically gets reduced to poor communication. And the best way to improve communication? Process. Or so goes theory.

The problem with using process to cure a communication problem is that is somewhat like putting ice on a tumor. It might make some pain go away, but it really isn’t solving the underlying issue.

The problem with process

I don’t want to suggest that process is not important; it absolutely is critical in creating an operating cadence and keeping things orchestrated, especially in complex environments. But understand that applying process to communication problems is oversimplifying the situation.

Process tends to be very transactional. Put slightly differently, the reason for communication becomes the process, not the sharing of information. In a transactional model, information might flow more predictably, but it still doesn’t flow freely. You end up creating an environment where information passes between stakeholders provided that information is part of some effort that is covered by explicitly-defined process. At the edges where the process doesn’t apply, the process doesn’t actually help.

On the surface, it might seem that the edges represent corner cases. Perhaps two business units in a company that have unrelated product lines each see opportunity in an adjacent space. Or maybe two engineering teams are implementing different features in common code. Perhaps you have two account teams engaging different offices of the same company, each offering their own pricing and discounts.

In the best case, when there are collisions, you quickly sniff them out before they become catastrophes. Then you add a new process to the operations manual to cover that corner case. The issue here is that you either have to foresee all possible corner cases and create a ton of process (along with the overhead that comes with it), or you have to wait for each collision to occur before taking action. Either way, you lose.

Communication is not transactional

While process will mitigate the risks of poor communication, the reality is that communication in well-functioning environments is not purely transactional. Information flows most freely when there are relationships that exist behind the transactions. In your personal life, the reason you tell someone something is that it occurs to you that the person might be interested or impacted in what you have to share.

Understanding people helps you decide what to share, and just as important, what not to. Creating process that requires sharing everything is the equivalent of those people in our social networks who broadcast everything they do to everyone. Without discerning what information is important, you force others to filter. While annoying in a social network, this type of noise can be debilitating in a corporate environment. Expecting people to ferret out the important bits in a stream of noise is unproductive and creates the same risk that the sharing processes aim to eliminate.

Relationships, not process

The real magic in creating corporate cohesion is relationships. This is certainly not a groundbreaking observation, but what exactly creates a relationship?

For most people, relationships are forged out of shared experiences. Those experiences can be as simple as a common set of coursework as in school, or a common objective as with a sports team, or something more dire as in shared fates in war. The more intense the experience, the tighter the bond. If you have ever wondered why teams do rope courses, it’s because it represents a shared experience.

Shared experiences in corporate environments

In work settings, shared experiences tend to exist within functional boundaries. That is to say that people who work on the same team will have far more exposure to a shared experience than people who work on different teams. This is why it is common to have very strong team communication even in companies that suffer dramatically in cross-functional communication.

When you think about what drives a shared experience in the work world, it is typically a deadline or an obstacle. Engineering teams will rally around a release date. Product management teams might rally around a new product. Sales teams will rally around a particular customer. The trick is getting different groups that don’t work together intimately on a daily basis to have a shared experience.

Getting in the same foxhole

Leaders in companies that have silos should work to create opportunities for multiple teams to climb into the same foxhole together. At startups, this is frequently a big early customer or a product launch. At larger companies, you can manufacture these foxholes with larger initiatives around customer satisfaction or transformational changes. The key is creating opportunities where success is dependent on multiple teams.

But the nature of most work is modular. So simply declaring something a joint effort and leaving teams to work on it is not sufficient to really build relationships. It’s the shared experience, not just the loose cooperation towards a high-level, somewhat distant goal.

Pulling people together means allowing them to work together to knock out large obstacles. This requires a common understanding of the challenges facing different parts of the team. Minimally, the various players need to at least be aware that their teammates solved a problem, even if they were not integral in the actual solution. It is incumbent upon the leaders in the organization to help propagate these challenges, allowing teammates to congratulate and celebrate together when meaningful progress is made.

The bottom line

The dynamic that leaders want to foster is less You vs. Me and more You and Me vs The Problem. By pulling teams together into the same foxhole, you create a shared experience. And that shared experience can establish the foundation for relationships that will ultimately mute the effect of silos in your organization.

- See more at: http://www.plexxi.com/2014/08/foxholes-corporate-silos/?utm_source=feedly&utm_reader=feedly&utm_medium=rss&utm_campaign=foxholes-corporate-silos#sthash.fD7Su7Hc.dpuf

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}