Monday, May 22, 2006



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.

Friday, May 12, 2006



How do you usually hold conversations with a technical person? Do you follow a plan? Or do you hold it like a normal one? If you're in the technology industry, communication is an important aspect of the operations. If you can communicate better with your peers/colleagues, you basically have 50% of your work done. However, not everyone has the best communication skills in the work place.

The perennial question in IT companies is how do you bridge the divide between the sales group and the tech group. What type of communication breakdowns usually occur? Are there any verbal or written cues that you should look out for? Is there more to it than meets the eye (or ears)?

In the next few posts, I shall discuss the many different issues interpersonal communication issues and problems in the technology industry especially in the small group sense. In the later parts, I shall outline the many pitfalls that non-technical people encounter when talking to technical people.

What you say and mean is not what I necessarily hear and understand.

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