Companies face a hard time transforming their (internal) organizations to meet Agile and DevOps goals. Especially large companies with a lot of business units, supporting departments, and developer teams face big challenges to make it all happen. Traditional silos still exist and form a true bottleneck for effective transformation programs. Yet, a lot of tips and tricks exist to tackle this problem. In this article, we’ll share our thoughts on breaking down IT silos, here’s where you can start.
Before you begin…
First of all, the organization itself needs to acknowledge that individually operating silos exist before one can even think of breaking them down. To identify the current situation, it’s not enough to just interview people or send out a questionnaire with crystal clear questions. Subtle issues reveal much more information to make a plan of action. It’s key to find them.
Perhaps you notice the many manual handovers between teams working on IT products? Or you happen to see that the same application (components) are created by multiple teams. Another example would be a massive amount of shadow IT which is difficult to trace. Let alone what happens inside these tools.
These above-mentioned aspects are key topics to be put on the management table to discuss. What exactly happens in other departments, business units, and developer teams and why does that happen in the first place? Once major people of interest in the organization acknowledge these problem-areas then a culture of change can evolve. Otherwise, efforts remain less effective as there might be too much resistance to actually break those silos down.
Share business goals
Every IT-minded organization should have clear business goals and thus an IT strategy. If this is not clear to everyone in the organization, people are not on the same page. This results in IT products that do not answer real business needs as well as solutions that live in isolation. If you share business goals and keep all teams aligned in their projects, you gain a motivated set of people to make it a reality.
On top of that, if you make people true owners of the business impact of their projects, they feel comfortable about doing the right things which are of interest to the entire company. Their business goals become part of the global business goals which apply to all of the teams. This also makes Business Owners enthusiastic to get the most out of their teams. Team motivation boosts as well as individuals who will shine in their efforts.
Reduce concentrated skill-sets
People who work for a long in the same role often feel very comfortable about it. Perhaps they specialize in a certain topic. This makes it hard to form cross-functional teams in which “everyone can do every task”. Given specialized teams like security teams or teams which are focused on a certain capability on a single tech stack might concentrate on those still-sets only. When the idea is to break down silos and to make each team responsible for the initial concept from which they design, develop, and test their solution, this is a severe limitation to establishing cross-functional roles.
Previously, companies kept those activities as separate teams which all have their tasks and place in a specific phase in the Software Development Life Cycle. Nowadays, developers need to adopt all of them in a single person. Logically, this does not happen overnight. However, senior management needs to foster a culture in which developers can learn from subject matter experts. Think of security experts, test automation experts, or other specialized personnel like risk officers. Try to hook them in with the team in charge and give them room to work together to ship features as a collaborative effort.
Use tools and processes to your advantage
DevOps and cross-functional teams benefit from a cultural change to use tools and processes to their advantage. When everyone in the organization keeps the following basic guidelines in their mind, breaking the existing silos down becomes a lot quicker:
- Everything is source code nowadays – if it is not stored in Git, it does not exist or it should not have a reason to exist.
- Infrastructure is generated using scripts, not manually executed scripts that tend to go wrong every time some small thing is changed.
- A single team is responsible for all phases of the SDLC.
- All tools are provisioned and configured using code, with no exceptions for “that special team” which wants to utilize the GUI to set up things themselves. Consistency is king here, every team needs to invest to use proper APIs to interact with those tools.
- Every team follows the same process to deliver new software features. Often, project managers tend to think in exceptions and facilitate them. That makes things worse if you want to have visibility about what is going on in your organization.
- Vendor lock-ins should be avoided whenever possible. This makes it easier to migrate away from proprietary tools which might become obsolete or tend to be replaced in the (near) future. Knowledge about those tools and processes should also be spread around so the knowledge does not “stick” to only a handful of people.
In addition to the last challenge, be sure to do all you can to let practical information about those tools and processes flow between different departments.
Improve and prevent the creation of new silos
Feedback and other measurements help to gather feedback about the existing strategies or unforeseen circumstances. When activities like the correct usage of tools, processes, workflows or team-building efforts fail, it’s time to evaluate and improve those things that are the real culprit here.
A powerful example here would be the patching of security issues. Once teams are free to decide whenever they prefer to fix critical issues, other teams might follow. This creates a culture in which fixing those issues is not considered important. Resolutions should be shared on a centralized board (perhaps scramble sensitive information) so other teams can learn about the root cause and the solution. Once other teams benefit from those solutions and share their feedback with the original team, the organization becomes a powerful workplace to collaborate on those things.
If organizations neglect these kinds of examples, things will get out of control and it is very likely that new silos appear since people will start to find a workaround in order to get their features to production in a timely manner. It can have a destructive effect on other teams if one of the “early adopter” teams is seen as an example for the rest of the teams. They should act like “the perfect example”, a team that leads the way.
Finishing words
No one can deny that creating a culture of collaboration is easy. There are so many items you need to work on to break down existing silos and to prevent creating new ones. A strong business strategy that is communicated to all actors, the right usage of tools and processes as well as proper feedback loops help to break them down. Beside these, try to create cross-functional teams which will happily share their knowledge and gained experience. All of these ideas help to get you started and make your company more effective in the era of true DevOps in which silos become a thing of the past.
