Back to resources

How to Break Down Team Silos

Innovation / Experiment
Internal Communication

16 August, 2021

Jan Macek
Jan Macek

VP of Engineering at Vendavo

Jan Macek, VP of Engineering at Vendavo, explains his strategies for establishing mandatory guidance for his team.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.