Shopify CEO Tobi 强力干预内部工具项目,砍掉过度设计的架构
某个 Shopify 团队在做内部工具,创始人兼 CEO Tobi 两周后才得知此事,强力介入并把项目掉头 ? Tobi 正面回应了这个传闻,也让我们看到了 Shopify 这个知名团队创始人的工作...
Shopify CEO Tobi 亲自下场回应传闻,分享他如何强力干预并砍掉一个过度设计的内部工具项目,以及他如何通过决策复盘机制对抗沉没成本谬误。
Shopify CEO Tobi 强力介入并砍掉了一个过度设计的内部工具项目。原方案采用 headless Rails + GraphQL API + React 架构,导致改小功能都需要前端工程师介入。Tobi 认为内部工具应使用朴素的 Rails 全栈架构,这是典型的“架构凭空过度设计”。
某个 Shopify 团队在做内部工具,创始人兼 CEO Tobi 两周后才得知此事,强力介入并把项目掉头 ? Tobi 正面回应了这个传闻,也让我们看到了 Shopify 这个知名团队创始人的工作...
某个 Shopify 团队在做内部工具,创始人兼 CEO Tobi 两周后才得知此事,强力介入并把项目掉头 ? Tobi 正面回应了这个传闻,也让我们看到了 Shopify 这个知名团队创始人的工作方式: Founder-mode-as-a-service! 1. 那个被砍掉的架构确实该砍。 Tobi 把原方案形容为“cosplaying an enterprise production app”:团队给内部工具搭了 headless Rails + GraphQL API + React 单页应用的前后端分离架构,结果连改个小功能都需要前端工程师介入。他的判断是:内部工具就该用朴素的 Rails 全栈(服务端渲染、单仓库、一人可改全栈)。这是典型的“架构凭空过度设计”,为想象中的规模和复杂度设计,而非实际需求。 2. 这类干预往往是一线团队主动请他做的。 Tobi 说自己经常做这种裁定,通常是因为有团队成员私下请他出手;想砍掉过度设计的一方需要一个“唱黑脸的人”,而他愿意在认同前提时扮演这个角色,省掉无休止的会议和变革管理流程。Shopify 内部戏称这项服务为 "Founder-mode-as-a-service"。 3. 他不只裁决,还做“决策复盘”。 十年来他持续做一档内部播客叫 Context,回头讲解这些决策当时的推理过程,目的是教会其他人以后不需要他也能做出同样的判断。他顺带点出这背后的敌人是沉没成本谬误,团队倾向于因为“已经投入这么多”而继续错的方向,而复盘机制就是为了对抗这一点。 4. 对“Shopify 是尽管有他干预才成功”的说法,他不接受。 他认为反过来才成立:公司的成功正因为这类干预。他称“两周后 tobi 才得知……”这种叙事是胡扯,并说那次项目掉头是他最成功的干预之一。他用一句很有担当的话收尾:“让公司保持高效、低技术债,这就是我作为 CEO 的本职工作;所以,罪名成立。” 最后他补了一刀:这类流传的故事之所以受欢迎,只是因为它们比承认“团队确实需要有人来叫停愚蠢的过度架构”更有趣,是更好的“cope stories”。 tobi lutke @tobi Yep. Except: 1. This was about important internal tools. The team was stuck in some architecture nightmare of their own doing (writing it in rails but headless, with graphql api, and a SPA react app, constantly needing frontend engineers for changes). I call this kind of thing 'cosplaying an enterprise production app'. All that complexity was in the way and using straight rails was perfect in that case. 2. I make calls like this all the time. Usually someone on the team asks me to. They see what needs to happen but don’t want to be the bad guy. I’m happy to just make the call if I agree with the premise. Saves enormous amounts of meetings and change management etc. Sometimes this is jokingly referred to as Founder-mode-as-a-service here. 3. For ten years I’ve also run an internal podcast called Context, where I revisit decisions like these and explain the reasoning so everyone can learn from them. This is helpful to give people all the variables that were considered and why this was the choice made given the information available at the time. I want to teach how to make such decisions effectively without needing me. Sunk cost fallacy is a problem. 4. Any notions that Shopify is succcessful despite of me doing this, instead of because of it, will have a hard time making their argument come together I think 😄 the part of 'two weeks later tobi learns about...' is nonsese and the pivot of that project up there happens one of the more successful examples of interventions. But getting the company to work effectively with great architecture and low technical debt baggage into the right direction is literally the job, so guilty as charged I suppose. But there are always cope stories floating around like this because they are more fun, than saying 'somehow we needed tobi to stop doing silly architecture astronautics'. I can totally see that. 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 0 👀 408 📊 1 ⚡