Glue teams own cross-cutting product features that directly impact users, while back-office teams serve internal needs; the piece argues you should prioritize glue teams early and add back-office only when ROI justifies it.
When a startup is tiny, everyone builds the product and the org chart is a simple circle. As the company grows, work splits into separate ownership zones, and two new kinds of engineering teams appear: back-office and glue teams. The article opens by defining back-office teams as internal service providers - they build developer tools, component libraries, and data platforms that make other engineers happier, but they sit one layer removed from the customer.
Glue teams, by contrast, own the product's cross-cutting features that users actually touch - auth, billing, SDKs, and other shared infrastructure. Because they sit at the product layer, glue teams must talk to users, own metrics, and fix pain points that directly affect revenue and satisfaction. The author stresses that these teams are essential early, while back-office teams can wait until the ROI of dedicated internal tooling becomes clear.
The piece argues that organizations often over-invest in back-office teams out of anxiety, which creates an approval culture and slows delivery. Instead, you should let small, chaotic, side-quest improvements address internal needs until the scale demands a dedicated team. This approach keeps engineering focused on user-facing value and prevents unnecessary layers of indirection.
Finally, the author offers practical guidance: spin up glue teams when users hit pain in cross-cutting areas, and only add back-office teams when the cost of not having them outweighs the impact on product development. The message is clear - prioritize direct user impact, keep internal tooling lightweight, and avoid early over-structuring that kills autonomy.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.