Thanks to Dilbert, developers, engineers and the rest of us managed people, have come to disrespect the “manager”. Ok, it’s not just the comic, some of it was perpetuated by actual managers. Still, there are cases where the managers do the right thing, and the developer messes up.

Whenever this occurs, regardless if from the manager or developer side, we’re making the divide between the business and development wider. Sometimes both mean well. But it just happens that the parties don’t talk the same language and then you get what’s in the picture on the right.

Here’s an example. When a manager asks the team to increase their velocity, we’re on a crash course. The real original definition of “velocity” is past observations of the team’s performance from which we can estimate their future performance. So in fact that the perfectly sane question the manager asked, sounds to the developers like this:

Can you build a time machine?

Notice that divide getting bigger?

What happened is what marketing does some time: take a word that sounds familiar, but means something other completely, move it out of context and appear to sound more intelligent now that we own it.

Only we don’t and we wind up sounding stupid.

Another example. When the developer says to manager that the tests keeps slowing him down, and he’ll be more productive without them, we’re on that crash course again. Because what the manager hears is:

Testing is an accepted best practice. But that’s for normal people, I’m better.

And the divide gets bigger still.

In order to bridge the gap, we (whatever we are – developers or business people) need to learn the language of the other side – the terms, the tone and the nuances. Only after we did, we can actually find how we sound like to the other side. And then we’ll probably hold our tongues a little more often.

Want to hear more? Come hear me tomorrow at the Agile Practitioners conference. There’s plenty more where this came from.