Establishing Communication in a Growing Engineering and Product Team

Problem

As our company branched out to different locations, the line of communication between the engineering and product team became difficult to regulate. Not everyone had the same context and awareness of what was going on in different parts. We started to see that we were not catching the problem of unreported progress reports soon enough and many situations became misaligned. It became hard to understand what was going on with different teams and we wanted to create transparency and visibility to be able to see this. We also wanted to establish a clear channel where you can ask for help and understand the balances of dependencies needed from one person to another.

Actions taken

This was not something that we did over night. We started by introducing different cadences of communication at varying levels of the product and engineering structure until it caught on.

Level 1 (Individual Teams)

• Introduced daily stand-ups, as well as, weekly demos and planning to establish clarity within the team.

Level 2 (Between Teams and Units)

• Created "Monday Demo's" where each team presents what they have done on a bi-weekly basis, switching between the different teams every week. We installed a projector for an informal presentation in which they can share insights in an exciting way. There is also a Q&A at the end to provide further clarification.

Level 3 (Between Engineering & Product Leaders)

• Established bi-weekly engineering and product staff meetings where you connect and talk about problems on both sides and the plans in place to fix them.

Level 4 (Department Wide)

• Ran monthly OKR reviews from all the units at the end of the month in order to present what they had done and where they are in terms of OKRs.

Additionally, the last month of the quarter became a Recap Day, likewise to the structure held for the conclusion of the entire quarter. It is more of a gathering where everyone comes together to discuss what has been done and celebrate the cap by having a little party after. Similarly, in the beginning of the quarter, we have a Launch Day where the teams and units present what they plan to do in the next quarter.

Lessons learned

• Communication is not just sitting and talking. You need to make it very operational. Otherwise, people will just skip it because they believe it's either not important or doesn't follow a strict enough agenda to be worthy of their time.
• Consistency is the key. You can't just say let's get together and expect everyone to follow. You need to have a google invite that makes it official and reminds key people to remain aware of this. I probably even need to get a person who is managing this and pushing people so they do not forget. Once you start running it this way however, people will get used to this process and prioritize it.
• One size fits all does not work with communication. We wanted to expand the information we compiled to the rest of the organization, but the way we present it doesn't work in the same way as it would for a sales team for example. There are too many details and it needs to be tied to a specific segment and the user profile you are targeting. In our case, it was internal and we wanted to know how we were doing against our own challenges. Teams outside our department do not care about all of this, they just want to know when the feature is going to be released. We tried to push it outside of our internal engineering and product focus groups and it did not work. In conclusion, you need to address one thing first, focusing on who you are serving, and fix that communication. Then you can move on and figure out the communication to the rest of the company.