Structuring a Flat Team Effectively

Problem

"When I first started working for Signal Sciences, there were only five engineers. With such a small team, it was easy to foster camaraderie, share responsibilities, and build strong personal relationships. As the team grew and tripled in size, with the majority of the engineers working remotely, I wanted to maintain what we had built, but knowing that it wouldn't scale, I chose to create 3 teams, each with a different manager."

Actions taken

"This approach did maintain the camaraderie within each of the teams and allowed them to share responsibility. The challenges came by putting people on separate teams, it created silos. Also, at 15 engineers we were still too small to make these teams completely independent and I was still giving day to day direction to the engineers around their projects and work. Going through their managers created an unnecessary layer of miscommunication. When I talked to my direct managers, my message would become diluted, and feedback wouldn't be clearly communicated. This led to teams having unclear goals. I realized I had introduced hierarchy too soon. The team was still small enough for me to be setting a lot of the direction. However, the team was too big for me to manage directly. Due to this, I introduced a different kind of structure. Instead of managing through a hierarchy, I created product teams and since our teams are very musical, we called them bands. The bands aren't hierarchical, they are functional in nature. Each band represents a product and a product can be anything - a customer facing feature or IT. Each band pairs a product owner and one or more engineers. The idea behind a band is to be independent and sovereign by nature. Not only did this new approach eliminate the silos while giving each engineer a sense of ownership and responsibility, it removed roadblocks and dependencies."

Lessons learned

"When faced with the exciting challenge of scaling a team, it is important to know what your goals are and what challenges you're trying to solve. Knowing the problem set makes it easier to find the right scale patterns. At the end of the day, there is no perfect answer so don't be afraid to try something - if it's not the right thing you can take the lessons learned from that to find a better solution. Just as in software development, team structure can be iterative."

Key quotes:

• "This approach did maintain the camaraderie within each of the teams and allowed them to share responsibility."
• "Not only did this new approach eliminate the silos while giving each engineer a sense of ownership and responsibility, it removed roadblocks and dependencies."