Written by Adam Berman
Just over two years ago, in March of 2015, I signed my offer letter to join Meraki. I was overjoyed to join the company; it felt like a great fit from the moment I’d set foot in the office, and I was chomping at the bit to get started. Little did I know, I was about to walk right into a grand experiment that would demonstrate our leadership’s trust in the team.
Meraki was going through a major transition. The company had recently been acquired by Cisco and our founders had moved on, leaving us wondering: if we were no longer a startup, what were we? Would different leadership lead to different values? The new leads taking over for the founders were working hard to identify and resolve problems brought about by this transition.
Around this time, several of our new engineering leaders read Creativity Inc: a book on management by Ed Catmull, the founder of Pixar. One section of the book resonated: the chapter describing an event called Notes Day. The book recounted that after a few successful movies, Pixar leadership realized there were a number of problems at the company they didn’t know how to solve. Rather than having managers develop and announce changes, Pixar’s leaders decided to open the floor, allowing those closer to the problems to offer up solutions.
Inspired by Pixar’s approach, Meraki’s leadership decided that the engineering team itself was better positioned to understand and solve many of the problems related to the acquisition and changes in team membership and structure. So, like Pixar’s leaders, Meraki’s engineering leaders made the nerve-wracking decision to put their trust in the team, step back, and let us run with it. Everyone in the engineering department was tasked with figuring out what we wanted to fix and how to fix it. Ideas would succeed because other people on the engineering team bought in, not because a manager approved it.
Designing the first Notes Day
The decision to create a Meraki Notes Day created a new set of challenges. How would we make sure that Notes Day would be a good use of engineers’ time and effort? Meraki’s leaders needed to figure out how to empower the team to tackle challenges outside of their regular job description. The team needed to feel ownership of the problems facing the company, and they needed to feel like they had the means and authority to propose and execute solutions.
With these goals in mind, engineering leaders went about designing Meraki’s first Notes Day. Leaders made it clear that while they would help by organizing the event, they would not actually participate. Any member of the engineering team could propose problems for the team to tackle. An inspired engineer consolidated the list of topics and spun up an internal Reddit-style forum to post them on so that people could begin drilling down to root cause of each problem.
Since anyone on the team could suggest a topic, the compiled list of topics was quite broad. Some issues were highly technical, like challenges with our deployment process. Others addressed broad cultural issues, like how to best integrate new hires. Some issues came up time and time again. For instance, many people noted that we need to address problems with our interviewing process. Many people also brought up the importance of managing our technical debt. The bottom-up topic proposal process also brought some issues that hadn’t been obvious to leadership to light. For example, a number of people pointed out that our work from home policy was unclear, yet the Engineering leads had been unaware of that until Notes Day.
The Off-site
After a few weeks of discussion, Notes Day arrived, and the engineering team headed off site. Each engineer signed up for three sessions: my sessions were Mentorship, Mission, and Culture. In each session, 10-15 people discussed a specific problem. Each group analyzed the problem, came up with actionable solutions, and then decided who would take responsibility to move the solutions forward. Before we started with our sessions, one of the engineering leads addressed the team, reiterating the importance of thinking critically and building toward solutions. He then instructed us to power down our laptops and phones and get to work.
As I walked toward my first breakout session, I was nervous. I had only been at Meraki for about six weeks, so I was uncertain about my ability to contribute. But as our moderator asked us to think about our experience with mentorship, I realized that I didn’t need to worry. The room was filled with people who had been successful mentors, but far fewer had been mentored recently. I was mere weeks into being onboarded, so I had direct insight into what it felt like to be mentored. Our discussion was more fruitful because of the diversity of perspectives, and we ended up exploring some important gaps in our mentorship story. For example, as a new hire, I had a lot of questions, but I didn’t want to prevent my mentor from getting his own work done. I had no idea that mentors were instructed to spend at least 50% of their time early on getting their mentee comfortable working on their own. We realized that mentors needed to do a better job of communicating expectations to mentees so that they would feel more comfortable asking for help.
Within a few months, plans from Notes Day began to come to fruition. From the mentorship discussion, a few people ended up writing documentation that clarified the process for team leads to help train first-time mentors. Other discussion groups proposed broader changes. For instance, the discussion group on geographic diversity discussion resulted in a rotation program in which engineers from the SF office work with the infrastructure team in our London office for 6-8 week stints.
Iterating on Notes Day
Since that first Notes Day, we’ve continued to experiment with the structure of the off-site. This year, our UX team helped to introduce design thinking methods into the process. The UX team partnered with engineering leadership to help rebuild the process around our stated goal of solving hard, not-strictly-engineering problems. As they examined the past two Notes Days, they noticed that while some groups successfully narrowed down the topic to a specific problem, many groups got stuck discussing the problem, or discussing the first idea proposed, and didn’t get to exploring ideas or developing actionable items. The goal for this year was to use design thinking methods to help groups get to the core of a problem and prototype solutions.
The first major change was that instead of having a single discussion about each topic with everyone in the room, each session broke up into groups of three or four. The second major change was that discussions were structured into time-boxed steps. Each group spent predefined periods of time analyzing the underlying causes of a problem, choosing a root cause to address, generating solution ideas, choosing an idea, and determining how to test that idea out on a small scale.
These strategies helped us uncover problems that were not visible at surface level. My first session of the day was supposed to tackle whether or not Meraki needed a web focused testing team. Following the design process, we dove deeper into the issue and asked ourselves why we might need a testing team. We reasoned that people didn’t have a lot of confidence in our current testing environment, so we focused on figuring out ways we could build confidence that our tests catch bugs and prevent regression. Our primary takeaway was that we were missing integration tests, so developers had to manually test whether systems worked together. We decided to spin up an integration testing environment and start writing integration tests. Instead of merely answering the original question posed to us and then leaving it for management to figure out, our group came away with an actionable plan we could start to follow through on as soon as we returned from the off-site.
Results from the new process were immediately noticeable. In smaller groups, people who might have been hesitant to speak up became active participants. The added structure prevented groups from getting stuck on analyzing the problem, or bike-shedding the first idea someone proposed without considering others. Moreover, Notes Day overall produced far more ideas to try out, and far more people excited to invest in those ideas.
Though we only recently completed our last Notes Day, the organizers are already considering possible improvements for next year. Is yearly the proper interval for Notes Day? How should we group people who work together on a problem? Should we reevaluate the amount of time we spend on each topic? These are open questions that we will attempt to answer over the coming months. To figure this out, the organizers are following up one-on-one with people who participated to understand their experiences of Notes Day. We want to build on what worked well, iron out areas of confusion, and try new things.
Notes Day and Meraki culture
Notes Day exemplifies a key aspect of Meraki culture: trust. Our leadership team trusts the engineering team to find the best solutions to technical and organizational problems. We trust our coworkers to put ego aside, engage in tough conversations, and listen when say we think something could be better. Trust is at the core of Meraki culture, and each Notes Day is a reminder of how truly powerful that trust is.