This is part of a new series: Globalization Motivation where I will continue to cheer on globalization, localization, and above all collaboration. I plan to break down and oversimplify in order to demystify the differences between functions in any organization to continue my quest to break down silos and bring teams together. 

All of the newer project management methodologies (Agile, Lean Six Sigma, Design Thinking) have one thing in common: they provide guidelines on how to collaborate effectively. Let’s begin by discussing the reasons why we need to collaborate in the first place. If you know me, I am always talking about breaking through silos. You can check out a webinar I did a few years back for The Content Wrangler where I discuss evil silos and the challenges they bring. Collaboration is something that is often mentioned but requires evangelization. For the purposes of this piece – Collaboration = Communication. 

The open office was supposed to inspire collaboration. Anyone who has ever worked in or visited an open office will see that most people have on headphones and have their in-depth conversations held behind closed doors; which are now on Zoom (or the equivalent). Hardly collaborative! These methodologies promote crucial conversations across organizations with empathy, schedule structure, and stakeholder management. 

Localization teams have transitioned into a more strategic role. It has become obvious that things break when you don’t consider language when you expand your product line, update software, and expand into new markets. The reality is that when most companies and products were created there was no crystal ball to see into the future. Take a look at WordPress, created for bloggers, not a CMS, and certainly not created to be available in various languages. Today, many companies rely on WordPress and the engineers who have inherited WordPress sites have had to work magic and find creative ways to allow for localization. Konstantin Dranch recently wrote a phenomenal piece where he breaks down that the CMS was not created for localization and shares proven work-arounds. I implore every localization team to forward this blog to your engineers. It will become an integral tool for them. This can be applied to almost anything else. When you started your organization, did you anticipate that you would have the product line you have today, a localization team, or being available in the countries you are now? Probably, not. 

Inherited technology is one reason why Waterfall has had to die. Another reason is the dependency on the tools that need to integrate within an ecosystem. Just think about the translation management tool that needs to connect to your CMS. Konstantin addresses this issue as well. Did we create our tools for integrations? Why do tools need to talk to one-another? Simply put, it’s efficient and the smartest way to work. 

I touched upon localization moving into a strategic role. Localization teams are not simply the owners of translation management. Although that is huge all by itself. It is not smart to create a product and not consider how language, geographic locale, and culture are impacted. The greatest challenge that I see with collaboration is communication. We all speak different languages. Who better to understand that each department speaks their own language and need support understanding one another? Being a non-irritative process, Waterfall, cannot anticipate the misunderstandings that occur between different roles that speak their own languages: engineering, marketing, product management, and localization. 

Nataly Kelly brilliantly referenced in her latest blog that language may not be the only solution when globalizing anything, however, the localization professionals are the subject matter experts needed to advise on what makes the most sense for the overall experience. That is of course the ideal, but what about when localization is brought in late in the supply chain? How often do localization teams inherit something where globalization was not anticipated? Waterfall, in this case, would be disastrous in today’s fast-paced world. Think about how fast you need to move into a new market and the dependency on analytics. We follow the data and the customer is in charge. You don’t have time to wait on features and silo the teams from one another. 

We certainly do not need to follow these methodologies to the letter. These are guidelines that help you to prioritize, empathize, and clearly communicate requirements. Moreover, I believe that the old “throwing it over the fence” and “assume” that you were understood is not a smart way to work. Let the engineers code and problem solve and let the designers design and you don’t need to understand how the soup is made but find a way to work together effectively while still allowing the subject matter experts to thrive.  You can find discussion on using a Waterfall-hybrid and since Agile has taken what still works from Waterfall, I really don’t think those arguments are worth it.

I’ve also spoken in the past about how there is no such thing as common sense. If we all speak different languages and serve different functions, then we can’t possibly share the same thought processes. You simply cannot rely on assuming that an engineer can visualize exactly what was requested and that the user or customer won’t request something different once they start using the product. 

Why do we need a methodology to promote smart conversations? Most of us are adults. However, we can no longer rely on assumptions and have learned that most companies are needing to be educated on inclusivity and discrimination. We may think we are showing respect to our peers and we may even believe that we know the role that every person in an organization is responsible for. After reading The Culture Map by Erin Meyer, I will never make those assumptions again. Her book maps out how different cultures communicate and how they are often misunderstood.  The advice she gives could be applied to the different cultures within an organization (creative, client facing, strategic, tactical). 

It’s easy to get siloed in the pandemic. We no longer have body language to aid in communication. This only adds to the further demise of waterfall. Communication requires context and empathy and assumptions are just bad for business. Project management methodologies are actually communication facilitators. They help you communicate across the various cultures of your organization. RIP Waterfall.