How to communicate "technical details" effectively?

[novinosrin]

How to communicate "technical details" effectively?

Hello Folks particularly Elders,  I am really struggling to keep it concise, short and just the facts at work, when we are dealing with serious technical and data issues. Granted, on an easy day, given the situation has no technical real issues per se, one could easily communicate results, summaries, fact findings in a simple format. 

However, when the issue is highly technical and has got nothing to do with succinct summaries, facts and so forth and that requires high levels of understanding of technical concepts,, attention to detail(the real details), I often observe the attitude of many being very impatient and wanting just brief facts. And when I just provide technical things in brief just to satisfy them, it's an easy tell that the folks seem clueless. It's often the case, they come back with extremely basic questions. 

Alas! To conclude, nobody wins except the ego and the problem remains unresolved for the simple reason if there's no clear or thorough understanding, there is no approach to a solution. What is the way forward?

PS I mostly see this behavior from those who do not have any tech experience and are mostly from consulting(MBA)  background and take up tech roles coz it's fairly easy to get a job in tech than competing with ocean of other MBAs for fewer jobs

[mkeintz]

@novinosrin

In the situation you describe, tell us what "success" would look like.  You don't really expect these folks to get as much satisfaction from the technical details as you do, right?  So, in the absence of personality change in your audience, what really would be the desired outcome?

But I won't wait for your answer to make the following comment. I've frequently had to present some SAS programming techniques to grad students in Finance, who really only want to know how to do their research, and don't care that much about the internals of the (statistical analysis/programming) tools they use.  Not exactly the same as your bored MBA's, but it's the closest I've come.  It pays that over the years, I've developed a good deal of expertise in financial research of the academic variety.  So I would recommend knowing what they do, and need to do.

As a generality, when I present a SAS topic - almost always fairly technical - even for the average SAS group, I usually follow the structure used by one of my statistics professors in my grad studies:

1. Tell the class what you are going to show  (i.e. what are the "take home" points - no more than three).  Explain what they mean, and hint at their importance to the subject.
   
   
2. Show the details, organized per the take-home points.  Here is where I try to be accepting of questions, which helps to engage the attentive.  And for the rest, at least they know how far you are through the presentation.
   
   
3. Conclude by repeating the take-home points, emphasizing the significant to the overall subject.

A number of my colleagues were newly minted PhD's in Finance, who would be part of the same presentation team as I was.  At the beginning, they would try to cover too much (and therefore talk too fast) - as if they were still grad students who needed to prove they had complete mastery of the subject.  Don't pack in every detail.  Slow down.  Remember your goal is one (or two or maybe three) take-home points.

[ChrisNZ]

I hear you. It's a pain when decision makers have no idea what they are deciding on.

Another angle would be to skip the technical details and present the facts as business alternatives and outcomes:

We are faced with X (describe business problem) and can do Y or Z (describe solutions with pros and cons).

People (especially managers, and especially if clueless, which is too often the norm when technology is involved) want solutions, not problems. Now they can choose between solutions. Another added benefit is that if they choose Y, they own the consequences of Y (in a perfect world).

And ensure there's a written trail of course.

[Kurt_Bremser]

Whenever you reach a point where you have to communicate technical details, say so.

Open with "This will be hard to understand, but it is essential for coming to the right conclusion. Please bear with me, and do not hesitate to ask if anything is not clear to you. I am perfectly aware that most of this might seem extremely boring for you, but I would not bother you with the details if they were not important for you to come to the right decision."

Make it clear that you do this to help them. And do this only when it is really, really necessary. If they know you do not have the habit of boring them to death with unnecessary details, then the one time you have to do it, they will be much more eager to follow you.

Anecdote: when working a game of American Football as a Referee, I once had a situation that involved a rather complicated application of several rules at once to deal with everything that happened during the play. As you may know, Referees in Football make announcements to the spectators (and, of course, the team boxes) when a foul or any other "special" situation occurs. In Austria, we have always made it a habit to do our announcements in English, so we can use the original terms (and the American coaches/players we often encounter understand us). I switched on my microphone, and started my announcement with "Das wird jetzt etwas komplizierter." ("this will be a little more complicated"). Then I described what happened in German, with the rules involved, followed by the typical, short announcement in English of the final ruling.

Some time later, people who were there that day lauded me for this. They (in the audience) felt respected and not treated as know-nothing noobs anyway, and appreciated my effort.

[novinosrin]

Thank you @Kurt_Bremser  @mkeintz  @ChrisNZ  for the fantastic responses. Whew! All those points are just incredible and I have just taken a print and stuck that on my desk. Well, I have to say I can't thank you enough as I really needed it having sleepless nights pondering about it. I was really worried the job is not getting done.

The real issue is we have lots of Data quality issues and so there needs some data processing right from source systems, warehouses etc all the way up to downstream reports as our systems are not sophisticated unlike what you would have experienced in a Big4-6 financial services company. Therefore, it's not really about a simple SQL as Mark and I once had a fun banter with the so called "ready-meals" solution i.e. Select- from -group by, which I am afraid the MBA folks believe tech mean that's all and is a piece of cake.  So anything beyond is almost taken as a conflict. Thus, in essence is the problem.

Thank you for your understanding and more importantly for offering your time. Cheers from CT!

[ballardw]

When talking to financial types I find it helpful to describe the costs involved. Person-hours involved in "fixes" down-stream from a process documented are simple to place a $$$ value. Then discuss the indirect costs like delayed response times from how long it takes to "fix". Not so much the "technical details" but more of a design/lack of design oversight/implementation is adding costs to their projects. Multiple by how many activities use the data or may require additional fixes.

I might pick on one variable that is obnoxious to deal with (or group that are treated the same way) and trace the processes and costs involved for "fixing" down the line to some finished state. Then finish with a "That's the cost involved with ONE variable. There are X number of others that each have similar costs."

Anecdote: I worked as a contractor for a largish company doing survey work. We received two or three files weekly that were used to contact the respondents for the survey. One of the managers asked why we had many billing charges related to programming changes. When we responded that we had to change the programming to extract the information from the file almost every single time because the column order would change, the variable name/column heading would change, and the content of fields would change structure they realized they were spending $$$ because of a process quality problem. (Aside, the comments we had sent multiple times about the potential cost of the changing file structures had been ignored until an audit hit the unit we worked with.)

[Astounding]

Unfortunately, I qualify as an Elder.  Here's a suggestion, based on a technical writing class I took 50 years ago.

For practice, write an essay on an everyday task.  But assume the reader has no related background.  For example, you could write about "How to Pour a Glass of Milk."  But the reader doesn't know what milk is, what a milk carton is, or what a glass is.  It might open up your eyes as to what (and how) you need to present your material.

[novinosrin]

Hey Generous folks who participated in this thread+ requesting @Reeza  @PaigeMiller  their opinion too, Pardon me plz for taking advantage of the same thread for another question though not quite related. 

Seeking another opinion- How does one cut across verticals using tech knowledge as the primary. For example, since I am in financial services, would it be daunting to move to insurance or healthcare or airlines? Thoughts plz at your convenience.

I was just thinking that the same challenge that i mentioned in original post could be even worse for those who cut verticals right? I know outliers like Guru @hashman  have been successful in doing that. However, do you folks reckon it's a show stopper for the rather mainstream average folks?

Basically, "money" excites me but commitment makes me nervous. Thank you in advance!

[PaigeMiller]

Some hiring absolutely requires experience in that exact industry, and someone from outside the industry will likely not be considered. Other hiring does not. I don't know how you find (with a high degree of probability) a job opening that will consider someone from outside the industry, but such jobs and hiring do exist.

At least in my company, many people are hired who have no banking experience. I spent most of my career in manufacturing, decided I wanted a change, and was hired by a bank because they primarily were interested in quantitative skills. My department also just hired someone working in the social sciences, but who had quantitative skills.

I can't say if it would be daunting to move to learn healthcare or airlines. There will certainly be a learning curve. But quantitative skills are definitely needed in most industries, and your quantitative skill don't have to be re-learned when you switch industries; but the subject matter of the new industry has to be learned.

[Kurt_Bremser]

If your work will be mainly as a "SAS data warehouse technician", then switching from banking to insurance (or healthcare, or airlines) won't be much of an issue.

If, OTOH, you'll be more of an underwriter with a side knowledge of SAS as a tool for the job, it's a different thing.

My company is looking for another SAS programmer to beef up the small staff of two that will be left when I retire. We do not expect any experience in insurance, in fact we are looking for a graduate of a technical school for CS who doesn't even need to know SAS (as (s)he will be sent to SAS for proper education anyway). Learning the essentials of the insurance business, as necessary for an IT worker here, can then be done on the fly.

Side note: in Austria, we have vocational schools which you attend from age 15 to 19 (5 years), graduate with a diploma, and are allowed to hold the title of "engineer" after three years of work in the field.

[novinosrin]

I agree. Interesting and makes sense.

"If, OTOH, you'll be more of an underwriter with a side knowledge of SAS as a tool for the job, it's a different thing." --Very crucial concern indeed. This is the essence of the question. 

[SASKiwi]

I'm sure I've mentioned this in other posts, but in my experience employers evaluate prospective employees in this priority order:

1. Personal attributes - how well they would fit in
2. Technical / IT skills - has the required technical knowledge and skills
3. Industry knowledge

If the employee has the first two then you will definitely have the interest of employers as learning the third is the easiest and quickest. If the employee doesn't have the first two then they are unlikely to be a candidate and the third becomes irrelevant.

[mkeintz]

Let me offer a slightly different take.

My career history, which has variously involved assisting researchers in criminology, demography, public health, finance, and economics, has been primarily conducted doing programming, mostly in SAS. But the skill I found most beneficial was at the interface of content expertise and programming expertise - i.e. being able to understand and anticipate the research and analysis agenda - and then to operationalize it.

I think the skill that was most relevant to my employers was my understanding of statistics and ability to communicate.  I had to know some SAS coming in, but that was more of a filter to get an interview.

[SASKiwi]

@mkeintz  - Nicely said. Your career history mirrors my own in recent times. I've built-up specialist industry expertise in banking credit risk that has enabled me to work in several different banks. That indeed can get your foot in the door. I still think you need to pass the "will you fit in" recruitment test though.

[Kurt_Bremser]

@SASKiwi has brought it to the point. This is the same we apply when looking for future colleagues.

Do they fit in?

Do they have the willingness and skill to find solutions and acquire skills by consulting the documentation (or other means, see SAS Communities) without constantly bothering coworkers?

Will they follow conventions that have been developed onsite, but not be hesitant to suggest improvements?

When these are fulfilled, items 2 and 3 from @SASKiwi's list become a breeze.