It’s widely said that good people are hard to find, and in the tech industry, where a gap still exists between skills needed and qualified candidates, this is even more pronounced. Companies are competing with each other offering higher salaries, more interesting work, upward mobility, and benefits that range from your standard health insurance and 401k, to in-office beer and foosball (apparently all software engineers decided college should extend indefinitely). With such a demand market, it can be challenging to find and successfully recruit the right talent to your company. But what happens when you finally do?
Managing 20, 30, 50+ engineers
At a certain point, the number of engineers you have can’t fit onto one team. Administrative burden, communication, and collision become too difficult and lead to frustration and inefficient development. This is easy to spot; as you add more people, even after the ramp up period ends, you’re slower than you were before. That feeling of moving so fast with a small team is replaced with this heavy burden of making sure everyone is moving in the same direction and it simply feels like you should be getting more done than you are.
It’s at this point, that you begin breaking the group into teams. Some companies choose to split by role (putting all of the web developers on one team), others by business domain (for example, an Order-To-Cash business process), and still others choose a product or module to focus on. I’ve had a lot of conversations around which is best and I have my opinions, but one thing is for certain; you must avoid isolationism.
Getting it wrong
Let’s talk about some of the problems that can happen when you’ve constructed these teams:
- Fiefdoms: The team becomes the sole owners of whatever they are in charge of. They become territorial.
- Tribal Knowledge: Because the team works so closely with this one focus, they stop documenting and knowledge simply exists within the group.
- Echo Chamber: Decisions and approaches to tackling problems don’t expand outside of the group, and yet the group continues to believe they are always coming up with the best way to do it.
- Slowed Growth: A lack of new ideas slows growth of the product as well as the career development of those working in it.
- Terrorists: This is a bit of dramatic wording, but one strong individual in the team, may capitalize the direction of the entire team and therefore the direction of the product/business/etc. Worse still, the team and business believes losing this individual would be so detrimental and costly there is nothing they can do (fear cycle).
- Production Support: The team can’t move quickly on project work and misses dates, but it’s because they’re getting pulled into too many directions, specifically Production Support or Hotfixes.
Getting it right
In my opinion, there are a few simple fixes (at least conceptually) which can resolve most, if not all, of these problems.
Direction: All of us want to be successful, and most engineers I know, want to know what the end goal is and then be allowed to determine the best way to get there. Keeping a pulse of how the teams are doing, as well as checking in on individuals about what they are actually working on (even reviewing code or discussing architecture), helps to guide or refine direction as the team learns new information.
Empowerment: Software development has become much more complex than it ever has been in the past. It takes teams to build great software in most cases, and in order for those teams to be successful, they need to be empowered to make decisions. Engineering teams should not only make technical decisions, they should also help shape the product or business. Don’t be just order takers, be contributors of great ideas and allow your engineers to have this say.
Silver Bullet: Rotate. Yes, if there is one silver bullet to building highly functional teams, it’s to introduce a methodical rotation of fresh ideas, talent, skills, and personalities.
Team Assembly and Rotation
Here’s my go-to recipe for assembling teams, which requires a minimum of six engineers (but I usually prefer eight) and can scale as large as you like. For this example, I’ll assume the following: we’re a company which offers products (either internally or externally) that is consumable via web and mobile, and we prefer to build centralized API’s for our own applications as well as third-party integrations.
My technical role requirements are that we need a frontend engineer (web), a mobile engineer, a backend engineer, and I believe strongly in at least one quality engineer per team.
Feature Team 1: 1 web, 1 mobile, 1 API, 1 QA.
However, I do not want this feature team to be distracted with production support, or ad-hoc small feature requests while they are trying to get the big project work done. So I immediately add another team to focus specifically on support (questions, hot fixes, small features) and I model it with the same exact roles as the Feature Team.
Support: 1 web, 1 mobile, 1 API, 1 QA.
We’re now at eight individuals, all of which are able to perform a specific role on the team to keep them specialized and fast. However, if they run out of work to do (which almost never happens), then they can always jump over and help in an area they are not expert in (giving them a chance to learn new technologies).
Imagine that you have a well defined roadmap of all the projects you plan on doing. In each of these projects that you define, you create epics (small mini-projects that have defined conclusions), and then you assign the Feature Team to work on this epic. At the completion of each epic, you simply rotate a member with your support team that has a matching role (the frontend engineer on the Feature Team swaps with the frontend engineer on the Support Team). After the completion of the next epic, a different role swaps (the backend engineer for example).
As a business, let’s decide that we want to capitalize on more of the opportunities in our roadmap. We’d like to be able to do more than one epic at a time. This becomes simple, and with a known cost. We recruit a new Feature Team which will later become indoctrinated into the rest of the product offerings through their rotation in and out of support and feature teams. Individuals may start in Feature Team 1, move to Support, and then rotate into Feature Team 2.
The following diagram helps to illustrate the assembly of teams I’ve used successfully in the past.
What does this do?
By rotating a member who actively built the new epic into support, you put someone who truly understands the newly built project into supporting it. Even if bugs pop up in areas outside of this individual’s direct technical skillset, they will have enough knowledge of how it’s supposed to work to help guide the right technical skillset on the support team to resolve it.
At the same time, you’ve rotated someone off of support and allowed them to now focus on creating something new, which helps reduce burnout for your support staff. This new individual to the team can now bring a fresh perspective into the next epic.
The team is working closely with a small number of people at a time (maintaining focus and reducing administrative or communication burden), they are also breaking down walls and establishing one large community as they continue to work with each other.
Let’s revisit our list of problems and see if we’ve solved them:
- Fiefdoms: Teams get continuity because the majority stay together after each epic, yet rotation causes ownership to be democratized across the entire organization.
- Tribal Knowledge: Since new members will need to be introduced to the project, documentation and consistency of approach becomes more important.
- Echo Chamber: Fresh ideas are constantly being introduced into the teams and approaches are constructively challenged.
- Slowed Growth: Both the product and individual team members are introduced to new ideas and varying levels of expertise, allowing for a sharing of knowledge on each project.
- Terrorists: No one person has the ability to remain on a project indefinitely, which limits a multitude of risks for products and business processes.
- Production Support: Support is more skilled and involved with the building of each project, while the feature teams are no longer distracted. Estimates become closer to reality.
Nicholas Barger's Blog 