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.
Why we have silos
As organizations grow, silos often start to form as a part of that growth. They form for several reasons:
-
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.
-
Fractional ownership of a business process causes the owner of a particular area to optimize within their team without looking at the entire process.
-
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:
-
A work request would arrive, through a variety of channels and bounce around until it found a home.
-
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.
It partially worked but, we had made a couple of mistakes:
-
Reorganizing the teams caused more discomfort than we realized.
-
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:
-
Identify and classify the work in the system. Make it visible to everybody.
-
Work with the teams to map out what all the necessary steps are to complete each type of work.
-
Follow-up with the teams regularly to support them through the transition to the new system.
-
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.
Archive
-
Directing Flow
Jan 5, 2021
-
Automating Governance
Nov 30, 2020
-
Metrics to help your team improve
Nov 19, 2020
-
Taking on your new VP role
May 17, 2020
-
Do I need a platform team?
Apr 27, 2020
-
Knowing where you are on your digital transformation journey
Apr 19, 2020
-
Securing the value chain
Apr 6, 2020
-
This is the time. Every crisis is an opportunity.
Mar 31, 2020
-
Face-to-face with the agile manifesto... Working with remote team members
Mar 17, 2020
-
Coaching Distributed Teams
Mar 16, 2020
-
Project vs Product
Mar 9, 2020
-
Identifying the bottleneck
Mar 2, 2020
-
Continuous improvement of work and psychological safety
Feb 24, 2020
-
How to scale the transformation
Feb 17, 2020
-
Making Digital Transformation Stick
Feb 10, 2020
-
Minimum Viable Bureaucracy
Feb 3, 2020
-
Application Modernization and Complexity Debt
Jan 27, 2020
-
Locality, Simplicity and Flow
Jan 20, 2020
-
First steps in making your Digital Transformation matter
Jan 13, 2020
-
Reflecting on 2019
Dec 22, 2019
-
Overcoming Organizational Barriers to Change: Part 3 - Dealing with silos
Nov 20, 2019
-
What throughput can tell you about your team
Nov 3, 2019
-
Be the change
Jun 13, 2019
-
Overcoming Organizational Barriers to Change: Part 2 - Not seeing the system as a whole
Jun 3, 2019
-
Different leadership styles
Apr 27, 2019
-
The decline of Open Space
Apr 16, 2019
-
Assessing maturity of a technology department
Apr 4, 2019
-
Overcoming Organizational Barriers to Change: Part 1 - Blame Culture
Apr 2, 2019
-
My journey: Corporate or Startup
Mar 31, 2019
-
The Queen's Hyperloop Design Team: a lesson in Systems Thinking
Mar 7, 2019
-
Importance of Criticism
Feb 14, 2019
-
Understanding DevOps
Jan 18, 2019
-
Applied Coaching
Jan 13, 2019
-
Reflecting on the year
Dec 20, 2018
-
Build powerful roadmaps
Dec 4, 2018
-
Satisfying controls at speed
Nov 28, 2018
-
Making every team thrive
Oct 16, 2018