Skip to content

BAU vs Scaling Investments

The Inevitable Choice

When demand outruns the team, the instinct is to read the constraint as capacity: not enough reviewers, not enough hours. Several things do bind a scaling security program, but the one thing more headcount cannot buy is comprehension bandwidth, the rate at which your people can actually understand what your factory ships. This is a race between two exponentials rather than a structural gap where a linear line loses to an exponential one and you manage the decline: how fast the factory produces, and how much of that output your people can actually secure and understand. Which curve you fund is the inflection point.

One honest caveat on the word exponential. The demand curve climbs as long as the factory ships more code and hands automation more authority, and that has compounded because AI capability has compounded. That engine is not guaranteed. Most people, when they say the models keep getting better, mean pre-training scaling. That mechanism is showing diminishing returns, and the public human text it trains on is being used up sometime this decade. Ilya Sutskever, who led much of that scaling, told NeurIPS in 2024 that "pre-training as we know it will end." A slowdown in that one mechanism is a real possibility rather than a tail risk.

It changes less than it looks like it should, for three reasons in rising order of certainty. The least certain first: the mechanism people will point to, pre-training, may stall. Next, and surer: even if it does, the demand this framework tracks is the volume of code shipped and the breadth of authority handed to automation rather than model cleverness, and both keep climbing on deployment alone, through test-time reasoning, agent fleets, and wider rollout, with no new scaling breakthrough required. Surest of all: the comprehension debt and the automated adversary are already here, since a plateau does not un-ship the code your people already cannot read, or call off the scanners already probing you. The destination is the same. What a plateau buys is time on the clock rather than a turn in the road.

A race between two exponentials: production against comprehension A line chart of rate against time showing two rising curves. The production curve, the volume of code shipped and the authority handed to automation, climbs steeply. The comprehension curve, the rate at which people can actually secure and understand that output, rises far more slowly. The vertical distance between them, widening to the right, is the share of output the organization cannot secure or understand. A dashed vertical line marks the inflection point: which curve you choose to fund. The production curve continues as a dashed line past the present, showing that it keeps climbing on deployment alone: test-time reasoning, agent fleets, wider rollout, with no new scaling breakthrough required. A pre-training plateau buys time on the clock rather than a turn in the road. This is a race between two exponentials rather than a structural decline a linear line manages. A race between two exponentials rate (volume per unit time) time the inflection point: which curve you fund production / demand code shipped + authority granted climbs on deployment alone comprehension bandwidth what people can secure + understand the gap what no one can secure Two exponentials racing, and which one you fund is the inflection point. A pre-training plateau slows the demand curve but does not un-ship the code already written: time on the clock rather than a turn in the road.
Production climbs faster than comprehension; the widening gap is the share of output no one can secure or understand. Which curve you fund is the inflection point. A plateau slows demand but does not change the destination.

The investment portfolio model sorts security spending into three categories ranked by the shape of their return; this page is the execution deep dive on the hardest move in it: shifting from linear business-as-usual work to compounding scaling investment.

The Capability Gap

The gap runs deeper than volume: a capability mismatch between manual defenders and automated adversaries.

The Adversary Capability Shift: Since roughly 2017, adversaries evolved from targeted reconnaissance to automated discovery at internet scale. Using techniques inspired by bug bounty programs and internet-wide scanning, attackers can now:

  • Discover unknown assets (forgotten servers, shadow IT, unmanaged dependencies) faster than organizations can inventory them
  • Exploit known vulnerabilities within hours or days of disclosure
  • Conduct credential stuffing at scale against thousands of targets simultaneously
  • Probe continuously while defenders scan quarterly

One Break, Two Bottlenecks: Organizations conducting quarterly vulnerability scans face adversaries who probe continuously. Manual asset discovery can't keep pace with automated reconnaissance. Underneath both sits one break showing up in two places. On the attacker's side, automation outran a human-bound defensive process, so manual throughput loses the speed race. On the production side, automation now outruns people too: code and systems are generated faster than anyone can understand them, so manual comprehension loses the understanding race. One root cause, two human bottlenecks, neither closed by hiring alone.

Critical Insight: Supply Chain as #1 Priority

Supply chain security became the #1 priority because adversary capability evolved rather than because dependencies increased. When attackers can discover your unknown assets faster than you can catalog them, supply chain security becomes existential regardless of your other security investments.

Once a program has enough repeated work to amortize, the dollar that makes the secure path the easy path, by automating a step or packaging it into a guardrail engineers plug into, buys more than the dollar that adds one more linear reviewer, including the dollar that pays the engineer who builds it.

What Compounds and What Doesn't

Scaling Investments compound in two different ways, and the difference decides what each one buys. Automation takes a human out of a repeated step, so the work runs hands-free and throughput stops being bound by hours. Composable guardrails keep the human but change what they have to understand: instead of reviewing N bespoke implementations of mTLS, base images, scoped roles, or secure pub/sub, your people understand one packaged path that teams plug into. The comprehension does not disappear. It concentrates into one durable review, amortized across every team that adopts the path, which is a real economy only on the traffic that actually takes it. A guardrail also does what automation does not: because it is a boundary, it limits what goes wrong when something slips through, beyond what your reviewers have to read. Two benefits from one artifact.

The Compound Interest Principle

Just as financial investments generate compound returns, security scaling investments compound. An automation capability used 100 times costs the same to build as one used once; the build cost amortizes toward zero per use while the value keeps accruing. Manual security work never amortizes. Each review costs the same effort as the last.

What to Avoid: Tools That Create Maintenance Burden

The Maintenance Burden Trap

Some security tools create ongoing maintenance costs that exceed their security value. Avoid investments that:

  • Require continuous manual tuning to remain effective
  • Generate high false-positive rates demanding constant triage
  • Need specialized expertise that creates key-person dependencies
  • Don't integrate with existing development workflows
  • Create new manual processes rather than automating existing ones

Favor investments that:

  • Become more valuable and less demanding over time
  • Store organizational knowledge in reusable form
  • Enable self-service without security team involvement
  • Integrate seamlessly into existing workflows
  • Improve developer experience while improving security

Constraint Strategy by Position

The Strategic Position and Investment Strategy table maps each quadrant's business-as-usual load to its scaling focus. The first-year balance between the two looks very different by position:

Year-one effort allocation by quadrant: constraining BAU versus scaling investment Four horizontal stacked bars, one per quadrant, showing the year-one split between business-as-usual to constrain and scaling investment. Craft spends about 80 percent on BAU and 20 percent on scaling. Mass spends about 80 percent on BAU and 20 percent on scaling. Studio spends 30 percent on BAU and 70 percent on scaling. Lean spends about 12 percent on BAU and 88 percent on scaling. The more readiness an organization has, the more of its effort goes to scaling rather than constraining BAU. Craft and Mass both spend most of their effort on BAU for opposite reasons: Craft by intentional simplicity, Mass because legacy work eats the budget. These are year-one figures. A dashed extension on the Craft and Mass bars shows the constraint share ratcheting down toward scaling over later years, a direction of travel rather than a dated forecast. Year-one effort: constrain BAU vs. invest in scaling 0%50%100% Craft BAU to constrain 80% 20% Mass BAU to constrain 80% 20% Studio BAU 30% Scaling investment 70% Lean 12% Scaling investment ~88% The more readiness you hold, the more effort goes to scaling rather than constraining BAU. Craft and Mass both spend most on BAU, for opposite reasons: Craft by intentional simplicity, Mass because legacy eats the budget. Year-one figures; both shift toward scaling over later years. dashed = BAU that shifts to scaling in later years (a ratchet rather than a dated forecast)
Year-one effort split per quadrant. The more readiness you hold, the more goes to scaling rather than constraining BAU. Craft and Mass spend most on BAU for opposite reasons: Craft by intentional simplicity, Mass because legacy eats the budget.

BAU Constraint Communication Strategy

Constraining BAU activities requires clear communication to maintain organizational support and developer relationships.

Communication by Organizational Stage

Pre-Crisis (Building Alternatives):

Message: "We're investing in improved capabilities that will provide faster, more consistent security support."

Actions:

  • Maintain current service levels while building alternatives
  • Gradual introduction of self-service options
  • Measure baseline metrics for later comparison
  • Build organizational confidence in new approaches

Crisis Point (Implementing Constraints):

Message: "We've reached a scaling inflection point. To ensure sustainable security support, we're shifting from manual processes to self-service capabilities. Here's what's changing, here are the alternatives, and here's the timeline for improved capabilities."

Actions:

  • Set explicit capacity limits with clear justification
  • Provide immediate self-service alternatives (even if basic)
  • Establish escalation paths for critical needs
  • Regular updates on scaling investment progress

Example Communication:

"Our security review process has reached capacity constraints. Starting next quarter, we're implementing a self-service security baseline that will enable most teams to deploy securely without security review wait times. For projects outside this baseline, we'll use a triage process prioritizing business-critical initiatives. We expect this transition to take 6 months, after which your experience will significantly improve."

Post-Crisis (Systematic Operations):

Message: "Improved self-service capabilities are now available. Most teams can now [specific capability] without security team involvement, and we've measured [specific improvement metric]."

Actions:

  • Demonstrate ROI realization from scaling investments
  • Showcase developer experience improvements
  • Adjust capacity constraints based on capability maturity
  • Continuous improvement of self-service platforms

Success Metrics for Investment Shifts

Track these metrics to validate your BAU constraint and scaling investment strategy:

Leading Indicators (Early Signals)

  • Scaling investment velocity: Projects started, adoption rates, developer feedback
  • Alternative capability usage: Self-service adoption rates, platform utilization
  • Developer satisfaction trends: Survey scores, friction reports, voluntary participation
  • Investment pipeline health: Approved projects, executive support, resource allocation

Lagging Indicators (Results)

  • Manual effort reduction: Hours saved per activity type, capacity freed for strategic work
  • ROI realization: Measurable benefits vs investment costs, compound return evidence
  • Security outcomes: Vulnerability detection rates, incident response times, risk posture improvements
  • Business velocity: Time-to-market improvements, deployment frequency increases, developer productivity gains

Next Steps

  1. Assess Your Position: Are you pre-crisis, at crisis point, or post-crisis in your scaling journey?
  2. Evaluate Current Portfolio: Catalog BAU activities and identify scaling investment opportunities
  3. Review Evaluation Criteria: Systematic framework for prioritizing investments
  4. Understand Platform Effects: Additional considerations for platform companies
  5. Develop Communication Strategy: Prepare stakeholder messaging for investment shifts

Back to Portfolio Framework Continue to Platform Effects

Edit this page