The Middle Job
This post is part of my Medium blog.
FinOps is a difficult job to get promoted from.
Not because it is unimportant. Because it is in the middle.
You work between engineering and finance, two functions that often disagree about what matters, what counts as evidence, and who is responsible for the consequences. Engineering wants to build the thing. Finance wants to know what the thing costs. FinOps is expected to translate between them, which means you spend a lot of time delivering news to engineering that engineering does not want to hear, then turning around and delivering a different kind of news to finance that finance does not want to hear.
Everybody respects the translator.
Nobody is especially excited to promote the translator into either country.
This is not unique to FinOps. DevOps has the same problem. Security has versions of it. Data architecture, platform engineering, enterprise architecture, technical program management — any job with a combination-word title is at risk of becoming a place where the organization puts work that belongs to multiple functions and authority that belongs to none of them.
I call these the middle jobs.
They are useful because the company needs someone to cross the boundary. They are difficult because crossing the boundary is not the same as owning either side of it. You can spend ten years learning how to make finance and engineering understand each other and still find that, when promotion time arrives, neither one knows how to sponsor you.
The people on both sides know your value. They just do not know where to put it.
That is a career problem, not a competence problem.
FinOps makes this especially visible because the job sits inside technical work while talking about money. I am an engineer, and when I ran FinOps as a function I treated it as an engineering function that happened to be accountable for cost. You cannot do the job well if you do not understand databases, systems, architecture, and the decisions engineering leaders have to make when every option has a tradeoff.
If you do not understand the system, you cannot understand what the cost means.
Finance people may reasonably point out that FinOps is about financial accountability, forecasting, allocation, and controls. They are right. Those things matter. But a FinOps leader who cannot understand the system behind the spend is reading receipts without knowing what meal was ordered.
Engineering leaders have their own objection. They may not see the FinOps director as an engineer. They see somebody asking why the service costs so much, asking whether the architecture still makes sense, and asking why the commitment made three years ago is still consuming budget today. They see the question before they see the technical background required to ask it.
So the FinOps person has to establish credibility twice. You have to explain the system to finance and explain your right to discuss the system to engineering. Then you have to explain the money to both of them, because the number means something different depending on who is being asked to act on it.
It is valuable work, but it leaves you standing in a doorway while everyone else gets to claim a room.
That is the problem with middle jobs: they become essential without becoming legible.
In Redundant, Rob Coleman and Rahul have worked together for years. They came up through roughly the same cohort. At one point they were both senior people trying to establish themselves. Now Rahul is a VP and Rob is a director.
They are still friends. That does not make the difference disappear.
There is a particular tension when someone you started alongside moves ahead of you. You can be happy for them and still look at the distance between your titles and ask what happened. Not in the abstract. In the personal, slightly humiliating way. You remember the same meetings. You remember when both of you were trying to prove that you belonged. You remember the version of the org chart where the difference between you was not yet visible.
Then one of you is a VP and the other is still explaining the cost model to VPs.
Rob believes Rahul has the easier job. That may not be fair to Rahul. Rahul has his own problems, and the book is not a case for the idea that software engineering leadership is easy. But Rob can see a path in Rahul's work that he cannot see in his own. Engineering leadership is allowed to own things. FinOps is often asked to explain things that other people own.
That distinction compounds over time. If you are the person who owns the platform, you can be promoted because the platform is legible. If you are the person who translates what the platform costs to the people who approve the budget, you can become indispensable while remaining difficult to place. You are needed in every conversation and claimed by none of them.
The work is cross-functional. The career path is not.
This is why the middle jobs can be so frustrating. You are trusted with the difficult conversation. You are invited when the company needs someone to say the thing people would prefer not to hear. You are sent into the meeting because you can explain the technical consequences to finance and the financial consequences to engineering without making either side feel stupid.
Then the year ends, and the people who got promoted are the people who own a function.
You get thanked for being a bridge. Nobody asks whether the bridge should become a city.
The organization does not necessarily mean to punish you. That is part of the problem. The arrangement works. Finance gets a translator. Engineering gets somebody who can explain why the bill is rising. Executives get a person who can be brought into a room, shown a number, and asked to make the number understandable.
Everyone receives value from the middle job. The person in the middle is the one who has to decide whether access is enough.
Rob and Rahul's relationship carries that tension into the opening of Redundant. The friendship is real. The history is real. So is the difference in their position. Rob knows Rahul is not responsible for the structure that made one career path more legible than the other, but that knowledge does not prevent the comparison from happening.
You can respect someone and still resent what their title says about your own career.
That is not a moral failure. It is one of the ordinary costs of working in an organization where people who began together do not arrive together.
The uncomfortable question is whether the middle job can become a destination instead of a holding pattern. Maybe it can. Some organizations eventually recognize that the person who moves between functions is doing leadership, not support. Some create real executive roles for FinOps, security, or platform leaders. Some do not.
The title helps. The reporting line helps. The budget helps. But none of those changes the basic question: does the organization want you to own a decision, or does it want you to make somebody else's decision understandable?
Those are different jobs.
The person who makes decisions gets judged by the outcome. The person who translates decisions gets judged by whether everyone in the room felt comfortable enough to keep moving.
That is why the middle job can feel like a ceiling. You can become the person everyone trusts and still be the person nobody knows how to promote.
Rob is good at FinOps. He knows how to find the number, trace it back through the architecture, explain it to finance, defend it to engineering, and present it to a room that would rather talk about anything else. He is useful to everyone.
That does not mean there is a place prepared for him at the next level.
The middle is not the absence of power. It is power without a clean title.
In Redundant, the first book in The Condition Set trilogy, Rob Coleman runs the FinOps review that names the waste nobody wants to hear about. The numbers do not change. The question is who they get used against.