Overcoming Organizational Barriers to Change: Part 3 - Dealing with silos
Nov 20, 2019
Peter Maddison

When working with some of our larger customers, we frequently run into common barriers to change. Change is difficult and, no matter how often we say it, there is no silver bullet for how to get there. However, we can say there are commonalities in approaches, things we’d look for and actions we’d take in response to those findings. When we look at the delivery of technology within organizations, we often come across the barriers within how the teams are working, but even more frequently, how the organization is working with technology is the bigger barrier. Developing powerful roadmaps is valuable and greatly helps with generating alignment and a common vision.

In my last two posts, I spoke to blame culture and looking at the whole system. In this post, I’m going to talk through the third of three common organizational problems we encounter, dealing with silos and specialization.

Silos

Why we have silos

As organizations grow, silos often start to form as a part of that growth. They form for several reasons:

  1. A need for specific skillsets requiring deep expertise form around areas such as people operations or in lines of business. This becomes an issue when people from those different areas stop talking.

  2. Fractional ownership of a business process causes the owner of a particular area to optimize within their team without looking at the entire process.

  3. Geographical dispersion causes teams across geographical boundaries to form silos.

Regardless of how they begin to form, the result is collaboration becomes harder and the delivery flow breaks. Given how common they are, silos may appear a natural part of how organizations must operate at scale. However, in high performing organizations, value flows across areas, breaking down silos, despite how the organization has been forced to structure itself.

An example

A few years ago, I noticed a problem with how work occurred across the teams I was leading. The two biggest problems I saw were:

  1. A work request would arrive, through a variety of channels and bounce around until it found a home.

  2. To execute the request, e.g. create a new database, the Unix team would notify the Windows team to create the necessary accounts, the storage team to allocate storage, the network team to create networks and open firewalls, the database team to install and configure the database and so on.

Of course, all these teams were already busy doing work in their areas and not just sitting around waiting for new requests to come in. Equally, a DBA generally could not do a network engineer’s job, and organizational policy kept their access separated.

The result of this was something a friend of mine refers to as “ the infrastructure swamp”. Things would go in and get stuck. You required a guide who knew how to get through all the interactions or nothing would happen at all.

So how to fix it?

Our first attempt at streamlining this involved working with the teams to reorganize into a series of delivery areas: planning, intake, engineering and operations. The application of Kanban practices was overlaid on this to identify, measure and improve the different classes of service, allowing for continuous improvement.

Kanban

It partially worked but, we had made a couple of mistakes:

  1. Reorganizing the teams caused more discomfort than we realized.

  2. Making the change and believing we were complete.

With six months of preparation for the teams, our mass change went well. We discussed and supported people, involving them in decision making. The initial results were great; people were happy, throughput increased, work started to flow. So we, unconsciously, patted ourselves on the back and walked away. The result quickly led to our falling back into old habits and not supporting the teams the way they needed, with the teams quickly following suit.

That was then; this is now

As with all painful mistakes, there was a lot to learn, and we did manage to course correct eventually. Nowadays, after several more successes, my approach would add the following components:

  1. Identify and classify the work in the system. Make it visible to everybody.

  2. Work with the teams to map out what all the necessary steps are to complete each type of work.

  3. Follow-up with the teams regularly to support them through the transition to the new system.

  4. Provide coaching services to help the team adapt and work within the new model.

Then, with happy and supported teams, we could have a more successful change. Service teams I work with today are far more energized and ready to work on solving the problems silos create.

Conclusion

Silos may be a natural part of any organization, a necessary part of scaling required to handle the complexities of the systems we work within. As such, the first part of setting your company up for success is not tearing down those silos but working out how to work within them to deliver value faster.

Xodiac and its ecosystem of partners are ideally placed to provide you with the understanding and skills necessary to make that happen.

Share:

Archive

Tags