Behind the Scenes: How Self-Organizing Engineering Teams Build Stellar Products

Posted June 2, 2017 by Molly Brown — Director of Engineering. Filed under Company, Engineering.

In the Qumulo Engineering team, we strive to build an organization that self-organizes. We do this for two reasons: to effectively meet the needs of our customers and provide a rewarding work environment for our engineers. We believe this creates a virtuous cycle – people who enjoy where they work and make their best contributions each day are more likely to build high-quality products for our customers. Self-organizing engineering teams provide autonomy that encourages creativity. The results are seen in the daily contributions from each of our team members.

It is your teammates that drive both your work satisfaction and work quality – they are the people with whom you work most closely from day to day. We are very intentional about team selection and movement between teams. We want it to be something that fosters self-organization by the team members themselves, while also helping deliver compelling improvements to our customers every two weeks.

Building a Culture of Self-Organizing Engineering Teams

In the early years of the company, the engineering organization was smallish – about 4-5 teams. Most projects took about 3 months, so once a quarter team membership shifted to bring the people with the ‘right skills’ to the next set of projects that were starting. The team changes and team membership were largely determined by the VP of Engineering. This had a few unintended consequences:

  1. There was an expectation in most teams that they wouldn’t be in place for more than a few months, so the individuals on the team weren’t highly motivated to ensure that the team worked well together.
  2. Engineers felt little agency in team formation and membership decisions. They waited for someone to tell them where to go, which wasn’t the environment we wanted to foster.

Then in January of 2015, we decided to change how we organized teams. We wanted our teams to be high-performing, adaptive to product demands, and give members the chance to develop their own management skills. The structure we ultimately adopted looked like this:

  • Each team to have 6 engineers, except for the Customer Success team which will be 3.
  • Each team starts off with a founding team member (one of our senior devs), a Product Owner (PO), and a work stream.
  • Each team is expected to last beyond the currently defined work stream, so engineers pick based not only on the current project but also on people with whom they work well.
  • No team is allowed more than 2 people who are 3 years or less in the industry.
  • No team is allowed a critical mass of people who come from one previous company with anti-collaborative cultures.
  • Team members must talk with the team’s founding member to get on the team. Both must feel the match is good.

The roll-out process we used was this:

  • We tell everyone in Engineering that this will be happening and when.
  • We let them know of the constraints around the teams, listed above.
  • A week later, we have an Engineering all-hands lunch where each Team Founder / PO combination pitch their team and their work stream.
  • We have a wall with each Engineer’s name on a sticky note. The Engineer takes their sticky and puts it onto a poster for the team they want to join.

Instead of engineers taking a few days to decide what their first choice team is, they all move their stickies in a flurry of activity, and within minutes every sticky is on a team poster.

Team founders and engineering leaders meet later in the same day to debrief. There is some speculation about which teams will be great, and which teams will have issues. We look over the elections, and there are a few places in which the constraints weren’t respected, mostly around having too many junior engineers on one team, and less than 6 people on another.

At first, there was a desire on the part of the team founders and engineering leaders to move people around right then and there. However, as this is an exercise to ensure self-organization, our agile coaches urged the group to simply go back to the Engineers, highlight the issues, and allow the individuals to work it out. We followed the agile coaches’ advice.

Within a few days, all issues are resolved. The teams started with team kickoffs a week later, and they were off to the races!

The Results of Self-Organizing Engineering Teams

That was nearly two and a half years ago. Since then, we have learned many things. Those that stand out the most are:

  • It’s great that no single person has the burden of having to create perfect team membership; we get the benefit of many perspectives and that often leads to better solutions.
  • Over time, it was proven that teams who had individuals who were committed to working together and becoming high performing did well. The teams who were not bought in did not. We now explicitly screen for teaming skills to compliment strong technical skills when interviewing potential engineers. We also support our new team members to become aware of and help develop these skills once they join our team.
  • To this day, team moves are initiated by the individuals themselves. We have one team with rotational membership for which people volunteer. When the rotations are done, those individuals may return to their former team, seed a new team, or match to an existing team which has an open space. If an Engineer decides they want to move to a new team for any reason (to work on a different project, learn a skill, work with a friend) they initiate the move, and the match must be a two-way fit between Engineer and team. With this system, individuals feel completely free to decline an invitation by another (regardless of rank) to move teams.
  • Things get messy at times and that’s okay. We have teams of 4 and teams of 8. We have teams without senior engineers. We still build a great product. We still strive for high performance.
  • It takes more than a single team self-selection process for everyone to really internalize this process. We follow team-selection exercises with frequent reminders of how our system works. We also coach individuals through the process of re-matching to a new team.
  • Once people do embrace the responsibility for ensuring they are on the best team for them, they suddenly want to be in control of other aspects of their work life, like what projects their team works on!

As we’ve grown from 5 to 10 teams, these structures continue to work for us. For the foreseeable future, we believe they will continue to provide enough support going forward, but we do keep watch for tweaks that help keep us true to our goal of building a self-organizing engineering team and create an environment where we can do our best work while building products that continue to delight our customers. Interested in being part of a self-organizing engineering team? We’re always looking for the right people.

224x224
Molly Brown
Director of Engineering
The self-organizing team structure at Qumulo fosters autonomy and creativity, which helps our team members make their best contributions each day

Molly is the Director of Engineering and is focused on supporting teams to provide a rewarding work environment while building a product that delights our customers.

Let's start a conversation

We are always looking for new challenges in enterprise storage. Drop us a line and we will be in touch.

Contact Information

REACH US

EMAIL

General: info@qumulo.com
PR & Media: pr@qumulo.com

WORK WITH US

SUPPORT

Search

Enter a search term below