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.
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. Cut all the unnecessary meetings and only allocate the minimum viable time to communicate. Then everyone will be listening.
I’ve been in so many meetings where the outcome is to plan another meeting, and include even more folks. Whichever team brings the most folks steers the decision in their favor, and thus manages hire more unnecessary employees for political will (which then increases the need for even more meetings).
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.
Maybe this is just my interpretation but OP effectively argued "too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".
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 much time is spent attempting to communicate and as such, communication isn't actually happening.
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.
For example, if a project kick-off meeting consists of the highest ranking managers talking and everyone else having no contribution, listen to what they are saying; their "vision" is all that matters.
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.
I don't think "attempting to communicate" - or especially not "attempting to LISTEN" as in the title here - would be the stated reason for many meetings. "Pitching people on your shit" or "making sure shit gets done the way management wants it to" is much more accurate for most corporate dev and B2B/B2C sales/product meetings.
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...
>And if you're wondering why this happens, it's normally because:
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.
Agree with the problem but this list reads like a vent.
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 systems and engineering are reached for. 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.
> Tonnes of frameworks around this concept, so I won't repeat what others have done decently already. Jobs To Be Done, Outcome Driven Innovation, and in the UX camp, empathy mapping.
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!
>> Tonnes of frameworks around this concept, so I won't repeat what others have done ...
> 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.
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.
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.
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 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.
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.
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".
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:
For example, if a project kick-off meeting consists of the highest ranking managers talking and everyone else having no contribution, listen to what they are saying; their "vision" is all that matters.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.
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...
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.
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 systems and engineering are reached for. 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.
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:
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.