Loading...

How to Break Down Team Silos

Jan Macek

VP of Engineering at Vendavo

Loading...

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Be notified about next articles from Jan Macek

Jan Macek

VP of Engineering at Vendavo


CommunicationOrganizational StrategyCulture DevelopmentEngineering ManagementTechnical Expertise

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up