Scaling Engineering Teams

The software engineering world has become a place where compute, storage, and availability have become the cornerstones of scale. As an industry and as individuals, we should stop to take a closer look at scaling the most important of all resources… our people.

In this post I've modeled a team with 6 engineers, 2 Sr, 3 Mid, and 1 Jr. This team is getting 450 “units” of work done ( where a unit is just some measure of throughput ) per interval (2 months). Given the recent success of their product and to keep up with demands for new features they need to scale that work up to 750 units per interval… a change of ~66%.

Model: Current Team

Role	Units	Performance	Output/Interval	Cost/Interval
SR	100	100%	100	$35,000
SR	100	100%	100	$35,000
Mid	70	100%	70	$20,000
Mid	70	100%	70	$20,000
Mid	70	100%	70	$20,000
Jr	40	100%	40	$9,000

Total Output per Interval:  450 units
Total Cost per Interval:   $214,000

Model: Outcomes

To build a more realistic model I wanted to factor in:

• Lead Time (how long it takes to find / hire)
• Fit Chance (likelihood of new hire fitting productivity, culture, etc)
• Time Till Productive (Onboarding time, or, time until new hire is making 90% or more of unit quota)
• Assistance Rate (%)(for every 100 hours of work this new hire will require this number of hour of assistance from an existing SR asset)
• Churn Rate (chance the new hire will take a different job, yearly)

Type	Lead Time (months)	Fit Chance	Time Till Productive (intervals)	Assistance Rate	Churn Rate (yearly)
Sr	2	90%	2	5%	30%
Mid	1	70%	4	10%	20%
Jr	1	50%	6	20%	5%

Given the two sets of data we can now model a few different strategies.

Growth Scenarios & Impacts

Scenario 1: Hiring 3 Senior Engineers

Metric	Value	Potential Churn Impact
Additional Output/Interval	300 units	-100 units
Total Output/Interval	750 units	650 units
Time Lost (Senior)	15 hours
New Performance (Senior)	95.31%
Additional Cost/Interval	$105,000	-$35,000
Total Cost/Interval	$319,000	$284,000
Churn Impact	10% chance of 1 loss

Scenario 2: Hiring 4 Mid Engineers and 1 Junior

Metric	Value	Potential Churn Impact
Additional Output/Interval	320 units	-70 or -40 units
Total Output/Interval	770 units	700 or 730 units
Time Lost (Senior)	60 hours
New Performance (Senior)	81.25%
Additional Cost/Interval	$89,000	-$20,000 or -$9,000
Total Cost/Interval	$303,000	$283,000 or $294,000
Churn Impact	6.67% or 1.67% chance

Scenario 3: Hiring 1 Senior, 2 Mid, and 2 Junior Engineers

Metric	Value	Potential Churn Impact
Additional Output/Interval	310 units	-100, -70, -40 units
Total Output/Interval	760 units	650, 690, 720 units
Time Lost (Senior)	40 hours
New Performance (Senior)	87.5%
Additional Cost/Interval	$95,000	-$35,000, -$20,000, -$9,000
Total Cost/Interval	$309,000	$274,000, $289,000, $300,000
Churn Impact	10%, 6.67%, 1.67% chance

Back of the Napkin

Let's take a quick look at the pros and cons of each scenario.

Scenario 1: Hiring 3 Senior Engineers

Pros:

1. High Skill Level: Senior engineers bring experience and expertise, which can boost productivity and mentor younger team members.
2. Immediate Impact: Given their experience, senior engineers are more likely to contribute significantly right away.
3. Reduced Onboarding Time: Senior engineers generally require less time to get up to speed.

Cons:

1. High Cost: Senior engineers command higher salaries, leading to a steeper rise in operational costs.
2. Churn Risk: This model assumes a 30% annual churn rate for senior engineers, which is risky given their high costs.
3. Impact on Existing SRs: Even though it's minimal, their need for assistance will still take some time from existing senior engineers, impacting performance slightly.

Scenario 2: Hiring 4 Mid Engineers and 1 Junior Engineer

Pros:

1. Balanced Skill Set: Provides a good mix of experience levels.
2. Cost-Efficiency: Less expensive than hiring all senior engineers.
3. Moderate Onboarding Time: Not as fast as seniors but quicker than juniors to onboard.

Cons:

1. Higher Time Loss for Existing SRs: Will require more assistance, leading to a greater drop in existing senior engineers' performance.
2. Moderate Churn Risk: Mid-level engineers have a 20% annual churn rate, and junior engineers have 5%.

Scenario 3: Hiring 1 Senior Engineer, 2 Mid Engineers, and 2 Junior Engineers

Pros:

1. Diverse Skill Levels: Provides a rich mix of experience and capabilities.
2. Moderate Cost: Less costly than hiring all senior engineers.
3. Moderate Time Loss for Existing SRs: Distributes the impact on existing senior engineers' time.

Cons:

1. Distributed Churn Risk: Because of the mix of roles, this scenario exposes us to a wider range of churn probabilities.
2. Operational Complexity: Managing a team with varying levels of experience can be challenging.

As a traditionally ( or chronically ) conservative strategist I always tend to lean towards the least severe option… so for me it would almost always be scenario 3, BUT, I think the main thing to take into account is, outside of this fabricated model lies a real world where teams are built in a staggered, piecemeal way, not always in line with what's best for the organization.. But usually in a way that's constrained by that organization's position.

Exploring Other Factors

If we can agree that onboarding isn't a problem you can “solve” only a thing you can optimize towards greater efficiency - then I think we can also agree that reducing the number of things needed to onboard new employees would be the first stop on the optimization express.

As software engineers face an insurmountable number of new technologies to learn and keep up with, there are certain pieces of the puzzle that we can solve for them.

If you look at Cycle, for instance, our users can leverage several benefits:

1. Reduction in total units of work.
2. Short ramp-up for new engineers.
3. Standardization that's easy to reason about.
4. Automation for everything else.

Reducing Total Work

The initial issue for the company we're modeling was having more units of work to be accomplished than engineering resources to complete them.

If this were a company adopting Cycle, they would be able to reduce their total units of work per feature. So, for example, if in their current model they required 100 units per feature and they were getting 450 units per interval, that's 4.5 features per interval. If you apply the efficiency gains of adopting Cycle (conservatively) at 10%, we can then say that it only takes 90 units of work per interval per feature getting us to 5 features per interval.

Extrapolating that to the engineering team growth model we built earlier, it would seem as though the team was looking to grow into accomplishing 7.5 features per interval, and applying the work savings that would accumulate 675 units of work needed. If hiring using the given scenarios, churn rate issues and possible “negative event” can be accounted for much in a much more forgiving space.

The Rest

To maintain that this piece be more about scaling engineering teams than it is about Cycle, I'll consolidate the other points into this short blurb.

New Cycle users are generally able to get up to speed in a few days of using the platform. The standardized nature of the platform means that learning one deployment is going to help new engineers learn the general concepts needed to understand the rest, and the automation layer eliminates work that can be error prone and hard to reason about.

The impact on scaling engineering teams, given these ideas, should be conceptually simple to understand and apply. Less work, more automation, standards, etc all play a major role in scaling the Total workload a team is able to take on.

Hopefully, this post brings the reader a better view of how they can approach hiring and onboarding, as well as some new ideas on how to solve some of the issues from different angles. I hope it has been insightful and helps shine a light on a direction you may have otherwise missed.

💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!