How to Break Down Team Silos
16 August, 2021
Imagine running a company, where you develop an excellent quality set of products, but there is hardly any transparency with the engineering. Basically, this was the problem at my end. I knew that building some teams around the products and components brings great benefits but at the same time can cause difficulties with synchronizing people. Hence, we did something different instead: we created a mandatory guidance despite the critical situation.
When teams have freedom, they use specific technology, adopt rare patterns, or move forward with unstable libraries, because they feel that they can. However, the problem arises when they do so in their silo and other teams are not aware of the direction that they are heading towards. Later in the process, we were faced with massive problems when we wanted to integrate products or components together. Since the teams were operating way too independently, while we were looking for ways to make things more transparent, it already became a problem.
On the other hand, teams were pretty good at updating themselves — most of them would read articles on the Internet regarding new technologies. Some were too eager to test things before even realizing whether it would bring us any value. While it was great for team members to be curious and willing to learn, it was a blessing in disguise for us. Along the way, teams were making a lot of technical decisions that others were not aware of.
First of all we introduced guidance to prepare RFC (Request for Comments) once certain conditions were fulfilled. RFC needs to include the problem statement, all the considerations relating to it and it's potential solutions. We had a fixed structure and guideline, and that the responsible person had to prepare the pros and cons of all options in order to analyse the benefits. The most crucial part of RFC is that it is available to anyone in engineering, and all people are encouraged to comment on this. So, by introducing RFC, we were building a mechanism to exchange information among the teams, and also get valuable comments and alignment on the problem solution. Everybody is educating themselves and learning something new. It was not isolating one person or team.
Next to that, we were aiming to improve cooperation on technical matters. In that regard, we had regular meetings on the progress of new development. Besides, we introduced ways to enhance communication within the teams and bring visibility into what was going on in the technology roadmap. All such actions were related to developing optimal solutions and eventually meeting customer commitments. While the technology roadmap can be floating, you can either push it back or accelerate but still teams have to focus on this.We had to bring clarity and transparency into the internal operation of the engineering teams.
Another thing that we introduced was aiming to break the silos between the teams. We introduced an innovation week where the teams were encouraged to form completely different groups. They were working daily, and they were supposed to build a new feature or a new product and demo the results of their work to the whole group. . They continuously learn how to work with others. Nonetheless, we were adamant on bringing in mechanisms on how to increase transparency into the engineering operations, break the silos within the team and eventually make us more transparent across the organization.
- Documentation of the engineering work is the key to success. Even if it is the trivial of a trivial matter, I would suggest people to write things down. While engineers are made for coding, and might not be fans of documenting their decision and mind process , make them understand how beneficial it is in the long run. Another way of seeing it is, if you look forward to bringing transparency and making everyone a part of the decision making process, documentation is the only way.
- Engineering managers have to focus on teamwork marketing. While the non-engineering teams are fully focused on the business mostly, there is a need to make them understand the engineering side of things. The more these teams will open up, other teams are less likely to be surprised when they find how costly technical works can be.
- Never let engineering operate as a black box. It would create more confusion and less understanding around the company. In open engineering, if you let everybody look inside at what was going on in the long term, it will be helpful. We started activity when engineering leaders identified and focused on the different non-engineering stakeholders in the company and specifically addressed them with tailored information about what is going on. . Even senior leadership teams properly communicated and explained things that were happening in the engineering.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Head of Engineering at Xero
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.
Senior Software Engineering Manager at Anaplan
Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.
Engineering Manager at AlleyCorp Nord
A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.
Principal / Founder at id8 inc
Lucjan Suski, CEO & Co-founder of Surfer, relates how he started a company as a side project and shares his insights on bootstrapping tech startups.
Co-founder, formerly CTO and CEO at Surfer