4 ms·

How Shopify’s anti-meeting, anti-mandatory-office experiment is going

33 points by replyifuagree 3y ago

xmcqdpt2 3y ago
This article was very detailed and yet conveniently did not mention the massive layoffs Shopify did over 2023, https://techcrunch.com/2023/05/04/how-shopify-bungled-its-latest-layoffs-and-made-employees-feel-like-npcs https://techcrunch.com/2023/05/04/how-shopify-bungled-its-la... This is PR, not journalism.
addicted 3y ago
Maybe if they had a few more meetings they might have realized that handing over their entire logistics and all that data entails to their biggest competitor and one of the most ruthless businesses in the world was not such a bright idea. I’m as anti meeting as anyone, and yet Shopify’s worst decisions seem to have coincided with this anti-meeting push, and almost makes me be less militant about my anti-meeting stance.
replyifuagree 3y ago
Archive link: https://archive.ph/Ezk6X https://archive.ph/Ezk6X
LapsangGuzzler 3y ago
My company has a similar policy and it’s worked pretty well, but has some downsides. A big one is that being a smaller, super ambitious startup means that we are shipping at an incredible rate (yay). However, the fidelity of our planning has declined quite a bit because we’ve taken the time previously allotted to meetings and increased our overall throughput with it. Because of this, there’s more deviation from what was planned and designed to what was shipped and there’s less alignment across teams, so it’s harder to coordinate feature development. Overall, we’re shipping stuff that tends to churn faster, but the hope is that it’s just temporary.
- jross225 3y ago
  > Because of this, there’s more deviation from what was planned and designed to what was shipped and there’s less alignment across teams, so it’s harder to coordinate feature development. Asking as an outsider, won't shipping a lot of things in this environment lead to some suboptimal product state. I'm used to coordinate > build > learn > iterate > ship; which although slows down gross feature development, tends to prevent the 60-80% of experiments that don't work from getting launched. Does removing meetings to optimize throughput of feature development not get us into some feature factory mindset? This isn't binary btw, but I think moves thinking more towards a build mindset vs a solve problem mindset.

33 points by replyifuagree 3y ago

This article was very detailed and yet conveniently did not mention the massive layoffs Shopify did over 2023, https://techcrunch.com/2023/05/04/how-shopify-bungled-its-latest-layoffs-and-made-employees-feel-like-npcs https://techcrunch.com/2023/05/04/how-shopify-bungled-its-la... This is PR, not journalism.

addicted 3y ago

Maybe if they had a few more meetings they might have realized that handing over their entire logistics and all that data entails to their biggest competitor and one of the most ruthless businesses in the world was not such a bright idea. I’m as anti meeting as anyone, and yet Shopify’s worst decisions seem to have coincided with this anti-meeting push, and almost makes me be less militant about my anti-meeting stance.

replyifuagree 3y ago

Archive link: https://archive.ph/Ezk6X https://archive.ph/Ezk6X

LapsangGuzzler 3y ago

My company has a similar policy and it’s worked pretty well, but has some downsides. A big one is that being a smaller, super ambitious startup means that we are shipping at an incredible rate (yay). However, the fidelity of our planning has declined quite a bit because we’ve taken the time previously allotted to meetings and increased our overall throughput with it. Because of this, there’s more deviation from what was planned and designed to what was shipped and there’s less alignment across teams, so it’s harder to coordinate feature development. Overall, we’re shipping stuff that tends to churn faster, but the hope is that it’s just temporary.

jross225 3y ago
> Because of this, there’s more deviation from what was planned and designed to what was shipped and there’s less alignment across teams, so it’s harder to coordinate feature development. Asking as an outsider, won't shipping a lot of things in this environment lead to some suboptimal product state. I'm used to coordinate > build > learn > iterate > ship; which although slows down gross feature development, tends to prevent the 60-80% of experiments that don't work from getting launched. Does removing meetings to optimize throughput of feature development not get us into some feature factory mindset? This isn't binary btw, but I think moves thinking more towards a build mindset vs a solve problem mindset.