Structuring a Startup for Scale
30 December, 2020
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).
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.
Director of Software at JANA Corporation
Philip Gollucci, Director of Cloud Engineering at CareRev, describes a new method for hiring in a market climate that favors candidates instead of recruiters.
CEO/Founder at P6M7G8 Inc.
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Tom Hill, Engineering Manager at Globality, Inc., shares how he works with a culturally diverse team based within a thirteen-hour time gap.
Engineering Manager at Torii
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.