Dev from team A explains problem to their mgr, mgr talks to team B’s mgr and the latter explain to their devs: recipe for miscommunication
— Nicolas Frankel 🇺🇦 (@nicolas_frankel) September 28, 2016
This post explains the reasons behind this tweet, sent on the spur of the moment.
Let’s face it, most developers - myself included, prefer to deal with code than with people. However, when communicating with other developers, we share a common context and understanding, which makes a lot of explanations unnecessary. It’s the same for all specialized jobs, such as lawyers or civil engineers.
Now, if I have to communicate with a developer (or other technical people) of another team, I’d approach him directly and have a chat. Sometimes, managers need to be involved for they have to be in the know and/or take decisions. In that case, I’d organize a meeting with this dev and both our managers, we would chat, come to a common understanding and then explain the meat of the stuff to managers and let them decide (and perhaps influence them a little…).
That would be crazy to spend a lot of time trying to explain to my non-technical manager the core matter, let him deal with the other manager without my presence, and finally let this other manager handle the issue with his team. Any child who has played Chinese whispers knows that multiple layers of intermediaries in passing a message result in a garbled mess. If a simple message that every layer can understand gets distorted, what would be the result when it becomes complex? And when not every player can understand it perfectly?
I’ve dealt with this kind of "process" early in my career - a lot. I assume it was for 2 reasons:
- Silo’ed structures
-
Because companies are generally organized in columns (Chief Financial Officer, Chief Marketing Officer, Chief Technology Officer, Chief Human Resource Officer, etc.) , communication is mainly vertical - from top to bottom (hardly reversed). As objectives are completely different, trusting another team is quite hard. So, this is a way to keep things in control… Or at least to pretend to do so.
- Middle manager
-
Cohorts of middle managers were required in factories, to handle assembly line workers and most traditional companies mirror that organization perfectly. In tech companies, the workforce is composed of educated developers: the need for middle managers is nowhere near as much. Hence, they must prove their "value" to the organization or be exposed as useless. Setting themselves as necessary intermediaries has become a survival strategy.
I was naively hoping that with all Agile projects around, this kind of behavior would have had disappeared. So imagine my surprise that it happened to me this week. After having explained to my manager the above part - about communication efficiency, I was gently (but firmly) told that it was not in his power to change that. I pushed back again pointing that if nobody does anything, things will never improve, but without results.
If you find yourself in this situation and have no way of improving the state of things, I’d suggest you vote with your feet. In my case, I’m near the end of my collaboration with this specific team, so my problem will resolve itself soon enough. I’m afraid the "process" is too deeply ingrained to change in the nearest future - if ever…