Posts Tagged ‘communication’
  • It depends

    Light bulb

    In the industry, there’s this widespread joke. Whatever the question you ask a consultant, the answer will be:

    It depends.

    This joke is meant to highlight that consultants never give a straight answer to a simple question, because they don’t want to take any responsibility. While I understand the frustration of the business when faced with this situation, I’d like to write about the other side of the fence.

    Let’s enlarge the scope: in the IT industry, it’s probably more about every developer rather than only consultants. But why is this answer so common? For one single reason: if the question - deemed simple by the person asking, doesn’t provide enough context - and they rarely do, then the answer cannot be any other.

    Let’s highlight that with a simple question:

    What’s the best transportation?

    Guess what? There’s no right answer to that, because no context has been provided. For example, context parameters that could help refine the answer include:

    • the distance, do you expect to move 200 meters or 200 kilometers?
    • the nature of the terrain, road vs. land vs. water
    • the time constraint
    • the expected comfort level
    • the cost
    • the physical condition - it’s hard to consider running/biking when in bad shape
    • for some, the pollution
    • etc.

    I hope this pretty down-to-earth example makes those who ask questions realize that the quality of the answer is heavily constrained by the quality of the question - garbage in, garbage out.

    I could stop there and everyone would ponder how stupid the business is, but every coin has 2 sides. In general, developers don’t react in a constructive way to context-less questions: "It depends", "I don’t know", "I have no clue", "Nobody can answer that", or even "That’s a stupid question" are comments I’ve heard already. If you’re a developer and reading this post, know it’s your job to guide the business. What do they know about scalability, databases, and so on? Probably nothing because it’s not their job. So, pro-actively guide them through questions. With the example above, the following could be an actual dialog:

    "What’s the best transportation?
    - Where do you want to go?
    - Munich
    - Ok, what’s your starting point?
    - Home
    - Ah…​ Where’s you home located?
    - Germany
    - Which city in Germany?
    - etc."

    I’m very aware that most developers - including myself, don’t like to talk to the business so much. I mean, that’s the reason most of us chose to work in IT, because we are more comfortable talking to computers than people. But in essence, it changes nothing.

    Be professional, ask for context instead of ditching the question.

    Categories: Miscellaneous Tags: communication
  • Making sure inter-teams communication doesn't work

    The 3 monkeys

    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…​

    Categories: Development Tags: communicationgood practice