Working Groups that Worked
By Mark Thomas Marcantano
At the core of any engineering organization is the ability to make great technical decisions– doing this well as a team grows and changes is quite challenging indeed. Earlier this year, we realized that while we had many strong ideas and constructive conversations, we had trouble carrying them through to decisive action. We needed a better way to align perspectives and priorities across our engineering org. We knew that we could solve more problems each quarter if we focused our solutions to one approach at a time.
We were missing a scalable framework for efficiently tackling our most important (and sometimes controversial!) organizational decisions. How could we do this in an inclusive and accessible way? How could we stay action and impact-oriented?
When our whole engineering team could fit in a small conference room, it was easy to solve problems by scribbling some technologies and shapes on a whiteboard. We could quickly hash solutions, circle what made the most sense, and decide what to work on next week. We wanted to capture the magic of those moments– knowledge-sharing, deep collaboration, and swift moves toward unified action.
But how could we translate those moments to our exponentially larger team and technological scope?
Keeping It Collaborative
We knew we wanted more structure, but not at the cost of our openness. Many of Calm’s most compelling products and ideas come from organic collaboration. We see success when we collaborate across orgs, across experience levels, and across backgrounds. This commitment to openness is where we started talking about working groups.
Centering collaboration as our key value led us to a working group model that creates access for all interested folks. To keep meetings focused and concise, we limit membership to 6. We incorporate perspectives from the rest of those interested through open and visible documentation.
When we decided it was time to iterate on our leveling framework, we sent out an email calling for team members to express their interest in taking part. There was more interest than we expected. We knew it would be difficult to synthesize all of the input in a round-table, discussion-type way. So, we selected a representative group based on the time commitment volunteers could make. To capture the full range of perspectives, we asked those who weren’t selected to write up their thoughts for the group to discuss. We also had working group members interview them as part of the feedback collection process.
How We Make Working Groups Work
To direct working groups toward impactful work and action, we time-box the duration to 4-6 weeks, which for us is 2-3 sprints. This constraint is key to breaking down large, complicated problems into manageable chunks. It helps us prioritize a solution that is immediately actionable and impactful. This time limit came out of a working group that asked the question “where do we test what?” This initial scope was intentionally broad. It was important for us to identify critical work across our automated testing systems and in our QA flow. The time constraint kept the discussion at a high level, allowing us to inventory the areas where we could improve quality. The output from feedback and discussion gave us a shortlist of tasks we could then assign ownership and priority. From here, we took the task we aligned on and started the work!
| Our Working Group Recipe | |
|---|---|
| Duration | 4-6 Weeks |
| Group Size | 5-6 |
Running this group took us from amorphous questioning to aligned decision-making around QA, automated tests, and scalability work. We aligned with a clear idea of what to work on first, and identified a strong backlog of next steps. It would’ve been almost impossible to sequence that effectively had we not drilled into that most immediate and wide-reaching problem: “where do we test what?” We had both the flexibility to do what was best for the org, and the structure to see it through to completion.
Working groups are a particularly good fit for Calm as the “sweet spot” between consistent process and adaptable agility. In the past, we favored that flexibility element too heavily and lacked the structure to take our brainstorms forward to actually “doing”. On the other side, we’ve tried to fix this by over-indexing on tools, meetings, and complicated processes– none of which ever stood the test of rapid growth. Because we're growing quickly, it often feels like Calm is a brand new company every six months. With that in mind, we need to think about our processes not just for 15 engineers, but for 500. The working group model allows us to scale horizontally as our team grows– spinning up additional, more specific groups in parallel.
Working Groups in Context
Outside org-based problems, we’re using working groups to streamline technical projects as they move into their next phase. An example of this is the work we’ve done around ever-changing laws and regulations concerning consumer data privacy. We work hard to protect our users and the data they trust us with. We know that the working group model will enable us to bolster our current efforts and continue to support newer regulations like CCPA. Our framework allows us to incorporate expertise across legal, data-science, security, and infrastructure teams, ultimately bringing us stronger solutions sooner. The documentation that comes out of these groups helps to distribute knowledge and create visibility into our systems and why they’re built the way they are.
There are a few areas where working groups haven’t really worked out for us. One of which was when we supported last-minute changes to high-traffic partnership launches. Schedules aligned such that two of our biggest and most exciting launch events had to happen on the same day. With a short runway to launch, we assembled a “task force” to take a close look at performance and reliability under this unprecedented, expected load. While the working group structure got us to the finish line, our engineers felt the intense strain of these deadlines, while still managing their typical sprint workloads. The new work was time-sensitive, cross-system, and deeply technical. It required a degree of focus and context that was not well-suited for the working group model. In all, it was a good learning experience for us. We took the feedback from our engineers to iterate on how we staff scalability work, ultimately prompting us to build out a new team to take on platform projects.
The Impact
Working groups have helped Calm’s engineering org mature as we make decisions that impact a growing ecosystem of engineers and users. By doubling-down on decision-making values like transparency, accessibility, and focus, there are already indicators of improvement present in both our problem-solving velocity and team engagement.
When considering places I’d like to work, I've given a lot of thought to the company's values around people and technology. However, I haven’t placed as much focus on how companies make decisions around these topics. In the process of spinning up these working groups, I’ve learned that a value-driven approach to decision-making is important to my happiness and effectiveness on a team. These added opportunities to engage in collaboration help me keep up with the growing range of strengths and talents across Calm Engineering.
If joining one of our working groups sounds like something you'd be interested in, check out our jobs page at www.calm.com/careers.