I have some of the greatest managers and colleagues I have ever had in my working life. Yet one thing that seems to be highly enforced at our company are workplace silos, i.e. information should not flow between different teams/departments unless the managers want it to.

Most business and management books/articles/blogs seem to demonize the workplace silos... but since we are a very successful company (market leader) and have some very qualified staff, I imagine that there can be situations where it might be beneficial and productive to the company's purpose.

I am personally not offended by the silos, but would simply like to understand what drives and motivates their existence.

An example reason that comes to my mind is: a very new strategy that shouldn't be leaked anywhere, and thus is held secret even to internal staff.

  • 1
    I don't know your business, but in some, different groups in a company may be bidding for the same business from a company or agency so they have to truly work in different information silos because of it.
    – user8365
    Commented Jun 17, 2014 at 11:28
  • The answer depends on exactly how you are defining "silo". With a large enough codebase it becomes impractical for everyone to have equal expertise in all portions of the system, and some siloing happens naturally as people pick areas to focus on. "Everything in moderation, including moderation."
    – keshlam
    Commented Jun 30, 2014 at 2:45

5 Answers 5


In my experience, silos work well in companies that highly value security and privacy. I have mainly seen this in companies whose primary business is contracted out to other companies. The customer will often require that their information be compartmentalized and separated from other parts of the company, particularly if you also work with one of their competitors. Companies that work with government customers are also often under strict security regulations and must keep all of their information compartmentalized.

I could also see silos being effective in companies that must keep valuable information from being leaked to the public. Only certain people at Coca-cola have access to the secret recipe, and not everyone at Apple knows when the latest iGizmo is being released. The less people who know something, the less chance there is for that information to end up in the wrong hands.

So silos are not in place because they are an effective management strategy that fosters innovation and growth. They exist as a successful means of securing highly valuable information and preventing it from being leaked to the wrong people.


I think silos seem to be an over-correction for companies or organizations that do not have a good communication strategy/plan and established processes. In enforcing the silos, it helps to keep information and personnel focused on tasks at the risk of not cross-skilling employees as well as making use of efficiency gained from information or skills existing in other areas of the organization (which also results in duplication of effort).

There are organizations that have very defined (or distinct) departments with self-contained projects and teams that do work very well together. But if this is the case then you could argue why the same process doesn't apply everywhere else to allow people to jump into any other roles or projects as well.

So I think silos are just a stop-gap or quick-fix to long term solutions of establishing a really efficient and effective work environment. A self-governing team may even be able to do without managers! Imagine the outrage that would cause :D


I'm going to lean on my own organization and my experience with silos.

Under what circumstances can workplace silos be beneficial to the company?

Not a single circumstance that I can think of.

I jest, but I can see the silo model working well if those at the top of the silo have an understanding that they're part of a company and may potentially need to work with another silo to get things done. Bridges need to be built between the silos in some sort of analyst capacity to evaluate and bring the groups together in ways that don't interfere with the point of having a silo, because the are benefits of the structure.

That's just an observation from my silo'd organization. I needed both the physical infrastructure team and security team to help me with something and it ended up looking like two groups going through a bad divorce. I needed someone from above to tell them to play nice.


I've worked in several different industries and there were few intentional requests to "silo" our data. Even a payroll system gets linked to other benefits and healthcare tracking. Any by that I mean having no need to move data in or out of a particular data store. This is different than security which should allow the access and flow of data "as needed" and rarely needs complete isolation. It's a matter of degree.

Silos get created because different parts of an organization need apps for specific tasks. During the growth of the business, many of these come in at different stages. A simple accounting system is put into place. The one person doing any sales has all the clients in his or her contact manager. Different industries have apps specific for their needs (building houses, managing stocks, insurance policies, scheduling deliveries) and then there are off-shoots like, inventory, project management, payroll, document management.

The need to integrate or connect the silos doesn't happen right away. Few companies will take the time and cost to prepare for this early on. Sort of a premature optimization. If you close one sale a week, it's not that hard for everybody to manually enter that in their system, but along with the increase in volume, comes other complexities. You need to avoid duplication. How do you cross-reference the same customer when no one even managed to spell the name the same?

A silo can be the most cost-effective choice to offer the security you need, but in my experience, they usually occur because of a lack of need, planning, technical expertise which all boils down to time and money.


One example of isolation of part of the workforce:

You can have a skunkworks project where a small and loosely structured group of people research and develop a project primarily for the sake of radical innovation. The idea is to not let external influences hold them back. One reason for that could be avoiding copyright claims: if you let your group develop product X which look exactly like the competitors' product Y, you don't want them to use any knowledge about the internal workings of Y.
(There a specific name for this, but I can't find it; please edit if you know).

Essentially, this is a form of Mushroom Management: You keep people in the dark, "feeding them shit, and watch them grow." That is, isolating the design team from outside influences and, instead, using the fear of the unknown to motivate the team.

Tracy Kidder, in the book "The soul of a new machine" describes exactly this method of operation.

  • When you're intentionally setting out to do something that looks like Y's product without using Y's IP, I've seen it called a "cleanroom implementation". It's only applicable to certain kinds of product, but for example you might do a cleanroom implementation of a particular device driver (whose required behaviour is very well defined by the OS) to avoid licensing the "usual" driver. A former employer of mine initially did a cleanroom JVM, but later switched to using some of Sun's class code. However, the term is ambiguous and I don't know whether that's what you meant, so I won't edit :-) Commented Jan 6, 2015 at 22:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .