How We Organize Ourselves
We practice agile development because it reinforces focus on short feedback cycles, shipping vertical slices, and regular reflection on what we’re achieving.
We organize in small, cross-functional squads with no fewer than three (ideally four) engineers, with embedded reps from other disciplines as needed (e.g., product, design, analytics, legal, investing, tax, marketing) because small teams simplify communication, and rightly feel a sense of pride in ownership. Our squads roll up into pillars representing a business unit that a customer would understand because teams should be bound together by shared goals that clearly benefit the customer.
Our squads individually and unambiguously own each domain module because ownership promotes expertise, accountability, and pride, and combats the tragedy of the commons.
We contribute code across ownership boundaries often (both module and application boundaries) because ownership shouldn’t lead to siloing, and cross-pollination of ideas is incredibly valuable.
We stand up tactical cross-domain teams to solve big problems that straddle domains because domain boundaries create a natural speed bump we seek to minimize.
Our squads never own more than one customer-facing application domain because that indicates that we split application domains too soon, the squad is understaffed and will be forced to choose between its children, or both.
Our security, site reliability, and data engineering teams, despite being central to the engineering org, are product organizations and boutique consultancies, not a NOC or a temp agency because hands-on-keyboards is dull work, doesn’t scale, and leaves a fuzzy ownership boundary between the teams.