Communicating and partnering across functions

A manager is the interface between engineering and the rest of the organisation — product, design, sales, finance, executives, customers — and v1.0 framed the competency as communicating decisions and trade-offs outward. v3.0 widens it to partnering, because the relationship runs both ways: product and design have constraints as real as engineering's, executives make better decisions when engineering brings options rather than verdicts, and the standing of engineering in a company is set by whether it shows up as the partner that prices choices or the department that says no. The core skill is communicating in the listener's language and at their altitude — outcomes, trade-offs and risks, not architecture — and its core move, at every scope, is the trade-off stated calmly when someone with power asks for something that violates capacity or sequencing. It matters because most of the situations that damage engineering's credibility are communication failures: the bad news surfaced late, the ask absorbed silently until delivery fails, the flat refusal that reads as obstruction. The examinations test it constantly, because the comfortable answer — yes, or no — is nearly always the wrong one.

1. Speak the listener's language at the listener's altitude. The same fact is cost and risk to a finance leader, timeline and scope to a product lead, impact and resolution to a customer. Translation is the job; a lecture is a failure of it.
2. Bad news early, with options. Surfacing a risk before it matures into a surprise is the single most trust-building thing a manager does with stakeholders. Set expectations you can beat, never the reverse.
3. Every ask is answered with its trade-off. Never a bare yes or no. "We can do this, and here is what it displaces" lets the decision be made on the real price and keeps the manager from absorbing demand until delivery fails.
4. Partner sideways on shared outcomes. Alignment with product and design is built with one plan and joint planning, not two negotiated treaties; a conflict with a partner department is resolved at the level where priorities are owned, with the shared goal on the table.
5. Bring options, not vetoes. The way out of being seen as a cost centre is behavioural: "yes, and here is the cost" as the default grammar, engineering work visibly tied to revenue and risk.
6. Disagree on the merits, then commit. A strategy you believe is wrong is argued against directly, privately first, with evidence, framed on company outcomes; escalated honestly if it matters enough; and, if the decision goes the other way, committed to visibly rather than resisted quietly.

Stakeholder communication is practitioner territory, and the unit grades it so. One of the models is a rule from a single company that has become general usage.

Communicating at the listener's altitude practice

Not a named model but the practice at the centre of this unit: the same update, re-cut for each audience's concerns and level of abstraction. Its discipline is to start from what the listener has to decide, and to give them the outcome, the trade-off and the risk in those terms. Its characteristic failures are the one-size-fits-all update, the architecture lecture to a finance audience, and the answer to "move faster" that is either capitulation or a tutorial.

Trade-off transparency practice

The move introduced in DE-1 Prioritisation under constraint and used here as the core of negotiation: state what the request costs in terms of what else moves, and let the person who wants it choose. At organisational scope it is what a manager of managers does with a request to pull a strategic initiative forward, to absorb a new product line with no headcount, or to reprioritise every few weeks — the cost is named, in numbers, and the choice is made explicitly rather than absorbed and then failed broadly.

Disagree and commit practice

The rule stated in Jeff Bezos, 2016 Letter to Shareholders (Amazon.com, Inc.) (2017): when you disagree with a decision, say so directly and with your reasoning, and if the decision goes the other way, commit to it fully rather than withholding effort while waiting to be proved right. For this unit it is the executive-table form of partnership: a peer's strategy you believe is wrong gets a direct, private, evidence-based disagreement, then honest escalation if the stakes warrant it, then visible commitment. Its limit is that it presumes a decision was genuinely made and the disagreement genuinely heard; used to silence dissent before the decision, it is a different and worse rule.

Engineering as business partner practice

Not a named model but the stance this unit treats as the fix for "the department that says no": bring options and trade-offs instead of vetoes, tie engineering work visibly to revenue and risk, and change the system rather than fight each instance — the explicit gate for custom commitments agreed with sales at executive level, rather than a fight over each deal. Its evidence is experiential; its failure is the executive who defends engineering with indignation instead of evidence.

The audience-specific update

Before any update to a non-engineering audience, the manager writes one line: what does this person have to decide, and what do they need from me to decide it well? The update is then cut to that — cost and risk, timeline and scope, impact and resolution — and the technical detail is available on request rather than delivered by default.

The early-warning habit

The moment a risk to a commitment crosses the threshold at which the stakeholder would want to act, the stakeholder hears it, with the probability, the cause and the options. Not when it is certain, and not with excuses. The habit is what makes a later "we will beat this date" believable.

The cost-of-yes reply

Every request against a committed plan gets the same shape of reply: yes, and this is what it displaces; or, this is what it would take. Delivered calmly, in the requester's terms, with the choice left with them. The reply is recorded where the next requester will see it.

Joint planning with product and design

One plan, produced together, against shared outcomes, with dependencies explicit. Not an engineering plan and a product plan reconciled by negotiation. When a partner department's roadmap conflicts with the department's own, the resolution is sought at the level where both priorities are owned, jointly, with the shared goal on the table, rather than through a proxy conflict between teams.

Disagreeing at the executive table

When a peer executive's strategy seems wrong for the company: the disagreement is made directly and privately first, with evidence, framed on company outcomes rather than turf; escalated honestly if the stakes warrant it; and, once the decision is made, committed to visibly. Fighting the battle through subordinates is the failure this practice exists to prevent.

At team scope the object is the team's product and design partners and the stakeholder pressing for a date, and the manager translates, surfaces bad news early and sets expectations to be beaten. At organisational scope the object becomes department-level partners and executives who need trade-offs explained; communication becomes negotiation, with the cost of every ask stated in numbers and sideways alignment built on shared outcomes and joint planning. At executive scope the audiences are the board, the chief executive and peer executives, and the stakes are engineering's standing in the company: investment as staged business argument, vague pressure clarified before it is answered, and disagreement on the merits followed by commitment. The pattern is in How Judgment Scales; the economics behind the arguments are SV-4 Engineering economics.

• Pitches the same message to each audience's concerns: cost and risk, timeline and scope, impact and resolution. team
• Translates technical facts into business consequences. team
• Raises risks before they mature into surprises, and sets expectations to be beaten. team
• Leads with the trade-off and the reasoning when saying no or delivering disappointment.
• Failure mode — drowning non-engineers in detail. team
• Failure mode — going silent on problems. team
• Failure mode — one-size-fits-all updates. team
• Failure mode — over-promising to dodge a hard moment. team
• Answers every ask with its trade-off, calmly, in numbers, and gets the choice made explicitly. org
• Prices the churn of priorities that change every few weeks and negotiates a stable planning horizon with a fast lane for genuine emergencies. org
• Frames an investment plan to executives around business outcomes and the cost of not investing, not the feature list or the technology. org
• Builds alignment with product and design on shared outcomes and joint planning — one plan, not two treaties. org
• Resolves a conflicting partner roadmap at the level where priorities are owned, jointly, rather than through a proxy war between teams. org
• Failure mode — heroically absorbing asks until delivery fails. org
• Failure mode — flat refusals that read as "engineering says no". org
• Failure mode — escalating partner conflicts as blame instead of resolving them as priority calls. org
• Failure mode — investment pitches framed in technology instead of outcomes. org
• Frames a multi-year investment to a sceptical board as business strategy: what it enables and protects, what not investing costs, staged with checkpoints. exec
• Answers "why did headcount grow without faster output" with what the scaling bought and outcome measures, not a promise to make everyone busier. exec
• Clarifies and diagnoses "engineering needs to move faster" before defending or promising. exec
• Repositions engineering as the partner that prices options: "yes, and here is the cost" as the default grammar. exec
• Changes the system with a peer executive — an explicit gate for custom commitments — rather than fighting sales deal by deal. exec
• Disagrees with a peer executive directly, privately, on evidence and company outcomes; escalates honestly; commits visibly after the call. exec
• Failure mode — defending engineering with indignation instead of evidence. exec
• Failure mode — answering "move faster" with capitulation or a lecture. exec
• Failure mode — letting "no" be engineering's public vocabulary. exec
• Failure mode — fighting peer-executive battles through subordinates. exec

Candour versus standing. Surfacing a risk early can look like engineering being the bearer of bad news again; hiding it protects standing until it destroys it. The resolution is options: bad news delivered with choices reads as control, not alarm.

Partnership versus capacity. Being the partner who says yes and being the manager who protects the team's capacity pull in opposite directions. The cost-of-yes reply is how both are honoured: the yes is real, and so is the price.

Simplicity versus accuracy. A message cut to the listener's altitude leaves out detail that matters to engineers, and a message with the detail loses the listener. The judgment is in which details change the listener's decision, and in keeping the rest available rather than delivered.

Dissent versus commitment. Arguing hard against a peer's strategy and then executing it fully feels inconsistent, and it is the only stance that keeps both the argument and the organisation honest. The failure is on either side: silence before the decision, or resistance after it.

System versus instance. Each custom commitment sales makes is easier to fight than the system that produces them, and fighting instances never ends. The judgment is to spend the political capital once, at the executive level, on the gate.

A team's manager is asked by the product lead, in front of two sales colleagues, when the new reporting feature will ship. The team estimated it last week as six to ten weeks, with the range driven by an unresolved dependency on the data platform and by a design question the product lead has not yet answered. The product lead wants a date, says a range is not something they can take to a customer, and suggests that "eight weeks" would be fine to say.

The two easy answers are to say eight weeks, which becomes a commitment the moment it is spoken and will be defended against evidence for two months, or to repeat that the team cannot give a date until the dependency is resolved, which is true and reads as engineering being difficult in front of sales.

The manager translates rather than either of those. To the sales colleagues, in their terms: the team can commit today to delivering the first version — the two report types the customer asked for — within ten weeks, and will know within two weeks whether it can be sooner. That is a sentence they can take to the customer, and it is true. To the product lead, in theirs: the width of the range is two decisions, one of which is the product lead's own — the design question — and the other a dependency the manager will confirm this week; answering the design question by Friday narrows the range on its own. The manager offers to walk the product lead through the two drivers in ten minutes after the meeting, not in front of sales.

They also do the early-warning work the moment it is possible. The data-platform dependency is confirmed that week; it will land in week five, not week three, which moves the range to seven to ten. The product lead hears that on the day it is known, with the option it creates: hold the ten-week commitment, or descope one report type to protect eight. The product lead chooses to hold ten, and the customer was never told eight.

What the manager does not do is give the number that would have made the meeting comfortable and the next two months a defence of a date nobody believed. The cost of the honest answer was a slightly harder conversation in front of sales; the cost of the other answer would have been engineering's credibility with both.

• DE-1 Prioritisation under constraint — the queue the ask is placed in, and the cost of yes as prioritisation.
• DE-2 Estimation, planning, and honest commitments — the honest forecast a stakeholder is given instead of the date they asked for.
• SV-1 Engineering strategy — the strategy the department argues from, and the capability gap surfaced upward.
• SV-4 Engineering economics — the economics behind an investment argument: cost, headcount, and the price of not investing.
• CC-5 Values, integrity, and ethical judgment under pressure — declining to shade a message under executive pressure, and absorbing the cost.

1. Why is surfacing bad news early a trust-building move rather than a damaging one?
   Answer

   Because it arrives while the stakeholder still has options, and because a manager who reports risks early is believed when they say a date will be beaten. Late surprises convert delivery problems into trust problems.
2. The same delivery risk must be explained to a finance leader, a product lead and a customer. What changes?
   Answer

   The altitude and the terms: cost and risk for finance, timeline and scope for product, impact and resolution for the customer. The fact is the same; the message is cut to what each has to decide.
3. You are told to absorb a new product line with no headcount. What does the strong response contain that a yes or a no does not? org
   Answer

   The trade-off: what the department will stop or slow, in numbers, with a recommendation, and the choice made explicitly by the person who owns the priority. A yes absorbs and fails broadly; a no refuses the business.
4. Leadership changes priorities every few weeks and your teams are suffering whiplash. What do you negotiate? org
   Answer

   Name the cost of the churn — lost throughput, eroding trust — and negotiate a stable planning horizon with an explicit fast lane for genuine emergencies, so responsiveness is preserved without the constant re-sequencing.
5. The chief executive says "engineering needs to move faster" with no specifics. What comes before defending or promising? exec
   Answer

   Clarify and diagnose: faster at what, by whose measure, compared with what? Then respond with an evidence-based picture and a concrete plan. Capitulation and a lecture are the two failures.
6. The board asks why headcount grew without obviously faster output. What makes a response credible? exec
   Answer

   Showing what the scaling actually bought — reliability, security, capacity to run more products, risk retired — with outcome measures, rather than a promise to make everyone busier. Unmeasured growth is indistinguishable from bloat.
7. A peer executive is pushing a strategy you believe is wrong for the company. What is the sequence? exec
   Answer

   Disagree directly and privately first, with evidence, framed on company outcomes rather than turf; escalate honestly if it matters enough; and if the decision goes against you, commit visibly rather than resist quietly or fight through subordinates.

• Jeff Bezos, 2016 Letter to Shareholders (Amazon.com, Inc.) (2017) — disagree and commit.