How do you talk to non-technical bosses

Question

Ok, so I'm a lone developer at a PSEUDO startup... it's a new venture for an existing small company. This is the FIRST time I have managed a project alone, usually I work for startups with lead tech guys that mentor/manage me.

It's really difficult for me to communicate priorities to my boss. With some things he is good, other things not so much. It is hard for him to understand what needs to be done. Have you run into this?

As far as takin g on such a huge task I turned this job down 4 times, lol... it's going better then I thought it would? Things are rocking out I am just running into these road block and trying to learn.

Most frustrating thing so far: depending on consutants

Answer 1

This is something you will have to learn for yourself really, but I would recommend trying to use something like a tasklist with priorities or maybe a ticket/issue tracking system and trying to collaboratively come up with priorities.

Answer 2

What I have learned from dealing with non-technical Bosses is to not talk down or dumb down your interaction with them.

A good Boss will ask questions about what they do not understand - take that as an opportunity to educate them. In time you will come to a common level of understanding.

A poor Boss will become frustrated with not being able to communicate with you. Still be patient and attempt to educate them also. You will eventually come to a common level of understanding.

Answer 3

with flannel boards

Answer 4

Great question. I often ask similar questions when I interview candidates. After asking a high level technical question, and the candidate answers, I often follow it up with "Now how would you explain that answer to a non-technical executive"? Answers vary, some good, some bad. But ALL can agree this is one of the biggest hurdles to overcome as a consultant.

I recommend building a mental glossary of non technical terms that relate to technical ones. Making the translation in your head while speaking is difficult, but it certainly helps me explain topics of technical nature in a non threatening, non technical manner.

In short, it takes patience and experience to overcome this all-too-often encountered hurdle!

Answer 5

Frame your conversations in terms of what info the boss needs:

• In layman's terms, wnat is it that you want to change?
• What will the benefits be?
• What will the consequences be if you don't do it?
• What are the risks?
• How much will it cost?
• How long will it take?
• What resources do you need?

Another thing to keep in mind is that it is your job to disagree with the boss if you are right and he or she is wrong. Don't be insubordinate, but don't just give up. If the boss doesn't understand something, educate without being condescending.

Finally, consider that your difficulties may not have to do with technical subject matter. If this is your first time in charge of a project, you may not be used to acting in a managerial way. Does the boss trust you? When you make suggestions, are you assertive and confident? Are you telling the boss what you want to do, or are asking the boss to tell you what to do? Are there other people around who are not supporting you?

Answer 6

This can be quite a challenge at times. First thing is to be very patient and respectful.

As a programmer myself, we have a tendency to over do stuff and want to redo things. Prioritizing is not our greatest strenght :) This is our nature.

A good boss will know this and ask many questions as to validate priorities, control costs and sometimes just to learn things. Just be honest as to why you want to rewrite such and such module or why it will take a week to properly do something when it seems that it could be done in 2 days.

As to 'how' to communicate with non-technical people, I've always found the easiest way to explain things is to use analogy. Try to use an analogy which suites his/her line of expertise.

For example, my girlfriend works as a corporate HR. One day she asked me what I meant when she overheard me talking with my peers about proxies and our cacheing system.

I explained that she filed her documents in filing cabinets in an organized manner. But she only had enough room in her office for one cabinet but had thousands of documents. So her remaining documents (to her choosing, more than likely older ones), would be sent downstairs to the storage room. These would be accessible to her but only uppon request and with a certain delay. Very old and unused documents were transferred to a massive storage area in another building and required a huge amount of time to get access to them should she need them.

As for the proxy, I explained to her that when she requested many documents at once (some from her filing cabinet, some from downstairs and some from the other building), her secretary knew the priority of the documents -- those she would need right away and those she would need by the end of the day. So of the 15 documents she requested, her secretary dropped 15 folders on her desk. Little did she know that the bottom few had no actual documents in them. But this gave her secretary time (during the day) to go downstairs and to the other building to collect the documents and discretely insert them into their appropriate folders.

With a simple analogy, she learned cache size, cache locality and cache efficiency, etc. But it was explained in a way to understand but most importantly in a way that she wouldn't forget which is just as important.

Hope this helps.

Jeach!

Answer 7

The other thing you'll have to gauge is how much information to give your boss. Some people are detail oriented - even if they don't understand everything, they'll want to know as much as they can and they'll want you to explain it.

Other people will get bored / frustrated with that - they just want to know "It'll be done in 3 days" or "We need do to this before that". Again, this is a judgement call. My preference is to start with the high level overview and drill down if it looks like they need it, at least until I can work out what the other person really wants.

Answer 8

Don't talk with him about technical details, better work as a self-directed team of one showing him your plans, and reports of your progress.

You can find more advise about this in the PSP and TSP articles of wikipedia

Answer 9

Use real-world analogies. Anything common and usual. Cars, traffic, people, food, other technology, and even other business processes. The human body or animal biology in particular with their multiple systems and organs are a fantastic pool of examples for design and architecture analogy.

When you explain things using familiar concepts, it gets a whole lot easier to digest.

Answer 10

I think manager do not need to me burdened with technical details. Their is to make decisions on which features to implement based on a fixed budget and time frame. Our job is to present them with enough information to make those decisions.

Answer 11

Take the time to understand their business environment, and how what you are doing addresses their business needs and problems. Spend the time to come up with suitable analogies to illustrate your point in ways that mean something to them.

As a project manager, you often have to manage trade offs - doing it one way has certain advantages, but some costs as opposed to another way - make sure you can explain those succinctly in business - not technical -terms.