> I believe that one of the most underappreciated skills in business is the ability to string a coherent narrative together. I attend many meetings with extremely-talented engineers who are incapable of presenting their arguments in a manner that others (both technical and non-technical) can follow them.
Yes, but the arguments they need to present are not necessarily the ones they used to convince themselves, or their own reasoning history that made them arrive at their proposal. Usually that is an overly boring graph search like "we could do X but that would require Y which has disadvantage Z that theoretically could be salvaged by W, but we've seen W fail in project Q and especially Y would make such a failure more likely due to reason T, so Y isn't viable and therefore X is not a good choice even if some people argue that Y isn't a strict requirement, but actually it is if we think in a timeline of several years and blabla" especially if the decision makers have no time and no understanding of what the words X, Y, Z, W, Q, T etc. truly mean. Especially if the true reason also involves some kind of unspeakable office politics like wanting to push the tools developed by a particular team as opposed to another or wanting to use some tech for CV reasons.
The narrative to be crafted has to be tailored for the point of view of the decision maker. How can you make your proposal look attractive relative to their incentives, their career goals, how will it make them look good and avoid risks of trouble or bad optics. Is it faster? Is it allowing them to use sexy buzzwords? Does it line up nicely with the corporate slogan this quarter? For these you have to understand their context as well. People rarely announce these things, and a clueless engineer can step over people's toes, who will not squarely explain the real reason for their pushback, they will make up some nonsense, and the clueless guy will think the other person is just too dumb to follow the reasoning.
It's not simply about language use skills, as in wordsmithing, it's also strategizing and putting yourself in other people's shoes, trying to understand social dynamics and how it interacts with the detailed technical aspects.
To give a brief example of this -- a college asked why an exec had listened to my argument but not theirs recently, despite "saying the same thing". I explained that my argument contained actual impacts: actual delays, actual costs, an actual timeline when the impact would occur -- rather than nebulous "there will be problems".
Everyone comes to execs with hypothetical problems that all sound like people dressing up minor issues -- unless you can give specific details, justifications, etc. they're not going to parse properly.
This would be one case where a person asking an LLM for help is not even aware of the information they lack about the person they're trying to talk to.
We could define expertise this way: that knowledge/skill you need to have to formulate problems (, questions) from a vague or unknown starting point.
Under that definition, it becomes clear why LLMs "in the large" pose problems.
I don't know. Predicting delays, costs and timelines is notoriously hard unless it's something you've done the exact same way many times already. For example in physical work, like installing external insulation on a building, a contractor can fairly easily predict the time required because they did similar buildings in the past several years, it's multiplying an area by a time average, and they know the delay caused by asking for some material by checking the shipping time on the website they order it from.
Developing software is very different and many nontechnical execs still refuse to understand it, so the clever engineers learn to make up numbers because that makes them look good.
Realistically, you simply come across as more competent and the exec compressed all that talk about the details into "this guy is quite serious about not recommending going this way - whatever their true reason and gut feel, it's probably okay to go their way, they are a good asset in the company, I trust that someone who can talk like this is able to steer things to success". And the other guy was "this guy seems to actively hide his true reasons, and is kind of vague and unconfident, perhaps lazy or a general debbie downer, I see no reason to defer to him."
I think there's an element to that -- I also said it's about trust and credibility. However in this case it was partly about helping the exec cognise the decision and be aware that he needs to make a decision, basically scaffolding the decision-making process for the exec.
It's kinda annoying for decision-makers to be presented with what sounds like venting. This is something I've done before, in much worse ways actually -- even venting on a first-introduction handshake meeting. But I've learned how to boil that down into decision-making.
I do find it very annoying, still, how people are generally unwilling to help you explore your thinking out-loud with you, and want to close it down to "what's the impact?" "what's the decision?" -- so I sympathise a lot with people unable to do this well.
I often need to air unformulated concerns and it's a PITA to have people say, "well there's no impact to that" etc. : yeah, that isnt how experts think. Experts need to figure out even how to formulate mental models of all possible impacts, not just the ones you care about.
This is a common source of frustration between people who's job is to build (mental,technical...) models and people who's job is to manage social systems.
I think nontechnical execs have a mental model of technical expertise, where there's some big rule book lookup table that you learned in college and allows you to make precise, quantified, authoritative statements about things.
But of course the buck has to stop somewhere. By being definitive, you as the expert also give ammo to the exec. Maybe they already wanted to go that certain way, and now they can point to you and your mumbo jumbo as the solid reasoning. Kind of how consultants are used.
Ooh there's the first positive thing to come out of this whole LLM thing. Can we replace overpaid consultants who contribute nothing with sweet whispers from an executive chatbot?
Yes, but the arguments they need to present are not necessarily the ones they used to convince themselves, or their own reasoning history that made them arrive at their proposal. Usually that is an overly boring graph search like "we could do X but that would require Y which has disadvantage Z that theoretically could be salvaged by W, but we've seen W fail in project Q and especially Y would make such a failure more likely due to reason T, so Y isn't viable and therefore X is not a good choice even if some people argue that Y isn't a strict requirement, but actually it is if we think in a timeline of several years and blabla" especially if the decision makers have no time and no understanding of what the words X, Y, Z, W, Q, T etc. truly mean. Especially if the true reason also involves some kind of unspeakable office politics like wanting to push the tools developed by a particular team as opposed to another or wanting to use some tech for CV reasons.
The narrative to be crafted has to be tailored for the point of view of the decision maker. How can you make your proposal look attractive relative to their incentives, their career goals, how will it make them look good and avoid risks of trouble or bad optics. Is it faster? Is it allowing them to use sexy buzzwords? Does it line up nicely with the corporate slogan this quarter? For these you have to understand their context as well. People rarely announce these things, and a clueless engineer can step over people's toes, who will not squarely explain the real reason for their pushback, they will make up some nonsense, and the clueless guy will think the other person is just too dumb to follow the reasoning.
It's not simply about language use skills, as in wordsmithing, it's also strategizing and putting yourself in other people's shoes, trying to understand social dynamics and how it interacts with the detailed technical aspects.