You assume what they say is the same as what they are thinking
The converse is also true. People saying something assume that people listening are understanding and thinking about the same thing. This is why it's important to write things down in details and as-unambiguous-as-you-can forms.
If you're in a meeting and someone puts up a slide deck with a 6 word bullet point that 'explains' what they want, that is a signal that literally no one understands the goal. If they put in a meeting without writing a one page doc about it, they don't understand it well enough to explain it.
And if your progression hangs off delivering that thing, you should by demanding that you get a clearer picture.
You also need to force them to justify their requirements, since asking for something way beyond what you actually need is an easy way to hide the fact that they don't understand what they actually need.
In my experience, people like that asking for 10x the actual requirement is fairly usual. But, every once in a while you hear someone say "we should buy the best, so we don't have to worry about it in the future" (when I heard it, that was a 500x cost difference).
> You also need to force them to justify their requirements, since asking for something way beyond what you actually need is an easy way to hide the fact that they don't understand what they actually need.
I've had a lot of success by shortcutting the refinement/request sessions with clients by simply asking "What is it you need to do?".
Due to an esclation from a client, I joined a meeting with a dev and a client to try and figure out why a single report is taking over a month to deliver. Dev reported (privately) to me that the client keeps changing their mind about what needs to be in the final report.
When I finally asked the client my magic question, it turns out they may not even need that specific report anyway - they're just not sure what can be retrieved, so they wanted one single report for every single thing they may want to do, now and in the future, attempting to squish hierarchical data and tabular data from SQL queries into a single gigantic report.
There's no way the dev was ever going to have a finished report for them. I broke it down into several simpler reports, some of which already exist, which turned a very frustrated client into, well, not exactly happy, but at least they are less frustrated now. They have some of the data generated daily now, and we can do the other stuff as and when they see a need for those reports.
> about the same thing
yes. I have to keep telling my colleagues "about what?" for about 4-5 times in a row, at least twice daily, until they finally realize they have to tell me which client, feature, product or whatever else they are referring to.
Even if i know exactly what yhey are talking about.
Mine is "What's the question?"
I basically have to ask that almost every other time someone starts a conversation.
They talked for 3 minutes and never actually articulated a problem or request but just sort of recounted some seemingly random but presumably related facts.
If there is a tech-person problem it is this one. I constantly have to interrupt collegues when they try to explain a thing as their explaination attempts are usually way too low level or even bordering on being self-referential. So they explain the concept by using other concepts the listener won't understand either.
In my opinion it all boils down to a lack of ability to remember how one felt before understanding a certain concept. If you did you would have an empathic understanding of how word-salady a lot of the explainations are.
The first thing you need to tell a uninitiated person is simply where to generally put it and how they already know it. If you explain DNS for example you explain it via the domains they know and how it is like a contacts list for webservers so your browser knows where to look when looking for google.com.
Whenever you explain anything you might want to ask yourself why the other side should even begin to care and how it connects to their life and existing knowledge. What problem did it originally intend to solve?
Many tech people may start in a different
When I taught I often thought of it as explaining in a spiral: first I must go around the concept, before I can dive in to the concept. Going around gives boundary and definition to what I'm talking about, allowing people to place it in the proper spot in their mental framework and to relate it with other nearby things. It also gives some motivation for what this thing is and why they should care. Then when that is done (and it does not take long), the details can be discussed, and they're easier to communicate because people are primed to receive them.
> This is why it's important to write things down in details and as-unambiguous-as-you-can forms.
While that might be a prerequisite for a deep shared understanding, I have made the experience in the last few years that the number of people really reading more than the starting sentence of any message/ticket/email is consistently decreasing. I often have to feed them the information in very small and easy to digest portions. I so dislike that.
Nobody reads the docs, tickets, or comments under a task, nobody really checks the code they are reviewing, and nowadays thanks to AI, some people don’t even read the code they “write”.
People love to ask for documentation, as long as it doesn’t exist. It lets them off the hook, “oh I would have known what to do, I wish we had this documented”. Then you point it out that you have it documented with video walkthrough, asked the team to read it and give feedback multiple times, and nobody gave a f.
Managers ask detailed questions about the IC’s tasks and priorities, only to forget it half an hour later and ask again and again.
I don’t see the point of fighting this, I’m sure I do the same to some degree. You just need to assume nobody reads anything and nobody listens or remembers anything, so be patient and explain everything every time… at least I don’t have a better strategy.
> Managers ask detailed questions about the IC’s tasks and priorities
I've told the various teams that I wouldn't have to phone anyone if they updated the ticket. When I see a ticket that has not been updated for 2 months, there's no way I'm not phoning the assigned person.
Problem is that, even when I was a f/time IC, we hardly ever update the ticket unless we feel we have made progress. An update saying "Chased bug with no success $TODAY, requested $SENIOR to consult with me on this" feels like a worthless ticket update, but from the client's PoV, this is valuable info - it means that it hasn't dropped off our radar, we haven't forgotten about it, etc.
I’ve been at it 18 years for different organisations and my experience and strategy is the same as yours.
No one bothers to read/understand anything until the very last minute, then they realise “oh shit this won’t work in this scenario, and it’s always a showstopper”…
But what about my impression that it is getting worse? When I (as a developer) was trying to help customers with the product 20 years ago, about 50% (my guesstimate) of the people were actually reading what I wrote, at least to a good degree. These days I am lucky if it is 20% who are reading answers to their problems more than in a completely superficial way. I blame social media and smartphones.
I think the quality of comms is definitely getting worse, I work for myself now and I am very selective of clients now. So I don’t butt heads against it as much, but it still happens despite best efforts, especially when people move on or even go on vacation.
Literacy skills have been falling and it shows up in testing of a lot of different countries, and it basically lines up with the arrival of iPhone/Android(or real smart phones).
In fact, people do read documentation when they know it exists and when it is reasonably written.
People often don't, but AI always does. As we rely on AI more and more, having strong docs will become even more important.
This is why I'm assuming so many people aren't averse to LLM-generated/filtered text. If you never really read or wrote what you were reading and writing anyway, the LLM can get something similar without much effort. Frustrating if you actually need something
What I say: This is not ready for production.
What management hears: We can sell this to the customer for acceptance testing.
What you say: I don’t want to take responsibility.
What management hears: I want someone else to take responsibility for me.
What I say: I want a pay rise.
What management hears: We want more pizza parties.
Nah. Our CEO just fires everyone who asks for a raise because they're a liability now.
FWIW, this is in a country that supposedly has really strong unions and worker protections.
There is a very weird and a very awesome soviet-era movie Kin-dza-dza. At one point one of the characters tells this about the other: "he says things what he does not think, and he thinks things what he does not think."