Cloud Cost and Capacity Should Not Be Your First Job

Cloud cost and capacity has become a destination career. Job postings describe it as a starting discipline, certification programs sell it as a first credential, and the scripts for running the practice are published and free. I want to argue the opposite. The job consists of judgment about other people’s systems, what a workload really needs, what a commitment really binds, what a shortage really costs, delivered to teams who have every right to test the messenger. Judgment like that has to come from somewhere, and the only place I know to get it is years of doing the work underneath. Cloud cost and capacity should not be your first job. Come into it midway through a career, after you have built and run the systems whose consumption you will one day be asked to govern.

The producer who made records first

Rick Rubin is the model I keep coming back to, and not only for the production philosophy. Look at the biography before the producing began. As a student at Long Beach High School he befriended the audiovisual department director, who gave him lessons in guitar playing and songwriting; he then played in bands and put together a punk band called The Pricks, whose CBGB set ended when friends of the band picked fights with hecklers to shut the show down and create a buzz.1 At New York University he formed the band Hose and played guitar in it, and in 1982 a Hose track became the first record Def Jam ever released. 2

So the most influential record producer of his generation was a musician first. Before he produced anyone’s record he was inside the work: learning the guitar, playing the rooms, carrying the gear, watching his own band get thrown off a stage. Rubin himself describes his method as stripping work down rather than adding credentials to it, and the evidence is in what he removed. The arrangements and studio polish he took away from Johnny Cash, leaving a voice and a guitar recorded in his living room and Cash’s cabin, produced an album that won a Grammy 3, and that judgment about what to remove came from years of making records before he ever occupied the producer’s chair.

The parallel to this job is exact. The producer sits between the music and the business, and everything he says is tested against people who know the craft from the inside. A capacity professional sits between the systems and the organization, and everything we say is tested against people who know the systems from the inside. The role carries no automatic authority over the people it advises. What carries the day is having been in the work before.

What the job actually asks

The textbook version of capacity work makes it look like arithmetic. Measure the workload, forecast the demand, subtract the supply, order the difference. Every part of that sentence is real and every part conceals judgment that has to come from experience.

Take a request that arrives in a capacity queue: a team wants 2,000 of a specific GPU next quarter. Answering it well means reading the request the way someone who has run similar work would read it. What is the workload doing, and does the request name the right hardware, or did somebody pick the first GPU-shaped name in the console? Does the work survive if that exact hardware is unavailable in that region that quarter, which for several of the rarest SKUs is the expected case rather than the exception? What does the same request cost under the organization’s existing commitments, and what does adding it do to the commitments’ remaining term? Can the power, the cooling, and the networking in the named data center carry it?

None of those questions is a formula. Each one is a judgment, and the judgment has to be sound enough to deliver to a team that knows its own work better than you know yours. An engineer who has carried a pager through a launch, waited out a hardware allocation failure, or paid for a badly sized commitment can hear the questions underneath the request. Someone arriving fresh from a certification course can recite the sizing method and still miss the part that matters, because the part that matters is knowing what the answers are worth.

There is also the standing question. This job delivers unwelcome messages regularly. The launch date has a supply problem. The savings proposal would break a recovery obligation. The commitment outlasts the workload that justified it, and the invoice will reflect that for years. The people receiving those messages can accept them from a colleague who has visibly done the work, sat through the 2 a.m. outage, run the migration, lived with an architecture someone else chose. Delivering the same message without that history, from a role that exists to say such things, reads very differently. Standing is earned in the work, and this job spends standing constantly.

The frameworks organize. The experience supplies.

The published material for this field is good, and the community that maintains it has my genuine respect. The FinOps Foundation’s framework organizes the practice into principles, personas, and capabilities, and its own persona descriptions tell the same story this post is telling. The Engineering persona is the group “responsible for designing, building, managing and optimizing technology infrastructure,” with architecture and design at the top of its responsibility list.4 The FinOps Practitioner persona is a bridge, someone who works “with business, engineering and finance teams, applying a working knowledge of the FinOps Framework to establish a FinOps culture.”5 A working knowledge of the framework, applied to teams whose own knowledge is deeper than yours in their domains. The framework is the organizing layer, and the organizing layer sits on top of something.

That is the honest description of the relationship between the literature and the job. The books and the framework organize knowledge; the knowledge itself comes from the work. Reading the FinOps book does not teach you what a stockout feels like in the week before your launch. Reading the SRE book’s capacity chapter does not teach you what it is like to be escalated on for a shortage nobody in the building could have prevented. Those experiences are the material the frameworks organize. A practitioner who arrives with the framework and without the material has an empty filing system.

If you want this job, and you are early

The honest answer is: not yet, and the not-yet is not a gatekeeping reflex. It is the same advice the music would give. Spend the first years of your career building and operating systems. Take the on-call rotation. Do the migration. Own the performance work and the bill for something that matters, including the quarter when the bill doubles and you are the one who has to explain it. Learn a workload deeply enough to know what its utilization chart hides. Everything in this book’s method will be waiting for you when you arrive, and you will use all of it better for the years you spent underneath.

If you are already in the role as your first job, the repair is the same experience, taken deliberately. Get close to the systems: sit in the engineering reviews, walk the data center or the region topology, take a shift in the incident channel, learn what the database team is worried about this month. Build the relationships early, because the relationships are where the demand intelligence lives. The disadvantage of arriving early is real, but it is repairable in a way that a damaged supply plan is not.

If you hire for these roles, weight the years underneath heavily. A candidate who has operated systems and absorbed their consequences will bring judgment you cannot train quickly, and the framework part is genuinely learnable on the job. The reverse hire is expensive in a way that shows up later, usually during the first real shortage, when the organization discovers whether its capacity lead can read the room and the supply at the same time.

The Rick Rubin rule holds for computing. Be in the work first. Then manage the work.

In the book

This argument runs through Scale Without Surprise from the first pages: knowing what you consume before you change anything (chapter 1), capacity as a decision rather than a spreadsheet (chapter 2), and the map of who can actually change a promise (chapter 3), the relationships and authority the job spends all day.

Sources

1. Wikipedia, “Rick Rubin”, Early life section, accessed October 6, 2026: guitar and songwriting lessons from the school audiovisual director, bands before The Pricks, the CBGB incident arranged by friends of the band.

2. Wikipedia, “Rick Rubin”, Def Jam section, accessed October 6, 2026: Rubin founded Def Jam while studying film at NYU, played guitar in Hose, and in 1982 a Hose track became Def Jam’s first release, a 45 rpm single in a brown paper bag with no label.

3. Andrew Romano, “Rick Rubin on Crashing Kanye’s Album in 15 Days”, Newsweek, June 27, 2013, recalling the Radio credit; American Recordings (1994) recorded in Rubin’s living room and Cash’s cabin, with the Grammy listed by the Recording Academy for Best Contemporary Folk Album.

4. FinOps Foundation, “FinOps Personas — Engineering”, accessed October 6, 2026: responsibilities begin with architecture and design and include infrastructure and platform management.

5. FinOps Foundation, “FinOps Personas — FinOps Practitioner”, accessed October 6, 2026: the bridge role and its working-knowledge framing.