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 hours 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:
- High Skill Level: Senior engineers bring experience and expertise, which can boost productivity and mentor younger team members.
- Immediate Impact: Given their experience, senior engineers are more likely to contribute significantly right away.
- Reduced Onboarding Time: Senior engineers generally require less time to get up to speed.
Cons:
- High Cost: Senior engineers command higher salaries, leading to a steeper rise in operational costs.
- Churn Risk: This model assumes a 30% annual churn rate for senior engineers, which is risky given their high costs.
- 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:
- Balanced Skill Set: Provides a good mix of experience levels.
- Cost-Efficiency: Less expensive than hiring all senior engineers.
- Moderate Onboarding Time: Not as fast as seniors but quicker than juniors to onboard.
Cons:
- Higher Time Loss for Existing SRs: Will require more assistance, leading to a greater drop in existing senior engineers' performance.
- 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:
- Diverse Skill Levels: Provides a rich mix of experience and capabilities.
- Moderate Cost: Less costly than hiring all senior engineers.
- Moderate Time Loss for Existing SRs: Distributes the impact on existing senior engineers' time.
Cons:
- Distributed Churn Risk: Because of the mix of roles, this scenario exposes us to a wider range of churn probabilities.
- 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:
- Reduction in total units of work.
- Short ramp-up for new engineers.
- Standardization that's easy to reason about.
- 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 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.