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%.
| 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
To build a more realistic model I wanted to factor in:
| 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.
| 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 |
| 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 |
| 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 |
Let's take a quick look at the pros and cons of each scenario.
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.
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:
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.
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!