Why We Don't Have a Junior Bench (And What That Costs Us)

Walk through any established engineering consultancy — the big-name ones, the mid-tier ones, the boutique ones scaling to become big-name — and you'll find the same staffing pyramid. One senior architect at the top. A few mid-level engineers doing the bulk of the work. A larger base of junior engineers absorbing tickets, writing tests, handling the parts of the code the seniors don't want to touch. Rate cards vary; the shape rarely does.

‍

This isn't an accident. Pyramid staffing solves several business problems for consultancies at once. Juniors are cheap, so margin per hour is high on the base of the pyramid. Juniors are also numerous, so the team can scale headcount fast when a new engagement lands. The seniors and mids get leverage — one senior architect can supervise the work of four juniors, so the seniors' expensive time is spread across more billable hours. The economics work.

‍

We don't do this. Every engineer on every one of our engagements is senior. Not "senior" as job title inflation — actually senior, with 8+ years of shipping production systems, prior experience with the kind of work your project needs. When we say "no junior bench," we mean it structurally: we don't hire juniors, we don't grow them internally, we don't pass some of your work to a cheaper tier because you won't notice.

‍

This is a business decision, not a virtue. And like any business decision, it has costs — real ones that affect who we can work with, how fast we can scale, and what we can charge. This article is about naming those costs honestly, because the pattern only makes sense if you understand what it isn't.

Three specific costs, ordered by which one bites us most often.

‍

Cost 1: We're more expensive per hour. Senior engineers cost more than mid-level engineers, who cost more than juniors. When our whole team is senior, our blended rate is higher than a consultancy running a pyramid. A pyramid consultancy might charge $150/hour blended; ours is meaningfully higher. For a client comparing two proposals on hourly rate alone, we look worse on the surface.

‍

We can (and do) argue that the total cost of the engagement is often lower because senior engineers ship in fewer hours. That argument is correct, but it's also self-serving, and CFOs know it. When the procurement conversation is "who's cheaper per hour," we're not the answer.

‍

Cost 2: We can't scale headcount fast. A pyramid consultancy that lands a big engagement can hire six juniors in two months. Juniors are relatively easy to find, relatively easy to interview, relatively easy to onboard. Senior engineers with actual shipping experience are none of these things. Our hiring process is measured in months, and the candidate funnel is narrow. We turn down more people than we hire.

‍

The practical consequence: we can't take on more work than our current team can handle. If you need a team of 15 senior engineers to start next month, we can't be that team. We can be part of it, we can help you build the practice around it, but we don't have a bench sitting on the sidelines waiting for a project. Every engineer on our team is either working on a client engagement or actively transitioning between engagements.

‍

Cost 3: We don't fit "just build this feature" engagements. Some engagements don't need senior judgment. They need someone to write straightforward code according to a well-defined spec, on schedule, at a reasonable rate. If your project has clear requirements, low architectural risk, well-established patterns, and mostly needs execution — a pyramid consultancy or staff augmentation firm is a legitimate choice for that work. We're not.

‍

The cases where senior-only makes sense are the ones where architectural judgment matters at every layer: where the wrong pattern early creates expensive rework later, where the "right" answer isn't in a textbook, where the team you're building around the work needs to internalise not just the code but the reasoning behind it. If your project isn't that, we're overkill and overpriced.

Now the other side, because those costs only make sense if what we get in return is real.

‍

Everyone on your project has shipped systems like yours before. Not "we have someone on the team who's shipped it." Every person on your engagement. This changes the shape of every conversation. The engineer you're pairing with today has seen the failure mode you're worried about, in production, more than once. They know which patterns work in your industry and which look attractive but fail at scale. They've read the papers, but more importantly, they've been on the receiving end of the 3am incidents when those patterns break.

‍

The compounding effect matters. When every engineer has this level of experience, decisions get made faster and correctly the first time. Fewer rework cycles. Fewer "we didn't anticipate that" moments. Fewer weeks lost to going down the wrong architectural path. Over a 6–12 month engagement, this compounds into a meaningful delivery advantage — often enough to fully offset the higher hourly rate, and sometimes more.

‍

The learning tax on your team is different. When you work with a pyramid team, your senior engineers spend significant time reviewing junior work, explaining context, correcting patterns. This is fine when the junior work is on your team and the mentoring builds long-term capability. It's frustrating when the juniors are on a vendor's team and will disappear from your project when the engagement ends. You paid for their learning.

‍

Senior-only removes this. Your engineers work alongside people whose skill level is comparable or greater. The mentoring flows differently — your team learns from ours, on the specific patterns we bring from other engagements, not on the fundamentals they already know.

‍

Decisions have provenance. When a senior engineer on our team makes an architectural call, they can explain why — in a way that references their prior production experience with similar systems, not what a blog post said. This makes the decision defensible, teachable, and reversible if it turns out to be wrong. Junior engineers don't have this depth of context; they follow patterns without knowing which parts of the pattern are load-bearing. Senior engineers know which parts to bend and which not to touch.

‍

Capability transfer is real, not performative. This is the one that matters most for our specific model. We're structurally trying to make ourselves unnecessary — every engagement ends with your team owning what we built. That only works if the people teaching your team are people who deeply understand the reasoning behind their choices. Junior engineers can execute patterns; they can't teach the meta-level of when to apply which pattern. Capability transfer at the senior level is transfer of judgment, not just knowledge.

Because we've been honest about the costs, we can be honest about the fit.

‍

Good fit for our model:

‍

• Product companies at the inflection point where architectural decisions have outsized long-term impact — typically the transition from MVP to enterprise-grade, or the modernisation of a legacy system that has to keep running.

• Engineering organisations that will keep the platform after we leave — where knowledge transfer is genuinely valued, not just a bullet in a proposal.

• Situations where the wrong architectural pattern early would cost significantly more later — regulated industries, high-load platforms, systems handling money or health data.
  

• Companies whose engineers are strong and want to work alongside experienced peers, not be trained by an external team.

‍

Not a fit for our model:

‍

• Fixed-price MVP builds with well-defined specs and low architectural risk. Cheaper options do this better.

• Staff augmentation — plugging engineers into a client's team to work under client direction on tasks the client defines. We don't operate this way.
  

• Companies where cost per hour is the primary decision criterion. We lose that comparison, and the argument that total cost is often lower doesn't move procurement.

• Very short engagements (under 6 weeks) that don't have room for capability transfer. Our engagement structure needs enough time for the transfer to matter.

‍

Being explicit about the mismatch isn't just honesty — it's also a filter. The engagements that succeed are the ones where the model fits. When we say no to a project, we're often preventing a bad outcome for a client who would have been unhappy with what we deliver.

There's a broader argument here that goes beyond staffing pyramid decisions. The industry standard exists because it solves the industry's problems: consultancies need to scale, need to maintain margin, need to place people. Pyramid staffing is optimised for the consultancy's business, not necessarily for the client's outcome.

‍

Senior-only staffing is optimised differently. It gives up scale and margin flexibility. In exchange, it produces better outcomes on specific kinds of engagements — the ones where architectural judgment compounds, where capability transfer is real, where the wrong pattern early costs more than the right team upfront.

‍

Whether that trade-off is right for you depends on what you're trying to accomplish. For companies where the engagement is a bet on the next 3–5 years of platform work, senior-only usually wins. For companies where the engagement is a bet on the next 3–5 months of feature delivery, it usually doesn't.

‍

The choice is honest either way. What we push back on is the assumption that pyramid staffing is the default, and any alternative needs to justify itself. Sometimes the alternative is the default, and pyramid staffing needs to justify itself. Both patterns exist because both make sense — for different work, at different stakes, with different clients.

The most valuable question a founder or CTO evaluating engineering vendors can ask isn't "who's the best." It's "which staffing model matches my work."

‍

If you're building something where architectural judgment matters at every layer, where the team you build around it will own the outcome, where the wrong pattern early is expensive to reverse — a senior-only model is worth its cost.

‍

If you're building something where the requirements are clear, the risk is contained, and execution is the main challenge — a pyramid model is often the better fit, and probably cheaper.

‍

The mistake is picking a vendor before you've thought about the model. Because once you've picked the vendor, you've picked the model — and if the model doesn't fit the work, no amount of great individuals on the vendor's side will fix that.