How to Achieve Cross-Departmental Alignment

Julius Uy

Chief Technology Officer at Zillearn



Some time ago, I was managed by a person who had experience in both engineering and product, but over the course of his stay within the company had dealt mostly with product. Some of our misunderstandings were the result of us coming from different departments. We would use different terminology, have different goals and priorities, but at the end of the day we were part of one same company and our main task was to bring value to the business.
Much of the misunderstandings between people is a consequence of the fact that the words that we use to convey our thoughts are - for the most part -- only a small subset of what we want to say. In general, people have good intentions and I try to decipher the meaning encapsulated behind what they have said. Other misunderstandings go beyond linguistic reasons -- people coming from different contexts (and departments) simply have different agendas and are trying to implement those.

Actions taken

My first and foremost reaction to any kind of misunderstanding and misalignment would be to ask questions and try to clarify intentions and context. People often believe that they share a context and would assume and take for granted much of what is being said. When it comes to cross-departmental misalignment I always seek clarification on how a particular project or task aligns with business goals and what is the context that I need to know and that I can explain to my engineers. Good listening skills should help you overcome much of the misunderstandings. Listening is, contrary to popular belief, a two-way street. People like to reciprocate and listen back; if you listened carefully to them and put an effort to understand their views on things, most likely they would do the same. Careful listening will not only iron out your misunderstandings but will create a relationship that will enable future collaboration since a rapport is already being built.

Misalignment often happens due to the fact that different departments use different terminology. When I was working with an advertisement team, I learned that they would use device ID to denote a particular device they were serving ads to. From the engineering side, device ID meant something completely different - a specific device whose ID didn’t change over time. The misunderstanding -- whether a device ID could be changed or not -- stemmed from our different contexts. To overcome this type of misunderstanding all you have to do is to ask for a definition or what a person means by this or that.

Other cross-departmental misalignments are a result of competing objectives between different departments. I remember when I was working in a video streaming company how we -- an engineering and product department -- disagreed whether to build first an in-app purchase fee functionality or to improve discoverability of our products. By improving discoverability we would help our customers find the shows they would want to watch, but as the engineering team, we thought that building in-app purchase should be a priority because we would earn zero money without it. Due to some contingencies on the product side, they decided that we should do a discoverability feature first and we were already halfway through with our in-app purchase. We shelved in-app purchase, our engineer moved to work on discoverability for the next two months, then again continued to work on in-app purchase but had to re-build the context. From our perspective, it would cost us less if we have continued to work on in-app purchase and then work on discoverability but from a product perspective, it was acceptable to lose money short-term because a TV platform was not creating value the same way as mobile apps.

In situations of conflicting cross-departmental objectives, I would always refer to first principles and annual business goals. If our annual goal would be to increase the funnel and have more people visit the platform and discover shows than discoverability should be a priority. However, the product side failed to showcase that argument and that has created a misalignment of goals. When they added the context that aligned with our principles, we were able to understand the logic behind their proposal.

Lessons learned

  • Misunderstandings happen when something is missing in communication. Whatever is missing -- and that is most often a shared context -- the first step forward is stepping back to first principles and working a way back to an actual disagreement.
  • Misalignment is sometimes a result of discordant personal values. Some people will prefer to push rather than share a context. To have sufficient data you have to keep asking questions and more importantly, listen to other people. Therefore, it is important to create an environment where information can flow and where communication channels are open and founded on respect and empathy.
  • Everyone in the company should understand its role and how it contributes to the company’s success and that everything else is subservient to it. Your attitude to work, your relationship with colleagues, your approach to problem-solving -- everything is subservient to it and first principles are pillars that safeguard that. If you work your way back to first principles you will be able to see what adds more value to the business.
  • There will be times when people would still disagree even when resorting to those principles or sharing all context. Then people should take the calculated risk to choose the best approach.

Be notified about next articles from Julius Uy

Julius Uy

Chief Technology Officer at Zillearn

CommunicationOrganizational StrategyDecision MakingCulture DevelopmentLeadership TrainingPerformance ReviewsFeedback TechniquesCareer GrowthCareer ProgressionSkill Development

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.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up