This is the kind of patronising attitude that will further the gap between engineers and product people.
Being able to articulate technical details with the right level of abstraction, and without "dumbing it down" is an essential skill when engaging with stakeholders of varying levels.
Agreed. When talking to a doctor, you expect to communicate in terms you understand, or at least have essential terms explained in a non-condescending manner. It doesn't matter if they know a technically correct term for something if it means nothing to you - you expect to be communicated with, not communicated to.
The same expectations carry across to most jobs in tech. It is rare that you work in isolation, so being able to communicate details without going over the head of the other person is an invaluable skill to master.
I agree with you... mostly. I do find it frustrating that almost all the effort is expected to be on the technical personnel. I don't care if you are a "business" person (aren't we all?), I don't care if your job is sales, or product management, if you deal with software all day, you should put the effort in to understand it.
There is an expectation that the technical person has to explain everything at 100 different levels of detail, depending on the composition of the people in the room. But there often isn't the reciprocal expectation that the non-technical people put some effort in. If you work with a technical subject and you can't understand it, past a certain point, that is on you.
It's your job to understand this stuff, do your fucking job.
Not sure where you are located, but I've lived in many places in the Midwest and Florida, and almost every doctor I have interacted with is fully capable of explaining things and does it well. This is not a once-in-a-lifetime thing, but a basic requirement. If your doctor isn't doing this, maybe you should ask more questions. If your doctor can't do this, find another one.
No its not. The commenter is right. There are schools that teach people how to transmit knowledge to other people. Not only it is not for everybody but even those that finish those schools usually suck.
You are missing one of the great untold truths of engineering: non-technical people can be just as brilliantly intelligent.
They just don't speak your language or have your experience.
You do not particularly need to dumb it down. You do need to think about which things they actually need to know, and provide some backstory that helps them contextualise it.
Get good at this and your life will be enormously better. Keep this attitude and you will find your world shrinking.
I agree wholeheartedly with this. I have lost count of the number of times I have found a solution to some problem after explaining some technical detail to a layman who then suggested something I wouldn't have thought of.
I don't really think of dumbing it down, more like distilling it to its true essence. To be able to do so requires even more skill and understanding than just enumerating the details. I always think of the Feynman anecdote where he talks about skipping chalk on a chalkboard.
I wonder how strong of a signal that is for a good engineer. There have always been people who've stood out as wanting to teach, wanting to mentor. Is it too much of my own bias to say that good engineers are good teachers?
I think that for example good designers are usually good teachers, so maybe.
Good design and good engineering explains itself; especially engineering that interfaces with other stuff. Well-designed things need less documentation.
Both, I think, require the same focus on clarity of intention as a good teacher.
> Talking technical stuff to non technical is an enormous pain. The levels of dumbing down is near endless.
It's rare that a non-technical person expect that they will be able to understand lots of technical details after one conversation. More likely, they aren't especially interested in technical details.
They likely want to talk at a high-level about requirements and development schedules. If a software developer is unable to communicate effectively with people who aren't software developers, that's a skill they should work on.
Lawyers, accountants, architects, and doctors, for instance, are expected to be able to speak with people from outside their profession. (I see wfme already mentioned doctors.)
> Not everyone has to be able to explain their product to the masses
That strikes me as unambitious. If software developers have earned a reputation for being unable to communicate effectively, that's unfortunate. The answer isn't to invent a whole new profession to fill the gap.
The only line of work I can think of that outsources communication with 'the masses' is science. I suppose there's an analogy between scientist/science communicator and engineer/marketer, but I imagine science communicators tend to be more technically literate.
> Lawyers, accountants, architects, and doctors, for instance, are expected to be able to speak with people from outside their profession. (I see wfme already mentioned doctors.)
Those are frontline positions working directly with laymen though. So while doctors needs to be able to talk to laymen, the chemists working in medicine factories don't. The problem here is that we have the same title for frontline and backline developers, frontline developers are doctors, they know a bit about chemistry and can prescribe and implement treatments. However there is no reason for a developer optimizing database engine queries to be able to communicate their work to laymen, as the entirety of their work are technical details no layman would care about, they are akin to the chemists working in medicine plants.
People will continue to talk past each other as long as we have the same word for those two jobs. Developers who double as product managers and work directly with clients says that technical skills hardly matters and you should be a product manager first and foremost, which is fine but they shouldn't tell pure developers that it is wrong to focus on the technical part since they don't do the same job.
> So while doctors needs to be able to talk to laymen, the chemists working in medicine factories don't.
But they for sure need to talk to lawyers, accountants and doctors occasionally. All of those (especially the doctors /s) are laymen when it comes to chemistry.
You have frontline and backline chemists as well. Some chemists needs to be able to talk to less technical jobs, but other chemists specializes on improving the process or other technical skills.
So it isn't laymen/specialists, you have many many layers with people dumbing it down a bit in every step. Telling the specialists at the bottom of those layers that they need to be able to talk to the top of the layers is just nonsense. You need to be able to talk to people who are less technical than you, and to people who are more technical than you, so the layer above and below you, but that is it. It can help to be able to bridge more layers, but it isn't that important.
The problem with programming is that almost all those layers have the same name: software engineer.
The levels of dumbing down is near endless.
Not everyone has to be able to explain their product to the masses, let someone else have that job.