This reminds me of a support call a few years ago from the user of a application that had a character-cell based menu interface. The question was "How do I do such and such task". I asked her to identify where in the menu system she was by reading the menu id number from the top right. She did. I then asked her to back out of the current menu by hitting escape, which universally took you back to the previous level. Her responce was, "Do you mean a soft escape or a hard escape"?

After a little quizzing, it turned out that a "soft escape" was hitting the escape key once. A "hard escape" was pressing and holding the escape key so that the keyboard auto-repeat resulted in a return to the main menu. It turns out that this terminology had been evolved by the users of this particular application themselves. It subsequently became so useful that it became a part of the documentation for the application. As far as I know, it could still be so.

One of my bosses asked me too explain the current state of the application, and I responded by telling him that we had a few problems with it, but that I thought that they would be fairly quickly resolved. His next question was; "Are these evening overtime problems or weekend working problems"?

I firmly believe that most coders make lousy managers and vice versa and that the most important, underrated and toughest position is the project leader. His/her job is -- or maybe 'should be' -- to act as the interface between the two disciplines. In essence a sort of universal translator and two-way filter. Not just literally translating geek-speak to PHB speak and vice versa, but also filtering the input from each direction to allow only the parts relevant to each to get through. Of course, with any form of translation comes the possibility for mis-translation and chinese whispers. The art is in knowing what to translate and what to filter.

I've never decided whether the Business Studies person that learns to code is better or worse than the coder who takes a BS course? It is my experience that the (too few) women I've encountered doing the project leader roll seems to do it with more aplomb and less fractiousness than they guys.

It's all in the terminology.

Remember. If you tell him that it will take you a lot of work, and won't ever work right, he will say, "Just another worker-bee moaning - when will they learn that they are being paid because it isn't supposed to be fun?" (But will be too polite to come out and say that to your face.) You are likely to get farther if you can honestly say, "This change will push out the deadline by at least 2 weeks, and the UI complexity will cause users to get frustrated at us." This he cares about. He may not believe your assessment, but he cares about the consequences described.

So add to your questions whether you made the problem description relevant to him, not you.

In Particular, you have to explain everything in terms dollars and cents (or your local from of currency). Management only seem to unsderstand what shows up on their budget

Thanks,




Greg

You seem to have a dim view of management. Granted, there are a lot of bad managers out there. But there are also a lot of techies out there who are very hard to manage, because they can't see the bigger picture, and have limited, naive thoughts about any non tech issue.

Abigail

To go a step further. There are probably no terms he really cares about. Like many he is probably just a monkey trying to keep the machine happy by meeting the deadlines other people have pushed on him. Hmm, now that's a bit cynical, but then again I live in the movie "Office Space".

smiles

Actually, it's a dim view of humans, not managers. I don't believe I singled out managers at all in my post. I find that most people don't care to learn anything unless you put a gun to their head. Especially learning how to talk or understand one another. (I'm no expert at this art.)

I find that most managers shouldn't be....
Tech people sometimes strike me the same way, but at least their job isn't to manage other people's jobs.

Of late, the problem I've seen is not the tech's lack of awareness of things outside the tech world or the overall picture. Actually, they always strike me as quite powerless and frustrated. It's that the managers over them don't care about any problem but their own deadline/goal/objective/whatever (strikes me as a big corporation problem). What good is a deadline if it guarantees failure?

Granted, I currently speak as an observer, but I have had my share of good and mostly bad managers. I haven't had much in the way of managers or deadlines over the last 2 years, yet my clients have enjoyed the benefits of my work.

smiles

PS. A warning to Mr. Muskrat: Be careful what you do and don't put into writing and make sure and never document promises you cannot fulfill. ie. don't be a day late on something you promised in writing for tomorrow.

I often find myself in the role of 'translator' for my team, and as I've probably said elsewhere, I tend to analogise at every opportunity - using cars generally - "We've got the whole engine built, but are waiting for the body to be finished so we can bolt it in..." - they may go away shaking their heads, but at least they think they understand :)

Cheers,
Ben.

Which reminds me... one time I half convniced a few people to do their status report in Interpretive Dance.

Here is how I see this issue. It's all relevant. What is that mean? Simply that your approach should be fine-tuned to your audience. If you are talking to a financial person - talk numbers. If you are talking to someone who is visually oriented - draw pictures. If you are talking to someone who is a "striaght-shooter" shoot back straight.

It's easy for those of us who "understand" the issue that is being discussed to present it in a logical manner - that is what we do when we develop or analyze something. But, to relay that information to another that does not share that type of background is difficult.

In addition to targeting my approach to the audience - for those that don't have a technical background - I try to find an analogy that is similiar in nature and explain using the analogy. In the case where you can not find a relevant (meaning something they can relate to in their field) try using something totally outrageous. Funny how the mind works - throw a very outrageous analogy at it and it will draw the proper conclusion - kinda like a old fashioned coffee perculator - the realization then tends to perculate up to the conscious mind.

Communication - it is just another tool for our tool belts and like Perl - there is more than one way to skin a camel or is that supposed to be cat?!

There's an anti-pattern for this (I don't recall it's name off the top of my head) for which the gist is:

Manager: Can you get task X done in Y weeks?

Geek: We can get task X done in Y weeks provided that: conditions a through z are met; we get buy in from stake holders Alpha, Bravo, and Charlie; if the stars are in alignment; and, we get enough goats/interns for the requisite blood sacrifice.

Pretty straight forward, right? However, from my own experience, this is how the above conversation is interpreted:

Manager: Can you get task X done in Y weeks?

Geek: We can get task X done in Y weeks blah blah blah blah blah blah blah.

Being a hardcore geek with no appreciable verbal skills, I've never been good at this in the past. Luckily at the moment I have a good boss that is very computer literate.

For example, one big problem is that many don't grasp how hard development really is. Even if they grudgingly admit, from past experience and anecdotal evidence, that it is hard and takes a long time, deep down in their heart many don't understand why, and are unwilling for whatever reason to find out why. I can only assume this is because they've never had to go through the design/write/test/debug/test/release/take some heat/fix/rerelease/maintain process themselves and boil it down to just the "write" phase.

Unfortunately, I've seen this manifset itself as distrust of the programming staff ("Those slackers have been writing that new OS for over two whole weeks -- why isn't it finished!?" :-). For more in-depth analysis, see Dilbert...

bluto

1. Understand your boss's needs from his/her perspective.
   1. What good it is going to do ?
   2. What is going to be done ?
   3. When it is going to be done ?
   4. Do we really need it ?
   5. What are the consequences of this ?
   6. How able you are to do the work ?
   7. Whom he needs to tell and when ?
   8. Does it require more money to spend on sorftware/hardware ?
   9. What if I say no ?
   10. What do I need to commit if I say yes ?
   11. How I am going to manage it ?
   12. How your time can be used otherwise ?
   13. How much time needs to be invested in analysis/design ?
2. Asses your boss's technical knowledge
   1. Platforms
   2. Programming Languages
   3. Available Technology
   4. Development Terminology
   5. Rough Idea of Development Time
   6. Company Resources
3. Write down on Paper
   1. Answer of boss's needs, as many as possible
   2. Technical specs overview keeping boss's knowledge-depth in mind.
4. Modify your writing to present it effectively.
   1. Apply common-sense.
   2. Apply experience

They said many things along the lines of, "How can it take that long?"

I told them how and then I reminded them, pretty forcefully b/c I was tired to the point of being angry of being ignored on the issue, that this was not the first time they'd heard this information explicitly but the third in six months.

They said (real quote): "Well, that just doesn't scale."

I explained in further detail. File system complexity, new employee, CVS delays, no testing framework except live, Akamai cache needs to be cleared to even know if you're looking at the right files, one change means 4 hours of waiting and your team always requests multiple changes after the spec has been agreed on.

"Well, that just doesn't scale."

...and believe it when I tell you that it went around again and came back to: "Well, that just doesn't scale." From the same guy all three times!

Not all the people we work with or for are this dense and a-technical, but what I've seen isn't much better than all. Many of these people are completely unable and unwilling to understand or even listen actively.

adrianh has the technique for combatting the problem when it's only communication and not IQ in the way: get them to repeat a summary back to you verbally. You quickly find misinterpretations and things that have been unintentionally ignored.

One simple tip's not been mentioned that I find very useful.

At the end of the conversation, when everything is agreed, get them to repeat a summary back to you verbally. You quickly find misinterpretations and things that have been unintentionally ignored.

In addition one of you should always write and distribute a summary of the meeting. That way everybody has a reference point if later problems occur.

It could be your answer was complete, succinct and technically accurate .. but it could also be that you didn't answer the question he asked.

I know that my weakness is in giving too much detail up front (being left-brained and all), so I have learned to package up my answer as 'short answer/long answer'.

You can even ask your boss to confirm that question that they asked: "So, you're asking if product X will do Y under the circumstances Z?" .. and then answer that.

A very insightful thing to post, ++ to you.

In m

No, you are not the only one. Add to your problems difference in age of 20+ years, and English being the only language to communicate without being native to neither one of you. This should make you feel better. :)

Leonid Mamtchenkov aka TVSET

Say it again. But LOUDER this time. ;)

I'd like to thank you all for giving some excellent advice.

I always summarize what the boss says or asks of me so that we both know that I understand the situation. He generally smarts off with a remark like "I asked you first". It is really annoying but what am I going to do, right? :-)

I also try to get the boss to summarize what I have said and the questions that I have raised. This is the part that is very difficult to accomplish. He doesn't want to take the extra time. I can't force him to do something he doesn't want to do.

He likes everything to be backed up in writing. This is my shortcoming. I generally forget to type up a summary of our conversations. I want to improve in this area and I have started getting better about it.

I will continue working on my communication skills in the hope that I may one day get through to him. ;-)

There's a rule to public speaking which explains just how repetitive you must be.

First you say what you're going to say, then you say what you came to say, then you say again what you just said.

Being repetitive in public speaking isn't to fill time, it's to let things sink in for a wide audience.

(See, it worked.)

--
[ e d @ h a l l e y . c c ]

I also find it frustrating when bosses or coworkers can't be bothered to read the materials you've typed up. You anticipate all their questions, but they gotta hear you say it for them.

Some people learn what they see, some people learn what they hear, and some people learn what they do. It's a pain in the butt sometimes, but it's just the way each brain is wired.

--
[ e d @ h a l l e y . c c ]

...when bosses or coworkers can't be bothered to read the materials you've typed up.

And worse: when they can't read it on the screen -- they have to print it on paper! (There's a special place in hell reserved just for them.)

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

It is really a shame that I can't use Perl modules to help out some! I'd be sure to start every conversation with:
use Acme::Snark;
"What I tell you three times is true". ;-)

That is to say, my message goes astray not because of what I said or didn't say, but because of the assumptions and misconceptions they bring to the conversation. Many non-technical people miss the connections between technical systems and their business activities, and assume that the computer can "figure out" the gaps in the requirements or the errors in the data. When we explain that the system is having a particular problem, they can't answer the "how does that affect me?" question, or they assume that they can work around the problem.

One system we put in was specified for a 3-day recovery time in case of system failure because the records were not "delivered in real time". They screamed after the first hour because they didn't make the connection between the data entry backlog that had them working 60-hour weeks and system availability (they assumed we meant that the reports would be delayed three days, not the data entry). I learned to explain how technical issues touch business activities.

It may be that your boss is interested in a productivity metric or cost that seems to him independent of your issues. You'll need to follow the thread past tech and into operational impacts to make those connections for him, then he'll get much more interested in managing the situation. We all have our expertise and our blind spots, or as Nero Wolfe put it, opportunities for snobbery. Consider objectively your business literacy in comparison to the boss's computer literacy, and see if you can help each other overcome blind spots. Not only will you make this boss better at understanding you, you'll be bettter equipped to manage the next boss.

You were fine, up to the note: "Non-analytical is a euphemism for stupid."

There are a LOT of people who are both predominantly non-technical, and non-analytical, who are still profoundly adept and effective at whatever they do.

"Analytical" means that you consciously break down a problem or task into its constituent parts. Some folks just divine the appropriate solution from a very fuzzy experiential decision-making method. They can't explain it, they just KNOW how to accomplish things. There's no analysis, just instinct and hunch.

Everyone is some mix of analytical and experiential. Do you analyze your trip to the kitchen during a commercial break? Do you analyze your software project estimates down to line count and hour-tenths of effort?

--
[ e d @ h a l l e y . c c ]