Reorganizing Engineering, Product, and Design Teams at Customer.io
What makes a great product? Many factors: value, user experience, code, pricing, and more. The most crucial, though, is the people behind it all.
At Customer.io, our team has expanded rapidly. As the number of engineers, product managers, and product designers increased, we needed new organizational systems to keep up. We took action in January, updating how we organize, prioritize, collaborate, and execute.
It’s been a wild ride.
The Challenge: Growing pains for a growing team
Our engineering, product, and design team started out small, with a total of around 30 people. We organized into cross-functional "squads,” with each squad focused on a business outcome. For example, Squad Data concentrated on increasing the percentage of customers sending data to our API. Squad Mobile focused on improving the percentage of customers sending push notifications. And so on.
As an overall department, we embraced an "Outcomes over Outputs" mindset. For a while, this worked well. However, as we expanded from four to eight squads and from 30 to over 90 people, two specific problems emerged:
1. Operational ownership: Squads were incentivized to ship features, but not operationalize them. Our single SRE team was attempting to shoulder responsibility for the security, reliability, performance, and cost operations of eight different squads' features! This was unsustainable.
2. Monolithic architecture: All squads worked on the same giant code base. While this empowered any engineer to add, change, or remove code, it also made it easy to break dependent code by accident.
The Solution: A bird analogy
Since Customer.io was founded, the internal mascot has been a pigeon named “Ami.” It means “dear friend” in French. It also means we love a good bird analogy.
Thus, we named our new prioritization framework, the “Nest.” The Nest encouraged squads to take operational ownership of their features. Where historically we prioritized from “Growth” down, squads would now prioritize from “Security” up:
This concept would address our operational ownership challenge (more on how later), but not our monolithic architecture. Inspired by Team Topologies, we applied a hybrid of the direct and inverse Conway maneuvers, defining new squads based on the reality of our architecture “fracture planes” today and the split architecture we envisioned.
Here’s where we landed:
With the Nest framework and organization plan ready, it was time to roll it out.
Building the Nest
In January 2024, we began the process. All newly formed squads underwent a four-week “Build the Nest” program, during which they learned about their feature areas and “claimed” the backend services that powered them.
For each feature area and service, squads then defined measurable indicators and objectives for each layer of the Nest. By the end, each team was able to report on the health of their Nest: 🔴, 🟡, or 🟢.
Here are templatized versions of the docs used for the process: