When I first joined Squarespace, a bug I wrote caused a minor outage in our Commerce system. When we held a retrospective on the incident, we realized that one contributing factor was that we weren’t using the right tests. Instead of making sure we had good unit and integration test coverage in our code, we relied on our end-to-end UI testing framework to catch regressions. End-to-end tests did help make sure we weren’t shipping code that broke core functionality, but they didn’t help us catch changes that hurt smaller groups of users. After talking to our peers, my team and I learned that other frontend engineers relied on these end-to-end tests too.
Squarespace needed to address the issue, but we didn’t know exactly how. We had automated testing built into our continuous integration pipeline, but not every team had consistent test coverage. Testing adoption came down to each team’s culture. As teams grew and took on new projects, they didn’t always keep up with testing if there was no one actively promoting the importance of testing.
Organic adoption wasn’t working, and we knew we couldn’t expect a single team to take care of testing for the entire codebase. Instead, we needed a group to come together from across Engineering to work on the problem. We wanted to change the culture and make automated testing an expectation, a normal part of shipping code. We decided to start a working group.
What is a working group?
Working groups are short-lived, temporary teams of diverse contributors created to solve a cross-organizational issue. To elaborate:
Short-lived: Working groups must have a clear, planned end to their existence. They cannot run indefinitely.
Temporary: Working groups do not live on an organizational chart, and the group’s work isn’t anyone’s primary responsibility.
Diverse: The members of the working group all see the problem in different ways.
Cross-organizational issue: Working groups only address cross-org problems; otherwise, an individual team could manage the problem themselves.
Working groups offer many benefits to mid- and large-sized engineering organizations.
They give individual contributors the chance to take a leadership role solving a problem that affects a cross-section of the company. Individual contributors also get to work with people outside of their team or department. For engineering managers, working groups can be a lightweight alternative to a cross-team project.
For organizations, working groups are an indicator of cultural health. Working groups can succeed only when there’s a high degree of trust between management and individuals as they run without the structural support of the organization. Additionally, working groups require motivated, committed, and self-directed employees to execute the group’s mission. An engineering organization that embraces working groups can give individuals an opportunity to make an impact and give managers more resources to solve problems without being directly involved.
Before starting a working group, you should understand a few key processes that will set it up for success.
Validation and Sponsorship
First, take some time to make sure you actually need a working group. Start by asking yourself and your peers the following questions:
Does this problem actually exist?
Are other people besides me affected by this problem?
Do colleagues across the company agree that someone should address this problem?
Is this problem ownerless?
If the answer is no for any of these questions, a working group is not the solution.
Next, find a sponsor for the group. A good sponsor should have executive authority over part of the problem. This might be your own manager, a manager of a group that’s particularly affected by the problem, or a technical lead who understands the problem thoroughly. You can (and should) have more than one sponsor. Your sponsors should champion the group’s work, introduce you to teams or individuals as needed, and help you manage requests that come up. Sponsors can also help you find new contributors to the group, because they’ll have a better understanding of where people are feeling pain across the org and can use their relationships to encourage those people to participate.
Assembling a Team
While validating whether you need a working group, you should have had multiple conversations with peers, engaged customers, and critics of the problem. These individuals are great candidates to join your working group. You don’t have to limit membership to engineering or even to your company. Having a diverse set of members is critical to the group’s success. Your members will all see the problem in different ways and should be able to provide unique perspectives and solutions.
Before the working group’s first meeting, schedule some one-on-one time with each of the new group members to understand why they’re joining the group. Learn how each member can help and what challenges they’re facing today.
Don’t forget to set up group communication channels like Slack, email groups, Jira projects, etc. These forums provide a convenient, asynchronous way to bring up issues, discuss solutions, and develop a culture between group members!
Defining a Mission
As the working group forms, it’s important that the group members and stakeholders agree on an outcome. Start by developing a mission: a short, one- or two-sentence statement that defines the purpose and the end goal of your working group.
For instance, the mission for our working group on frontend testing was:
“To establish a culture of frontend testing through defining standards, documenting best practices and patterns, and by acting as a resource for engineers at Squarespace.”
Effective mission-setting is a topic that warrants its own discussion, and we won’t get into it here. You can find plenty of resources online to help your new working group develop their own mission.
Creating a Roadmap
Once you’ve defined a mission, your working group should start developing a roadmap that breaks down your goal into manageable steps. The initial roadmap doesn’t need to cover the whole lifespan of your working group, but it should include all the deliverables you know about so far. Usually, your roadmap won’t have deliverables that are more than a month away.
When you add a deliverable to your roadmap, ask the group these questions:
Does completing this bring us closer to our goal?
Are there stakeholders for this deliverable?
Are there indicators we can use to measure the success or failure of the deliverable?
A well-written deliverable should include all this information when you add it to the roadmap. That way, you ensure everyone knows what your acceptance criteria is and you use metrics to confirm that each change is an improvement. You can even use these metrics to report on the group’s success with stakeholders and interested parties!
Working Together
Now that you have your roadmap, your group just needs to do the work. Working groups should meet regularly. The cadence may change over time, but pick an interval that gives people time to complete a step of the roadmap. Schedule meetings in advance; otherwise, without a deadline, people will leave their working-group tasks at the bottom of their todo list as they are assigned other work.
Borrowing from agile ceremonies, your meetings should include demos, a retrospective, and planning. Start the meeting by having members show the work they’ve done and let the group and stakeholders give feedback on that work. Then, as a group, talk about the work and any problems that have come up since you last met, making sure to assign people to any tasks that come out of the discussion. Look at your roadmap and talk about any deliverables that should be added.
Don’t forget to communicate your group’s progress to stakeholders and to the broader engineering organization. The more you communicate, the quicker you can get feedback from a wide group of people; you can even recruit new working group members through your update communications!
Lastly, save some time at the end of each meeting (around 10-15 minutes) for an open discussion. Group members can bring up questions for the group and spend some time exploring them. Having this open time to ask questions of each other in person gives members a chance to provide real-time feedback and builds rapport within the group.
Wrapping Up
Congratulations! At this point the working group has shipped their last defined deliverable and stopped active development. Before cancelling future meetings, your group needs to validate that you’ve achieved your mission.
Start by informing all stakeholders that the group is coming to an end. In these conversations, confirm that the group addressed the problem. If your stakeholders are still having issues, then the working group needs to reconvene and identify a plan for addressing the issues.
Once your stakeholders sign off on the outcome, hold a group retrospective. Invite stakeholders and contributors to dissect your working group’s development process. Celebrate successes and keep faults blameless. Write down and publicize your findings within the organization so the same mistakes don’t occur again.
Lastly, take time to celebrate. Your group achieved a major milestone, and you improved the engineering organization through your work and perseverance. Enjoy some sweets and spend some time with one another in a different dynamic. Even as the working group comes to a close, the bonds between members will continue, and contributors will likely be working together again in the future.
Working Groups at Squarespace
Using this process, our working group shipped a suite of impactful work in under six months:
A new onboarding course on testing for all newly hired frontend engineers
An advanced, hands-on lab-based testing course targeted at experienced engineers and teams
A proof of concept for an in-house xpath selector library integration with headless Chrome
A company-wide survey of testing practices
A series of Squarespace-specific testing documentation and how-to guides
The number of test suites in our primary codebase more than doubled since the working group kicked off—a huge improvement from where we once were! The working group’s effort wouldn’t have been possible without a diverse group of members, spanning nine teams from different departments including QA, product engineering, internal engineering, and infrastructure.
Squarespace has also used working groups for a range of other issues, from removing legacy code, to advocating for certain technologies, to improving our interview process.
If you’re interested in learning more about how we work, take a look at our open roles.