The brake gets treated as the pedal that slows you down, but ask yourself why cars have brakes at all: not so you can drive slow, but so you can drive fast. Nobody takes a car with no brakes onto a highway. The brake is the reason the gas pedal is usable at speed.
Every company has both pedals, whatever the org chart calls them.
Growth teams are the gas pedal. Product, engineering, sales, marketing: the teams whose output is the business. They're measured on shipping, closing, launching, and pipeline. Speed is their currency, and every hour spent waiting on something internal is an hour of output lost.
Enabler teams are the brake. IT, security, finance, HR, compliance: the teams whose output makes the business durable. They're measured on stability, cost control, risk posture, and the employee experience. Nothing they do shows up as revenue, and nearly everything they do shows up as a step someone else has to take. But like the brake, they're not there to slow the business down. They're what makes going fast survivable.
Because here's the part the speed conversation always skips: the point of driving fast was never the speed. It was reaching the destination, and you only reach it if you get there safe. A company that crashes on the way to its targets doesn't arrive late. It doesn't arrive at all.
Different names get used for this split: run-the-business vs. grow-the-business, protect vs. produce, guardrails vs. growth. Call the two sides what you like; the tension is the same everywhere. Growth teams experience enabler teams as friction. Enabler teams experience growth teams as risk. And most internal investments deepen the divide, because they make one side's life better by making the other side's harder: a new control adds steps for growth, a new velocity tool adds risk for enablers.
Which is what makes identity governance genuinely unusual. Done right, IGA is one of the very few investments that lands on both sides of the divide as a win, at the same time, for reasons each side would name in its own language. This piece walks through exactly what each side gets, because that's also exactly how the investment gets funded.
The Divide, Mapped
The last two rows are the real problem: most investments are asymmetric. One side buys, the other side pays in friction or risk. That asymmetry is why enabler-driven purchases get resented by growth teams and growth-driven tool adoption terrifies enabler teams, and it's the pattern IGA breaks.
What Growth Teams Get: Speed With Nobody's Permission Slip
For product, engineering, sales, and marketing, governance sounds like the last thing that would help them. Here's what it actually delivers on their side of the divide.
Access in minutes, not tickets. The self-service request flow replaces the email-a-ticket-wait-three-days cycle. An engineer who needs a new tool requests it, approval routes automatically, and provisioning executes in minutes. For teams whose output is measured in shipped work, this is not an IT improvement. It's recovered velocity.
Day-one productivity for every new hire. A new salesperson with CRM access on day one starts building pipeline on day one, not day four. A new engineer with repo and environment access immediately starts contributing that week. Growth leaders feel onboarding lag directly in their numbers; automated joiner workflows delete it.
Role changes that don't strand anyone. The engineer moving to a new team, the marketer picking up a product line: their access adjusts automatically with the role change, instead of a week of "can someone add me to..." messages while their output stalls.
Less friction than the workaround. The honest reason growth teams adopt shadow tools is that the sanctioned path is slower. IGA, properly deployed, inverts that: the governed path becomes the fast path, which is the only argument that has ever actually beaten shadow IT, because it's the only one that doesn't ask growth teams to trade speed for compliance.
The summary for the growth side: this is the first "control" that gives time back instead of taking it.
What Each Enabler Team Gets: The Outcome It's Actually Measured On
The enabler side doesn't win as one bloc. Each function gets something specific, in its own metric.
Finance: spend visibility and recovered waste. The same discovery that powers governance surfaces every SaaS subscription in the environment, including unused licenses, duplicate tools, and spend tied to no active user. That's money finance has been trying to find with spreadsheets for years, delivered as a byproduct, and it routinely offsets a meaningful share of the platform's own cost. Finance's metric is controlled, justified spend. This moves it directly.
HR: an employee experience that stops generating complaints. Onboarding, role changes, and offboarding are HR's most visible moments, and access is where all three most often go wrong. Automated joiner-mover-leaver workflows mean new hires who are productive immediately, transfers that don't stall, and departures handled cleanly and respectfully. The "I still can't log into anything" complaints that land on HR simply stop arriving. HR's metric is employee experience. This is the infrastructure underneath it.
IT: fewer tickets and a team doing higher-value work. Access requests are a dominant slice of most help desk queues, and JML automation removes the bulk of them at the source. The IT team stops being a provisioning bureau and gets its hours back for the work that actually requires judgment. IT's metric is service quality delivered per headcount. This is the biggest single lever on it.
Security and compliance: a posture you can finally prove. Complete visibility including shadow IT, deprovisioning that reaches every application rather than just the SSO-connected ones, access reviews that run on schedule, and audit evidence generated on demand instead of assembled in a panic. Security's metric is risk reduced; compliance's is findings prevented and evidence produced. This is both, by design rather than by heroics.
Why "Both Sides Win" Isn't Spin: The Mechanism
Claims that an investment helps everyone are usually pitch-deck arithmetic. Here the mechanism is real, and it's worth understanding why.
Both sides' problems have the same root: nobody can see or automate who has access to what. The lack of visibility and automation shows up on the growth side as slow tickets, stalled onboarding, and workaround tools. The identical lack shows up on the enabler side as ungoverned spend, offboarding gaps, audit scrambles, and complaint volume. One root, two symptom sets, one on each side of the divide.
Fix the root, visibility plus automated lifecycle workflows, and both symptom sets resolve from the same fix. Growth gets speed because the automation is fast. Enablers get control because the automation is governed. Speed and control stop being a trade-off because they're now the same pipeline, and that's the underlying reason this isn't zero-sum: nobody's win is funded by anybody's loss.
What This Means for Whoever Is Building the Case
If you're the one championing an IGA investment, this framing is not just an observation, it's the funding strategy.
- Pitch each side its own win, in its own metric. Growth leaders hear recovered velocity and day-one productivity. Finance hears the spend offset. HR hears the complaint categories that disappear. Security and compliance hear posture and evidence. One project, five pitches, each in the listener's language.
- Let the growth side advocate, not just tolerate. Most governance projects arrive at growth teams as an imposition to be endured. This one can arrive as the thing that kills their ticket wait times, and a sales or engineering leader who wants that is a fundamentally different budget conversation than one who's merely agreed not to object.
- The coalition is the point. An investment that four enabler functions and the growth org each independently want stops being an IT line item competing with every other project. It becomes the rare cross-company priority, which is what actually survives budget season.
Frequently Asked Questions
Isn't this framing just a nicer label for cost centers vs. revenue centers?
It's adjacent but not the same, and the difference matters. The cost-center label implies enabler teams are overhead to be minimized. The enabler framing is more accurate to what these functions actually do: they make growth durable and repeatable. A company with weak enabler functions doesn't grow faster, it grows recklessly until something expensive happens. The point of the framing is that both sides are doing real work, which is also why an investment serving both is worth more than one serving either.
Won't growth teams still resist anything called "governance"?
If it's pitched as governance, often yes. That's why the pitch to the growth side should lead with what they actually experience: access in minutes, day-one productivity, no more ticket queues. The governance is real, but for growth teams it's the invisible substrate, the same way nobody pitches a highway to drivers as "a traffic enforcement surface." Lead with the speed; the control comes along inseparably.
Which side should own the IGA initiative?
Ownership usually sits naturally with IT or security, since they run the identity infrastructure it builds on. But the requirements and the budget case should be built with all of them, both enabler peers (finance, HR, compliance) and growth representatives, because a project scoped by one function alone gets championed by that function and quietly resented by the rest. The dual-win only materializes if both sides shaped what "win" means before the platform was chosen.
Is there any scenario where this genuinely is zero-sum, where one side loses?
Yes: a badly scoped deployment. If governance is configured with maximal friction, approval chains for everything, no self-service, reviews designed for auditors with no thought for reviewers, then growth teams do lose speed, and they'll respond the way they always do, with workarounds that recreate the original risk. The both-sides win isn't automatic; it's a property of deployments that took the growth side's experience as a first-class requirement rather than an afterthought.
.svg)
