As your product and team grow, the need to strategize that growth will become inevitable. This week we are focusing on a few different ways our clients structure their teams with scalability in mind. Let's jump in.
Frequently smaller teams are divided by engineering role: frontend and backend. Because the group is small, this division makes the work responsibilities clear, and communication is rarely a problem. With smaller team sizes it's easy to be agile and be clear on business initiatives, however, acceleration may be limited. As the engineering department grows, it will inevitably require those teams to be subdivided further. In addition, small teams like this often have special requirements that don't merit a full-time hire. So, specialty skills or components that are siloed from the main software can be easily outsourced to a staff augmentation firm or freelancer with great success!
Once the engineering team grows large enough that the structure of dividing things by engineering role becomes unwieldy, there are a few directions the company can take. One really successful strategy is to make product-focused teams. These teams can be made up of a couple of frontend and backend engineers, along with QA, and the team lead. These teams then become experts in a particular component or section of the software. The advantage here is that it is easy to spin off new teams as teams get too big or create new ones to be responsible for new initiatives or components. This is a really agile way to grow. The downside is maintaining strong communication so that each team doesn't become too siloed or disconnected from the business initiatives. It's also important for leadership to maintain transparency and clarity in each team even as growth makes the company increasingly hierarchical and complex.
One way to avoid some of these problems is to maintain as flat a company as possible for as long as possible. Some engineering departments similarly create micro teams structured as described, but instead of locking them into particular sections of the product, create a cycle of team rotations. This allows for greater coherence between the team members. It improves everyone's understanding of the software as a whole. And the flat structure allows leadership key insight into what is actually going on.
Other companies avoid the problem of team management entirely by relying on staff augmentation almost entirely. While they avoid being responsible for payroll, benefits, company culture, and HR, communication becomes even more important. With Staff Augmentation you get the benefit of a deep bench of varied talent that you can bring on as needed, and offload when needed. You get the benefit of building trusted partnerships with a company or maybe more than one to fulfill those staffing needs for you. However, off-shore teams often have large time zone discrepancies that must be handled carefully. Identifying overlapping hours between your staff aug team and your in-house team is essential. That time must be inviolable.
Regardless of the way you structure your team and strategize for growth, there are a few things you can put into place that will be key to your success.
-
Monitoring KPIs
Over and over again we see that the companies that succeed are the ones who are paying attention. A lot of times story points, deployment frequency, or lack of errors can seem like arbitrary measures to individual engineers. However, seeing these metrics in the aggregate is extremely helpful to decision-makers. Keep up the discipline! It pays huge dividends!
-
Splitting teams when they get too big
It's essential to understand what a minimum viable team is: likely in the neighborhood of three engineers and a team lead. However, it is equally important to understand when a team has gotten too big. It is too difficult to communicate, manage schedules, and have a clear picture of your high or low performers. It becomes too difficult to respond to crises or support each team member. Thus it is imperative to spin off teams once they get too big.
-
Maintaining stakeholder focus
Engineers tend to be an idealistic bunch. They often love their engineering best practices. They often have strong opinions about the "right" way to tackle a problem. Some can get stuck in the weeds of perfectionism. That is why it is so important to consistently communicate your business objectives. Rarely are we in the business of trying to forge the flawless diamond equivalent in software. Instead, we are trying to build something of good quality, that provides value to our customers, and continues to drive consistent revenue. Taking the time to communicate how the software is going to achieve that for the business and building motivation and excitement around that goal will never be a waste of time.
-
Smooth Onboarding
To scale rapidly means that you must have a smooth onboarding process. Bringing on team members only to have them spin their wheels for two weeks, is two weeks of payroll wasted. This almost always means up-to-date documentation! It is also one of those things that engineers may resist, but every engineer always appreciates when they are the one who benefits from accessing it. Do not paint yourself into a corner with that one genius engineer who has been there from the beginning and who is the only one who knows about the random dusty corners of your project! (Nearly every company has one and they are so valuable!) However, you want to make their niche and obscure knowledge of the project available to the broader team. In addition, make sure your HR process is on point. Be ready with their hardware on day one. Transition to digital documents to ease the vortex of paperwork.
-
Continue to incorporate staff augmentation
It is important to be clear about which roles are best to bring in-house: you actually have full-time work and it's likely to be there for a minimum of a year. It is important to be equally clear about those roles which are better to outsource. Is it a specialized tech stack? Is it a job skill that you don't need full-time, like DevOps or design? Is it a whole integrated department that is simply more affordable to outsource, like QA? These are key areas where the benefit and affordability of staff augmentation really make sense.