Back to resources

Bridging the Gap Between Engineering and Product Teams

Alignment
Collaboration

15 September, 2021

Gaurav Sharma
Gaurav Sharma

Engineering Manager at GlobalLogic

Gaurav Sharma, Engineering Manager at GlobalLogic, shares how he enabled cross-team collaboration and delivered valuable end-to-end functionality.

Problem

"Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results."

一 Andrew Carnegie

One of the biggest challenges I encountered was dealing with ambiguities in software development. What happens is that most of the time there are no clear expectations, and as a leader, we succumb to making some decisions and giving directions. How can we do that if there is not enough visibility for me as the manager? Getting a shared understanding might be an answer, but here’s what happened in my case.

Working with the product teams, specifically the ICs and the developers, we jotted down all their requirements. Most of the time, what the product teams talked about was pretty high-level. For example, they might simply mention that they need a car. Whether it was an SUV or a sedan, it was not clear. So, let’s say that the developer likes an SUV to opt for one. Therefore, it is about the gap between the two different teams, and as a manager, I needed to bridge that gap.

Actions taken

Starting with the basics, I knew that I had to set some fundamental agile principles. The project is one of the most recent ones that enabled me to put some outlines. We prepared the “Definition of Ready,” which is the set of agreements that tells anyone when something is ready to start. As an engineering team, I believed that it should be respected if something needs to come to us. There is a required focus on Definition on Done, but DORs are usually ignored. This has been a classic software engineering problem since the beginning.

We conducted a small workshop with both teams. This was pretty interesting because we asked people from each group to explain their part without fully communicating with them. This was how both the parties realized that they were right in their ideas and areas of expertise. Working with people from different backgrounds 一 for example, the product team in our case 一 helped us build trust and understanding.

While the product team was blank on the coding side, the engineering team did not understand the product life cycle and customer needs. Adding a few agile experts to our workshops helped the product team get an understanding of the engineering side. Introducing lightweight, agile practices to the product side through the seminar was such a success. We asked a group of product managers to design an employee onboarding workflow for an HR app with some minimal requirements. As expected, everyone designed a different version as things were not defined at minute level. This gave some perspective and enabled cross-team collaboration within the organization.

When the teams started capturing each other’s tasks, we added a few more calls. Previously, the teams would have met merely once or twice a month to visualize all their work. On top of that, there were no demos, which added to the complexity. My suggestion was to meet weekly or bi-weekly and show what we had built in order to get some feedback. Of course, we would incorporate the feedback during the next meeting.

The process helped us clarify and did not leave room for any misunderstandings. Gradually, the friction between the teams started to disappear as the two groups of people collaborated and understood each others’ personalities. In my perspective, the first 3 months were quite challenging to bring them to work together, but once everything started falling into place, there was an alignment.

The whole procedure was a game-changer. Earlier, the engineering team would only think about two things:

  • What to build?
  • How to make it?

They would often forget about the “why” part. As soon as they started paying attention to that aspect, many creative ideas popped into the team. As soon as more innovation came in, people were not just following orders anymore but thought about their actions.

Lessons learned

  • Only because you are right does not mean that the other person is wrong. You have to start seeing things from their perspective. Working in a professional environment requires people to spend some extra effort and understand the reason and “Why’s” behind a need.
  • Trust takes time to build. If you join a new team, chances are your new peers or managers are not likely to take your ideas or suggestions right away. It would be best to let that sink in for a while, and then you can start recommending processes and bringing about changes.

Discover Plato

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


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

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

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

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.

How Less Viable Solutions Solve Common Architectural Challenges

13 May

Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.

Architecture
Different Skillsets
Conflict Solving
Collaboration
Tom Hill

Tom Hill

Engineering Manager at Torii

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.