5 comments

[ 5.6 ms ] story [ 220 ms ] thread
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.

> 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.

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.