-
Engineering leaders: Don’t automatically split the dev team on code boundaries if you want >2x impact from 2x headcount 🚢 When teams and products are small and slow growing, it's better for everyone to know all the code. But what happens in rapid growth?Permalink On twitter.com
❤️ 4 Favorites 2022 Aug 20 Mood +7 🙂
-
…in reply to @ZekeAranyLucas
When doubling headcount, each new dev needs to get ramped in and start contributing quickly (without overly distracting the existing team). This means partitioning the team so that onboarding focuses on building confidence where the growth needs to happen.On twitter.com
-
…in reply to @ZekeAranyLucas
The obvious choice is to split the team based on the existing code structure: repos, namespaces, apps, etc. This works because it's easy to explain how new devs are assigned. Individuals can onboard and unblock quickly, but that doesn't translate into a more effective org.Permalink On twitter.com
-
…in reply to @ZekeAranyLucas
Conway's Law states organizations design systems that mirror their own communication structure. So by organizing around the code base, you start shipping the new org chart as the new product vision. Instead, organize around your strategy and make the code follow!Permalink On twitter.com
-
…in reply to @ZekeAranyLucas
Imagine a company (EG) that had some tax filing software and 15 devs. Everyone worked from one common backlog and could solve any issue. Before they start adding 15 devs, the org must divide into two: X & Y. Here are 3 ways to allocate headcount instead of code boundaries:Permalink On twitter.com
-
…in reply to @ZekeAranyLucas
1) Focus on business problems Take the business goals for the org, and make those engineering units. Uber was famous for doing this. That also makes it easy to confirm business priorities by sharing the assigned headcount. EG • X = Grow customers • Y = Improve unit profitsPermalink On twitter.com
-
…in reply to @ZekeAranyLucas
2) Protect your expert assets Isolate the high-value domain knowledge into a team that exposes simplified interfaces. Derive the other dev work from more generalized software principles. EG • X = Tax rules database and validation (domain experts) • Y = App flows (new devs)Permalink On twitter.com
-
…in reply to @ZekeAranyLucas
3) Match in/out rhythms Align engineering to the cadence of specific business activities and SLAs. EG • X = Continuous stream of customer support fixes • Y = Features tied to seasonal marketing campaignsPermalink On twitter.com
-
…in reply to @ZekeAranyLucas
BONUS) Let them pick It sounds like chaos, but most Big Tech does self-organizing to varying degrees, by making it easy for devs to move teams. Leaders have to figure out how to get the gaps filled, and some projects will implicitly die because nobody wants to work on them.Permalink On twitter.com