Opower Case Study: Running a Self-Selection Pilot in Three Weeks
This spring, after a large internal reorganization, Opower, a software company based outside of Washington, DC, experimented with self-selection. Forty distributed engineers were allowed to choose what team and projects they would be working on for the next six months. The catch? We had to figure out how to introduce, prep, and run a self-selection exercise successfully in just three weeks. This is how we did it.
Opower is a SaaS company that develops software for the utility industry. At the intersection of behavioral science and energy savings, our main product, the Home Energy Report, compares household energy usage with neighbors’, using ‘good peer pressure’ to get large numbers of people to save energy. Each year, our programs save nearly enough energy to take the Hoover Dam offline. We have a distributed engineering team in Arlington, VA, San Francisco, CA, and Odessa, Ukraine, with approximately 175 engineers organized into scrum teams and tribes using the Spotify model.
Why Did We Self-Select?
Our entire engineering organization restructured at the beginning of April 2016, to better align our people with our future goals. In the process, the Outbound/Demand Side Management (DSM) tribe, responsible for all of our outbound communications and energy efficiency programs gained six new products. The new tribe could no longer organize around singleproduct teams, not everyone was happy with their place in the new structure, and teams were not wellbalanced. We decided to try the selfselecting teams exercise to rebalance the tribe and empower our engineers to choose what THEY wanted to work on as well as pilot self-selection to see if it could work across Opower.
We had exactly three weeks to do all of our preparation for selfselection. We needed to get the new teams up and running quickly, so we researched the process, paired Product Managers with Engineering Managers, developed project lists for each team, discussed the process with our tribe and broader organization, fielded questions and concerns, setup the event, and ran it all between 4/11/16 & 4/29/16.
What We Did Differently
Given such a short runway, there were a lot of things we decided to do a bit differently:
- Shared Team Info 3 Days in Advance
Some engineers had pre-planned vacations or simply wanted to mull over their choices ahead of time, so we shared our team information three days before the event.
- Proxies or Top 3 Choices
People who had to miss the event were allowed to pick proxies or send the tribe leads their top three choices ahead of time.
- Distributed Event
No one traveled for the event. Instead, we used Lifesize to bring three rooms together (one in Arlington, VA, one in San Francisco, CA, and one in Odessa, Ukraine) and had ‘Location Captains’ that were responsible for digitizing the choices made in each of their rooms. We uploaded all team and individual info sheets to shared Google Drive folders and kept a digital version of team choices after each round in Trello.
- Switch Period
To better accommodate the portion of our engineers who like to think their decisions over, we had a ‘switch period’ in which you could raise your hand and ask to be considered for another team. This lasted from the end of the self-selection event on 4/29 through 2pm EST the Monday after (5/2). Spoiler Alert: No one needed to use the switch period!
How We Did This in Three Weeks! (Deep Dive into Opower’s Selection Process)
Here’s how we pulled everything off in just three weeks!
Research (Approximately 1 week): Our tribe leads needed a solution to a big problem: how do we form teams around a new set of products with fewer people to support them? We quickly saw self-selection as a viable answer. We read Creating Great Teams: How Self-Selection Lets People Excel by Sandy Mamoli and David Mole, which gave us a great framework for moving forward. During this week, we drafted out our version of the process and came up with the following rules for our event:
- Do what’s best for Opower!
- Teams should be 4 - 6 people
- Teams should be co-located if possible
- One Engineering Manager
- One Product Manager
- One Quality Assurance Engineer
Introducing Self-Selection (1 hour): We held a tribe all-hands in which we discussed the self-selection process and fielded a lot of questions. We got some great feedback, but because we didn’t have team missions, Product Managers, or Engineering Managers set, most people left the room feeling, at best, cautiously optimistic. We proactively reached out to most tribe members individually and in groups over the next week to find out if there were any real issues with the process and to get further suggestions and feedback.
Determining Teams, Leads, & Project Lists (1 – 1.5 weeks): Following the info session, we had little time to figure out team leads and prioritize product investments. We had to move quickly because we knew the selfselection event was coming up and we wanted to be prepared. At the time, we had around 15 products that consisted of UI frameworks, consumer facing communications, batched jobs and products that were in alpha, beta and general availability (GA). We had to prioritize and carefully select the products that we felt would be most valuable to invest in. During this week, all engineering managers and product managers got in one room and started listing everything that we had planned to work on for the upcoming two quarters. In order to help prioritize product investments, product managers worked with the sales organization to understand the sales pipeline and revenue models for many of these products. At the end of the three hour session, we were left with the most important tasks and features that we wanted to finish.
Structuring Teams with Team Themes:
In the past, we had one team dedicated to each product, but this time we didn’t have enough teams to cover all products. What we did instead was form themes around the cross-product work that needed to be completed. Instead of having one team dedicated to a product, we had a team dedicated to building key sets of features and functionalities that would span multiple products. We expect this will also result in a consistency across products that was not present when solution decisions were made within the context of a single product team. By the end of
this week, we had six cross-product themes of work that were allocated across six engineering managers and aligned with the revised top priorities of the tribe.
Team Templates (2 – 3 Days): Using Google Documents, we created a team template that included the team name, team goals/projects for the next six months, Product Manager, Engineering Manager, their photos, info about them and why you’d want to work for them, and skills needed. These were sent to team leads at the end of Week 2 (4/21) and were due Monday of Week 3 (4/25).
Individual Templates (2 – 3 Days): We created a template for each engineer in Google Documents that listed their name, photo, location, favorite movie and hobbies (for fun!), and the skills they bring to the table. These templates were sent out at the beginning of Week 3. Engineers were asked to print and bring them to the event as well as upload a copy to a centralized folder.
Room Set-up & Location Captains (2 Days)
One person in each location served as the ‘Location Captain’. They were responsible for setting up the room: hanging team descriptions, hanging rules, and creating an “I am not on a team” space (which, for us, was never used). They were also responsible for helping to mediate stalemates and digitize the team selections by adding people to the Self-selection Trello board. Location Captains were found and briefed a few days before the event.
Event Day (3 Hours)!
Our Selection Event took place on Friday, 4/29. We made sure to order dinner for Odessa, whose team stayed late for the event, lunch for Arlington, and breakfast for San Francisco, whose team came in early for the event. Having everyone connected at one time was key, even though it meant extra hours for portions of the tribe.
- 11.00am – 11.15am EST: Gather & Explain Logistics
- 11.15am – Noon EST: PMs/EMs pitch their teams and answer questions (each team gets 5 – 10 mins)
- Noon - 12.15pm EST: Break to Grab Food & Further Questions
- 12.15 – 12.30pm EST: Round 1
- People place their individual info on teams
- Location Captains digitize the results as they happen
- 12.30pm – 12.45pm: Assess
- Are any teams complete? Take them down.
- Point out gaps
- 12.45pm – 1.00pm: Round 2
- Repeat, 10 minutes for a self-selection round and 10 minutes to assess; stop when teams are full, nothing is changing, or we run out of time
Round 1: The results after round 1 were shocking. We expected to have maybe one team filled, but instead we had three teams filled, and two of them were fully co-located in Odessa. We still needed to staff three teams.
Round 2: Very little movement. We had two teams that were understaffed and one giant team with 11 people on it. We asked that group to go off on their own and figure out who would move. That worked terribly. Some intervention was needed.
Round 3: We had a full-fledged stalemate. We really only needed 1 – 2 people to move, but no one wanted to volunteer and be that person. It was clear that further rounds would not be successful unless we could break the stalemate. We turned the timer off and took a different approach.
Breaking the Stalemate: Our Engineering Director started a conversation, discussing everyone’s motivations for being on the over-staffed team (people loved that it was a full-stack team, they wanted to work with the leads, they wanted to do front-end work, etc). After one of our engineers spoke about wanting to work on a front-end solution that we call the Monitoring Dashboard, one of our Agile Program Managers realized that if we moved the Monitoring Dashboard work to one of the open teams, 1 – 2 engineers would happily come with it. After several sidebars, the matter was decided. The stalemate was over, we had our teams filled, and the event ended 30 minutes ahead of schedule!
Post-Event: We held a tribe leads meeting the Monday after the event to finalize teams and discuss any switch requests. We had no switch requests and very little to talk about in that meeting. Everyone was happy with their teams.
We sent a follow-up survey to all engineers immediately after the event and found that the majority of people were happy with their decisions. We also learned some new things that we didn’t expect. We asked: “Did you end up on the team you thought you would?”
Product and engineering managers, whose teams were determined ahead of time, account for the 28% of respondents who chose “Not applicable to me.” All but one participant (4%) ended up on the team they expected to going into the event. We then asked “Are you happy with team you will be on?”
This was surprisingly very high! Almost 90% of the people were happy with their selection and ended up on a team that worked out for them. Finally, we asked “What primarily drove your self-selection choices?” We had thought that most people would choose teams based on the type of project they wanted to work on. But instead, as seen below, we found that most made their decision based on the best interests of the company as well as the people they wanted to work with.
One of the things we frequently hear from skeptics of this method are that “people will just work on what they want and leave the company high and dry.” As you can see here, a plurality (40%) of the respondents primarily chose their team based on the best interests of the company and then, secondarily, were driven by the people they would be working with (28%). It is important to note here the positive impact empowering employees to work with the people that they wanted to can have on worker happiness (Figure 2). Additionally, while it may seem that the type of
work chosen was comparatively less important based on this data, our experience suggested that every team needs to have a critical mass of compelling work in order for everyone to come out moderately happy with the process.
In the end, we came out of this experiment energized and optimistic that self-selection would end up being positive for the company. After reading the quote below from one of our engineers and seeing the data above, it truly felt amazing to know that we made our tribe happy with the process.
“Looking at the outcome of the process, it is difficult to argue against each team appears well-suited to meet its short term needs and the teams are reasonably well-distributed. If we had done this through another process 100 times, I believe that most of the outcomes would not have been as good as this one.”
– Josh Essex
Despite the fact that we held a very successful event, there are quite a few things we will do differently next time.
- Don’t share the team information more than a day ahead of time.
With three days to discuss and form alliances, there was a fair amount of backroom discussions and decisions made. This frustrated many of the engineers who felt they adhered to the spirit of the process. Knowing the team structure ahead of time leaves too much room for politics and it would be better to wait until the event day to share this information.
- It’s important to have people in the room who can moderate and read the room.
Left to their own devices, our large team wasn’t able to ‘vote anyone off the island’ (they’re great people to work with, after all). It was only through coaching and moderation that we finally were able to form balanced teams. Recognizing a potential breakthrough and digging a little deeper to figure out what’s really motivating people is really important.
- People love full stack.
Most people were drawn to the teams that had control of their products, end-to-end. When possible, form teams that allow engineers to work on the full stack.
- Set expectations.
We did a pretty good job of setting the expectation that this first pilot would be chaotic. It was in some ways, not in others, but people didn’t seem to mind because they expected it.
- Directors should not be in the room because they encourage people to act differently.
We found that people could be shy in front of managers, directors and VPs. At times, we had to have a difficult conversation with an engineer regarding why they want to join a team and why they couldn’t be part of another team. This put people in an uncomfortable position. We learned that we should motivate people to talk amongst themselves. If directors, tribe leads or VPs are in the room, then people generally look towards them to solve issues. Instead, self-selection should really be about allowing team members to make their own decision and be able to have an open conversation when there is a deadlock on team structures.
- No computers!
Everyone should be in the room and should not be distracted. Have them put their computers away and have some fun!
- Remote meetings are horrible :(
Enough said. If we had the time and travel dollars, we would bring everyone together into the same location. The good news is that this process works with distributed teams, even if you can’t travel.
We’re extremely happy with the way the self-selection process worked and would love to do it again on a broader scale. Our new teams went into effect on 5/16 and we’re looking forward to watching them gel and checking in with them on a regular basis.
WHERE TO FIND OUT MORE
We explain in a lot more detail just how the process works and use real-life examples from companies who have used this with 200+ people at a time. If you would like to read more, our book ‘Creating Great Teams: How Self-Selection Lets People Excel’ is available from the Pragmatic Bookshelf and from Amazon.