What Happens When Agile Engineering Teams Self Organize?

We strive to make engineering at Qumulo an organization that is agile and self-organizes. We do this for two reasons: to effectively meet the needs of our customers and provide a rewarding and agile 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.

So what does an agile team at Qumulo look like? For us, they are self-organizing teams that provide autonomy that encourages creativity for each member. The results are seen in the daily contributions from each of our team members.

What is it like to work on agile teams? Click here to learn more about life at Qumulo

It is your teammates who 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 Around Agile 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 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 build their skills around managing agile development teams. We wanted each of our agile development teams to be just that. Agile. So what is an agile team at Qumulo? Each agile team:

• Has six engineers
• Starts with a founding team member (one of our senior developers), a Product Owner (PO), and a work stream
• 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
• Is not allowed more than two people who are three years or less in the industry.
• Can not have a multiple people who come from one previous company with anti-collaborative cultures
• Must be comprised of people that want to be on the team and have approval from the founding member

The roll-out process we used was this:

• We told 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 had an Engineering all-hands lunch where each Team Founder / PO combination pitched their team and their work stream.
• We had a wall with each Engineer’s name on a sticky note. We then took sticky and put it onto a poster for the team they want to join.

Instead of everyone taking a few days to decide what their first choice team was, we all moved our stickies in a flurry of activity, and within minutes every sticky was on a team poster. Team founders and engineering leaders meet later in the same day to debrief.

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 was an exercise to ensure self-organization, our agile coaches urged the group to simply go back to the team, highlight the issues, and allow the individuals to work it out. We followed the agile coaches’ advice.

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

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 four and teams of eight. We have teams without senior engineers. Our agile development teams 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 five to ten 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 agile engineering team? We’re always looking for the right people. And subscribe to our blog for more helpful best practices and resources!