Why We Made Product and Projects Dev Teams Attend the Same meetings

Keeping product and bespoke development teams separated seemed a good idea until it was not anymore

In our company, there are several engineering teams, divided into two main groups: Product Team and Professional Services. The Professional Services team provides designs and develops bespoke solutions, most of the times this means designing, developing, and maintaining the frontend development of solutions based on our main SAAS product, including time-limited projects, demo sites, and so on.

The Product teams know that their code will “last forever”, it is going to be used by all customers, it must prevent any regression and its design must stand the test of time because every time you change something you might cause issues to your customers. The Professional Services teams, however, have different challenges, often the projects last for a limited amount of time and they usually are dedicated to a single customer, this makes optimizations for the specific use case not just possible, but desirable. This difference between those two approaches was what drove the decision to split those teams into two different groups, but they also often tackle similar challenges and, being independent, can hinder both teams because of a lack of shared knowledge.

This, over time, turned out to be a problem because it became more and more frequent the need to replicate product components to be used in projects and the other way around. Those cases were managed by having each team write their own components, lowering efficiency and driving higher development costs. We quickly understood we had to improve the communication between the two teams to prevent each one from re-inventing the wheel from time to time.
Each team had made its own components such as “search” and “login” which are standalone functions often required in projects, so we stopped to collect information about how much time each team spends creating and maintaining them. The components were not exactly identical but we believed that with some combined effort we could increase efficiency by sharing ownership of a single set of components.

Issues caused by having two independent teams

We identified several issues that we wanted to address:

Insufficient communication between teams — this was especially true regarding communication about how to solve problems. The lack of internal knowledge about who did what and how, caused two different issues: the first one is that it took more time and effort to reach the correct person that was able to answer our questions, the second one is that not sharing how issues have been solved by others led to a wide variety of ways to solve similar (or same) problems, making code less maintainable. As an example, the P.S. team sometimes didn’t immediately know that new versions of libraries had been released including new features that could accelerate development. Also, when operating on tight deadlines, the delay in getting answers was critical, and not knowing who was the best recipient for your questions led to a waste of precious time.

Mismatch in the technology stack and project management — having a different frontend technology stack between the teams makes components made by each team unusable by the others, this is often caused by the usage of different libraries (ex: JQuery/VUE). Lack of consistency in tech stack did cause increased development time because teams had to replicate standard components instead of being able to just use what other teams created.
As I mentioned before, because of the infrequent communication between the teams, we didn’t even realize we were duplicating the code or functionalities of existing components.

Inconsistent code standards or project structure— The P.S. team did not have well-defined standards and this causes increased difficulty in understanding the code written by other people and higher maintenance costs. One example of this is the “utility” functions that were sometimes separated in a specific js file, while other times code was inside a <script> tag; there was no consistent way to structure functions and files. Same for code indentation, consistent usage of spaces vs tabs making the code less readable for everyone. Those things might seem small issues to the person writing the code but they become big deals as the team grows and the code gets older.

Poor code review— having people from the same team to perform code reviews will not bring a fresh “point of view” to the team code and increases the risk of errors and limit the growth of the developers.
In fact, it is easier among people who work closely together to have a similar way of working, so you risk not identifying and ensuring an efficient and consistent design and implementation, damaging the maintainability and longevity of the software.

What has changed since we improved the communication between the two teams

Faced with these problems, we asked ourselves how we could improve this situation and set-up simple solutions that led to important improvements.

Shared chats: To mitigate poor communication problems, we created a common chat to exchange opinions/articles that might be interesting and we would also use the same chat to ask for code reviews. This helped also sharing information about what people were working on and the problems found or solved.

Include P.S. teams in Product guild meetings: we have competence-specific meetings (see: Guilds and teams for better engineering ) where people involved in the same tech stack (eg. frontend, backend, DevOps) share knowledge and discuss how to improve their tooling or processes. This helped to address the scenarios in which people did not know who to ask questions: the guild meeting is one channel to “broadcast” the trickiest questions and quickly broadcast the best course of action.
Another positive aspect is brainstorming during the guild meeting about the new technologies and techniques encountered while code reviewing other colleagues’ work, to cooperate and improve our skills.

Adopt the same technology stack: P.S. teams started using Vue for all FE projects in order to sync with the Product teams tech stack. By using the same libraries we were able to start re-using components and reduce development time for the various projects.
We are now able to use product components for the various bespoke development projects saving a huge amount of time. This also helps us collecting more use scenarios that we feedback to the Product teams so that they consider them for future developments.

Adopt shared guidelines: The Professional Services team started following the same guidelines as the Product teams, making it easier to understand the code and reducing writing errors. The experience gathered in product development which had to pay more attention to code quality and testing brought improvements in the way the P.S teams were writing code and organizing projects.

Share projects and code: we now share projects to allow people from different teams to review the code. As an example, at my first merge request, I was advised to not include a library via URL because such URL might change in the future, or the library might change by preserving the same URL and this could introduce bugs on the project. I was advised to include the library by using NPM (we wrote an article about this).

What went well

• Increased productivity due to shared tech stack and components.
• Improved growth of new personnel thanks to broader shared knowledge and bigger guild.
• Increased code quality and tooling thanks to common coding standards.

What went not as smooth as we wanted

To change the tech stack, we had to convert ongoing developments to the new libraries and coding standard, and this was really hard to do while working on tight deadlines but it was the only way to move forward.
During the first weeks, when reusing code from the Product teams we needed more support than expected from the Product teams, especially when using code that was not released to customers and which didn’t have full documentation at the time.
P.S. teams also had to take a VUE course to jump-start its usage, further increasing the required development times in the early stages.
Also, what might seem a downside is that when we want to change guidelines or elements in the tech stack we now have more dependencies to manage and this takes more time and communication to happen in a safe way. This situation may arise when some team wants to change the way libraries are managed, new product components are released or new elements are added in the guidelines.

Conclusions

We are very satisfied with the improvements we made, it was especially exciting to learn and adopt new libraries for our projects. Sharing the same guild meetings also improved the meeting itself, because there are more perspectives being shared and this helps everyone in their path towards excellence.
Both development groups are committed to maintaining the shared processes and guidelines to ensuring there is enough communication but this is an increased effort and time will tell if this additional workload will be sustainable for both groups.