4) Use only one language

It is absolutely maddening when one faction of the group splits off and starts discussing in another language. Sometimes it is just a comfort thing, other times it’s actively done so some in the room won’t understand what’s said. It’s borderline unprofessional, in my opinion, to not keep everyone in the room in the loop. Best rule of thumb is to stick to the most common language in the group while in the workplace, this is usually English at my company.

5) Only use data-driven status reports:

It’s not “done” or “almost done” until reports and results are clean.

“What’s the progress on <fill in the blank>?” ”Oh, it’s done. Just waiting for the final report.” Nope, not done. Not even close actually. It’s not done if something is still running. It’s not done if something is finished but the results aren’t clean (can mean a lot of different things, depending on industry). And, most certainly, it’s not done if engineers are still actively working on it. I’ve been around cultures where everyone in the organization is claiming their portion is “done”. It’s toxic. Here are just some of the effects of not using real, quantifiable data when reporting status:

Unpredictable schedules. You can never accurately predict when all the T’s are crossed and I’s are dotted. In other words, when the work is actually “done”.

Managers will undoubtedly mis-evaluate their engineers. How in the hell can a manager be expected to evaluate his talent when half the people are telling him “it’s done”, and the other half are giving him detailed, data analysis reports? It’s up to the manager to clearly dictate how work status is to be reported, and it should always be strictly data-driven.

Breeds bad temperament between your engineers. The engineers that do things right will constantly be annoyed by the ones that vaguely report unclear status. The ones being vague are trying to make their work look better by not giving clear detail. The engineers doing things right can at times look worse when the manager’s expectations are unclear.

6) Unite team culture to a single working style

This one is up to the engineering managers. It’s imperative to have a working style that the organization or team below you willfully adopts. I’ve been in teams where the culture is split, and in teams where the culture is united. There is no comparison, the united teams work more efficiently.

When it comes to solving big-time problems that can take months, it’s very important that everyone has similar working styles. And I don’t just mean what hours people work or what language they speak. I’m talking about intricate engineering skills: Is it preferred to write code to solve, or fix things by hand? Is it preferred to report status with one-line summaries, or multi-paragraph rambles? Is it preferred to stick to a strict design flow, or do everything ad-hoc?

First and foremost, from a communication perspective, the manager has to set these ground rules in place and get everyone on the same page. Otherwise, the communication will desolve and no one will be on the same page. I may devote an entire blog to this topic in the future.