The number of times I see my words interpreted as though my choice in words had been imprecise is a near constant source of pain, particularly in the workspace. I might be on the spectrum, I am undiagnosed.
About six months ago I was tasked with building a little RPC for a different division to be able to kick off a long running process and documenting it for them. The documentation was complete, correct, and relatively terse. Less than a page.
I sent my manager the documentation to pass on, and for reasons I will never understand he passed it through AI before handing it over to the other department. No one informed me.
Within a day I start getting feedback that makes zero sense. Seemingly no one can get the RPC to work. I had tested this extensively, the complaints made zero sense. One of the complaints includes the actual request being made and the endpoint is entirely wrong. Not a single character typo, a complete fabrication. I ask where this came from and they point me to the documentation they were sent. Every single thing was wrong. The endpoints were wrong, the required parameters were wrong, there were invented features that do not exist. I am a very easy going guy, and I have genuinely never been so furious in my entire life. I am still angry as I write this. If the job market were not what it is I would have quit there and then.
I feel like people using AI to both read and interpret language is the death of rigorous language. I have genuinely been pondering for months if generative AI is the "Great Filter" preventing space faring civilizations from flourishing. Around the same time a civilization begins to enter space they invent a device that destroys their minds.
You aren't alone. My professional written communication is meticulous. I think carefully about my audience and optimize word choice for very low probability of accidental collision or misinterpretation.
I don't think everyone should communicate this way all the time, but I do think everyone should recognize that loose communication in mixed company can waste a lot of time. My job involves inter-team and inter-department collaboration and I take the time to do it well.
> I feel like people using AI to both read and interpret language is the death of rigorous language.
I agree AI is eroding diction. I don't like the idea of such a heavy inertial force on the evolution and usage of language. Or the idea that it might be grinding off variation in word choice and self-expression.
I think there are bigger negative impacts here than most people realize. For example, it reminds me of the part in Snowcrash about how language variation is important to mitigate the spread and criticality of mind viruses and danger memes. I think you could totally look at modern authoritarianism through this lens, for example.
It might be that with precision, readability is lost. It's a tradeoff: the more compressed your language is, and hence the more precise, the more cognitive effort you require the reader to expend on each word. Reading is a translation from your mental model, as expressed in words, to the readers mental model. Words alone don't perform this translation, the act of reading and interpreting does so. With your concision you give no help to the reader in this process.
One suspicion I have is that your one-pager was passed through AI because it was too terse to serve the job of aiding the general reader in obtaining an understanding of the topic for themselves.
Writing to be read by an audience is a vastly different activity than writing notes that merely, precisely, document for the maximally informed highest-context reader (or one willing to do the work of reassembling this context during reading).
When you're writing for others, especially a "generic other", you're expected to adopt their uninformed, low-context, high-difficulty reading position, and fill-out the prose in an aid to their understanding.
This will involve: repetition (restatement with different words and ideas), illustration with simple examples, grounding in examples most likely to be familiar to them, explicit statement of steps/procedures/processes that breakdown topics/actions into small units which are each easy to immediately understand, possibly: some humor to break the effort of reading, some asides which engage or interest the reader, some context which makes the reading reelvant to them so they will be willing to expend the effort to read it.
Since the poster here wears his personality and writing motivations on his sleeve, it is very obvious to me that he writes at cross purposes with those who read. he says very clearly: he writes for precision, expended a vast cognitive effort per word.
Even if, in this instance, my analysis is wrong -- its a comment for the poster here worth considering. Because people don't like to read writing which has taken such effort to produce, because it then requires a great effort to read.
Sufficiently advanced incompetence is indistinguishable from malice.
I'm not seeing the point.
Chasing readability without maintaining accuracy is a failure in the context of documentation no matter the motivations involved.
I'm not saying that readability can't be a consideration when making documentation. I am saying that if you discard accuracy in the process, you've fucked up quite badly.
This anecdote would likely be very different if the AI-modified version had been passed back to engineering for a review before sending it out.
That is malicious and inexcusable. It's not on GP, the fault lies with the idiot that ran gold documentation through the bullshit machine. Don't blame someone who was wronged, that makes you a malicious asshole.
Note that the manager may or may not have incentive at all to provide useful or even meaningful feedback.
I mean, he did pass on an incorrect version of the documentation, didn't he?
hi! yes. perhaps he wil write inchoate sentence like point out which word is wrong
>One suspicion I have is that your one-pager was passed through AI because it was too terse to serve the job of aiding the general reader in obtaining an understanding of the topic for themselves.
"Too terse" beats "factually wrong" any day. Anyone who claims otherwise is evil.
>Writing to be read by an audience is a vastly different activity than writing notes that merely, precisely, document for the maximally informed highest-context reader (or one willing to do the work of reassembling this context during reading).
Now do "writing to be read by an unwilling audience", and "writing to be read by an audience that controls the feeder and shockprod".
The very first sentences should clear warnings not to modify the document, and read it entirely. That the contents of the document are short (<5min of reading) and extremely important. That a lot of effort has gone into making the document short, to the point, and easy to read/use.
And if that still doesnt work, arrange a 15min meeting with relevant stakeholders and go through the document quickly before releasing it.
It is my view that we have always been an oral species, and the great tyranny of the written words always a great burden, and any writing of any complexity or technical depth, out of reach for all but an elite.
Speaking to people in a meeting allows them to emote, express difficulty of understanding, understand the sentiment and priority of what they're hearing -- and most of all, it allows them to listen rather than read. People speak at a much lower information density, and this is a less taxing form of communication.
Writing has always been a great burden. It should not be elevated to, nor equivocated with, some great utility or intellectual practice. That was for an era where sound was harder to record and transmit than words; and where meetings required moving around the world.
A kind of writing which makes reading even harder is an even worse pathology. This isnt writing for a species of ape, but some one deranged enough to expend cognitive effort in such inhuman ways.
At some point I realized that if I didn't want to be permanently frustrated, I had to adapt to the broad reality of how humans communicate. I introduced more context and redundancy into my writing, I learned to use analogies to make it easier for others to get the big picture. Most importantly, I stopped expecting every word I read to mean exactly what I thought it meant, and instead tried to get an idea of what they were trying to say, rather than fixating on what they were actually saying.
Years later I figured that I was autistic, and that it had played a big role in my difficulties trying to understand and be understood by normies.
However I also sometimes cannot find the correct precise words to describe what I mean in unambiguous, but also concise words, so I sometimes choose much less precise words for lack of a better alternative. Oftentimes I denote that when I find it important, but it happens way too often to do that every time.
Also words simply aren't completely precise. A word might be perfectly fitting for what I want to say with it in a situation, but someone else understands it as something slightly different and they are not wrong about it. Words often simply do not have one exact shared meaning.
Natural language is imprecise and it is fundamentally a lossy compression function. One that uses a shared dictionary that is not identical for both encoder and decoder. You simply need some amount of error correction in encoding and decoding.
I have extreme examples from friends, where somehow they “hear” the opposite of what I say because they are always looking for the indirect meaning, not what you are saying.
Fun example from a friend: his family were extremely direct but his girlfriend’s family was very indirect. As a young naive guy he was having dinner with his girlfriend’s family and her father asked: “is there any salt” and my friend looked up at the glass salt shaker and said “yes” and continued with his meal.
Holy cow what a great premis. I require that Cory Doctorow write this book as soon as possible.
It's just frustrating. I'm not one that obsesses over the meaning of every word, but there's no way a summary in 10 bullet points can contain all the information from a 4-page document.
I find this notion a little strange. The implication here is that words are precisely bounded to bounds of thoughts. Language is a representation of our world (and our individual understanding of it) - we all (including you) will use different words to describe similar-ish concepts. This will always be more clear to you as the originator of the thought -> word process than the receiver.
You can’t hand wave away the work of interpreting (aka listening) to someone.
I’m sure if I spoke to your counterparts in the scenario you described they’d say different words which also ultimately amounted to something like “it’s difficult to interpret what they’re saying.”
It's true that misunderstandings can arise between people who both tend to communicate very explicitly, but they're just different from the kinds of misunderstandings that occur with people who tend to leave more disambiguation work to the interpreter. I'm feeling lazy atm so idk what to say about that except that you'd know it if you saw it.
It's true that the details are messy, but in practice it's not that difficult to recover basic concepts related to such differences in personality like "more literal" vs. "less literal" in a way that's useful.
> I’m sure if I spoke to your counterparts in the scenario you described they’d say different words which also ultimately amounted to something like “it’s difficult to interpret what they’re saying.”
Yes and no. Lots of people who speak in a way that relies more heavily on (real or presumed) shared context react to precise turns of phrase from their counterparts who prefer explicitness like "Wow! You're so good and finding the right words for things.". When they do misunderstand, they're typically less likely to notice. You only usually get the "you're difficult to interpret" realization from them if you are discussing a specific misunderstanding and you come upon a logical or grammatical distinction they just can't see.
I'm not a linguist or communications scholar and idk if any work has been done to see whether related traits really form identifiable profiles or personality types or whatever, but at least some individual traits and behaviors that I associate with these personality differences are pretty easy to measure. For example: the "intuitive" speakers/listeners tend to make more use of anaphora as well as more difficult (more distance in the conversation from the referent) and more complex (the referent may not be the most recent grammatically compatible named thing/person) use of anaphora. They also tend to see more ambiguous use of quantifiers as grammatical (little sensitivity to "surface scope/logical form isomorphism").
Idk what to tell ya but there's a real spectrum here. If you fall in the middle of it, it might be easy to miss. But for people at opposite ends of it, the kinds of communication they encounter with one another are pretty unmistakable.
Relatedly, there's a single load-bearing word in GP's comment that you seem to have missed or given inadequate emphasis:
> Many people I find speak in what I would describe as tone poems.
It's that first word I've emphasized above, "many". They're not running into this kind of communication problem with everyone. That should increase the curiosity you hint at in the beginning of your comment, because it suggests that this is not the simple problem of one person assuming everyone can/should automatically understand them as well as they understand their own statements. Their experience and their self-report of it describes a structured and selective clash in communication (down to their admission/suggestion that they may be on the autism spectrum) which your reply seems to miss.
And yet, that's what their manager did.
Not only that, they precluded interpretation for the other people, by running the documentation through the language mixer.
And half the commenters are blaming GP for making the effort to do the right thing.
"Power", "authority", literally refers to the ability to hand-wave interpretative labor uncontested. (See: Graeber 2006, yeah the one about his mum dying)
Let me add a couple to this list.
1. No amount of knowledge or discussion will make a person accept something they don’t want to accept.
2. To truly listen means to place yourself mentally and physically in a vulnerable state. Because you will likely hear things that run contrary to your experience, beliefs, and worldview. Judging people is often a self protection mechanism; which means you will almost never listen to someone.
3. Listening often means not jumping to a solution; but absorbing and processing someone’s pain. Product managers for example are quick to jump to a solution, a new feature, or they’ll push the request off as “oh, ok, we’ll make a ticket for that ”
When in actuality, they should be listening to the use case, looking for the pain, and finding a way to solve the pain points. As opposed to trying to understand what feature the user wants to request.
Not sure it's ever good to assume this beforehand though. Most things are negotiable, if you know how to negotiate right.
I usually have very strong opinions but try to hold on to them very loosely. It happened that I was convinced with evidence that I am right and refused to accept any alternative until new evidence slapped me in the face. At that point knowledge and discussion made me accept something I had previously thought preposterous, sometimes to the point of outright dismissing any conversation, this is how preposterous the proposition sounded at first sight.
What I want to say is that if you don’t know your audience, if you don’t know for sure your attempts are fruitless, it’s always worth a shot to use your knowledge in a discussion and let the other party digest that and see if it that moves the needle.
If you can guarantuee me this will not be abused in every situation ever and/or come back to haunt me, i will gladly always give up as much time as i can to actually listen. :)
I am biased in this answer on vulnerability, and I know it. I’ve lived a full life. I’ve nearly died multiple times, one instance was on my knees with a SWAT Team standing behind me with rifles pointed at back.
When you’ve lived through such events your risk calculus changes. Things that seemed terrible like being fired or laid off, tend to feel not as insurmountable or scary.
I say this to outline my bias, but also add evidence to my view on vulnerability. I’ve seen both sides, and while being concerned about abuse when vulnerable is a concern that should be seriously considered.. often people who are forced to make that decision miss the other part. The audience.
Vulnerability will almost always grant you the favor of the audience. If you work a job with half decent people, being vulnerable and abused when exposed will cause leadership to side with you. In my experience, most people are decent and want to cause the least harm to others in personal and intimate settings. So being vulnerable is almost always a win, even if it’s not the win you want.
And the place/scenario in which you’re purposefully vulnerable results in abuse/neglect without recourse for action… well.. then unfortunately you’ll know that situation is untenable and unlikely to change. So you can react accordingly.
If it was guaranteed that it will not be abused or that I would regret it, it would not _be_ vulnerable. Just like its not bravery if I am not afraid or I am assured of my safety. Such a paradox. Being vulnerable for me is acknowledging that it might have an increased probability of a more negative outcome, but still trying to be vulnerable because of the huge connection unlocks that (often) occur in my experience.
On balance intellectually i am coming to see the expected value from being vulnerable in communications is high, but my little lizard brain keeps saying to me "what if you get hurt though" and being closed off haha. its an exercise to shut it up.
If your range of outcomes is [He'll do things my way, There'll be a scene and a strained relationship] then sometimes there'll be a scene and a strained relationship. If the range of outcomes is [we do things my way and he hates it, we do things his way and I hate it] then that's at least softer on the relationship. If you're lucky maybe you don't even care and you can just live with some parts of the work being bad.
One of those awkward things is that being good at negotiating means that other people are more likely to get what they want. It is actually a bit counter-intuitive.
I will admit that sometimes the circle of influence seems bigger than expected though.
Thank you.
> When in actuality, they should [...] finding a way to solve the pain points
Honest question, how do I 'absorb someones pain'? And how do I transition from that into eventually formulating the feature/ticket?
if it's not two ways, stop trying, stand up and leave.
Your assumptions are also very wrong, my psyche could kill you, I simply know what I want on my side and you on your side, we have to meet somewhere in the middle, otherwise it's not listening, it's abuse.
If you don't stand up for yourself, nobody will.
Your view is US centric, I live in Europe, we have rights, we can't be fired for having opinions. We don't work 10 hours a day, we have rights.
You have this strange stance where employees are slaves, living in a one man dictatorship.
We are not.
This just sounds nuts to me, not being able to have the right for sick days/leave when your mentally unwell...
It's also counter-productive, people that are unwell won't be very efficient. Happy and healthy people work better.
You have now described the value of product design (no matter if the person doing this is labeled PM, UX, Product design, or whatever)
This claim is demonstrably untrue.
Do you believe that a written argument cannot be convincing? Or do you believe that when you read a written argument, your beliefs can somehow be transmitted back to the author, even if the author is long dead, and be convincing in that author’s mind?
Communicating effectively is the central problem of all humanity!
This vent criticizes developers for not knowing how to listen. that's why it comes off condescending. The root problem is that people don't know what they don't know.
The best communicators are translators. People listen because the message becomes self evident in their understanding.
It's hardly a breakdown because everyone is acting like a toddler with their fingers in their ears.
This is ironically why we reach for systems and engineering. The system can build in gap detection and frameworks for translation. It's not perfect and creates its own problems but scolding each unit human to listen better does nothing for the collective environment: the team, the company… the system.
Bounded meaning there are upper limits to what anyone can do. And there are upper limits to how frequently model updates of the chimp brain can happen per unit time. And the limits of a group are much lower. At the extreme end Large institutions once they settle on a model of reality can take decades to radically update it. Even if all signs say reality has totally changed.
So with those constraints in mind decide what you want to spend your energy and time on.
Former UK Prime Minister Margaret Thatcher: “Consensus ... is the process of avoiding the very issues that have to be solved.”
I buy that inevitably the system becomes it's own constraint and local optimum. But working together is a practical reality too. Worth making the best of.
A typical pattern I recognized is that many developers communicate like bad medical doctors: they do "Mhh, Ahh" and then after a way to short period they fire out a diagnosis of what you need, sometimes without you even having said everything relevant yet.
It is nothing new that people in software are at times not the best communicators. For the first part the interesting bit isn't what your clients want, it is what they need. Unless they are the usually rare customer that has a good understanding of how software could solve their problem elegantly, you will have to assume it was someone's job to come up with something and that someone has never written or thought a lot about software before. That doesn't mean their ideas are worthless, but it means the work of finding the requirements and coming up with a solution is usually not done when you arrive. And the way to get it done is communication, by observation and by having them explain the processes.
Many software developers are in fact really not listening in my experience. Not that developers are the only people that happens to, doctors or other technicians also come to mind. They are often trying to quickly come across as competent by showing off their good grasp of the subject. To them you are a clear case of some category of problem they have dealt with a hundred times. This can work for them.. Until it does not.
But singling out specific archetypes is an obvious contradiction of the article, which is weird. Author is in the UX design space so likely has particular lived experience with specifically eng orgs.
Wow, you've just described my communication style when I'm angry. So consice yet captures the problem so well
If that were true, there'd be something about it in the Bible.
That is what I was referring to. I don't see that you need to contort anything. The story plainly states that without communication problems, man is powerful enough to frighten God, and that the solution God reaches is to introduce communication problems, leaving us stuck in the situation we actually have.
The importance of communication has been recognized for a long time.
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.
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).
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.
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.
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.
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
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.
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.
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.
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”…
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).
What management hears: We can sell this to the customer for acceptance testing.
What management hears: I want someone else to take responsibility for me.
What management hears: We want more pizza parties.
FWIW, this is in a country that supposedly has really strong unions and worker protections.
This is a phenomena I have yet to experience in the wild.
> Cut all the unnecessary meetings and only allocate the minimum viable time to communicate.
Most meetings are not about communication. They are usually prescriptive in form and dictatorial in nature.
> Then everyone will be listening.
Listening is a skill, one which is can be perfected if practiced. Neither meetings nor their duration are contributory to this skill.
communicating is also a skill
learning to communicate effectively can be perfected too
I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
Too much time is spent attempting to communicate and as such, communication isn't actually happening.
(i.e. we all spend way too much time in useless meetings where nothing happens and few people are any more informed than they were before)
The commenter above argued that the problem was slightly different, it's not too many meetings for communication but too many that are not achieving effective communication. A meeting in itself does not create communication (of information and exchange of opinions etc.) and the commenter wanted to increase the number of meaningful meetings instead of/in addition to just cutting down meetings by numbers. The criticism of not enough time spent on communication is in the same vein, both agree on the issue of "too many unnecessary meetings".
>"too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".
>it's not too many meetings for communication but too many that are not achieving effective communication
^^ there's no meaningful distinction between those two, discussions that devolve into such things suck all potential value out of a thread.
The first is:
* Acknowledging that too many meetings are ineffective
* Suggesting reducing the number of inneffective meetings
* Saying there needs to be clearer, independent direction
The second is:
* Stating that there are not too many meetings in general (the first says nothing about this)
* Acknowledging that too many meetings are ineffective (same as bullet 1 of the first sentence)
* Not suggesting how to address either problem
I agree with GP. There is no meaningful distinction between the 2, but the first suggests 2 ways to solve the problem of ineffective meetings whereas the second simply acknowledges the existing of problems.
This is where I think we have a different definition of communication.
> (i.e. we all spend way too much time in useless meetings where nothing happens and few people are any more informed than they were before)
Hence my clarification of:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
Listening is a skill, one which is can be perfected if practiced.Step back and think if a dispute over the usage of the word is necessary or helpful in this context.
Amusingly this is where a lot of communication goes to die, loss of the big picture and discussion of how to use particular words.
Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
Perhaps I should have said we have a different understanding or expectation of communication, instead of "definition." For this confusion I introduced, I apologize.
> Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
I do not.
Again, as I previously self-quoted:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
Or maybe we're spending too much time on communicating.
If too much time is allocated then its hard to stay focused
and there's always the next time that can be used to
clarify.
Finally, OP concluded with:
Cut all the unnecessary meetings and only allocate the
minimum viable time to communicate. Then everyone will be
listening.
... we all spend way too much time in useless meetings where
nothing happens ...
You are not understanding, perhaps willfully, what people are writing and muddying the waters by trying to make unimportant distinctions about words instead of engaging with the meaning as intended by the author.
Every one of your clarifications has just been a pedantic restatement of what someone else clearly meant using different words trying to make a distinction which is not at all necessary to make.
For the typical "agile" process for software:
- standup: this fits, attempting to communicate status and request help with blockers
- backlog grooming: attempting to figure out what to do with artifacts of generally-async communication (tickets from a backlog, either created by you in the past or by others). attempting to fit them into the process best. Communication is often seen as a necessary evil, and this process often goes faster with fewer people. if people bring up questions, there may be some attempts to communicate in explanations.
- sprint planning: work assignment and time management/estimations. similar to above, questions could spark attempts to communicate, but it's not the primary purpose.
- sprint retro: improve the team dynamics and the flow of the process. communication is usually assumed here, but in practice it's "people saying things, they get written down, then the next sprint happens same as the last." there often isn't effective communication to the people who could change things
I think if the goal of meetings was more specifically "we are going to communicate until our mental pictures are exactly the same" you'd end up with faster/better actual work from everyone on the team.
But in big orgs that's usually not even what's wanted. If the plan sucks, but it's a VP's pet project, it's not good for various whole teams in that org to all effectively communicate with each other to realize it sucks but not have the political skills or pull to change the VP's mind...
The way out is creating a singular vision (eg leadership) and assigning teams goals they can work independently on towards that vision. It is to remove dependences between teams (and thus the need for them to communicate as much), not to increase communication or Jira tickets or Gantt charts or RACI matrices.
Use an Ai agent + Mermaid.js for a quick scribble if you are in a remote meeting. Use white boards or pen + paper in a local meeting.
Diagrams are so much clearer then words, especially if the concept or logic in question is not trivial.
And the problem is that the communication (or alignment) is the thing that the meeting is supposed to be about, sharing well-considered thoughts and cohesive direction, soliciting meaningful feedback against clearly-articulated assertions. Instead, we're all-to-often addressing someone's attempt to turn their job into a group project, the stone soup of the modern business world. You can lay this bare by asking "what is the aim of this meeting?" early on, to level-set that the meeting owner isn't just setting up a study group.
Birds-eye-view-only managers only see work get done in meetings, so they assume that the meeting is where the work gets done. They don't understand all of the work that went into what came before the meeting to make it a successful one. If you rush the "communication" before you've found the clarity of thought, your meeting is just noise.
There's a simple but powerful response to this sort of persistent malaise, one that strikes fear in the hearts of the secretly inept: "I don't know, but let's figure it out right now."
When it's time to slow down and walk through the problem, I hold folks to an ordering of dependency: Why, What, How, Who, When... If you don't know all of the things before (e.g., Why, What, How - if you're trying to figure out Who), you cannot proceed. I don't care if you're an intern or a VP. No short-cuts to bullshit hand-wavy answers.
Decompose the problem, do the thinking, reason through it right there, and, if the team doesn't change its behavior, find another team. In the right environment, some folks are willing and able to step up to the plate and act like grown-ups working together to craft something better. Sadly, quite a few can't (or won't) answer the call to be responsible adults.
So they call another agenda-less meeting.
Once a customer's expectation is in-line with with can be done, and how long that will take, and how much it will cost, and when it can be used in production, you have one happy customer, even if they are unhappy with the projected start date, or the projected cost (generally a deal-breaker, so that's why I align that upfront with ballparks).
You can listen all you want, empathise all you want, but the reality is the reality - they have to acknowledge and/or accept the realities.
Having a customer relationship manager who agrees to everything the client wants is going to result in one very unhappy customer. The customer-interface person needs to listen to both the client and the internal team, to make sure what the client expects is what your team can actually deliver.
I've caught myself frustrated at users for not understanding something I've spent years internalizing. The problem is: they've spent those same years internalizing something else entirely. Their knowledge isn't absent, it's just elsewhere.
Funniest experience I've had with this is paraphrasing someone almost exactly in a reply to check I understood, and emphatically being told that was absolutely not what was being said.
1. people aren't talking to people
2. people aren't listening
I don't think this is right; I think the reason is - to use the metaphor from the cartoon image at the top - that what most of the people involved in the not talking and/or not listening were looking to get out of the situation in the first place was the ribbon cutting, not the road, and they got it.
I think it's a mistake that such people often stop even listening to those who are less well-read or less experienced in a subject; they prefer to adopt the position of the 'source of truth' and the teacher. Although, it seems to me that people who are less 'biased' by extensive reading often come up with original—perhaps unpolished, but original ideas. To hear those ideas, you have to know how to listen and extract thoughts rather than suppress them."
Totally understand, but I would love if the author included links to these other things for articles/etc they thought did a good enough job not to repeat them!
> Totally understand, but I would love if the author included links to these other things for articles/etc they thought did a good enough job not to repeat them!
I believe the author identified the primary remedy in the article:
The problem isn't that you need a better system. The
problem is you're avoiding doing the work.I'm so sick of it. Comunication is a tango. If you - who need the product and are ready to pay for it - don't take your damn time to effectively articulate what are your needs then you should go to school again and learn it.
By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?
Bring on the down votes.
I see UX and usable documentation as among my responsibilities as a developer. It's not that I "blame" myself if the documentation is confusing for a user, it's that I say "oh, that's a documentation bug". And it's my job to fix bugs.
Instead they will go and buy a product that was made by engineers who asked them "what they actually need" and "how can we make it easier for you".
It's not about "why should I always care, I have enough". It's about "who will make better product and earn more money".
> By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?
They are good at socialising, blurting out words at each other and they think it's good communicating (it's emotional reassurance of eachother, not a technical facts exchange, but it's still their valid need), but when you say that to them, they are upset and don't want to buy a product from you. Don't tell that to their faces. Of course, if you want to do something and don't want people to buy it, do follow on what you wrote.
Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?
Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options? Was it because they sell one thing and didn't even know there are other options? Did you even ask what options you have or did you just order the thing?
Communication is damn hard, again.
Yes, but it is necessary to achieve better results.
> Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options?
That's bad communication from both sides. Having good information on each of the sides leads to better communication. Client with better communication will have better results for himself. Seller having better communication will give better results to his clients. Worse than his average to clients with bad communication, better than his average to clients with better communication. But his average will be higher than average of seller with bad communication.
Sellers with better communication will provide better service and will attract customers. Sad corollary: he will also attract a lot of customers with bad communication.
> Was it because you didn't know what to ask for?
Yeah, when I don't know what to ask for, I search for expert who will know what I should ask and will help me with expanding my knowledge of the options.
> Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?
Yes, I speak from experience of such moments.
> The thing is, neither the software engineers nor the users know wtf should be done completely.
It's easier and more effective to educate a small group of software engineers than a lot of users, that's why engineers SHOULD try to communicate better.
> Communication across domains is hard.
It is. But the expert has typically to communicate across one domain, his own against "no_domain". User would have to learn to communicate better or become domain expert in a lot of different domains.
> Yes, I speak from experience of such moments.
And did you actually look for an expert or did you just get something from Ikea? Do you even know how to identify an expert furniture designer?
One of my points is we think we're damn unique but we aren't. And my example has us as customers.
Real world example: I was in $RANDOM_HOTEL last month. Now I want to redo the attachment system for all my curtains in the house because theirs was smarter than what I knew to ask for.
Sorry, but I don't see the point of your comment.
I looked for an expert who helped me with expanding my options. Expert != "will sell his exact product he is trying to sell in the place he is working at". Sometimes as an expert you even have to advise a client against your product, because he will try to use something not designed for him.
> I was in $RANDOM_HOTEL last month. Now I want to redo the attachment system for all my curtains in the house because theirs was smarter than what I knew to ask for.
But did you look for an expert? Expert might suggest a better alternative than you currently have, but you gained information yourself by accident. If not for that happy accident and you being observant, you wouldn't know.
The whole idea is I'm trying to place the "expert" software engineers in a position where they're not the experts to make them understand their clients better.
> and you being observant
OT: How many other great home improvement ideas have i missed because i wasn't observant enough?
Edit: or is it really off topic? Will the customer of the software engineer research, say, all possible database solutions or, even assuming great communication with the engineers, just pick a good enough one from their combined knowledge?
That sort of decision making is not done by engineers. You are blaming engineers about product decisions made by management, product management, UIX design, analysts ...
Engineers should have better communication skills, but if the whole weight of communication is put on engineers instead of people hired to actually be responsible for this, engineers will be burned out.
Thank fucking god someone who understand it. Sometime I feel an alien listening people bitch about engineers. A product is not just the result of engineers.
1. Can u add X 2. Can u change Y
Without understanding cost of doing all this. Yes, i can do all and everything you ask for, but each action has a cost, which you fail to understand.
We cannot do everything if we need to launch a reliable product.
The customer doesn't need to understand how the solution works, as long as they can understand that it would solve their problem (in the case of the power plant: producing "clean" energy) and any potential drawbacks or limitations (in the case of the power plant: the waste byproduct).
The point here is that as a "tech person", it's your job to help the customer understand the cost of what they're asking, and come up with a satisfactory solution based on your understanding of their needs.
> We cannot do everything if we need to launch a reliable product.
Agreed, otherwise it would be Turing complete Excel/Email clone.
A good article about the costs of not listening to your customers would be useful.
Talking to a 'yes and autocomplete' that will agree with everything you say and praise it as a "Great idea!" will make everything terrible
(Procrastination, Red Dwarf reference)
Lol on this one. I mean, yes, it is true, but also funny.
You know, I was actually hoping for a good listicle of things to watch out for in meetings. The author should take their own advice. Assuming bad faith immediately kills all productivity, so there's no point in finishing reading this.
I agree with the general notion that there are often knowledge gaps getting in the way of better planning and execution. I was hoping for techniques to overcome them, but (sigh) I guess that's just more "engineering" getting in the way.
I've been doing this for long enough to realize there's no substitute for experience. It's basically the opposite of all the popular advice. If you're serious about any successful long-term career, you can't avoid looking foolish and having lots of difficult discussions. There are no shortcuts. There is no "higher path" you're missing out on. If you're going to grind it out, at least save face by working at the "shitty places" with bad reviews on glassdoor where you can safely fail without damage to your ego or reputation. When you finally get hired somewhere nicer mid-career, you can just bury all that in your mind and pretend it never happened. Nobody cares anyway.
If we're going to be judgy, I gotta say some of the worst people I've ever worked with never got out of that phase. It's that simple.
This was too absurd and hostile for me to continue listening.
I asked myself whether I thought the author was bad at writing, and realized I fell into their trap.
I asked myself how lost and angry someone has to be to write crap like this, and realized I did it again.
Some people have a real knack for being so defensive and insecure that they invite their own pain. They unwittingly coerce people who meant them no harm into doing so. Everyone is a victim for trying to take this blog post seriously.
First, the author is not assuming bad faith. They are saying that judging people is common pitfall. And the "hating or dismissing people for misunderstanding the thing you documented badly" is something I have seen done so many times, that yep, it exists.
But second unrelated thing is, sometimes there is a bad faith. Refusing to accept that bad faith situation can happen just makes it massively harder to solve the issue. It empowers the person acting in bad faith.