In person, it's somehow easier to tune the office chatter in and out as needed to keep track of what your colleagues are up to. I have yet to find an electronic replacement for this phenomenon. Email, if nobody thought to CC you, you simply won't find out. If people deal with this by defensively CCing everyone, you drown in email. Slack's value is inversely proportional to its uptake: The more people talk on it, the more it resembles a sort of workplace Twitter where it's simply impossible to try and keep track of what everyone is saying, so you give up and resort to only looking at it when you're trying to slack off. Threads attempt to work around this by replicating the problems of email in a chat app.

I suspect that an old-school web forum like phpBB could work well, but any technical merits won't overcome the social perception. There's just no getting around the nerd factor there.

The only technique I've seen work well is the manager-as-dispatcher approach. This poor soul becomes the designated firehose-drinker. They get CC'd on every email, and they subscribe to every Slack thread. They keep an eye out for anything that Sam or Pat might want to know about, and check in to make sure that Sam or Pat is keeping an eye on it.

This is miserable for everyone. Don't make Slack the center of your workflow. Don't let spontaneous Slack chats dictate your process.

The manager's job shouldn't be to scour Slack for information and then ping every person who might need to participate in or read each conversation. That just amplifies the noise. It's terrible to be deliberately ignoring Slack for 30 minutes to focus on work, only to have your manager ping you back into Slack to make sure you don't miss something.

Instead, the manager should be forcing important conversations to happen outside of spontaneous Slack conversations. If something important is decided in Slack, the decision needs to be recorded in the tracking ticket, Wiki, or other important location. If it changes anyone's active work, they should be interrupted. Otherwise, they can pick up the information from the single source of record (ticket, wiki, etc.) rather than being expected to follow every detail of Slack all day.

Small groups working on tasks together should have private PMs or channels to discuss implementation details, not giant Slack channels with 10s or 100s of members.

A good manager will avoid design by committee and will stay ahead of the spontaneous Slack firehose by arranging planning sessions and scheduled meetings where necessary.

Don't let the Slack chaos drive your workflow. Don't try to make managing Slack someone's job. Manage the workflow first, deliberately rather than reactively. If important conversations are happening spontaneously in Slack too often, that's a sign that you need to fix your workflow.

My working hypothesis here is that, when there is someone that the team trusts to do that, it will ultimately reduce the level of overcommunication and design-by-committee. Everyone feels more comfortable focusing on their immediate work, and limiting their active participation in things that don't require their active participation, because they know they'll get the memo.

In some ways, having the manager buffer up the pings is even worse, because then each person has to revive the topic again if they want to have a voice. People don't want to be left out of important conversations, so the only solution is to watch Slack like a hawk all day. The people who spend all day in Slack instead of doing work end up dominating the decision making while the people who focus on work suffer.

Instead, don't hesitate to gather people for a scheduled call after lunch, at the end of the day, or first thing tomorrow morning to clear it up. Record important decisions in a single source of truth that isn't Slack, like your Wiki or ticket tracker.

Treat Slack almost like you would in-office conversations: If you have a spontaneous watercooler conversation about an important topic in-person, you wouldn't go gather everyone involved to come to the watercooler to continue the conversation. You'd send out an e-mail update to others who need to know. Or you'd scheduled a follow-up call or meeting to discuss it.

The in-person rules of communication and avoiding interruption are a good template for how to behave in Slack.

This sounds great in theory, but one of the key issues with managing remote teams is there is no common time in the day that is "after lunch, end of day or first thing in the morning".

The reality is most remote scenarios require you adopt at least some async process; fighting this is a losing battle.

Some good news: your manager's job was always facilitate internally and protect externally; how this is accomplished has certainly changed but the core essence of management, if anything, is even more crystallized now.

Also, async is one thing. Respecting your peoples time is another thing. Slack, etc can show you what time it is in that employees time zone. How do you feel when the first thing you do is open Slack while sipping coffee and eating your bagel and your boss has 10 messages to you from 6am-9am your time?

Probably not the best start to your day. Let people log in, socialize, be humans and colleagues for a little bit before you hammer them, especially now when work is the only real human interaction some people are getting.

Feels like it’s a day that ends in ‘y’. (My boss and our team get along famously and are all in the same time zone, yet have loads of traffic on our channel(s) between 6 and 9 most days.)

Right now, most async communication processes (like status updates or daily standups) involve a ton of manual effort to make sure that people share this information.

I strongly recommend creating systems and using automation as much as possible here.

The best managers know what the appropriate communication channel is for their employees and the issue at hand, and I don't think any strong managers are going to point to Slack pings at their preferred method.

Just my anecdata; this is the polar opposite of what I want. I do not ever, ever want a meeting or a follow up call over an async slack message unless it must be a meeting.

Some managers really need to talk to their engineers and see what the engineers need to perform best and not make every assumption based on what they, the manager, are used to from the last 10 years of their career at 1-2 places.

Forcing a square into a round hole makes engs leave and I've worked for a lot of managers who feel like they stopped growing a decade ago or are using outdated ideologies because the people who promoted them are so far away from the real people creating the sauce now.

There is a balance between them. I think where you draw that line largely depends on the team. An effective manager navigates a team by helping to unblock and de-risk efforts. It's hard for a manager to do that with zero information.

I used to be very bad at that. Now I'm pretty firebrand for employees to be treated right as I've finally been to companies that I felt did so (then back to companies that don't) so I recognize what I consider abusive places/mgmt pretty quickly.

That's really my point, some of us work completely differently. Ask your engineers how they can perform best..

Slack is good for chat and quick discussion.

https://zulip.com/#tour-carousel

What people really need when remote is a way to help create and automate a series of communication habits/workflows, so instead of hunting around or perusing Slack to understand what's going on, the information flows to you. Like a series of communication pumps.

Right now, most managers manually collect this, which is an epic waste of time.

Self plug, but after 8 years working remotely and constantly running into the workplace chat firehose, I've built software to help automate any routine update at work (https://www.friday.app).

It comes down to structuring some type of process for facilitating communication rather than being reactionary.

Spontaneous conversations are going to happen and should be encouraged, but Slack is not a platform for documenting a decision or conversation. If for no other reason than it’s not concise. Coming back and trying to parse an hour long slack convo is a waste of time when it can likely be boiled down to a one paragraph summary.

If something interesting happens I find it helpful to take that opportunity to get the gist or decision documented in a ticket or wiki page somewhere for easier dissemination and for centralizing further communication and decisions related to the topic.

A great point. They will ideally also have enough context, experience and intuition to 'individualize' comms - providing detail from an earlier briefing to the ux person while omitting the unnecessary technical details that are more relevant to the other team mate who is working on a security feature.

As a team lead, I do subject myself to a bit of a firehose outside my immediate team in the hopes of stumbling across little nuggets of useful info and context, but if I orchestrate communications within my org well enough, that's the only time it occurs.

It’s funny that you say this, but at Automattic (where I work), we use a tool called p2 [0] which is built on WordPress blogs. So it’s basically a blog with real-time comments, and each team/division has their own p2. As our saying goes, “p2 or it didn’t happen” — and it’s probably the main thing that keeps communication healthy. It’s easy to follow the set of blogs applicable to your work, easy to cross-post to other blogs, it’s globally searchable, and easily sharable. Thus it avoids the problems you mention with email and slack. We use slack a lot as well, but few use email at all.

Like you say, it works because everyone buys into it and uses it.

- [0]: https://wordpress.com/p2/

It seems like one of the great tragedies of tech is that the kind of personality and temperament that would predispose a person to being able to genuinely enjoy this kind of work probably also tends to greatly diminish that person's chances of ever being promoted into a position where they'd be asked to do that kind of work.

Slack was a disaster for us when we last tried using it. Several people muted it for hours at a time, the only way to get someones attention was to call. By which point it was probably important enough to warrant a call.

Our theory is that for people to be able to focus on work for reasonable periods of time you need good async communication. And for that need good sync communication for where it's appropriate. We've been using whereby.com for video calls, much better than zoom. This is where we all checkin and Sam/Pat find out what the need to keep an eye on, and then they can start a thread on plum mail for the content they need to keep track of over time. One of the favourite features we have build from a manager side of things is the following. A manager can join a conversation, but then set the notification level to be only notified when a conversation is resolved, i.e. they find out the conclusion and can see the history if they want, but the aren't distracted by the discussion towards the conclusion

What's worked for me is 1-on-1 meetings with each team member each week. We set strategy for high level goals (e.g. a quarterly software release), measure progress, and I let them know about work other folks are doing that is related. I trust them to use slack/email/phone to get the work the done, and I don't closely monitor those channels.

Doing 1-on-1s is a lot of meetings, but I don't think as a manager you can avoid that work and still move effectively towards a larger common goal. Eventually though, a lot of people learn to execute more complex and valuable work, they get promoted, and then we meet less. But then there's hiring. The cycle continues.

I'd be interested to know how folks who have 2 layers of reports learned to work effectively with that size setup.

You should be collecting agenda items all week by listening, and then discussing them during the meeting.

Also, waiting for the meeting and sharing information live is both laggy and a waste of face time. Share the info in advance, and ask for follow-up in meeting if needed.

So, how do we "sell" forums to our friends and colleagues without them knowing they're using one? :)

If forums are inherently useful and the issue is just perception, then this sounds to me like a design question.

Don't get me wrong, I miss the style of conversation predating social media, but I think that if the reason was purely perception based, we'd find a solution. Think of any annoying, seemingly useless, or just impractical rituals we follow every day.

Forums provide a much better signal vs. noise ratio due to its async nature and increased effort required to submit content. And, that's great.

But, it's also terrible, because most people just won't bother putting more effort into written communication. This is too much friction. This isn't how we talk any more. And, I think that's the main reason why forums are not mainstream.

or yammer are good options for async communication approaches w/o the need for defensive ccing

A flashy new version of AIM is popular, a flashy new forum could be too.

I think the difference here is that forums were popular for communities where people were active at different times, while chat was real-time. For in-person offices, things then trended after the physical real-time nature.

If people stay more remote after this, though, and time zones are less uniforms, I think that's ripe for a change.

If someone replies to someone else's message in a thread and it scrolls off my view, they could have a 50+ message conversation in there that I would never see.

In a "traditional" forum, if a topic is that hot, it'll stay on top of the topic list. Even in a more threaded forum like HN, where ordering is done separately, when I refresh, I'd see there were more replies on a hot sub-thread, in a way that can disappear entirely in Slack.

Someone needs to do that job, but it doesn't have to be the leader. It's an admin job. In non-combat military units, sergeants do that.

This can be alleviated by aggressive threading

Competency was probably the most important trait. A boss without a clue was easy to dupe and avoid, but also a pain when you were actually doing plenty of work. A boss that knew what was what would be on your case if you slacked, but also super relaxed if you were producing to expectations.

Clear communication was also critical but it was even more important to be measured in the volume.

Very true. We struggled with this at a past company. Most engineers were inherently honest and hard working, but maybe 1 in 5 were constantly playing games to convince their manager that they were working harder than they really were.

Managers who were formerly engineers had no problem spotting this. It was the managers with non-technical backgrounds who struggled to gauge if their employees were really working hard.

My workaround was to coach non-technical managers to pick up clues from the person's peers. If you privately ask 3 random team members to estimate tasks and 1 person constantly gives estimates 10x longer than anyone else, that person should be watched closely for performance issues.

It also helps to group people together to finish tasks, then ask each of them how it went in private direct conversations (your schedules 1:1s). The person's honest peers will give strong hints that another person isn't pulling their weight.

Trust your employees until they prove themselves untrustworthy, but be careful. We had at least one confirmed situation where a remote employee took another full-time job but didn't quit our company. Instead, they worked on doing the bare minimum to keep their manager satisfied so they could collect paychecks until we were forced to fire them. I suspect this play will become more common now that WFH is on the rise.

So I had a boss who would call a group meeting, bring up a problem that needs to be solved, and ask people who can do it. One engineer would explain that this is a research-level AI problem that would take years to solve, another engineer would say he's going to have some time to hack on it later in the week, and a third would say that he can pull an all-nighter tonight and solve it. So the manager would pat himself on the back for a job well done. He created a spirit of healthy competition in the team, he exposed the slacker (the first engineer) for what he is, and he squeezed the third engineer for all he got. A year later, the team would be back in the same place, with the manager calling a meeting and bringing up the same problem, which as it turns out the users are still suffering from and higher-ups in management are pestering him about again.

I thought the third engineer pulled an all-nighter to solve it?

There's a habit of technical folks to come to conclusions they shouldn't, and this is a perfect example. It generally manifests itself in interviews where the technical interviewer will come to conclusions that don't necessarily follow, only in this case it's not in an interview, but with respect to fellow co-workers.

I mean, you can see the hubris in the poster, who would have you believe that they're somehow "training" their management to "spot poor co-workers". Yeah, ok.... sure you are. Because managers are like monkeys apparently?

That's some dark humor, there.

But in terms of "exposing" how many managers in the industry think -- so true, so very true.

But apparently, this is in the opposite direction of what you are talking about. That said! If I were to pad my guesstimates, then it could legitimately look like sand-bagging. I don't know that there are any easy answers. I am trying to become more accurate (if for no other reason than not having to work over Christmas holidays to keep up with my promises), but estimation is hard!

An interesting experience is to estimate things in your own life. You plan to do something, write down when you expect yourself to finish it. It is quite humiliating to notice the effort you put into convincing yourself that you are more productive than you actually are. Unlike with job, you can't make the excuse that impressing other people is a good strategy. Yet, it can take a lot of work to stop doing that.

2hrs === 4 days.

A week == 2mths.

Anything past that would never get done.

He was a cynical bastard but not a bad guy and sadly he was in a lot of dysfunctional environments not that far of the mark.

The golden rule of estimating is to measure past estimates and use them as a multiplier in future.

The platinum rule is to stop estimating because it's useless.

  20*2*1.2 = 48  
  20*2.2 = 44 // I, also, was confused myself at this point  
  2 *1.2 = 2.4 // not 2.2

If a manage doesn't pick up on it early enough, then shit will eventually hit the fan.

e.g. there probably wasn't video chat. So how did you communicate? Were you coding? What were tooling like for coding remotely back then? etc etc

I worked at the end of a Telebit Trailblazer, so I had a 19200 baud link to the internet. I remember emailing myself GCC - staged the tarball on a remote host, uuencoded it and sent it home as multiple email messages.

We mostly did stuff via email, with the occasional conference voice call. I had to learn to restrain myself and not try to solve user problems when I first saw them - because of the distribution of time zones, I would tend to be the first person awake.

This was definitely coding - we were selling and supporting Interlisp-D and its many derivatives.

When I worked for other people, management spent a lot of time with requirements and specs before implementing, which often resulted in mismatched software expectations. Agile gets poo-poo'd now, but it was a revolution at the time

When I was doing my own consulting, I always did my best to find local clients for remote work (often building e-commerce web sites when the competition was still using FrontPage) because it was preferable to be able to call the client or meet in person to discuss the inevitable requirements snafus.

Honestly, it doesn't seem that much different now. Humans are generally not all that great at communication. The tools we have today make a dent in that problem but there's still significant unresolved challenges.

When I'm leading teams, I tend to spend a lot of time on teaching people to communicate more effectively and creating processes to enable it. It makes things go more smoothly than trying to be the central hub for all communication.

Remote also feels more empowering should one encounter a bad manager. During my WFO days I had a boss who berated me privately and publicly; even in front of clients. It was humiliating and destructive. Only when a more senior (by age, not rank) engineer finally rebuke them did the situation improve.

To the parent's point: 100% agree, you essentially need a different style of communication. Has to be more explicit and include some built-in check-ups and dates. It's easy to pop in and see if someone is frustrated, a lot harder to see them failing remotely.

Ironically I think the hardest part is not internalizing the temptation to be an ass to others. Maybe if I had called them out on it myself? IDK.

On the flip side I can say after 5 years there I never once referred a soul and in fact helped many get jobs elsewhere and have pulled friends out of them when I could.

Can you provide an example of this and whatever the implicit alternative is?

"Ok, so action items from this meeting are:

* Bob, you were going to investigate bug foo and circle back tomorrow.

* Alice, you had an idea that you were going to explore, please let us know when you can deliver that."

Implicit:

"Great meeting folks, see you tomorrow".

[Next week]: "Bob, did you investigate bug foo yet? What do you mean you thought Alice was going to do it, I asked you to!"

Often in person communication can be rushed if it’s between meetings when someone has a few min to drop something on you. If you don’t have time to write it down or ask follow up questions, the ability to deliver the right thing is going to be limited.

When we’re remote, almost all delegation is either conducted or followed up in async text. This means you have something to refer back to as well as a thread to ask questions without having to find free time from the other party.

People move jobs a lot in the tech industry, so as a result senior roles are often filled externally. It helps to have a recommendation, but roles are rarely filled by asking the team who they would most like to work with an approaching them. Normally companies advertise roles and try to use some kind of standardized process. So CV writing and interview technique are critical.

Promotions often happen because people apply for the role up when it is advertised competitively. My observation is that people succeed at this by focusing on performing against their current objectives, not being a problem, requesting training, and picking up the tasks relevant to their current role that will be on the job description for the next one up. That next role up might be in another team so your own teams favor matters less. The main thing is not to have been a problem to management and to present yourself well during the application process.

I think external upwards moves are more likely to be powered by skill at believable exaggeration, and internal promotions by rules compliance and consistent ambition driven box ticking.

Finally, some people get promoted because management need someone they trust to do that job now, at least temporarily. This happens when a new project team is created and someone is told they are in charge of it, or someone quits and their duties are reallocated to an immediate report. These reward competence yes, but such a people keep their winnings or fall back by their actual short term success - if things look shaky management go out externally for a permanent replacement and quietly put them back where they were.

I don't really see any of this changing due to work from home.

It is probably different at high levels of management because these roles seem to be filled more based on relationships.

Leave someone off the invite, have side-bar convos via slack without people knowing, mute people in calls -- and being the loudest, pushiest person in the room absolutely works on skype if the meeting presenter won't mute you.

Remote working does remove some of the rapport and chemistry from relationships, which is regrettable, but on the other hand it also reduces the ability for people to 'dominate the room', intimidate, etc.

These kinds of people are sometimes intellectual giants, but very often simply bullies.

But I find well-aimed questions can often derail attempts to railroad a situation from a position of power, and it can be very uncomfortable to field those questions in an in-person setting. Much less so remotely.

No matter what, some group of people is going to be at a disadvantage. It doesn't really make sense to me that you want everyone to specifically cater for the minority, as opposed to the majority.

Trying to somewhat accommodate everyone? Great. Forcing changes to accommodate minorities? Doesn't really make sense to me.

1. Fully abled people are already, as John Scalzi put it (with regard to another category), playing on the lowest difficulty setting, across all of their lives. SO I think it's not so bad to take away some advantages, to level the playing field.

2. There are different kinds of disadvantages. There are disadvantages from skills you haven't yet learned, and there are disadvantages from abilities you can never have. What I propose is to replace the latter category for some people with the former category for others. Of course, if biotech someday allows us to give physical abilities to people who don't have them, that changes the equation. And perhaps my thick accent example was weak; my understanding is that it's possible, with great difficulty, to change one's accent.

I have seen people suddenly develop this trait on amphetamines, but ruining your health by abusing amphetamine to have charisma isn't a great trade. This observation does make me wonder if it doesn't have something to do with dopamine levels/sensitivity and whatever other systems amphetamine acts upon. People with bipolar disorder can be superhumanly charismatic when they are in a manic phase, and moderate to heavy amphetamine doses more or less approximate mania (in people without ADD/ADHD).

Like height and facial symmetry it's a trait that is unrelated to the content of one's mind but heavily biases people toward you in one on one interactions... regardless of the merit of what you're actually saying or doing.

The different favorable trait would then have effect on the productivity, though. Asynchronous communication is way more friendlier to deep work like programming.

I don't know if I'm talking too much or if they are bored. Online I'm quick/short.

That said, I enjoy being a tech guy over a leader. I tried leadership in done personal business and I don't like playing politics or psychology tricks.

Yesterday, though, the pictures editor made a masterful choice.

https://www.bbc.co.uk/news/health-54088206

https://journals.plos.org/plosone/article?id=10.1371/journal...

https://www.scientificamerican.com/article/should-you-wear-m...

https://www.sciencedirect.com/science/article/abs/pii/S01674...

https://www.researchgate.net/publication/299431552_The_Impac...

Just because you or I may not get dressed up ... my wife certainly does.

> actually dothe work of gettingprojects done

This research isn't based on what's happening in the real work world, with real workers, in real companies. After reading the summary, I'm having a hard time giving this much weight.

> The researchers conducted a series of in-lab experiments with 86 four-person teams, and also traced the communications and experiences of 134 teams doing a semester-long project in a university class

The original WEIRD paper contrasts the industrial societies with small-scale ones. Can we even find small-scale societies that do virtual remote work?

You could also see how it works for Canadians, Indians, Chileans, Thai, Russians, Nigerians... all have developed enough economies that there are at least some remote workers.

https://www.cambridge.org/core/journals/behavioral-and-brain...

Wisdom, Emotional Intelligence, Initiative, Robot, Dastardly or something like that.

1) Is anyone who does have the context able to weigh in?

From my own digging I'm not seeing a lot of agreed upon definitions of "leadership emergency theory". I found one paper [1] which I read the abstract of. It again, like the OP, seems to talk about how "leaders emerge in teams that lack a hierarchical structure". From my experience this doesn't seem incredibly useful given all managers/leaders I've seen have been appointed by someone else. It's not some subconscious, democratic process where they're chosen by the group.

2) Kind of meta, but did the writer of the article do the research that seems necessary for this? And if not is this acceptable, given that I can only assume numerous people will take this at face value and may even make organizational changes as a result?

[1] https://www.emerald.com/insight/content/doi/10.1108/LODJ-08-...

There's no reason to assume that, and millenia of history to the contrary. If leaders were mostly good at leading, organizations would rarely fail.

To be stereotypical, I'd go ahead and assume that a majority of people on HN work in tech and likely are paid a decent salary.

The one thing I find in bad leaders (remote or otherwise), and relational in poorly run companies is the lack of trust.

I've worked with leaders who micromanage as much/more than I was when I worked a minimum wage/high supervisory job. This is bad and holds back many employees/companies. It encourages "shared courage" and centralized decision making.

I'm usually amazed at how much responsibility people are given who make over 6 figures, but yet how little decision power they are given. Even when the leader may not have the same knowledge level as their employee.

I've had the pleasure of working with many people who respect that I know how to manage my time, that I know things they don't, and the understand that I appreciate the same about them.

I can imagine how much the "wrong" side of this is amplified when you suddenly aren't around each other all the time.

It's an interesting distortion of the inflated tech-skill market I think. I have individual team members doing software who are paid more than entire group leaders doing other things but they are still very immature, and in no way can accept responsibility for more higher level things.

I do agree about the responsibility / decision power point though. To me one of the most powerful motivating forces for tech people is giving them autonomy to make technical decisions themselves. It's somewhat tragic that this is so negative in the large - allow a whole team of engineers to each choose a different web stack and they'll love it, but you're in for a disaster.

One wishes. That almost sounds too ideal to be true.

EDIT: I'm glad it has now been edited to be more sensible.

Managers bias towards taking an overly hands-on, interventionist style, because that creates a lot more visible signals that they're not easily replaced. There's no incentive to build a well designed process that the team's empowers self-driven success. As often happens to programmers, that type of manager often finds that he's engineered himself out of a job. Much better to create busywork, lest senior executives start asking "what exactly would you say you do here".

What often separates out great senior leadership is recognizing the pernicious influence of this bias. John D Rockefeller was famous for having tons of middle managers who barely worked at all, took naps in the afternoon, and the like.

I know it's been almost 4 years but I still have a hard time grasping that I'm not on The Onion when I'm reading sentences like this...

"Table 4 – Correlation of Development Phases, Coping Stages and Comfort Zone transitions and the Performance Model" in "From Comfort Zone to Performance Management" White (2008) tabularly correlates the Tuckman group development phases (Forming, Storming, Norming, Performing, Adjourning) with the Carnall coping cycle (Denial, Defense, Discarding, Adaptation, Internalization) and Comfort Zone Theory (First Performance Level, Transition Zone, Second Performance Level), and the White-Fairhurst TPR model (Transforming, Performing, Reforming). The ScholarlyArticle also suggests management styles for each stage (Commanding, Cooperative, Motivational, Directive, Collaborative); and suggests that team performance is described by chained power curves of re-progression through these stages.

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C43&q=%E2...

IDK what's different about online teams in regards to performance management?

when that status quo slips away, it exposes those who were merely charlatans acting the lauded part (putting on a good facade face while lacking depth in teh actual capabilities society and organizations rely on, simply fronting a good appearance)--the changes uncovers those who failed to put forth the front out of ignorance of or disdain for it. it raises those whose true strengths mattered more all along, but to which broader culture was blind to, having long lost its way tacking too hard towards praising the facade, assuming it implied the foundation

fires burn away some moss; the hardwood remains--it was always there, but now we get to see it, and further see that some of the most elegant fungus was naught but a large clump of mold growing upon itself alone, without much underneath

a venn diagram of good leader qualities and charismatic qualities has non-trivial overlap. A leader lacking people skills has a very limited ceiling in what he/she can affect.

Just because the physical connection is gone, it does not mean a robotic / formulaic approach is now the only way to lead/manage humans

Nobody is suggesting 'robotic' or 'formulaic'.

Charisma does one thing: Make other people work for you and let you steal their output and take credit for their successes.

The leaders of the successful Asian tech nations don't seem that charismatic, but rather competent and intelligent. The West should take note.

And in two companies I worked at, the minute a charismatic, clueless bureaucrat swaggered in, took over the orgs and started barking orders (in a polite and charismatic fuck-you way), all top developers left, as if by magic.

Does that happen 10% of the time? 30%? 60%?

If virtual work reduces that effect, its all to the benefit of the workers and the work, in my view. It seems a slam-dunk.