Common Purposes, Different Languages

I’m writing from Europe, where I am part of a project team that speaks four different languages. The team has a singular interpreter who speaks all the languages. My team speaks English, and the other three teams speak Slovak, Hungarian, and Czech. Our poor interpreter is the sole medium through whom all the teams can collaborate.

This got me thinking about language barrier issues on a smaller scale, and closer to home. Specifically, most companies have three distinct languages being used internally: marketing speak, tech speak, and design speak. Each of these languages is vital to their respective teams, and each of these teams work together on the same projects. But often a lot is lost in translation when these teams try to talk to each other. Worse, the factions are sometimes afraid to talk to each other, which leads to even more disaster.

It’s vital to find a good interpreter. In many cases, this is the project manager. All too often, however, project managers each come out of the business or tech side of the company and are as intimidated by the other sides as the team members themselves are. I remember back when I was an employee (before I owned my own company) and our project manager would come back and say things like “IT said this feature would take four months to build.” I would ask her “did you ask why?” The reply would be either a simple “no,” or an “I didn’t understand the answer.” Having one foot in the tech side and one in the marketing/business side, it is easier for me to push back on the tech team, because I know what building a certain feature will entail. I can’t even tell you the look on the faces of the tech folks at Barnes&Noble.com when I asked them to see the database schema they were designing for one of my features. I was on the business side, but I wanted to make sure that it was going to be efficient and scalable for our future needs. It wasn’t micromanaging per se, but I didn’t want to get into a situation six months later where the new features we were planning were impossible to implement given how the database had been designed.

This actually happened to me in my first job out of college. I was a software architect, and marketing asked us to build in certain reports to the software we were designing. This was no problem. But, right before launch (about four months later), when we were in our final beta test, he asked for another reporting feature. It seemed simple enough to him, but it would have required a major rewrite to our code to be able to generate the data needed for this report.

Whose fault was that? In that case, I will place the blame on the marketing folks for not thinking about the business case enough in time to give us detailed specs. Further, had they told us why certain reports would be included instead of just telling us what they needed, we probably would have pointed out this final report as one that we should build as well while we are building in reporting. In other words, had marketing involved tech in the business side of things, we would have had a better sense of how the tech would evolve over time, and we could have helped a lot more.

While it’s easy to always blame tech for things because their language is the most foreign to people, the business side’s unwillingness to think of tech as a business partner is equally to blame for these situations.

The lessons here are simple. The project manager must not only speak all the languages, she can’t be intimidated by any of them. The business side should work more closely with tech instead of simply handing off requirement documents. Tech needs to get more invested in thinking about the features they create in a larger business context, and work more to explain their world to everyone else instead of purposefully retreating in the “black box of mystery” they like to cloister themselves in.

Are you in this situation? Write about it below!

Until next time…

Jack