6 Mechanisms That Enable Engineering Teams to Scale
Jack Cohen / 07.07.18
Jack Cohen / 07.07.18
Because the team is so lean and tightly focused on a small number of goals, every employee understands who owns what, what work needs to be done, and what the quality of that work should be. The processes that are in place, if any, are basic.
And that’s ok.
Young companies don’t need overly complicated systems to act as blockers to early momentum.
But, what happens as that young company starts to scale? As a five-person team becomes fifty? As your customer base grows from 20 to 20,000? Just as a company matures, so too must the mechanisms by which it operates.
At FirstMark’s 2018 CTO Summit, Ian Wong, co-founder and CTO of Opendoor, shared six key mechanisms that helped his team stay on track as they scaled from 4 to 650+ employees in four short years.
“Good intentions don’t scale — mechanisms do. What you realize quickly is that it’s not just about the people you assemble, it’s not just about the market, it’s not just about your ideas, it’s actually about that meta work as the leader, it’s about the work that enables great work to happen.”
Keep Your Plans On Track
The first mechanism Ian shared in order to keep your scaling company on track is a proper planning system. This creates efficiency and accountability.
Many are familiar with and have had exposure to the OKR framework. Developed by Andy Grove, OKR stands for: Objectives and Key Results. The objectives are the “what” you hope to achieve and the key results are the “how” you plan to achieve them.
For example, an objective might be to “delight our customers” and a key result could be to “achieve 30% month over month growth in NPS.”
After he implemented OKRs, Ian realized they weren’t by any means a perfect solution. “In the beginning, we implemented OKRs on a monthly basis, then changed it to every six weeks, and now quarterly. When we first implemented them we had all this energy. We said, ‘Hey, we’re going to do these five things.’ But six weeks later we’d check in and half of the OKRs would be red and the other half were no longer applicable.”
So what went wrong? Ian shared two small ways he tweaked the OKR framework to create a more optimized and realistic planning mechanism for Opendoor.
1| Create ‘Aspirational’ & ‘Committed’ Key Results
Ian advises breaking key results into two categories: aspirational (AKRs) and committed (CKRs) key results. This is a simple and effective way to increase clarity, set clearer expectations for team members, and create a healthier and more flexible planning process.
An aspirational key result is “one that you want the team to really go for” — it’s a big swing. But, from a business standpoint, it may be acceptable for the team to only achieve 70–80% of that goal. For example, increasing site traffic by 10x is aspirational, while achieving a fraction of that goal would still be considered successful. Of course, not all key results can be so aspirational.
It’s also important to identify committed key results — these are generally more binary in nature (e.g. shipping the product) and where 100% completion is non-negotiable.
Wondering how many OKRs to set? Ian says the magic number is about 3–5 OKRs per team–each of which consists of one objective and roughly three key results.
2| Build Rigor Around OKR Check-Ins
Ian also implemented a lightweight, templated discussion around plans, problems, and progress against each OKR. This created transparency across teams and leadership.
After several iterations, Ian settled on 30-minute, bi-weekly check-ins against OKRs. This was frequent enough to facilitate continued progress and eliminate roadblocks, while not creating too much administrative overhead. More frequent discussions also enabled a dynamic and flexible planning process, which is crucial for a scaling company whose goals may be changing over time.
One final aspect of a healthy planning process is to highlight any objectives that your team is not currently prioritizing–an equally important distinction for any startup with scarce resources.
Keep Stability On Track
As Opendoor continued to scale, and more senior leaders joined the team, Ian realized that he needed to focus on two very clear areas in order to keep the organization’s stability on track: (1) operational excellence and (2) the post-mortem process.
3| Think Critically About Your Monitoring Process
One other process adjustment that helped Ian’s team was to implement a monitoring process… for their monitoring process. He first realized something needed to change when two unexpected Sev0s occurred the very same week that the team’s new VP of Engineering started, which made him revisit whether his current bug monitoring process was working:
“We learned that we weren’t putting the proper monitors in place to understand the quality of our incident response, or whether our monitoring processes even worked.”
While this sounds recursive, it is an important step to keep your processes healthy as you scale.
By reflecting on the team’s monitoring process, Ian identified a number of simple adjustments that made a substantial impact. One specific example was to track bugs with more granularity: the nature of the bug, its severity level, which SLAs were breached, who was on-call, among other factors.
This enabled the team to easily run actionable analytics against bug queue. It also gave leadership a high-level dashboard, which facilitated more efficient and effective operational excellence meetings.
4| Implement A Post-Mortem Template To Ensure Consistency
In addition to a more robust bug tracking system, Ian says that a prescriptive post-mortem process is a must-have to keep stability on track as your organization scales.
In the early days, when a smaller group of engineers conduct a post-mortem, you can assume total coverage and consistency in the team’s understanding of what went wrong and what needs to be remedied. However, as you scale, that assumption can no longer be made. Again, Ian and the team turned to a formalized template to ensure consistency across the organization.
The template, most importantly, starts this directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” This shared vision promoted openness and a growth mindset across the team.
The template then includes the following sections: what happened, what was impacted, the timeline, five “whys”, ideas to prevent similar issues in the future, and finally, resulting action items which are then ticketed to Jira to ensure the underlying issues are addressed.
Keep Quality On Track
The third and final piece that inevitably comes off track when a company scales is the quality of work. Ian shared two ways he mitigates that risk.
The first way is to adopt a more proactive posture, for example, by defining what quality means at your company. The second is to work on forming better habits early in your company’s life.
5| Define What Quality Means to Your Organization
One of the simplest ways to ensure consistent quality as your company scales is to proactively define quality itself, instead of reactively fixing quality issues.
For Ian, the definition of quality was codified in a design doc template. The template laid out a structured way for engineers to think through and document how new features were designed by, for example, articulating “potential impacts on other stakeholders.” In addition to making life easier for engineers, it innately increases cross-team design consistency.
“The reason why a lot of us struggle with quality as we scale is that we’re being so reactive to the demands of the day and we just don’t take a step back and think proactively about improving quality.”
6| Don’t Underestimate The Power of Better Habits
Ian also added that simple design critiques in small groups can be extremely helpful to form the right habits early on. If ingrained while a company is still young, these habits will only compound their positive impact as the company continues to scale.
While many review processes can feel heavy and top-down, lightweight crits empower designers and engineers alike to feel true ownership and responsibility over the quality of their work.
In closing, “good intentions don’t scale, mechanism do.” While it sounds straightforward, sometimes the simplest changes to your internal processes can be the difference between successfully scaling your company or watching as it fails to handle the growth.