Structuring a Startup for Scale

Problem

When I joined my current company back in 2016 it was still an early-stage startup graduating with 20-some engineers in an office only to rapidly scale in no time to 250 engineers across four geographies (two at East Coast, one at West Coast, and one in Bangalore, India). The engineering processes were still taking shape and didn’t allow for clear ownership of product areas. Rapid growth was often at the expense of documentation and hardly anything was documented. You would have to go talk to one of the OG engineers with institutional memory to understand aspects of architecture and design in order to do your job. Field escalations were complicated as there wasn’t clear ownership and most of the escalations landed on one of the few OGs (with a few individual exceptions).

Actions taken

For starters, I documented all of our CLIs and started working with others in the organization to assign teams as owners to each one. The process I initiated was simple; I was able to obtain a complete list of customer and support CLIs from our documentation team and create a Confluence page of that list with a new column to document “Owner” of each CLI. Then I sent out a call-to-action email for our managers and Product Owners to fill in this info. By doing so, we were able to complete 75 percent of the information needed. We had some CLIs that weren’t straightforward to assign to a specific team and the only way to resolve that was by meeting with my peers and settling on a proposal that we would take to the teams for feedback and buy-in. This process enforced the assignment of ownership and the path for escalations and feature requests became more visible to the entire organization.

The very act of mapping and documenting product ownership empowered each team to further monitor quality, technical debt, feature requests, escalations by product area and focus their energy accordingly. As stakeholders started seeing the value of alignment, another ownership mapping effort was followed to map other product areas to the team (e.g. services, frameworks, etc.), which some teams started documenting on their own ahead of the mandate from our VP of Engineering.

As ownership cleared up, so did backlogs for teams. This created opportunities to dismantle some Scrum teams and start others with a new focus. Not everyone was happy about this turn of events, but when the dust settled and the population of engineers were surveyed about the outcome of this experiment, the majority felt a higher sense of purpose, empowerment, and satisfaction.

Lessons learned

• As an organization scales, it’s important to consider how to keep focus within each team(s). The answer to dealing with more work isn’t necessary to bring in more people. Enabling a team to operate with minimal dependencies on other teams is critical to faster delivery and greater talent retention.
• Have the courage to lead through change by performing your own analysis and proposing data-driven changes. I couldn’t recommend any reorganization from the get-go. I needed to understand how teams map to product areas to backlog items first. Once I saw the data and some teams raising the flag that they don’t have enough to keep them busy, I was able to put together a proposal for change that would benefit the business and employees. We were able to re-direct hiring towards starting new teams to develop new features as a result.