The Ten-Minute Reorg

I spend a lot of time working with growth-stage startups. I often see similar problems across companies when it comes to scaling up their tech teams. At a certain point, the intuitive way to grow a team breaks down, and a reorganization (“reorg”) is necessary in order to adopt a scalable structure. Where some companies may take months to design and execute a reorg, I prefer to handle the majority of it in about ten minutes. In this post I’ll discuss the rationale, and introduce the major stages of the ten-minute reorg.

Evolution of a Tech Team

When a startup has a small team, usually less than five people at inception, each person will probably have a clear specialization. As the company and workload grows, the intuitive coping method is to hire additional people. The new staff fill a new specialized need in order to maintain the output of the team. If the frontend development team is bogged down with work, another developer is hired to work on frontend tasks. This is similar to vertically scaling a database server, only with people instead of hardware.

Eventually, this single team gets large enough that it’s no longer manageable as a single entity. The intuitive solution is to split it into two teams, and since technology leaders are typically responsible for the team structure, they proceed as they would with a technical problem. There’s a clear interface between the frontend and the backend of their software, so frontend and backend teams are created. The company assumes that each of these teams will continue to scale up both people and output as needed.

However, whereas with technology you have an API facilitating a link between the otherwise decoupled frontend and backend services, this partition doesn’t work as well with teams. There is an inherently strict dependency between both teams in order to deliver a product to the customer: the backend can’t be delivered without the frontend, and the frontend can’t be useful without the backend. This organizational structure provides many opportunities for conflict and roadblocks when it comes to expediently releasing products to customers.

The result of continuing to scale these vertical teams is an increase in headcount, staff costs, communication complexities, software complexities - and a decrease in output.

If vertical teams aren’t the answer, then what should we do?

Enter Feature Teams

Instead of hiring more people in an attempt to solve a bottlenecked area and ultimately adding to the problem, there’s a much simpler fix available. Take your current organizational chart, rotate it 90 degrees (or Pi/2 radians if you prefer) and use that as your new organizational chart. The columns of the chart represent your new cross-functional teams, each with their own team lead who reports to the next level of leadership in the organization. In growth-stage startups, this is usually the CTO.

The benefits of having teams with this composition are immense. Instead of a particular feature having to go through multiple steps and teams in order to arrive at the customer, a single team can now handle the implementation, testing, and deployment. By reducing the number of dependencies from multiple tiers in multiple teams to a single streamlined team, a company can quickly and much more efficiently progress from idea to deployed feature.

Feature teams work from a single, prioritized backlog. They can pull stories from the backlog as quickly as they have capacity available. The priority of the backlog is decided by the Product organization, so feature teams never have any confusion about what they’ll work on next.

Teams develop features in parallel, and each feature goes through the deployment pipeline as part of a continuous delivery process. The flow resembles a standard fan-out/fan-in pattern similar to a high-performance processing system, except with people and teams instead of worker threads and queues.

Implementing the Ten-Minute Reorg

When moving to this type of scalable organization, the most significant change is from having all teams report to a single leader (probably a CTO) to having each team report to their own team lead, who in turn reports to the CTO. Anecdotally, I’ve found that when technology organizations grow to around twenty or twenty-five people, they simply cease to function effectively without this intermediate leadership layer.

Step 1: Selecting the Team Leads

The first thing to consider is that the team lead is a not necessarily a tech lead. The team lead may or may not be the most technically competent person on the team. Leading a team requires many skills in addition to technical capability, including communication, planning, managing expectations, and the ability to ask tough questions and provide tough feedback. The first and foremost job of the team leader is to ensure that the team has everything it needs in order to be able to have a high output of features to customers. Sometimes the best technically-minded developers aren’t strong enough in these important areas to be a suitable choice for team lead without further management skills training.

You’ll need as many team leads as you will have teams. I suggest a team size of four to five members, plus the team lead. This allows for two backend developers, a frontend developer, and someone specializing in testing. In larger organizations, the size of the team may increase to also include someone who specializes in databases, someone with a focused development operations background, or similar. Regardless of the number of people, the team should, to the extent possible, have all the skills needed in order to take ideas through the entire development process and deploy features to customers.

Step 2: Get the Team Leads on Board

Have a meeting with the prospective team leads. Provide them with the background of why the current structure is no longer suitable, and how they can expect the organizational flow to evolve. Help them understand that having cross-functional teams allows your organization to parallelize development and become much more effective. While dependencies between teams or different software components may still exist, they will be reduced in comparison to a totally separated frontend team and backend team.

Describe the role of the team lead. Communicate that this meeting is taking place because you believe those in attendance have the potential to be great team leads. Impress upon them that the team lead role is perhaps the most important in the entire tech organization. Team leads serve as the glue between ground-level operations and code, and the big-picture goals at the strategic level. They are the communication interface between ideas and output.

Make sure you get their support, since you’ll need it in the weeks ahead.

Step 3: Get the Whole Tech Team on Board

Have a meeting with the whole tech team. Help them understand the same goals you impressed upon the team leads, but most importantly, as always, communicate the why of these goals.

Often, people are worried about blowback from employees. In general, I’ve found the opposite to be true. Once people understand that this evolved company structure will allow them to be more productive and to have more ownership of their work, they tend to be extremely excited about the changes.

There will, however, be some people who are apprehensive about these changes. I’ve found this generally to be due one of two reasons.

In some cases, the person is just naturally averse to change and might have some legitimate concerns. Hear them out and try to address their worries.

In other cases, certain people may be unhappy for a more problematic reason. Quite simply, they’re unhappy because in this new model there will be nowhere for slackers to hide. In a large team of developers, someone who wants to coast and not actively produce can slip by unnoticed for some time. However, as part of a tight team geared for high output with only one or two people assigned to a certain skill area, it becomes quickly apparent when one person isn’t performing as well as the others. Those who fall into this category of concern tend to be the most vocal in their opposition, reflecting the fact that they have the most to lose from being noticed. Deflect their questions and speak with them privately after the general meeting. If further investigation reveals that they can’t perform because they lack the necessary mentoring or development, then it’s partially your responsibility as a leader to address their needs. If they simply don’t want to be responsible for performing, then it’s your responsibility as a leader to fire them. Small, high-output feature teams cannot abide members who don’t have the drive to perform.

After the briefing, the entire tech team should be aware of the current state, be on board for the goals to be accomplished, and understand the reasons for wanting to accomplish these goals. The team lead role should be sufficiently explained, and those who have accepted your nomination to become team leads should be introduced as such to the rest of the team. Now, it’s time for the actual reorg.

Step 4: The Ten-Minute Reorg

Many companies will take weeks to accomplish this next step. Growth-stage startups can’t afford that long. Luckily, it only needs to take about ten minutes.

Have the team leads stand in maximally separated areas of the room. Explain that the goal is to create a first draft of the new company structure. Teams should be as balanced as possible given the skills present in the current employees, and you as a leader will have the final say on team makeup in order to provide better balance, plan for future staffing, and make other strategic decisions. The goal is to get as close as possible to a reasonable approximation of the final teams. Have everyone assign themselves to teams by standing with the appropriate team leader. Give them ten minutes to accomplish this objective.

Be on hand to answer questions that will almost certainly arise during this time. After the ten minutes are up, make note of the people on each potential team, and thank everyone for their time. Let them know that the reorg will undergo further discussion with the team leads before everything is final.

Step 5: What Next?

Talk with the team leads about the prospective teams. Address any concerns about balance of skills or personalities of the people within each team, and as much as possible with your current staff, balance the team. If there are gaps, these will be filled by cross-training, hiring, or some combination of the two. However, don’t treat every skill shortage as a hiring problem - that strategy harkens back to your previous organizational structure and presents scaling problems. Now, the goal is to make each team productive, which will often mean broadening the skills of the people in the teams.

Throughout this process, many questions will likely arise. How do the feature teams interact with the product owners or product team? How do two teams handle a situation where they’re working on two different features for the same software component? (Hint: one team takes both features.) You may even encounter questions for which you have no answers yet - this is an expected and necessary part of the process. It’s important to remember that your reorg is about heading in a defined direction, and that the process of getting there is a process of evolution. What works tomorrow may not work for your organization a year from now. It’s important to keep your goals in mind while remaining fluid on the process of achieving them.

What does the flow look like? Will each team have their own development environment? While this question is a future post in itself, generally, each development team member should have a complete development environment on their machine, including databases and/or mocks as needed. Enabling each person to do their own development and testing locally will result in them being able to work faster and thus be more productive. After local testing, each person should send a pull request and review their work with their team lead. Once everything is reviewed and approved, their changes should be merged with master and pushed to the development pipeline shared by all teams. This pipeline includes the development, testing, staging, and production environments. This is the fan-in portion of the process, which I’ll elaborate on in future posts.

Conclusion

In a growth-stage startup with under one hundred developers, there’s no real need for a long drawn-out reorg process. It can be started and completed in a matter of days, with the major component of creating initial teams finished in ten minutes. I’ve used this process multiple times with teams of varying sizes, from less than twenty up to nearly a hundred, and it has worked well across that spectrum. If you are a growth-stage startup or similarly-sized company with reduced development output due to bottlenecks, it might be time for your ten-minute reorg.

Good luck!

P.S. - In case you want the DOT code for the team flow above:

digraph G {
	rankdir=LR
	
	"Feature Backlog" -> "Feature Team 1";
	"Feature Backlog" -> "Feature Team 2";
	"Feature Backlog" -> "Feature Team 3";

	"Feature Team 1" -> "Deployment Pipeline";
	"Feature Team 2" -> "Deployment Pipeline";
	"Feature Team 3" -> "Deployment Pipeline";

	"Feature Backlog" [shape=box];
	"Deployment Pipeline" [shape=Msquare];
	"Customer" [shape=doublecircle];
    
	"Deployment Pipeline" -> "Customer"
}