When techs try to communicate with management

Let’s face it, companies need techs.  There’s no way they can run their business today without them.  But unless your company is in the business of writing software or developing computer hardware, most business owners and managers do not understand techs.  Techs speak a different language. In fact, we seem to live in a different culture.  I learned this many years ago on one of my first programming projects.

In a recent post I introduced a scenario in which I was engaged to write a custom database program for a tropical fish wholesaler.  As soon as I got back into the office after the initial meeting I tore into the project, anxious to build a prototype for the boss to show the prospect as soon as possible.  Wow!  They were sure impressed and gave the green light to get started on the programming project.

Now it was time to build the database and the screens that the customer would use to interact with the data.  All went well for a few days.  Then it was time to provide a progress report to the customer.  Another meeting was scheduled and the basic functionality of the initial design was demonstrated.  Again, everyone was happy.

What neither the customer nor the boss knew was that these screens were just mock-ups.  The real work was yet to be done.  In my mind I knew that it would take many long weeks of programming and testing.  The only problem was that I never communicated that to the boss.  They expected results in a few short days.  They based their expectations on the short time it took to do the previous mock-up.

Day after day over the next several weeks, I would sit in my office and work hard to bring to reality the vision I had when the customer had asked if the function could be done.  I knew how it was supposed to look.  It was just time-consuming to get each piece to work just right.  I could tell the boss was getting frustrated.

Bosses just don’t think like techs 

Finally, one day the boss called me into his office and asked when the project would be completed.  I began to talk about the problems I was experiencing and the progress I was making.  His eyes glazed over and then began to burn with an intense stare.  “That’s not what I asked,” he snapped.  “When will it be done?”

Again I tried to describe the processes I was going through and what I expected would be next on the list after I completed this task and then that task.  His eyes got larger and larger.  He finally snapped.  “What are you saying?  I thought this would only take a few days!  Why is such a simple project taking so long?”

I finally realized that we weren’t communicating and probably never had been.  I had assumed that he was thinking like me and looking at it from a programmer’s point of view.  I thought he would be interested in the intricacies and the details of all that was involved to get the program to work the way the customer wanted.  Frankly, he could care less about the technical details.  He only wanted results.

I wanted and needed someone with whom I could discuss the technical issues and he had no clue what I was talking about.  He only wanted to know when it would be completed and did not understand why it was taking so long.  How could I tell him how long it would take when I wasn’t even sure why the parts I had already completed weren’t working exactly like I had hoped?  We had a serious communication problem.

Update: Part three of this story can be found here: Project management responsibility can be elusive.

Has this ever been a problem in your organization?  What is the solution to eliminate such miscommunication?