Your Infrastructure Proposal Makes Sense to Engineers, and the CFO Still Said No

Your engineering team has been living with the same system for two years. Every new feature touches it, every incident review mentions it, and your best engineers have quietly stopped volunteering for anything near it. Everyone on the team agrees on the fix: a migration that will take two quarters and most of the platform group.

So you wrote the proposal. It explained the coupling, the gaps in test coverage, the deployment risk, and the architecture you want to move to. The engineers who read it nodded. Then it went to the CEO and the CFO, and came back as "let's revisit next quarter."

The usual conclusion is that leadership doesn't understand engineering. Sometimes that's true. More often, the proposal answered questions the decision-makers weren't asking and skipped the ones they were. That's a writing problem, and an engineering leader with a full calendar is badly placed to solve it alone.

Why good engineering proposals lose budget fights

Engineering proposals are usually written the way engineers evaluate ideas: describe the current system, explain what's wrong with it, present the better design. For a technical reader, that order builds the case. For the person who controls the budget, it buries it.

A CFO reading a migration proposal is asking a different set of questions:

• What do we get, and when? Not "a cleaner architecture," but what the business can do afterward that it can't do now.
• What does it cost, including what we won't build? Two quarters of the platform team is a roadmap decision, not just a headcount line.
• What happens if we don't? "Technical debt" is not an answer. Slower releases, more incidents, a compliance gap, or engineers leaving might be.
• How will I know it's working halfway through? A two-quarter project with one outcome at the end looks like a bet. A project with checkpoints looks like a plan.
• What's the smallest version of this? Decision-makers trust a proposal more when it shows the author considered doing less.

Most rejected proposals answer the first question with architecture diagrams and never get to the last three.

A structure that survives the executive meeting

Here is the structure I'd use for any technical investment that needs approval from people outside engineering. It works whether you write it yourself or hand it to someone else.

1. The decision, in the first paragraph. State what you're asking for: the people, the time, and what gets deferred. "We're asking to dedicate four platform engineers to the billing migration for Q1 and Q2, which moves the reporting overhaul to Q3." Busy readers read the top of a document carefully and skim the rest. Put the ask where they'll read it.

2. The cost of the status quo, in business terms. Translate each technical problem into something the business already cares about. "Tightly coupled services" becomes "every change to billing requires a coordinated release across three teams, which is why the pricing change sales asked for took a quarter." Use your own evidence: incident reviews, cycle times from your issue tracker, support escalations, features that slipped. Numbers you can defend from your own systems beat any industry statistic.

3. The options, including doing nothing. Show at least three: do nothing, do the smallest useful fix, do the full migration. Give each an honest cost and an honest outcome. If doing nothing is viable for another year, say so. The credibility you earn here carries the rest of the document.

4. The plan, in phases with real checkpoints. Break the work into stages that each deliver something on their own and each end at a point where leadership could stop. "After phase one, billing deploys independently. If we stop there, we've still eliminated the coordinated release." That turns an all-or-nothing bet into a series of smaller decisions, which are far easier to approve.

5. The risks, stated before anyone asks. What could make this take longer? What is fragile during the transition? What will customers notice? An executive who finds a risk you didn't mention will assume there are others.

6. What you'll report, and how often. Name the two or three measures you'll bring back at each checkpoint. This is what turns approval from an act of faith into an act of oversight.

Move the technical design to an appendix or a linked document. The engineers who need it will read it. The people approving the budget need to know it exists and that someone they trust has reviewed it.

Write it for the skeptic in the room

Before the proposal goes out, identify the person most likely to say no and write for them. Often that's the head of sales, who sees two quarters of platform work as two quarters without the features customers keep asking for. Name that trade-off yourself, and show which of those requests get faster to deliver once the migration is done. A proposal that already contains the strongest objection, with a fair answer to it, leaves the meeting with much less to argue about.

It's the same discipline that makes public thought leadership work, which I wrote about in Your CTO's Byline Is on an Article Nobody Could Disagree With: know your claim, know the strongest case against it, and answer that case in writing.

Why this is a ghostwriting job

The engineering leader is the right author. Their name goes on the proposal, their credibility carries it, and they'll answer the questions in the meeting. But they're often the wrong person to draft it, for two reasons. They're too close to the technical problem to see which parts a non-engineer needs explained, and they're writing it in the evenings, between everything else the job demands.

Drafting this kind of document takes two skills at once. The writer has to understand the architecture well enough to interview your engineers, check the claims, and catch the hand-waving. Then they have to translate all of it into cost, risk, and time without losing accuracy. A generalist writer produces something polished that your engineers won't recognize. An engineer produces something accurate that the CFO won't finish.

That translation is the work I do. I spent decades writing software before co-founding Inkwright, Inc., so I can sit down with your staff engineers, understand why the current system hurts, and write the version of that story your executive team can approve or reject on its merits. The named author reviews it, owns every word, and walks into the meeting with a document built for the people in the room.

Get the decision you need

If your team has a technical investment it knows is necessary and leadership keeps deferring it, I'd be glad to talk it through with you: what you're asking for, who has to say yes, and what the proposal needs to say to get a clear decision either way. You can reach me through the contact page.