Not gonna lie, I've had the PR issue before.

The solution? Blast the PR into your shared slack noting that it isn't being reviewed on time because maybe XYZ person is busy.

Watch how fast they are suddenly free to review when their name is attached to something in public.

The real solution is to simply fire these people. There is no good excuse for ignoring requests repeatedly besides laziness or self importance.

I believe that some of this is differences in communication style. I like written communication because I don't process verbal communication as well. But I've also had plenty of colleagues who are more comfortable with verbal communication, and may not process prose as well. Many of them seemed hesitant to believe they'd fully understood something until they'd had a chance to talk through it to confirm. And, yes, needed verbal prompting in the same way that I tend to need written prompting.

The most functional workplaces understand and respect these differences and make room for everyone's communication style.

I can see where this can be abused. (The PR review example is pretty rough!) I can also see where it's a strategy for triaging which tasks are a priority.

I've had projects presented to me over email that sounded great and seemed like they would have good traction, but then fizzled out once I asked if we could discuss it further in person. Blocking off face-to-face time is a signal that the work is important enough to get done.

100% agree. Most of the time, when I hear "this could have been an email," it's from someone with a track record of not reading (or writing and responding to) emails meaningfully.

How you asked them why?

It could be more productive than being angry. Or not, but worth a try.

They sound like poorly run companies, management should be aware and dealing with both of these problems.

> * When faced with some well-written, succinct email/text explaining both a problem and supposed solution, will "respond" with "let's discuss this" instead of an intelligent response, taking action as proposed, or even mentioning any particular concerns to be discussed / researched ahead of the meeting. They just need it to be spoon fed to them, and need to be "heard", before anything can happen.

You hit the nail on this, a lot coming from middle managers too who still think that a busy calendar of these meetings it means they are very productive. I remember a manager I worked with, he was so keen on having meetings, a discussion between me and a colleague and he overheard it? Meeting to discuss “the conflict”!! It was soul crushing experience thankfully i left quickly, only to know later he started having meetings for meetings, so in those meetings they discuss what they will discuss on the other meetings!

Also, there are some other sinister reasons, an email is an artifact that can be traced and searched, a meeting usually is just verbal communication and even meeting minutes get challenged later.

Email chains can fail to converge. Yeah, the meeting could have been an email, but what if it was going to be 20 email back-and-forths? And not everybody is responding quickly?

You ask three people what we should do about a problem. They float ideas. You think the discussion is converging on a solution, and then one of them (who hasn't been heard from for the last three days) suddenly protests where the group is going, saying that they don't agree at all, that they have several concerns, that nobody talked to this other group that needs to be consulted, and so on. Then for that other group, nobody responds for a week because they're busy on something else.

A meeting can force people to say what they have to say, now, or be ignored. That forcing function has value.

And it's not (just) that "people refuse to do anything". It's that multiple people, doing things asynchronously, on different time rhythms, sometimes means that the group consensus advances v e r y s l o w l y, if at all.

I've faced this same PR problem. Something is very wrong with a software development process when one developer can halt forward progress on the repo by simply ignoring PRs. One solution I've thought about is to automatically accept any PR that sits idle for 48 hours without comments or modification. After that, the reviewers lose the right to complain. If some nasty bug is later discovered, that's what git bisect is for.