Bootstrapping Eng Operations Part 2: Maker time and Recognition
This is the second post in our series entitled Bootstrapping Engineering Operations. In our original post, we highlighted the role that Eng Ops can play in driving organizational maturity by developing programs and systems to help make engineers and the team more effective, efficient, and happy. We talked through an example program, eng onboarding, and an example system, an ownership application. In this post, we’ll share two more examples of areas where Eng Ops helped scale engineering at Dropbox.
To tackle the most pressing issues faced by a rapidly scaling engineering organization, we always start with a crisp problem statement. We look for inefficiencies slowing down engineers and opportunities to make them more engaged. At Dropbox from 2014–2018, as we grew from 100 to 800 engineers, there was no shortage of emergent challenges. Here, we’ll highlight two and explain how Eng Ops solved them.
Org Problem #1: Meeting Overkill
In 2015, the rapidly scaling engineering org at Dropbox was growing increasingly complex across many dimensions. Seattle was rapidly expanding and we were growing new engineering offices in New York and Tel Aviv. Documentation couldn’t keep up with the expanding codebase and Dropboxers depended on in-person meetings and relationships to share knowledge. More org layers were introduced to account for the burgeoning technical and product surface area, which meant more coordination across teams and more reporting up the management chain. We were also still hiring at a rapid clip, which meant conducting lots of interviews. These challenges led to much less time for focused knowledge work and much less time for writing code. Engineers weren’t productive or happy.
There are numerous attractive ways to solve these problems: improve the culture of documentation and knowledge sharing, streamline systems of reporting (re-org, anyone?), make meetings more efficient, improve the efficiency of the interview process, and many more. At one point or another, we pursued many of these solutions, but it isn’t where we started. We started at the heart of the problem: there were too many meetings and not enough maker time.
Eng Ops Solution: Establish No Meeting Wednesday (NMW)
Why Wednesday? Mondays and Fridays are valuable bookends to the week: alignment happens on Monday and valuable retrospectives happen on Friday. Tuesdays occasionally become Mondays with periodic three-day weekends. Thursdays were another solid contender, but Wednesday, being the most removed from the weekend, won out.
We knew that a No Meeting Wednesday (NMW) policy, in-and-of-itself, wouldn’t outright reduce the number of meetings; it might simply displace them to the other days. However, we believed it would become a great forcing function to change meeting behavior broadly. By making the problem on other days worse, it would encourage the adoption of proximate solutions. But we also knew that there were many other failure modes that we’d have to watch out for.
NMW Failure Modes & their mitigations:
1. Super Meeting Overkill on other days: without time to meet on Wednesday, the remaining days of the week could become overrun with meetings and every person’s calendar would need to be reset.
- Mitigation: Eng Ops aggressively campaigned for and began implementing more efficient meeting culture. We led by example, with the org-wide meetings we ran, like eng manager meetings and product strategy reviews, by setting and communicating clear meeting objectives and agendas, by proactively canceling or reducing meeting times as needed, and by sharing detailed meeting notes, so only those actively involved in the meeting needed to attend it live. We also revisited the operating cadence of the eng leadership team, pruning recurring syncs that were no longer needed and more deliberately aligning and sequencing meetings that we elected to keep. While eliminating Wednesday meetings initially disrupted schedules, it forced us to critically examine our meeting hygiene and reconstruct our calendars with more intention, and ultimately increased maker time.
2. Poor coordination among teams: some meetings are really valuable for alignment and advancement. Less meeting time could result in less alignment.
- Mitigation: we exempted managers from NMW. While managers would also derive benefit from fewer meetings, we decided that protecting maker time for IC engineers was a greater priority. We updated our expectations and training for eng managers, making cross-team alignment and protecting maker time an explicit responsibility for them. We also encouraged, and saw success in, getting most manager-only syncs moved to Wednesdays, freeing up time on other days of the week.
3. Reduced collaboration across challenging timezones: Our Tel Aviv office operated +10 hours from our SF headquarters. The timezone shift, coupled with the fact that they work Sunday through Thursday, meant that by the time engineers sat down at their laptops on a Monday morning, 40% of the Tel Aviv work week had already elapsed.
- Mitigation: Meetings with Tel Aviv were exempt from NMW. The overlapping work window with Tel Aviv was small, so Wednesday meetings from 8–10 am PST with IC engineers were allowed.
4. Decreasing efficiency of the recruiting machine: Dropbox had a well-oiled eng recruiting machine. We conducted hundreds of interviews, screens, sell chats, etc each week and there was push back on eliminating interviewing, which took away from maker time, on Wednesday. How could we handle the high volume of eng interviews if we eliminated 20% of scheduling capacity?
- Mitigation: Eng Ops partnered with the recruiting team to make the entire system more efficient. There is another blog post to be written on this topic, but we built better systems for knowing which engineers were calibrated on which technical questions and got new engineers trained as interviewers faster. By increasing the pool of available interviewers, we were able to actually increase the recruiting capacity, despite losing a full day for interviewing. We also did an analysis on the effectiveness of our technical interview questions, deprecating the least signal-ful and driving the creation of new questions. NMW forced us to make the recruiting machine run more efficiently.
NMW was a stake in the ground demonstrating our commitment to increasing an engineer’s maker time. Eng Ops took the lead by establishing these principles, creating an execution plan, and navigating the problems surfaced above. We began by piloting NMW for a quarter. We carefully collected our baseline stats, primarily around engineers’ self-perception of productivity, and sampled a number of calendars for absolute time spent in syncs with others. We monitored recruiting efficiency, primarily our time-to-hire stat. At the end of the pilot, the response was exceedingly positive. A vast majority of IC engineers reported an increase in productivity and more than one wrote that we’d have to pry NMW out of their cold, dead calendars if we wanted to eliminate it.
During these COVID times, No Meeting Wednesday is potentially more attractive and valuable than ever. While there is certainly a need to stay more connected to your distributed team and an increased sense of isolation for some, there is also a growing sense of “Zoom Fatigue” — too many meetings, too much time staring at small faces in your monitor, communicating over intermittent internet connectivity issues. NMW offers a nice, mid-week reprieve and an opportunity to get into flow, wherever you may be working.
Org Problem #2: Incentivizing Engagement
As the Eng Org grows, there are more and more opportunities for engineers to engage in and contribute to org-wide programs: mentoring interns and new hires, teaching onboarding courses, writing blog posts, creating new interview questions, participating in campus visits and other recruiting events, organizing hackathons, etc. These evolving challenges are often deliberately unstaffed — it’s inefficient to allocate headcount against these relatively small, broadly-diverse, org-wide problems — at least until you decide to invest in Eng Ops more heavily. And yet, this work is impactful enough to be tackled. You may find high-performing and high-burnout-risk volunteer engineers, who take pride in editing the company and building community, take ownership. However, this additional work requires commitment, and because engineers are more often evaluated by their impact on product or infrastructure, they are not directly incentivized to volunteer for these important but rarely urgent cultural contributions.
Again, there are many ways to solve this problem: re-write your performance framework to properly reward these contributions, hire more Eng Ops program managers, require company building, etc. We chose a different solution: establish a permanent, publicly visible recognition system to incentivize and celebrate cultural contributions.
Eng Ops Solution: Badges Recognition System
Moments of recognition take many forms: a shoutout in an email announcing a new product launch, a picture of project contributors on a slide at All Hands, an email from the CEO thanking the team for a job well done.
Yet, these moments of recognition are just that: moments. They’re ephemeral instances of appreciation that fade into the thicket of noise: emails, chat messages, meetings, etc. We needed a system in which public recognition and visible examples of exemplary work would endure.
During one of Dropbox’s famous Hack Weeks, we created a badging system built on top of the internal employee directory, called Dropabout. Dropboxers were granted badges for specific contributions or achievements that we wanted to further incentivize, like teaching an eng onboarding class, filing for and having a patent approved, winning a Hack Week award, etc. These badges were prominently displayed on individuals’ profile pages, and Dropboxers could not only nominate themselves and others to be awarded existing badges, they could also suggest the creation of brand new badges, like contributing to our design systems library or making meaningful contributions to our documentation or, my personal favorite, the Dead Code Society badge for deleting more than 10,000 lines of code. We also built an underlying notification system so Dropboxers and their managers would receive an email when a new badge was earned.
Eng Ops product managed the Badges system, partnering with two engineers on its creation, and then managed the operations of the program, granting badges, establishing new ones, and building out additional features (the leadership board was quite popular!). We were able to measure behavior change through the up-tick in volunteerism for org-wide programs and sentiment change through our company wide engagement surveys, though the response to statements like “I feel recognized for my contributions.” and “I feel like I belong.”
Tying it all together
There are no shortage of problems faced by a rapidly growing eng org. In the two examples above, the Eng Ops team took the same approach: deeply understand the problem, articulate the principles, values, and priorities that will guide the decisions and trade-offs you’ll have to make, and then execute on your solution. To help us identify the best solution, we asked ourselves three questions, about culture, process, and tooling:
- Will your culture adopt and value the proposed solution?
- Is there a clear, reasonable process or policy to follow such that the solution is as frictionless as possible?
- Do you have tools to support the process to automate the solution and help it scale systematically?
For No Meeting Wednesday, the culture was very ready to embrace meeting reduction and we had the necessary tools (primarily Google Calendar and Google Groups), so we focused on building the right process and policy.
For Badges, the culture was hungry for recognition and we already had processes to highlight and express gratitude through one-off segments at All Hands, occasional org-wide emails, and our performance review process. What we didn’t have was tooling and infrastructure to make this recognition durable, visible, and scalable, so we focused on building a web app on top of our employee directory.
Identifying and prioritizing your org’s problems are just the beginning. You need to have organized, thoughtful, org influencers who are charged with bringing the solutions to life by collecting and analyzing data, building internal tools, and conducting targeted training. An Eng Ops function, which specializes in building programs and systems to make the org more effective, efficient, and happy is a great solution to making this happen.
