Eng org seniority-mix model.

One of the trademarks of private equity ownership is the expectation that either the company maintains their current margin and grows revenue at 25-30%, or they instead grow slower and increase their free cash flow year over year. In many organizations, engineering costs have a major impact on their free cash flow. There are many costs to reduce, cloud hosting and such, but inevitably part of the discussion is addressing engineering headcount costs directly.

One of the largest contributors to engineering headcount costs is your organization’s seniority mix: more senior engineers are paid quite a bit more than earlier career engineers. This model looks at how various policies impact an organization’s seniority mix.

In this chapter, we’ll work to:

1. Summarize this model’s learnings about policy impact on seniority mix
2. Sketch the model’s stocks and flows
3. Use lethain/systems to iteratively build and exercise the full model

Time to start modeling.

This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts.

Learnings

An organization without a “backfill at N-1” hiring policy, e.g. an organization that hires a SWE2 to replace a departed SWE2, will have an increasingly top-heavy organization over time.

However, even introducing the “backfill at N-1” hiring policy is insufficient, as our representation in senior levels will become far too high, even if we stop hiring externally into our senior-most levels.

To fully accomplish our goal of a healthy seniority mix, we must stop hiring at senior-most levels, implement a “backfill at N-1” policy, and cap the maximum number of individual at the senior-most level.

Any collection of lower-powered policies simply will not impact the model’s outcome.

Sketch

We’ll start by sketching this system in Excalidraw. It’s always fine to use whatever tool you prefer, but in general the lack of complexity in simple sketching tools focuses you on iterating on the stocks and flows–without getting distracted by tuning settings–much like a designer starting with messy wireframes rather than pixel-perfect designs.

We’ll start with sketching the junior-most level: SWE1.

We hire external candidates to become SWE1s. We have some get promoted to SWE2, some depart, and then backfill those departures with new SWE1s.

As we start sketching the full stocks and flows for SWE2, we also introduce the idea of backfilling at the prior level. As we replicate this pattern for two more career levels–SWE3 and SWE4–we get the complete model.

The final level, SWE4, is simplified relative to the prior levels, as it’s no longer possible to get promoted to a further level. We could go further than this, but the model will simply get increasingly burdensome to work with, so let’s stop with four levels.

Reason

Reviewing the sketched system, a few interesting conclusions come out:

1. If promotion rates at any level exceed the rate of hiring at that level plus rate of N-1 backfill at that level, then the proportion of engineers at that level will grow over time
2. If you are not hiring much, then this problem simplifies to promotion rate versus departure rate. A company that does little hiring and has high retention cannot afford to promote frequently. Promotion into senior roles will become financially restrained, even if the policy is explained by some other mechanism
3. Many companies use the “career level” policy as the mechanism to identify a level where promotions generally stop happening. The rationale is often not explicitly described, but we can conclude it’s likely a financial constraint that typically incentivizes this policy

With those starter insights, now we can get into modeling the details,.

Model & Exercise

We’re going to build this model using lethain/systems. The first version will be relatively simple, albeit with a number of stocks given the size of the model, and then we’ll layer on a number of additional features as we iteratively test out a number of different scenarios.

I’ve chosen to combine the Model and Exercise steps to showcase how each version of the model can inspire new learnings that prompt new questions, that require a new model to answer.

If you’d rather view the full model and visualizations, each iteration is available on github.

Backfill-at-level

The first policy we’re going to explore is backfilling a departure at the same level. For example, if a SWE2 departs, then you go ahead and backfill them at SWE2. This intuitively makes sense, because you needed a SWE2 before to perform the work, so why would you hire something less senior?

There are two new systems concepts introduced in this model:

1. For easier iteration, we’re going to introduce the concept of using a stock as a variable by initializing HiringRate with a size of two, and then using that size as the rate that we hire additional.
2. There are effectively an infinite number of potential candidates for your company, so we’re going to use an infinite stock, represented by initializing a new stock surroundined by [ and ]. Specifically in this case this is [Candidates], if we wanted a fixed size stock with 100 people in it, we could have initialized it as Candidates(100). Depending on what you’re modeling both options are useful.

With those in mind, our initial model is defined as:

HiringRate(2)

[Candidates] > SWE1(10) @ HiringRate
SWE1 > DepartedSWE1 @ Leak(0.1)
DepartedSWE1 > SWE1 @ Leak(0.5)

Candidates > SWE2(10) @ HiringRate
SWE1 > SWE2 @ Leak(0.1)
SWE2 > DepartedSWE2 @ Leak(0.1)
DepartedSWE2 > SWE2 @ Leak(0.5)

Candidates > SWE3(10) @ HiringRate
SWE2 > SWE3 @ Leak(0.1)
SWE3 > DepartedSWE3 @ Leak(0.1)
DepartedSWE3 > SWE3 @ Leak(0.5)

Candidates > SWE4(0)  @ HiringRate
SWE3 > SWE4 @ Leak(0.1)
SWE4 > DepartedSWE4 @ Leak(0.1)
DepartedSWE4 > SWE4 @ Leak(0.5)

To confirm that we’ve done something reasonable, we can model this using Graphviz.

That looks like the same model we sketched before, without the downlevel backfill flows that we haven’t yet added to the model, so we’re in a good spot.

With that confirmed, lets inspect the four distinct flows happening for the SWE2 stock. In order they are:

1. External candidates being hired at the SWE2 level, at the fixed HiringRate defined here as 2 hires per round
2. SWE1s being promoted to SWE2 at a 10% rate. This is a leak because someone being promoted to SWE2 doesn’t mean the other SWE1s disappear
3. SWE2s who are leaving the company at a 10% rate
4. Backfill hires of departed SWE2s, who are rehired at the same level

Running that model, we can see how the populations of the various levels grow over time.

Alright, so we can tell that this backfill at level policy is pretty inefficient, because our organization just becomes more and more top-heavy with SWE4s over time. Something needs to change.

Backfill at N-1

To reduce the number of SWE4s in our company, let’s update the model to backfill all hires at the level below the departed employee. For example, a departing SWE2 would cause hiring a SWE1. This specifically means replacing all these lines:

DepartedSWE2 > SWE2 @ Leak(0.5)

To instead hire into the prior level.

DepartedSWE2 > SWE2 @ Leak(0.5)

The one exception is that SWE1s are still backfilled as SWE1s: as it’s the junior-most level, there’s no lower level to backfill into.

Running this updated model, we get a better looking organization.

We’re still top-heavy, but we’ve turned an exponential growth problem into a linear growth problem, so that’s an improvement. However, this is still a very expensive engineering organization to run, and certainly not an organization that’s reducing costs.

No hiring

One reason our model shows so many SWE4s is because we’re hiring at an even rate across all levels, which isn’t particularly realistic. Also, it’s unlikely that we’re growing headcount at all to the extent that we’re aiming to reduce our engineering costs over time.

We can model this by setting a HiringRate of zero, and then setting more representative initial values for each cohort of engineers (note that I’m only showing the changed lines, check on github for the full model):

HiringRate(0)

[Candidates] > SWE1(100) @ HiringRate
Candidates > SWE2(100) @ HiringRate
Candidates > SWE3(100) @ HiringRate
Candidates > SWE4(10)  @ HiringRate

Now we’re starting out with 100 SWE1s, SWE2, and SWE3s. We have a smaller cohort of SWE4s, with just ten initially. Running the model gives us a updated perspective.

We can see that eliminating hiring improves the ratio of SWE4s to the other levels, but it’s still just too high. We’re ending up with roughly 1.25 SWE1s for each SWE4, when the ratio should be closer to five to one.

Capped size of SWE4s

Finally, we’re going to introduce a stock with a maximum size. No matter what flows want to accomplish, they cannot grow a flow over that maximum. In this case, we’re defining SWE4 as a stock with an initial size of 10, and a maximum size of 20.

SWE4(10, 20)
Candidates > SWE4  @ HiringRate

This could also be combined into a one-liner, although it’s potentially easy to miss in that case:

Candidates > SWE4(10, 20)  @ HiringRate

With that one change, we’re getting close to an engineering organization that works how we want.

We ratio of SWE4s to other functions is right, although we can see that the backpressure means that we have a surplus of SWE3s in this organization. You could imagine other policy work that might improve that as well, e.g. presumably more SWE3s depart than SWE2s, because the SWE3s see their ability to be promoted is capped by the departure rate of existing SWE4s. However, I think we’ve already learned quite a bit from this model, so I’m going to end modeling here.