When a Lack of Clarity Impacts Performance

Problem

In recent months -- when all the work transitioned to remote -- I too often encountered the lack of shared understanding of the team’s goals. Unfortunately, I firsthand experienced how a lack of clarity can lead to a team’s dysfunctionality.

In this particular situation that troubled my team, not only that Engineering lacked clarity, but I had to spend much more time in meetings with Product, Design, and QA to help them understand engineering effort and goals. I realized that if Engineering looked like a black box to people outside of Engineering, that left room for guessing and uncertainties. If other stakeholders couldn’t understand how we were building things and what our timeline was, we would risk vagueness, inaccurate updates, and overall confusion.

Actions taken

Whenever I would be put on a new team, I would do a “How we roll'' meeting, a 90 minutes long meeting on how we should roll as a team. During that meeting, we wouldn’t only discuss engineering processes such as how we do branching, how we deploy code, etc. But we would talk about other things as well -- how we would share our work with QA, how we would let Product know of the changes and how to test them on a master branch, how we communicate with Design to make their design technically feasible and aligned with what we were building.

Next, I have one-on-ones every week with stakeholders on a team level -- with Product, Design, and QA. Even if there is nothing to talk about in terms of action items, I would still do those meetings because I would use them as an opportunity to share what we were working on and what would be coming from the engineering side. That update would help other stakeholders prepare their own work and sync their timelines. Our frequent exchange helped collaboration and alignment across different departments that were often chasing different goals.

We also do monthly retrospectives to make sure that we are learning and progressing by evaluating our past work. By revising our processes and practices, we are refining as we go. We blamelessly dissect our past actions to learn what we did well, what we could improve, or what we need to reconsider doing. That helps us come stronger after each retrospective and learn where to put our effort into.

Lessons learned

• While some people were complaining that we have too many meetings, most of the meetings were critical, especially in a remote setting. Weekly sync-ups and one-on-ones with internal stakeholders especially contributed to alignment and clarity and helped us save resources that would be otherwise scattered and misaligned. As long as a meeting improves clarity and encourages shared understanding, spending time in meetings is valuable.
• It is important to have a custom working relationship between Engineering and other departments. The relationship between Engineering and Product works in one way and is different from the relationship between Engineering and Design. I assumed that Engineering would be more inclined to collaborate with QA in the same way Product will be with Design, but I was mistaken. We created a circle where cross-department collaboration between all stakeholders intersected, which significantly improved clarity. Each relationship needs to be handled separately in terms of needs and jointly in terms of collaboration.