Shopify tells employees to just say no to meetings
bloomberg.com
bloomberg.com
I won't comment on the merits of this at large, but it was annoying for me at the time because I had several recurring calls with external partners, which were all summarily axed. The bot didn't discriminate between meetings with 3+ Shopify employees, or 1 Shopify employee and 2+ external contacts. Hopefully they fixed that this time, because it was embarrassing having to explain to partners why all of our recurring meetings had gotten deleted.
What about when you are working on something but you also message somebody on Slack/Teams a question and they instantly hit you back with "hey, instead of talking through it on chat, let's both stop everything we're doing and join a call"?
By all means, I get it that sometimes (not sure how to measure it/what the answer is) it's quicker to "bite the bullet", hop on a call, screenshare, etc.
but it does seem almost like a communication style preference. some people are super quick to want to jump on a call no matter what. and then the question becomes does it "impede" those whose communication style is not to jump on a call. it's like "rude" to say "i'd prefer not to jump on a call with you", forcing them to go from "call communication style" -> "type communication style"
it really makes me wonder if some people are on 1 on 1 or small group calls basically 4+ hours out of the day (by choice. not scheduled meetings or on call incidents)
I think this misses the point. How do you navigate this if you never want to do the voice call and always just handle it over text? I'd have to lie (every time they want to call me) saying "I'm busy". It's like you accepting the call is insisted/expected.
I'm talking about preferring to never do a voice/video call.
That would drive me crazy.
I think you'll have to accept that somethings have to be face to face. And some companies prefer to do things that way.
I guess you adapt or go to a company that can guarantee you'll never have to speak to someone at all.
But face to face is the oldest form of human interaction. Its going to be hard to get along in the real world if you really don't like it.
I'm trying to imagine how you'd do something like a lay off over chat or an interview or a performance review? That just seems like living life on the hardest possible mode.
I for one prefer actually face to face, then text chat, then voice chat, video chat never. Screen shares are almost always a signal that this call will be a huge waste of time, but I suppose it’s fairly necessary if you insist on voice chat.
Video chat is obviously here to stay in the software industry, which is why I’ve left it. I worked started working remotely from 2015 onward, felt ambivalent about it, but the the proliferation of video meetings with the pandemic really made it bad. I worked in office in 2021 and 2022, but once the genie was out of the bottle, you’d get calls all the time. Used to be you could just send a status report to sync up with overseas teams, but now, why not a daily video call? just a bizarrely irritating and draining way to spend your day.
If you're talking about just sharing images of each other's faces, then sure. But if you're talking about an actual screen, with an editor, and code, and config files, and debug logs, or whatever, then "hard disagree" here. I can't even count the times somebody has pinged me for help with something, made it sound super mysterious and unsolvable while explaining through text chat, and then we had a Teams call and I saw something in (their code|their config|their debug logs|etc) that let me solve the problem for them in like 2 minutes.
That shit is exactly why I agree with the person up-thread who said "I almost always want to jump on a call ..." IME, things get done quicker when I can actually see what's going on for myself instead of having to read someone else's abridged / misinterpreted / whatever version of events.
It's fine to have preferences but to expect your company and team to let you always do things your personal preferred way is pretty unrealistic. I don't think even the CEO of any company gets to have their way 100% of the time (although they almost certainly get their way more than anyone else in the company does)
Another way to say this is "if you work a remote coding job, it is expected that you hop on a video/voice call pretty much whenever one of your teammates/managers/co-workers wants you to whenever they have a question they don't feel like typing out" because it's basically just a socially accepted norm. The majority of people prefer you stop what you're doing, get into a socially uncomfortable/awkward situation, and you're "the victim" until the person on the other end will let you hang up.
Repeat that 4+ times a day on average 5 times a week and that $120k/yr comfortable soft 8am-5am "IT" job starts looking less attractive/more soul sucking/5-10 years in you're dreaming of buying a van and moving into a cabin in the woods.
Why? ¯\_(ツ)_/¯
Someone else could probably explain (or disagree & explain) better than I can.
It's because we've built an industry-wide culture of never broaching a topic of feedback that might be even a little uncomfortable. So it's frowned upon to say the thing that would actually help both the other person and yourself — and, often, the other person would have no idea how to hear such a thing anyway.
What we mean:
"The exercise of writing out what you want/mean will help you clarify your own thoughts and end up saving us both a lot of time. It would make the whole company better if we were all disciplined about doing that first, genuinely trying to make progress asynchronously, and then only jumping on a call if really needed."
Instead, we say:
"My internet has been weird all week. Do you mind if we do this one over chat?"
And then we hope that, after the 25th time we say this, they'll figure out the common-sense basics of human communication and empathy on their own.
</cynical-but-true>
On a whole people tend to do a good job of working together in a way that minimizes instances of anger, dislike, or irritation. Not everyone is good at it, and few people are aware of what behaviors contribute to this cohesion.
This is one of those behaviors.
Here's the way I look at it.
If you are asking me a question where my reply isn't time sensitive, and it doesn't need to turn into a conversation about my answer, that doesn't need to be a call.
If you just want a status update on XYZ from me, which may be a short conversation, that probably does not need to be a call.
If you want my help with just about anything code related, that's a call. Screensharing is way easier for me to see what you are talking about, and it's much easier for us to be on the same page if we're both looking at the same thing.
It's also a massive peeve of mine when someone asks a question on messaging, refuses to have a call, and then proceeds to take forever getting back to me. It's one thing it I say something like "Try this, this, and this. Let me know what works" and then I can get back to my work.
But if I'm trying to step you through something and you sometimes reply immediately, sometimes in 5 minutes, sometimes in a half hour, then you get to have calls whenever you want my help from then on
I agree. When someone asks for help, I want to give them my undivided attention so we can get the stuff worked out immediately instead of having split attention so I'm not helping you as effectively and I'm not able to focus on my work. I want to sort it with a call because it's MUCH faster. Let me call you so I can return my full attention to my own shit.
That's probably what happened here, and I see it so often: CEO can work best under pressure, can communicate best in a call, whatever: In an almost selfless gesture, they aim to produce these good (for them!) conditions for others.
And since they are unable to understand that this doesn't work for everybody else, they get (at least a bit) upset because the only remaining explanation is that those people don't _want_ to be productive, or don't _want_ to communicate effectively.
This isn't about being comfortable it's about communicating clearly and effectively.
Some (Many?) people are just not good communicators regardless of the medium. However we learn to communicate verbally long before we learn to write, and most people communicate verbally in almost 100% of the interactions in their lives.
Additionally we first learn to talk about things with a lot of visual association. We use the shared ability to point at a visible thing and understand this is what we are talking about. You can even use this to communicate crudely with people who don't speak or read any language that you do.
Beyond all of that, writing clearly and reading comprehension are both additional skills that are needed for good written communication to occur, and all parties involved in the conversation need to have both of those skills to make it an effective communication style.
Given all of that, I'd say that if good communication is your goal, and it should be, then defaulting to verbal communication with a shared context (screen sharing or in-person or something else) is realistically likely to be better than written communication in almost all cases.
I said most people learn to speak before they learn to write. Is that untrue?
How about the idea that you can communicate (crudely, sure) with gestures even with people you don't share a common language with?
How about the idea that both writing comprehensively and reading comprehension are high level skills that many people don't possess enough to truly communicate effectively via writing? Do you disagree?
I don't think it's unfair to say that verbal communication is a cornerstone of the (near) universal human experience.
This isn't just "my preference" is what I'm getting at. I'm pretty sure it's just the human default.
>I said most people learn to speak before they learn to write. Is that untrue?
This is true but completely irrelevant. Most people also learn how to dance before they learn how to write, that does not mean interpretive dance is a suitable medium for conveying technical information.
>How about the idea that you can communicate (crudely, sure) with gestures even with people you don't share a common language with?
This is an edge case, and again, kind of cheating as you are attributing the benefits of visual aids to the verbal format. It does not provide any evidence that spoken communication is universally better.
>How about the idea that both writing comprehensively and reading comprehension are high level skills that many people don't possess enough to truly communicate effectively via writing? Do you disagree?
Reading comprehension and the ability to write cogently are basic skills of any knowledge work. I think people who are poor communicators are probably poor communicators regardless of medium, so this is a red herring. In general, the things you are saying are true to some extent but do not constitute an argument for verbal communication being universally better than written (your claim). Rather, even if I am charitable and ignore the clearly fallacious parts of your argument, at most you've shown that in some circumstances verbal communication has some advantages (a much weaker claim which does indeed seem rather uncontroversial).
>I don't think it's unfair to say that verbal communication is a cornerstone of the (near) universal human experience.
>This isn't just "my preference" is what I'm getting at. I'm pretty sure it's just the human default.
So, those of us with hearing problems or speech impediments are simply inhuman? This is the arrogance I was talking about. Your assumption that your preferences and the way that you work most efficiently is universal when it is clearly not. Again, you are free to conduct yourself in this fashion but it won't make you many friends.
Not OP, but if I were to guess, the "arrogant" part is the sentiment you express here combined a little bit of what comes off as "talking down" in how you argue to support it.
> You gave a bunch of good examples of people being bad communicators in your reply, so I feel like you agree with me on that?
Many of the examples of "bad communicators" were showing how written communication can work around some of those flaws.
Good communication is hard, and it involves not assuming that your preferred/standard methods are the best in every context. You have to be willing to adapt based on who you are communicating with and what you are discussing. If someone is barely literate, written won't work well except for pretty simple things. If hearing, (or quality connectivity, social anxiety etc.) are an issue then you'll struggle using just verbal.
It also isn't always just one or the other. One person I work with really struggles with expressing ideas clearly in the written form, yet also struggles with understanding complex ideas if he doesn't have a written reference. Neither one of those issues is very uncommon in my experience.
While I'll agree that verbal does serve a large role (probably largest in this specific context/scale), I don't agree with you apparent suggestion that it should be the default / universal method nor that other preferences / needs are invalid.
If the choice for me is going to be spending 5 minutes to help you debug something over screenshare where I can actually look at what's happening and get backtraces, context, poke at things , or it's going to be 10+ messages over an hour and a half, then I think the screenshare is going to be better for the team most of the time, EVEN IF in a vacuum i prefer text-based communication.
When I ask for help I try to be the one doing most of the work, at the very least describing the problem accurately, and not forcing others to solve it on my terms.
There are reasons to go on a call but to default to a call IMO is an expression of the dynamic above.
I tend to, and I know I'm not alone here, accomplish most of my work in very focused blocks that often take me multiple hours to get into. Often I'll go a whole work day without being able to get there, and often when I'm in the flow, I'll work 12+ hours because that's how I'm most productive.
Your 5 minute call may cost me 3-6 hours of productivity. Once I've pulled my head out of what I'm working on, it's not a given that I can jump right back in. Sometimes that's worth it. It's possible not having that call may cost you 3 hours of productivity. But because some people have different work styles, people who focus easily (or are working on easier problems) often don't think of the costs for those who don't.
You're also assuming there's only one task the developer could be working on. That's a very rare scenario.
I think that's an entirely reasonable position. How does this depend on "If both people are working on the same thing"? If I'm trying to help you debug something, and it feels like pulling teeth when I know I could solve your problem with a 5 minute screen-share, I'm probably going to choose the 5-minute screenshare over the hour-and-a-half of 10 different messages spread out over random intervals. The GP said the exact same thing:
It's also a massive peeve of mine when someone asks a question on messaging, refuses to have a call, and then proceeds to take forever getting back to me. It's one thing [if] I say something like "Try this, this, and this. Let me know what works" and then I can get back to my work.
But if I'm trying to step you through something and you sometimes reply immediately, sometimes in 5 minutes, sometimes in a half hour, then you get to have calls whenever you want my help from then on.First off, since you’re the one interrupting them, common courtesy suggests you should try to accommodate their communication preferences.
Second, that five minute call is saving you 45m of text back-and-forth, which lets you get back to focusing faster. Not to mention saving the helper frustration, if you’re regularly leaving five minute gaps between replies.
And not even getting into the pernicious effects of having a culture where pseudo-synchronous instant messaging is broadly preferred over synchronous calls. In such cultures, all communication is so inefficient that everyone is in several conversations at all times; good luck ever achieving focus in that environment. There’s a reason why Cal Newport hates Slack, and he literally wrote the book on focused work.
I read the first two paragraphs as general policy, and then the following lines as specific cases. To come to the interpretation you guys had, you have to assume that the fifth paragraph supersedes the first. It's possible that's how the author meant it, but that's not obvious. The first paragraph implies virtually always preferring calling, independent of which direction the help is flowing.
Addendum:
I don't love Slack, but my company is small, and the number of messages per day is in the 10s. Nevertheless, I have notifications disabled for all messengers, because I also find them interrupting. I only see messages when I'm switching windows anyway. I have the same on my phone: I only have visual notifications. I disable sounds and vibrate. When I'm either being particularly productive, or particularly struggling to focus, I close all communications apps.
Except five minute calls tend to last 60 minutes...
> pseudo-synchronous instant messaging is broadly preferred over synchronous calls.
Yep, you should go fully async.
On the other hand, if a call takes five, ten, fifteen minutes for good reason, it would have been hours or even days of messages. How many times have you spent ten minutes helping fix a newbie’s dev environment, and afterward they say “wow, thanks, I’ve been stuck all morning”?
And those calls aren’t rare! Knowing how (and when) to use calls over messages has been one of the most useful “soft skills” in my career toolkit.
I find it interesting that something measurable like this feels (not saying it is) like an opinion.
It's my opinion (maybe because I'm a semi-effective text communicator?) that handling it "async" on chat is more often than not quicker. Maybe I'm wrong/biased? I wonder how something like this is measured. It does feel like people who want to not accept calls are in the minority based on my experience/the response this is getting.
I'm sure there are times when it is better, and times when it isn't. I generally find that if a question is REALLY simple, then async is fine. Eg:
Q: What's the IP for the bumblefraxx gateway again?
A: 10.0.14.233
Ok, sure. Done, handled in a few seconds. But for anything that goes beyond about 2 Q/A "cycles", I generally find that a call is faster, because I can figure things out a lot faster when I can see all of the relevant details myself. Eg:
Q: The bumblefraxx gateway isn't working, can you help?
A: Did you make sure the IP is right?
Q: Yeah. Do you think the frozgibbit might be wedged?
A: ...
15 minutes later
Let's have a call so I can see this myself
/me looks at screen. Notices some trivial typo in config for bumblefraxx gateway. Problem fixed in 15 minutes and 15 seconds, when it could have been 15 seconds
I say 'no' to random requests for calls every single time, I'm sure I'm not alone.
Imo when you go with async communication you pay the cost of that context switch over and over, with interest.
For one, calls don’t result in a searchable log. If I remember I talked to someone about Foo, I can search for that in my Slack history. If someone else asks me the same question about Foo, I can just send them a screenshot from our earlier conversation and we’re done. I can also talk to 4 different people about four different issues at the same time in chat, but I can only be in a single call at a time.
Yeah but search in Slack and MS Teams both suck IME. The idea of what you're talking about makes sense and I'm sure it works out for somebody sometime or other. But I haven't found having that history particularly useful.
* Even if I can't remember the exact phrasing I used for something, I often remember the person I discussed it with and just check my DMs or threads with them.
* Half of my responses to "help me" questions include links to repos in files. So I search for the last time I typed out three paragraphs talking about a a given link and that works pretty well.
The other situation "type it out" is useful is when I think a particular problem is likely to be encountered by multiple people and essentially force someone to ask the question in a public channel so I can answer it there and everyone can see it (we have channels like and #new-eng-questions for this). Even if people don't find it via search, there are enough people checking the recent history of these channels that it's a useful exercise.
Agreed. Assuming it's the kind of question that's amenable to being answered in text-exchange format in the first place. I've gotten plenty of Teams / Slack messages where my response was "Can you ask this in the public team chat, so everybody can see it?" for that exact reason. That and it also opens up the pool of people who can potentially answer the question to more than just me, which is also a Good Thing.
But there are still plenty of questions where it quickly becomes apparent that having a call with screen-sharing and everything is going to be a much more efficient way of solving the problem at hand.
I don't just offer to have a call when someone says "Hey I need help"
My approach is to have them write out the issue in text, and say what they've tried. Then I judge the urgency and if it's a barn burner I get on a call immediately. If it's a Junior blocked on something that I think they can solve I will tell them we can have a call in a half hour or something and very often they do solve it on their own.
Essentially I use the async communication methods as the gatekeeper to prioritize the incoming requests for my time, but when I do give people my time it's on a call so I can give them my full attention.
Self improvers are the ones reading Hacker News, going to conferences, and generally trying to hone their skill.
Dark matter developers are a class I've shamelessly stolen from https://www.hanselman.com/blog/dark-matter-developers-the-un... - which is definitely worth a read for the context, but the gist is that they're in this as a 9-to-5.
The trouble comes where the two groups meet. We can all learn about how to ask better questions and more generally improve our communication skills, but it's vastly more difficult to _make someone care_ to do so. We've all seen and empathized with https://www.nohello.com/, but if you link it to a dark matter coworker who behaves exactly this way, chances are they will see it as an attack, not as a recommendation - and that attack reflects poorly on you, rather than on them.
I've had a lot of luck with "Hey, I appreciate that you always ask how I am when you're reaching out to me, but when you need something from me you can just ask upfront. You don't need to say Hi and wait for me to reply before asking. That way I don't keep you waiting and I can answer you as soon as I see your message"
You don't have to tell them that you actually want to prioritize them based on their question, and absolutely will keep them waiting if you don't think it's urgent.
It has happened plenty of times that I had a simple question during my research, and the other person very helpfully decided to help me solve the problem, instead of just answering. The result is always that it takes hours of both of our times to get little done, and the problem actually gets solved afterwards because the research was not all done yet.
I think he just wanted shit to stick on his calendar for the sake of having a (more than) full calendar, which I'm guessing he found useful for advancement or deflecting criticism. Given some of the other stuff he did and said I think an awful lot of his behavior was one kind of career-hack or another.
To talk with "foreign" team, you have to figure out if they are teams / meeting driven, slack driven, use webex, only reachable via email, have their own weird thing, ignore everything that doesn't come through a manager, or only respond to service now tickets, or require a ticket AND and followup (via one of the above methods) to get them to look at the ticket.
Figuring out how to talk to all the different people you need to takes several months and a lot of people leave before working it out.
If you stay long enough you end up with an informal network of people in the company you know and trust and work with them to get anything done. Often these are helpful ICs working around non-responsive management.
Even for devs who didn't have a lot of external meetings it was a pain because the executive leadership is basically just undercutting the authtority of managers. When I was there Shopify's middle management was extremely ineffectual because devs basically had free reign and executives didn't put any effort into top-down management, they just focused on "vision" (like joining the doomed Facebook crypto project, or hiring interns based on their esports experience)
I never worked under Tobi directly (or even close), but I was almost always thoroughly impressed with his communication and direction. I think I have a totally different take than the one you stated. The only axis I could see Elon & Tobi both sitting on is being members of the tres comas club.
Your experience reminds me of the saying, sometimes "the best people to work WITH are the worst people to work FOR".
https://www.youtube.com/watch?v=FaOSCASqLsE
Kylo Ren as Matt: "He said Kylo Ren has an 8-pack. That Kylo Ren is shredded."
I've worked on projects within the last year that had (pretty heavy) direct involvement from Tobi.
/s
https://writingexplained.org/free-rein-or-free-reign-differe...
The reason I speculate this may be better is that it respects the agency of employees more, isn't such a shock to the system, and allows a buffer time to correct serious issues such as those mentioned in the top level comment.
> The company said there will be a “two-week cooling off period” before anyone can reconvene a canceled meeting.
The company isn't saying no recurring meetings. It is saying, "hey, we have too many meetings, let's do a reset and think carefully about which ones we really need... and by the way, it's okay to decline a meeting that you don't think you'll gain value from.
I personally think that an occasional reset to figure out which meetings are actually necessary is a good idea. Also, sometimes there are personal/political reasons for joining meetings that you aren't going to get much out of. Having the top management say "try to cut down on unnecessary meetings" is a good way to give individual employees cover.
... sounds a lot like "make sure you're taking your vacation; we want employees to be recharged and energetic!", aka a feel-good CYA. My pointless, time-wasting, huge audience meetings are all owned by the top-half of management.
And everyone knows that refusing a meeting invite from a boss or boss-peer (or boss's boss) is career limiting.
As you pointed out, it's not as strange as the headline makes it out to be. "Big organization finds effective communication difficult; tries something new" ... big deal?
Also, I remember a similar anecdote about an executive who gave his assistant two weeks off, took their responsibilities himself, and concluded he didn't need their services anymore.
However, from what I can tell shopify has the opposite of a command and control culture. They believe "everyone is an owner" which is another way of saying that no one is an owner. The result is that dozens of people need to approve every little change because there is no clear ownership structure and you can't just tell an adjacent team's manager to buzz off. In addition to getting sign off from adjacent teams, you need approval from your manager, their manager, the manager after that, all the way up the chain often to Toby himself.
Everyone is afraid of being shit on from the level above that they all need to review. This behaviour is explicitly encouraged. In the end you get a bureaucratic and political nightmare where everything is designed and developed according to the loudest consensus opinion.
Making things even worse, making data-based decisions is explicitly discouraged, I guess because it makes things more difficult for the loud opinions of main product drivers.
it's automatically assumed/implied that this is an attempt of cost saving / reshift in priority. They'd rather have staff focusing on delivering products (code/completed projects) that will increase revenue.
I wonder what they are struggling to ship (or if you can make the assumption that, the only time you'd cut meetings is when you want to prioritize shipping and the fact that you need to cut meetings means you're struggling to ship based on XYZ standards/opinions (CEO thinks things could get done/out the door faster/quicker?))
I wonder what's on their internal roadmap that's exciting + going to "sizably" make a difference/grow the company/that they are "itching to ship".
I don’t know these circumstances but I completely agree with the premise of not allowing indefinitely recurring meetings. Perhaps it’s better to simply limit them to say 10 occurrences before they must be reconsidered, participants reevaluated and so on.
It is a good way. Shopify should have considered doing that, and let managers make the call, instead of summarily killing all meetings remotely and leaving managers to reschedule everything from scratch.
That sounds even worse. Talk about infantilizing your employees. "No, you don't know your job well enough to know that you need to do X, even if you think you do, we're not going to let you..."
I've worked with some middle managers that I would classify as infants.
Simple, colorful graphics really add that little bit of spice to the presentation.
GPT-3 and the grade-reading-report feature in word also help hone in on the right style.
I wonder if execs think that running companies is so easy because they get such a dumbed-down report about the company all the time. They know it's all at such a limited reading level, but think that their underlings are actually that stupid.
At an organization this large I imagine somewhere there is always a team X with a project Y.
Status Meetings Are About Status
A real working meeting is called when there is a real reason for all the people invited to think through some matter together. The purpose of the meeting is to reach consensus. Such a meeting is, almost by definition, an ad hoc affair. Ad hoc implies that the meeting is unlikely to be regularly scheduled. Any regular get-together is therefore somewhat suspect as likely to have a ceremonial purpose rather than a focused goal of consensus. The weekly status meeting is an obvious example. Though its goal may seem to be status reporting, its real intent is status confirming. And it’s not the status of the work, but the status of the boss.
When bosses are particularly needy, the burden of ceremonial status meetings can grow almost without bound. We know of one organization, for example, that runs daily two-hour status meetings. When participants are off-site during a meeting, they are expected to call in and participate by speakerphone for the whole duration. Nonattendance is regarded as a threat and is subject to serious penalties.
But actually IME it's not uncommon to actually chat about stuff. What'd you do this weekend? Did you see X movie? How did you solve that issue? But that might only work if it's not 6am.
“Oh, that’s easy, you just need to change Z.” Or, “No worries, let’s stay on the call and figure it out.”
But, for example, maybe the person isn't blocked yet so they don't know to ask, but they're going down a road that a coworker knows will be a dead end, and by overhearing it that coworker will speak up and offer a suggestion.
Maybe a senior dev is a 'curmudgeon' who doesn't follow public slack channels, but if you put them in a room with everyone else then they'll contribute.
I think the benefit of status-meetings/stand-ups are not for the status so much as the forced recurring interactions with teammates for humanization and collaboration (a la the infamous "water cooler chats").
(Also FWIW I'm pretty against these sorts of meetings every day. But I think 2-3 a week is a nice balance.)
Again, generally speaking, no one should have more than one of these meetings a week unless they really have a good reason to be actively involved in multiple independent teams.
The real meeting-smell is when people have lots of weekly recurring meetings. If you're not a manager then two would be expected for most people, a 1hr team meeting and a 30min 1-1 with whomever they report.
Like the parent post mentions these kinds of meetings are for the benefit of managers and executives, not people working on the project. And this validation shouldn't come at at the expense of everyone else's time.
Granted, more often than not, something's seriously fucked up.
It would seem reasonable to me if it were "no meetings with more than 5 people" or something, depending on how their product and development teams are structured. But... three is verboten?
> Teams that work together on the same project should regularly get together in a synchronous conversation.
This doesn't prevent that. It seems that it only prevents you from automating the decision on when to do that. If you need to synchronize, you can. However, if you don't, there is no need to hold a meeting. But people tend to make meetings opt-out rather than opt-in. This seems to enforce an opt-in approach first.
- any team member can propose an ad-hoc whole-team meeting at any time.
- any two team members can propose an ad-hoc whole-team meeting at any time.
- any team manager can mandate an ad-hoc whole-team meeting up to four times yearly
The Shopify rule is "no team member and no manager can mandate a recurring meeting with more than one other person."
Also, I would expect the management to be the ones to care the most about hoe team functions overall. They should be the ones to notice communication is dying or that we are splitting into subgroups or that someone is isolated work wise (unable to get answers to questions or whatever).
Team dynamic is literally work of leadership, so they should be able to decide on meetings.
I have no idea how they make policies like these work with business partnerships though. I could live with a rule like this internally, but it's hard to get time on a client or partner's calendar and, when you do, recurring meetings let you reserve it.
Of course, if it's just a 5 minute status update you should just send a memo.
* Engineers rushing to wrap up for the sprint (stress and decreased quality is bad for morale)
* Engineers getting monitored and measured on a task level since all tasks need to be estimated (micromanagement, lack of trust)
* Agility is decreased since everything needs to be planned (lack of autonomy)
Sprints tend to become “phony deadlines”, a key component in “Teamicide” (from “Peopleware”).
I’ve been trying to come up with benefits but I’m coming up short. Wish someone could tell me!
I get the sense most managers stick to scrum and all the unnecessary overhead mainly because they are creatures of habit. Pushing a non-scrum system in an organization that fully embraces it is hard (especially when senior leaders enjoy the micromanaging aspects of it).
That's in the unicorn-rare case that you're in an org that can do "agile" right, but still has the problem of clueless stakeholders shitting everywhere and no discipline or expectation that PMs are empowered to tell them (politely) to fuck off without the support of this kind of framework. Otherwise, yeah, they're not that useful. You can track velocity and such without them, so that's not a good reason to have them.
The dysfunction can certainly go the other way (the stakeholders are competent and reasonable, but the teams are broken) in which case I'd not expect sprints to be helpful, and possibly abusable in the ways you suggest.
> if a team can only plan a couple of weeks ahead, how should stakeholders be able to plan?
When it's done right (ha, ha, ha) there absolutely is long-term planning, but adjustment of priorities sprint-to-sprint (which should be happening due to stakeholders and product managers and such making decisions, since they set those priorities) can affect that—the flux in long-term planning should be a reflection of the reality of choices made sprint to sprint that differ from the original plan, not due to a lack of planning, so that no-one's surprised when the mark that's hit in six months differs—for the good reason that the direction of the project was modified in-flight—from the one that was originally targeted. The entire point of sprints is to allow flexibility without day-to-day thrashing, while also capturing the effects of each sprint's work on that longer-term planning to avoid big surprises farther into the project.
Again, that's all if it's done correctly, and if the situation even warrants using sprints in the first place. Which, every now and then all that's true, but I'd not say it's the norm. I don't think most orgs even think very hard about what the point of having sprints is, before imposing them.
This generalization is clearly not strictly true, but people stick to it anyway without thinking.
Who should get together, exactly? When should they? Why? What is the goal, and are they meeting that goal?
Almost every single recurring meeting I've been in has not considered these things seriously. It's just generic people making a generic meeting to talk about generic things to make it feel like work is getting done, when usually, at the end of the meeting, you realize the entire meeting could have been an e-mail.
The only useful purpose of a generic, purposeless, recurring intra-team meeting is to reinforce social working relationships. They aren't going to solve a bug or ship a new feature or solve a design decision in one of these meetings. They exist solely to talk about work without doing work, because the interaction between humans smoothes the social dynamics of doing work. But nothing actually gets done.
I'm beginning to think most HN posters do not talk to their co workers outside scheduled meetings.
Like seriously, I don't even have stock or stock options, if the company makes more money, it's someone elses choice whether I get anything more out of it, or whether I get fired because my role doesn't fit within their new structure.
Historically we did this event in `rand(600)+300` days anniversary of the previous run (to make it somewhat unpredictable) but we had enough chaos during COVID so that we queued this run to get a fresh new start this year.
The article implies that they previously had multiple 50+ person meetings per week(!!) "Big meetings of more than 50 people will get shoehorned into a six-hour window on Thursdays, with a limit of one a week."
As someone who has never worked a company larger than ~300 people, can anyone enlighten me on what kind of meetings would have that many attendees, outside of say a quarterly all-hands?
A 50+ person meeting could be the global team brief (monthly), the regional team brief (weekly), kick off or milestone meeting of any project branching across multiple legal entities, change to global policy such as HR or finance, further meetings for IT to plan and implement these changes.
The list really goes on.....
I tend to mute myself and do some housework. I find i can get 99% of the detail from 5 minutes with the slide deck and the minutes.
Then you have central efforts liked software supply chain security, DE&I, etc
The best setup I've seen required only managers to attend such meetings, and those managers could open up invites to team members if they wanted them, or if they had something worth presenting. The meetings were all recorded anyway, so if someone felt like they missed something after the fact or couldn't attend, they could watch it at a more appropriate time.
The only real "all-hands" meetings we had was off-site, in person, and bi-annual. The only department that had more frequent all-hands meetings was sales with their quarterly kick-offs.
This predated COVID by many years, and remote work was only just becoming a thing, so we had custom built video streaming software once we opened additional offices so that the whole company would see the demos, if not so much the in-person chatter and snacks before and after.
All-hands happen, as you say, approximately every 2-3 months.
It’s odd. My entire career my calendar has never been as full as my peers’ in PM-land. And yet.. I don’t seem to be less productive.
Everyone in the meeting may be thinking "this is a waste of time", but each person doesn't know that everyone else is thinking that, so there is no natural processes to discuss ending the meeting. Worse, there is sometimes a perverse incentive to keep meetings going to maintain control or power.
This change shifts the equilibrium from "default on" to "default off" in a way that probably would not happen organically at a big company.
People really like it.
Canceling all recurring meetings may work for awhile, but I imagine it won’t be long before there’s a permanent action item for every meeting to schedule the next one. And it also won’t be long before senior management is made exempt.
We've just found better ways to share state, like emails and chat apps. They don't require synchronous attendance, they allow more space for thought and correction, and they are naturally part of a record that you can reference and copy.
These forms don't share emotional state as well as synchronous presence and so don't completely replace it. But the modern workplace has less use for sharing emotional state than other things.
> Most people’s writing skills are not up to replacing the back and forth synchronization that happens in meetings.
They may be technically better - for some definition of better - but they're going to be poor replacements in reality.
Would still be a repeating meeting. The way it is entered into the calendar software does not change that.
Maybe this isn't so bad for a small number of meetings or in a very small organization, but the other problem with regular sync meetings is that they tend to proliferate, especially as you go higher up the management chain. If you don't just work exclusively with a single group of people all working on the same effort, your entirely calendar can fill up with sync meetings. It can even become comical in cases where the Venn diagram of who is working on what significantly overlaps and you end up seeing many of the same people over and over again with a slightly different audience and topic each time. No joke, I have seen this lead to the creation of another sync meeting with all the people from the other meetings, but then the other meetings also stay on the calendar because people also want that smaller group discussion. Very easy for it to get out of hand, so I tend to like the idea of a regular reset to cancel all those meetings and then add them back as needed.
I also approve of this kind of house-cleaning. Calendars, like any other storage device, get a lot of built-up cruft too. Mine have even had some absurdly long-interval meetings with people no longer with the company.
But I think that Shopify took it a bit too far by banning them all going forward as well.
Else, every synchronous meeting should be possible to be replaced with other forms of asynchronous communication.
Status meetings are the simplest one to replace: just add a bot that asks everybody what are you working on and then sends a summary with all the answers to the team.
Don't ask people if they are blocked or if they know what to work on next day. Teach/support/grow/encourage them to announced when they are blocked as soon as that happens and to know to whom to announce that. Teach them to ask for help when help is needed and ping a colleague to discuss the matter.
Support people asking their PMs/Business/... about priorities. Don't set the culture of waiting for priorities to be announced at fixed points as priorities should be able to be changes quickly and each team should have info boards where the priorities are cleary expresses.
It is very easy to create a culture where everything is fixed by a meeting. Thus everybody belives the meetings are the only answer to communication. You can see this in some comments here where people are asking: if we don't do a daily meeting how can we work as a team?
If you ask this you are putting an equal between communication and meeting, but that is not true.
A team cannot work without _communication_, but synchronous meetings are only one of the many ways to communicate.
So I like the idea of throwing all meetings into the "konmari" method of tidying, where you completely empty your closets and then decide what should be kept, rather than trying to pick out which things should be discarded.
At my company, we have started "async weeks", where, basically once a quarter, we try to basically use async communication instead of recurring meetings.
First, this is executed without a lot of shock. You know it's coming and plan around it. But two, it does help promote writing - teams experiment with doing one or two things differently. It's a slow roll, but I'm seeing a bit more adoption of written tools, like doing reviews in Google docs instead of just reading them, etc.
Importantly, the lame "status update" meetings have become much more tighter and focused. We used to pack things into these generic one hour sessions, and now more meetings are starting to have better focused agendas, people get used to saying "you know, maybe only two of us need to discuss this...", etc.
Taking a week 2-3x a year to iterate and experiment with process changes like this feels pretty useful. Teams _should_ be doing this frequently if they're "agile", but I've rarely seen that actually pan out in reality. But it's a lot easier to take than the CEO surprising everyone electronically the first week back after a break.
IMO the person creating the meeting has that responsibility to prepare and structure the event to minimize the time required.
I personally include a document in the meeting invite containing the talking points in advance, which gives the time to those who participate to prepare their content and add more points if relevant. I guide the discussion through those points while also taking notes, and when the meeting is over I share a meeting summary to all those who attended so that we all have that info written down, easy to Ctrl+F if needed.
So far I think everyone enjoys the effort I put in these.
The rest of the work is documented through our incident management system to keep everyone in the loop, and wr have our group chat for the ad-hoc discussions.
Otherwise it will be awkward to manually have to schedule:
- Daily stand ups - Biweekly (or sprint_length) sprint planning/review/retros
Those sort of things are built into scrum to keep your team on track and prevent problems from being withheld until it’s too late.
On the other hand, if a company assigns a huge chunk of responsibility to every engineer and value "show and tell" or "freedom and responsibility" in general instead of "get permission first", then there will be very few meetings, just like Netflix did in the early 2010s, or as AWS did with true 2-pizza teams. The question is, does the leadership in your company has the stomach or means to cultivate the culture of encouraging individuals to carry out big enough tasks?
Wouldn’t it be better to measure outcomes and sentiment, and allow teams to adapt to what works for them? “Hey your team isn’t really enjoying all the meetings you call, maybe try having fewer to improve your team’s morale?” vs. “No recurring meetings for anyone!”
Likely to be one of those great ideas that gets ruined in implementation because that's how humans do things.
I don't like meetings, I constantly try to remove meetings from my team's process, but that doesn't mean that I think the ones we have are not useful and a waste of time.
Yes there might be some fat to cut but this approach just sounds terrible
In reality projects will go in random unwanted directions, or TBs that used to be recurring will be manually created one at a time, and things will continue just like before this decision
At least thats what it seems like email job people think.
On the five years I served We went over time twice. Once by five minutes and once by 90. We had a very good facilitator
In business I have almost never been in meetings that well run.
Good on Shopify. But the problem is not "meetings". The problem is those meetings
It's very straight forward.
I like technical work, design and coding and interaction with customers to understand their needs. I'm okay with approximately weekly status updates and ad-hoc quickie get-togethers to figure something out, but I hate stand-ups (so-called) that feel more like justifying one's job or trying to sound productive (I knew for a fact some of those fancy updates people were giving were just covering for watching Netflix and Youtube 4 hrs/day) :)
It seems to me Shopify's approach might have some merit, even if it seems heavy-handed and clumsy.
I tried to keep my check-ins to 30 seconds.
Others could go on for nearly limitless time until the mgr finally shut them up.
I suggested to the mgr, a nice enough guy, about splitting the team into smaller groups with 15-minute limits on morning stand-ups, and he responded that he had already proposed that but had been shot down.
For years I've been hearing about how Agile is an effective methodology, but I have not been able to verify this personally. On the contrary, I've come to believe that poorly executed Agile is much worse than nothing.
Now I'm contemplating my next steps and many if not most employers do list Agile as a "skill" or a requirement. Not sure if I should just smile and make nice about it, or be honest and say "Yes I've used Agile but it was at best a waste of time."
When will we see a company forbidding Slack and Teams?
IMO it worked great, and I prefer that to slack.
Email is much more linear and more permanent so it’s much harder to lose things. It’s also much easier to search for things in email IMO. The extra friction invoked with e-mail can also be good for cutting down on unnecessary communication.
Using your own client allowed you to squash notifications and other silly engagement tactics that plague slack today
It was wonderful
Bots that can't be completely muted, for example. The best you can do is disable notifications for messages created by bots (except slackbot) but as far as I can tell you can't stop the dreaded "red dot" from appearing.
Slack conversations and threads are a good sweet spot for team discussions
> can also be good for cutting down on unnecessary communication
Or you're discouraging conversations that didn't need to, but it would be better in the end if they happened.
You can always enter DnD on Slack and attend to DMs as needed
I can’t remember ever seeing a thread of just 1 line back and forths (although I have seen this on slack). The 1 line emails I remember were usually from some higher up person who was signing off on some decision and that ended a thread usually.
(A collaborative doc would probably be a better venue for that, of course.)
The only thing worse than email for communication is talking on the phone....
I would love to kill email completely
Unless I have prescheduled a call with you, and I am expecting our call you are going to VM, i do not answer unsolicited calls even from people I know
You can file a bug with some product and someone from the other side of the campus will typically reply within days.
I think part of it is a user interface issue, interacting with Jira is such an unpleasant affair that often only PMs in a company will interact with it in any depth.
tmux can also be used for screen sharing, if anyone needs support or wants to pair on something.
One nice thing about using this comms stack is it doesn't exclude people who are on slow internet connections. Video/audio is grossly inefficient for transfer of some bytes of raw information versus text.
So many folks are completely disconnected from the performance of their group (whatever structure that group takes), that stuff like this starts to sound appealing.
Nobody who wants to get things done (that actually benefit the group) would advocate for not collaborating with other members of the group, but folks who want to maximize extraction with minimal effort would.
Periodicity is an arbitrary line upon which to draw acceptability, so when one draws it there's usually a reason other than, "I want to maximize effectiveness."
I guess I’m not entirely mad, Slack has a lot of downsides. But feels like they only half-assed solving for that set of problems.