Talk to the Business: Working With PMs and Non-Engineers

TL;DR Explain a real problem in technical terms and the business says no, and the fix you need never gets funded. To talk to non-technical stakeholders, convert the problem into their units (money, time, risk, customers), put the impact and the ask in the first two sentences, offer options with costs, and ask for one decision by a date.

Do this: Rewrite your next technical request so its first sentence says the cost in money, time, risk or customers.

Part 4 ended with the crew adopting the AI test tool, Ollie wanting it on every team, and the Admiral asking whether any of it is worth paying for. Pip has the pitch ready. She has numbers. She stands up in the steering meeting.

"Our end-to-end suite is flaky, about one run in six, so we'd like budget for the AI tool and two weeks to stabilise..."

The Admiral holds up a flipper. "Why should I pay?"

Dev Voyage: Open Ocean, in six parts:

1. Working With a Difficult Boss Without Losing Yourself
2. Feedback Both Ways: Asking For It and Giving It
3. Say No Without Making Enemies, and Keep Your Energy
4. Keep Learning: Bringing New Tools (and AI) Into Real Work
5. Talk to the Business: Working With PMs and Non-Engineers (you are here)
6. Ask for the Raise: Showing Your Value Without Bragging

Same facts, wrong units

Everything Pip said was true. It was also in units the Admiral doesn't use. Ollie, the product manager, tried again.

Engineers think in tests, services and latency. The people who fund the work decide in money, time, risk and customers. The same fact has to be converted before it can be weighed.

Use numbers the listener can check. Pip took hers from the release log: 9 delayed releases in four months, and 8 of them caused by test failures that turned out to be false alarms.

Impact first, details last

The Nielsen Norman Group calls it the inverted pyramid: the most important information first, detail after, because readers stop early. For a business message that means the impact and the ask go in the first two sentences. Pip rewrote hers that evening.

Releases slip by a day about twice a month because of false alarms in
testing (8 of the last 9 delays). We'd like two weeks to fix it.

A) Fix the test suite: 2 weeks of one developer. Delays should become rare.
B) Do nothing: keep losing about 2 release days a month.
C) Fix only the 10 worst tests: 3 days. Roughly half the delays.

We recommend A. Could you approve it by Friday, before the sale freeze?

Details for the curious: which tests fail, and why, in the attached page.

It's part 1's options pattern, plus a single ask with a date. "Thoughts?" opens a discussion that never ends. "Could you approve A by Friday?" gets an answer.

When they pick "do nothing"

Sometimes the business picks B. That's a real decision: they may have a bigger risk on their desk that you can't see. Write it down with its known cost and a date to look again.

14 Oct: Admiral chose B (do nothing for now).
Known cost: about 2 release delays a month.
Look again: 6 Jan, with the delay count since today.

Google's SRE book does something similar with reliability in Embracing risk: engineering and the business agree a number, the error budget, and plan against it. Once the number is shared, the argument is about trade-offs, not feelings.

Your PM translates with you

Ollie saved that meeting because translating is half her job. On most teams the split is:

• The product manager owns why and what: which problems matter, in which order.
• Engineers own how: what it takes, and what it risks.

So Pip booked fifteen minutes with Ollie every Monday, with one question on the table: what should the Admiral hear from us this week, before he hears it from someone else?

Try it

This week:

1. Pick one technical problem and find its cost in money, time, risk or customers, from your own logs.
2. Write the impact and the ask in the first two sentences, the detail last.
3. Give two or three options with costs, a recommendation, and one ask with a date.
4. Book a short weekly slot with your product manager.

The Admiral approved option A in one reply, and told the client's board that the Red Fox crew "explains things like adults". Ollie forwarded it to the whole ship with a crown emoji. Then, at Friday lunch, Bun asks Pip the question she has avoided for months: if the client trusts her this much, and she's doing a senior engineer's work, is she paid like one? Part 6, Ask for the Raise: Showing Your Value Without Bragging, is how she prepares the talk with Kit.

Read this with your AI

Read the post "Talk to the Business: Working With PMs and Non-Engineers".
1. I'll describe a technical problem. Convert it into money, time, risk or customer impact.
2. Rewrite my message so the impact and the ask are in the first two sentences.
3. Draft three options with costs and a recommendation, ending with one clear ask.