Dahlia Season Consulting

Originally published July 15, 2016 on cocktailmonkey.blog

I walk into my first 1:1 with my new VP of Engineering. He’s 20 minutes late for a 30 minute meeting, and I have no idea what to expect. The first thing he says is, “I want to do a reorg in January.”

I find this statement enormously curious, as just a few days ago he did a mini-reorg, combining two teams into one. It seemed random and disruptive, but maybe he had a good reason to do it. I can’t stop myself from investigating his motives.

“What is it that you want to achieve with the reorg?” I ask.

“The teams are not self-organizing enough,” he says, with a heavy sigh.

Of course, there’s nothing that will motivate teams to self-organize more than $BOSS telling them how to organize. Well, okay, maybe not so much. But I do have a firm policy of never wasting a perfectly good reorg!

What *does* help people learn how to self-organize in a team? Having them self-organize into creating the team itself! So, instead of discouraging the notion of a reorg, I embrace it and float the idea of team self-selection. The VP buys the logic, so I create a proposal and work with the team leads to structure the exercise.

The structure we adopt looks like this:

• We want each team to have six engineers, except for the Customer Success team which will be three.
• Each team starts off with a Team Lead, a Product Owner, and a work stream.
• No team is allowed more than two people who are three years or less in the industry.
• No team is allowed a critical mass of people who come from companies with anti-collaborative cultures. (This rule is secret, only leadership knows about it, and we are just going to keep our eyeballs peeled for potential issues if they arise.)
• Team members must choose the team they want to be on and have a chat with the team lead to get onto the team. Both must feel the match is good.

The roll-out process we use is 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 Lead / 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 the 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.

The leads 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 fewer than six people on another.

There is a desire on the part of the leads to move people around right then and there, to ensure the teams meet the constraints. However, as this is an exercise to ensure self-organization, I urge the group to simply go back to the Engineers, highlight the issues, and allow the individuals to work it out. They do.

Within a few days, all issues are resolved. The teams start with team kickoffs in January, and they’re off to the races!

….

That was a year and a half ago. Since then, I have learned many things. Those that stand out the most are:

• The VP of Engineering appeared to have a heavy weight lifted from him once he no longer felt the burden of having to solely create the most perfect team membership for all teams himself.
• One team that the leads speculated would be amazing wasn’t.
• One team that the leads speculated would have trouble turned out to be amazing.
• Over time it was proven that the teams who had individuals who were committed to teaming well and becoming high performing did well. The teams who had individuals who were not bought in did not do so well.
• The Engineers did indeed learn to self-organize.
• To this day, team moves are initiated by the individuals themselves. We have two teams with rotational membership which people volunteer for. 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, the individuals feel completely free to decline an invitation by another (regardless of rank) to move teams.
• Things get messy. 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.
• For many people, it takes much more than a single team self-selection process for them to internalize that they are in control of their own situation. We have had to follow this exercise 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!

I’m a person who believes that if you structure the system to foster the environment you want, you’ll get it. We structured the system to require choice within constraints, and to foster self-organization. We got it, and even with the messiness, I love it!