Monday, May 22, 2006

 

Tomato

Tomaytoe, Tomahtoe -- the same thing, referred to differently. Usually this is one of the major problems a non-tech person will encounter when talking with a tech person. Although techinical people are very precise (or very particular) with the words used to refer to things (server application as opposed to server hardware), there's a certain degree of assumed context whenever two technical people talk to each other:

Developer 1: "I built the version, and it ran without bugs. However, when you did it, the bugs came out!"
Developer 2: "Yeah, but I seem to have used a different version of the library from what you used, so I'll just get 2.0 then build-run-test it."

That's usually how developer talk happens within a team. The problem is, there's something missing: context. But they seemed to understand each other! Non-technical people hearing this will most probably say "WTF?!"

Now let's see another conversation between a business person and a developer (which happens all too often):

Business Person: "I just committed a delivery date on the 10th, we need it out by then..."
Developer: "It's not going to happen."
Business Person: "What do you mean, it's not going to happen?!"
Developer: "It's not going to happen."
Business Person: "What do you mean it's not going to happen?!"
Developer: "It's not going to happen."
Business Person: "It's not going to happen on the 10th?"
Developer: "It's not going to happen."
Business Person: "When will it happen?"
Developer: "It's not going to happen."

You can just imagine what will happen to this conversation... Absolutely nothing. The business person is looking for an explanation, and the developer isn't interested in giving one. Who's at fault here? Look at the first statement: I just committed a delivery date on the 10th, we need it out by then...

Does it look the least bit familiar? It's the PHB syndrome... If you don't know what PHB means, maybe you should start reading this too.

At any rate, the business people (especially management people) tend to keep their eye on the sale, and not on the product. While the developers on the other hand, tend to look at the product more than the sale. Here's a way of rephrasing the first statement:

Do you think we can get this out by the 10th?


This way of approaching developers will convey 2 important messages: 1) I'm asking for your opinion 2) I think I might be willing to listen. The last thing you want is a developer that doesn't listen, and will sabotage your project. We all don't want that.

Rephrasing your statements can go a long way especially if you want to make sure that some things happen as you expect them, while keeping everyone happy. Try it, then make sure you say it with sincerity. You might get a different answer from the developer.

Do you have communication stories? Let them be known by emailing me your comments and stories through dean [at] orangeandbronze [dot] com -- they might just well be listed here.

Communication is a process of conveying information while dodging the challenges brought about by media, experience, environment, and preference. Effective Communication happens only if the process is effective and the message clear.

Comments:
hi Dean!!

nice [new] blog!!

anyway, i recently had a problem with communication... for better experience [lest i drone on and on], better read from my blog na lang...

all the best!!

8)
 
Thanks for dropping by sir Chris! :)
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?