The Gist

Building software teams is a very difficult task. In most organizations, managers cobble together teams based primarily on who’s available when the team is forming. Since managers can only know so much about the skills and relationships of each engineer, forming teams this way is chaotic and produces inconsistent results. Instead of management selecting teams, what if engineers created their own teams based on need, past experience, relationships, and doing what’s best for the company? Creating Great Teams by Sandy Mamoli and David Mole (published by PragProg) explores the team self-selection process in great details with step-by-step instructions on running one’s own self-selection event.

Takeaways

Managerial selection is the act of management selecting teams. Self-selection is the act of individuals deciding which team to be on

Managerial selection works really well for smaller companies as there are fewer variables. As an organization grows, it’s illogical to assume that a single manager forming a team can continue to know every engineer’s skills, interests, career path, and personal relationships with all the other engineers and managers in the company. The writers of Creating Great Teams believe that managerial selection can begin to break down with as few as 10 engineers in an organization.

Managerial selection has the tendency to treat people as interchangeable parts. Every engineer has a different personality and skillset. Project A doesn’t need “Generic Engineer”, it needs Sally and her particular brand of software development.

Engineers working on multiple projects is non-optimal. Everyone agrees that there is a cost to context-switching in productivity, but there is also a cost in engineer happiness and energy levels. The concept of putting engineers on multiple projects is guided by utilization numbers. Utilization tells a manager that Joe is 50% on Project A, so the manager also puts him 25% or 50% on Project B. Utilization-based team design treats engineers like computers as opposed to really nerdy, easily-agitated human beings.

Of course, we already know that self-selection has the potential to build really cool software. Every hackathon weekend starts with engineers building self-selected teams, and these teams are able to crank out more code in the course of a weekend than some projects team can in a month. It’s not just the lack of rules that’s making these teams more productive, but the joy of working with people you like and the motivation of working on something that interests you.

Convincing an organization to try self-selecting teams is an exercise in public relations. Everyone needs to be on-board and no one can undermine the self-selection process. If “management” decides that Betty would be better off on Project B than on Project A and moves her after the self-selection process, people will lose faith in the whole event.

People will generally do what’s best for the company. Self-selection is a socialist process, where everyone will want to feel good about the outcome. If there is a project that doesn’t seem very fun but is vital to the organization’s success, someone is guaranteed to bite the bullet and put themselves on that project for the sake of the company.

The middle of the book is dedicated to setting up and running a self-selection event. Setting up the event is a tough process and may take several iterations.

My Action Items

• Perform a trial event. At some point in the near future, I want to be involved with a trial self-selection event at my current organization. We have several outlets to do this, such as the Leadership Review or a Lunch and Learn. Although it might be difficult to put company-wide self-selected teams into practice at my organization due to the client-based nature of our work, I am positive we would have many wonderful insights from running a trial event.
• Read Daniel Pink’s Drive. Drive is about what motivates people and is cited several times throughout this book. I’ve been meaning to do this since I read Punished By Rewards, but now it’s officially on my up-next reading list.
• Read Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds. Scaling Agile at Spotify is a whitepaper by some of the employees at Spotify discussing how Spotify was able to successfully scale Agile within their organization by breaking groups down into smaller and smaller subgroups.
• Talk about it. I was invited to join a small book group to discuss the implications of this book after the holiday. Hopefully we can find a way to implement some small amount of self-selection within our own organization, or at the very least determine all the current blockers for doing self-selection. I’ll note that this book group is a self-selected team.