The Argument against Organizational Silos

Being from the Midwest, SILOS were a common sight. A silo is a structure for storing bulk materials. Silos are more commonly used for storage of grain, coal, cement, carbon black, wood chips, food products and sawdust.

Why are SILOS in place in IT organizations?

We have organizational silos in IT as a way to structure the department or division into components we can manage. While the organizational structure is often started around a “target” (often defined by external factors around responsibilities or metrics for depth/breadth of a targeted managerial scope), they often evolve to being structured around people. For example, we may start with an organization defined by ANALYSIS, DEVELOPMENT, OPERATIONS with a pure distinction, and then move “maintenance & adhoc reporting” between development and operations based on the people in these roles.

With the target organization in place, we then build management systems reflecting this structure. Objectives, budgets, headcounts, reporting and bonuses all get layered around this structure. Each silo begins to have a well defined culture with unique operating norms.

While fine on paper and intriguing to consider, the SILO structure breaks down when a project transcends a silo. We forget the reason we have an IT area is to support and improve the business process. Wherever there’s a handoff there’s potential for friction or something to be missed.

For example, when the CIO makes a commitment for delivery, one would expect all departments to line up around said commitment. In some organizations, the only group aware of the commitment is the business analysis area, who then transitions a commitment to a project request to development, who then makes a valiant attempt to release something to production only to get pushback from Operations on why something is being “slammed” into production.

When commitments are shared across the organization, success is often more readily attained.

Another example is around procurement. Procurement may be within the IT organization, or external in an administrative area. How does IT interface to procurement? If by providing simple requisitions yielding a purchase order, the contribution of procurement is minimized. When procurement is involved throughout the process, breakthrough performance (total lowest cost) can take place.

You may be thinking here’s another bigot for a matrixed organization, and I’m not. In my experience people often get confused when in a fully matrixed organization as to who is calling the shot.

I believe organizing around the process is the key. Yes, the traditional model can stay in place; the components are rewarded based on successful delivery. Everyone is pulling on the same rope regardless of the functional area. There is ALIGNMENT across the organization.

With alignment, great things can happen!