Software Development

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?

21 comments
BALTHOR
BALTHOR

This is how you protect your invention---

No User
No User

OK, you get your hand slapped for not communicating do you feel better now? I really don't see your part as being much of an issue if at all. Your ex boss was obviously in a position of incompetence and had no business being there. He knew nothing about the technical aspects and more importantly couldn't understand the technical aspects, you said his eyes rolled when you tried to explain them to him and he certainly had no business making a quote for when a product would be delivered when he had no clue about the process at all and more importantly didn?t ask you the very person who was to create the product how long you thought it would take for you to make it. He did have several meetings with you about the delay and instead of him asking how long you thought it would take to over come each obstacle you encountered and perhaps asking how he could help you over come them as well, he simply asked when the product would be delivered. Your ex boss just hurled a proposal to a customer with out having a clue of the process nor asking you how long you guesstimate it would take. The failure to communicate is clearly with your ex boss. Your ex boss was clearly a blooter and I don't see a tech to management communication problem at all or perhaps I should say I do see the stereo typical tech to management communication problem. Although your situation unfortunately is typical it is neither a fault of poor communication on your part nor IT folks in general. It serves as an excellent example of how conditioned IT folks have become to taking responsibility for the failures and specifically the communication failures of others and specifically those of management. It?s scary to see someone who was obviously so inept being in a position of power. Since he was fired that situation was finally corrected but not until after several incidents in addition to yours. Just think how many customers and in turn their customers were hurt and the overall damage to your company. That points to yet another problem who hired and or promoted that guy? My guess it was upper management and they put someone with neither a clue of the technical aspects nor the ability to acquire them nor of entire process of creating and delivering the very products he was in charge of which of course were technical by nature.

tmalonemcse
tmalonemcse

...that was trying to break into the micro based world. This was back in 1981-1982. It was called Delphi Systems and was based out of North Hollywood, CA. It was my first job as a programmer on micros as opposed to the big iron I used to work on in Cobol & RPG. Their top products were "Criterion" and "Oracle", both of which ran on DEC PDP-11 time-sharing systems and Honeywell DTSS. Don't confuse Delphi?s financial product with Oracle Corporation?s database system. Delphi had the corner on software for oil and gas exploration companies and had a big, big chunk of the market for insurance agencies. They moved to Westlake Village and were then acquired by Ebix, which promptly closed the office. I lost track of them after that. I added more detail in this response to another comment, which explains a lot: http://techrepublic.com.com/5208-13621-0.html?forumID=102&threadID=256869&messageID=2446704 But I wanted to comment on your excellent analysis of the situation. I see it a lot different now than I did 25 years ago when it happened. But your take on it puts it in a whole different light altogether. Thanks. I especially liked your point, "It serves as an excellent example of how conditioned IT folks have become to taking responsibility for the failures and specifically the communication failures of others and specifically those of management." I see this same communication problem even today in dealing with my current boss. I have to bend over backwards and make special efforts to communicate in terms that he will understand - few or no acronyms, short and simple phrases and summarized sentences. Why is that? The guy is smart. He runs a multi-million dollar business. Why do I have to make such an effort to explain technology? Are heads of businesses today still so technophobic that they just can't or won't take the time to learn a few basics about how computers and networks work? Anyway, thanks for helping me see things differently. Communication is obviously a two-way street. Information technology seems to mean figuring out what people are asking for with the most limited information possible being offered. We have had to become experts in translating requests.

Neon Samurai
Neon Samurai

In my situation, the pressure was eleviated somewhat when a more technical manager was put between us key monkeys and the MBAs. My manager still wans the "when will it be done" answer but at least there is room to discuss issues as they arrise. Previous too that, my best example is giving a brief point form list of issues we where having with a project. This was not to provide an excuse for not having it done but rather the manager with background information for when they had to explain to the next bigger fish up the chain. Anyone can guess how that turned out; "I don't want excuses. It's late, when will it be done?" Managing Expectations is the MBA buzzword that discribes the rift between a technical mind and a management mind.

Tony Hopkinson
Tony Hopkinson

You estimate the job will take thirty days. They cry nd whine about it shouldn't take that long. Some one chops your contingency out to make the job more appealing, goes back get's grudging agreement. Signs off, does paper work. It's now twenty days later, you have 12 days to do the job in, three others on going (also 'late') and the due date was calculated from when you did your original estimate. Who doesn't have this tee-shirt, I have several spares.

tim
tim

Makes me so glad my career direction shifted away from programming and into tech support. At one time I envisioned myself as becoming a wise and grizzled old coder, managing a staff of coders, handing out advice on how to get that particular task done quicker. I didn't last more than a few years as a programmer. I soon realized that it was a thankless job when a major project I worked on with a small team (different company) was rejected in the end because of corporate politics at the customer site. We were proud of our work and wanted bragging rights but the system was never put into place. The whole thing was written in early MS Basic running on a bunch of Kaypro portable computers that nobody remembers or cares about now. In this case, I think it was the hardware platform that caused the project to be rejected in the end. Oh, we got paid but there was no more work after that. Time to move on. Programming seemed like an unstable world to me back then. Thanks for the comments. Be aggressive in those progress reports is my only advice - even if you have to stay late to write them. At least they can't accuse you of not communicating, which was the major problem in my story and the subject of the post.

Michael Kassner
Michael Kassner

I think most of the members understand what you are going through. I really do not have any kind of golden rule as to how I handle these situations. I just realize that you are referring to your boss and that kind of says it all, i.e., signs pay check. In my old age, I have learned more patience is better and CYA tactics are always the rule.

tim
tim

Too bad they don't teach a course in CYA. This story took place more years ago than I care to admit. I took a class in Systems Analysis in school but it was written with a large company in mind. The emphasis was on team communicatoin with project review meetings and milestones and design specs. None of that fit this situation. Being the solo tech on a major project like this was nothing like what I envisioned when I was in school. You are not just expected to do the coding, you also have to manage the project. There's a big difference. Patience is what you get when you've been there. I have lots of patience now too.

Locrian_Lyric
Locrian_Lyric like.author.displayName 1 Like

If not in schools, we old hands who have learned the hard way should teach it to the energetic kids. I've seem too many energetic youths get crushed by the corporate machine for lack of CYA skills. As geeks, we tend to believe that our work speaks for itself. This is not the case, we have to speak FOR it.

tmalonemcse
tmalonemcse

We "seasoned vets" of the IT world who have been burned or had our knuckles rapped know when a project is worth the personal energy investment. It becomes clear after awhile which issues are worth fighting for and which ones can slide. For example, I have become much more tolerant of stupid user requests. In my younger days I would have launched into an all-consuming effort to "educate" my co-workers. I wanted them to know just how much work and effort their "simple" request really requires. Today, I search for ways to respond simply and directly. Yes, that can be done and it will be done by such and such a time. Or no, that can't be done with current resources. Oh, you really want it - how much are you willing to invest? I am sometimes amazed to see the things that new techs can accomplish because they don't know any better and are not yet jaded. I love to give assignments that I don't want to the new guys and see them go to town to get it done. Youth has it's advantages. Energetic youth need an old grizzled manager to keep them from getting burned. Sometimes they listen and sometimes they don't. How could they know that you don't mess with that user's desktop settings unless you warn them? CYA skills are usually acquired by mentoring.

Michael Kassner
Michael Kassner

The ultimate good is that you understand. I know countless people that are still fighting and losing. Having a triple bypass 4 months ago also garners a slightly different outlook on life as well. My humble advise is to figure it out before that happens and not after like I did. It seems like you have and that is a very good thing.

dawgit
dawgit

#1. ?companies need techs.? Don't count on it. Unless the company is actively producing IT services, IT is Overhead, and expendable. There is always another way. Understanding each other is irrelevant. #2. ?... these screens were just mock-ups.? and ?The real work was yet to be done.? People really only care about (and want to pay for...) Real Work. It's how the Business World runs. (Outside of Governments) Mock-ups and Models are good guides for the builders / architects, but nobody buys the Models, they want the building. Hense: ?He only wanted results.?. #3. ?I finally realized that we weren?t communicating and probably never had been.? No, there was communications, just the wrong messages were being communicated. The overall concept could have been presented, but only in conjunction with an approximate ?Time Line? of the project goals. #4. ?Why is such a simple project taking so long?? All projects are Big projects. (They pay the bills) Of course, all problems do turn into the ?small stuff?. But the projects themselves, are the Big Stuff, at least to the customer. If it was simple, you wouldn't be needed, they would do it themselves. #5. ?What is the solution to eliminate such miscommunication?? Don't make Assumptions. Start with the idea that the customer don't / won't know the concepts involved. Again, if they did, you wouldn't be needed. I've learned to be primarily up front with all the possible difficulties and problems in a project. This solves several problems before most even happen. *It confirms to the customer that his problem is a real problem. (and justifying that you and your solution be involved.) *It gives an opportunity for examining that goals are realistic are relevent. (keeps a project a solution, and not being another problem.) *Total times, difficulties, and actual work involved are known by all up front. (when it turns out easier and quicker than explained or anticipated it's a bonus.) IMHO, of course. Arguments always welcome. -d

tim
tim

From this and other projects I soon learned to write proposals that included a billable design phase. So, yes, you can get clients to pay for mock-ups. I have learned that they will pay for a good design spec. Sadly, I have also learned that they will take that and shop it around. That's just the risk you take when you lay it all out in advance. But it's better than keeping it all in your head because nobody can read your mind as I learned in this experience. I remember thinking to myself as the boss was coming unglued, "What's the matter with you? Can't you see it?" No, he couldn't see it. He simply had no clue.

tim
tim

Even if a company is small and has put into place all the technology they can handle, they still need someone to support them when something breaks. If they don't have anyone on staff, they call the outside company. So I submit again that all companies need techs. However, you are absolutely correct that IT is considered overhead and always will be unless it is being billed out to a client. That has been a tough fact to accept as I have moved through each company in my career. It was painfully obvious in some companies and always present even when management appreciates IT contributions.

smclean9
smclean9

Yes a company that is using technology needs support for that technology. But in your original story, I would describe your function on the "miscommunication job" as a developer/programmer. That is different, to me, then someone who is supporting the infrastructure that the company has put in place to run their day-to-day operations.

tmalonemcse
tmalonemcse

You are correct. At the time of the story I was a programmer / developer. Today I am a tech support manager. But I still contend that even the smallest companies need techs. I'm sure someone can name a business that does not use computers or technology but for the most part, anybody who uses a computer is going to eventually need some help with it. The issue of techs communicating to "regular" people in "normal" language is always there. It's a big complaint by those who are simply intimidated by our tech knowledge. We have paid the price to understand what we do. I always contend that anybody could do our job if they had studied and learned the same stuff we have. It's a good thing they have put their energies elsewhere. That allows me to provide value and be highly compensated!

highlander718
highlander718

I just don?t understand how could the timeframe not be discussed right at the beginning of any project ? Second, of course you should not suppose that a regular nonIT manager gives a rat?s ass about what problems and challenges you are encountering. It is supposed that you know your stuff and you can at least make a close enough prediction on how long it will take to complete a project. Including of course adding about 1/3 of time for the ?unexpected?.

tim
tim

Not discussing the anticipated timeframe is a gross sign of inexperience. Being anxious to prove myself in my first job, it did not occur to me that I didn't have all the time in the world to build fancy interfaces. I just wanted to jump right in and go to work. You are also right on about point two. Up until this point in my career I had worked with other techs as a team. Now I was the only tech and had additional responsibilities that I did not yet understand - like how important it was to regularly communicate. I was good at what I did. My portfolio impressed the company enough to hire me. It's easy to see the major blunders now looking back after all these years. Everybody knows how to at least make an estimate, right? You might be surprised. Good observations. Thanks.

dave_terpeny
dave_terpeny like.author.displayName 1 Like

I've been a year in a structured company after having spent years freelancing. In a sense it was like going back to my "first job". And I work alone now instead of with a client's tech team. It's been difficult and that sits with me. The communication, estimates and ownership that I was comfortable with "out there" has not transitioned well "in here" but we're getting there. You hit it right on when you say "regularly communicate" and I'd add, as the post references, communicate smartly. Mgmt wants the hamburger, not a detailed review of the slaughgterhouse. Its good to know we're not alone. ;-)

Tony Hopkinson
Tony Hopkinson

Double it and add ten Do the work and how long it took is the estimate. All else is bollocks, trotted out by the perfect world one size fits all sales types from the Planet Panacea.

highlander718
highlander718

I had the same tendance in my first years. I was sent once to replace my boss in a meeting, and the plants Director asked if somethig is possible and in what amount of time. Fact is the thing was possible and not to hard to achieve, more to that I knew already how to do it, so I replied that it could be ready by tomorrow (I obviosuly wanted to impress, silly me). I heard my share after from the boss, who while agreed it is definitely possible by the next day, teached me to never say that right away, especially in a management meeting :-)

Editor's Picks