Communicating and partnering across functions

A manager is the interface between engineering and the rest of the organisation: product, design, sales, finance, executives and customers. 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 decide better when engineering brings options instead of verdicts. And engineering's standing in a company depends on whether it shows up as the partner that prices choices or as the department that says no. The core skill is communicating in the listener's language and at their altitude, which means talking about outcomes, trade-offs and risks and leaving the architecture out. Its core move, at every scope, is to state the trade-off calmly when someone with power asks for something that breaks capacity or sequencing. Most of the situations that damage engineering's credibility are failures of communication: bad news surfaced late, an ask absorbed in silence until delivery fails, a flat refusal that comes across as obstruction. The examinations test this 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. To a finance leader the same fact is cost and risk; to a product lead it is timeline and scope; to a customer it is impact and resolution. The job is translation, and a lecture means the translation failed.
2. Bad news early, with options. Raising a risk before it matures into a surprise does more to build stakeholders' trust than anything else a manager does. Set expectations you can beat, never the reverse.
3. Every ask is answered with its trade-off. Never with 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 stops the manager absorbing demand until delivery fails.
4. Partner sideways on shared outcomes. Alignment with product and design comes from one plan, planned jointly, instead of 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. Engineering stops being seen as a cost centre through how it behaves. Its default grammar becomes "yes, and here is the cost", and its work is visibly tied to revenue and risk.
6. Disagree on the merits, then commit. Argue directly against a strategy you believe is wrong: privately first, with evidence, framed on company outcomes. Escalate honestly if it matters enough. If the decision goes the other way, commit to it visibly instead of resisting quietly.

Stakeholder communication belongs to practitioners, and the unit grades it that way. One of the models is a rule from a single company that has passed into general usage.

Communicating at the listener's altitude practice

This is a practice, not a named model, and it sits at the centre of the unit: the same update, re-cut for each audience's concerns and level of abstraction. The discipline is to start from what the listener has to decide and 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 a reply to "move faster" that is either capitulation or a tutorial.

Trade-off transparency practice

DE-1 Prioritisation under constraint introduces this move, and here it becomes the core of negotiation. State what the request costs in terms of what else has to move, and let the person who wants it choose. At organisational scope a manager of managers uses it when asked 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. The alternative is to absorb the request and then fail across the board.

Disagree and commit practice

The rule is stated in Jeff Bezos, 2016 Letter to Shareholders (Amazon.com, Inc.) (2017). When you disagree with a decision, say so directly and give your reasoning. If the decision goes the other way, commit to it fully instead of holding back effort while you wait to be proved right. In this unit it is how partnership works at the executive table. A peer's strategy you believe is wrong gets a direct, private disagreement based on evidence, then honest escalation if the stakes warrant it, then visible commitment. The rule assumes that a decision was in fact made and the disagreement was in fact heard. Used to silence dissent before the decision, it becomes a different rule, and a worse one.

Engineering as business partner practice

This is a stance, not a named model, and the unit treats it as the remedy for "the department that says no". Engineering brings options and trade-offs instead of vetoes, ties its work visibly to revenue and risk, and changes the system instead of fighting each instance. An example is an explicit gate for custom commitments, agreed with sales at executive level, in place of a fight over every deal. The evidence for it is experiential. Its failure is the executive who defends engineering with indignation where evidence was needed.

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 fit (cost and risk, timeline and scope, or impact and resolution), and technical detail is available on request instead of delivered by default.

The early-warning habit

As soon as a risk to a commitment crosses the point at which the stakeholder would want to act, the stakeholder hears about it, with the probability, the cause and the options. They hear it before it is certain, and without excuses. This habit is what makes a later "we will beat this date" believable.

The cost-of-yes reply

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

Joint planning with product and design

There is one plan, produced together against shared outcomes, with dependencies made explicit. An engineering plan and a product plan reconciled by negotiation is the thing to avoid. When a partner department's roadmap conflicts with the department's own, the two sides look for a resolution together, at the level where both sets of priorities are owned and with the shared goal on the table, instead of letting the teams fight a proxy conflict.

Disagreeing at the executive table

When a peer executive's strategy seems wrong for the company, the manager disagrees directly and privately first, with evidence, and frames the case on company outcomes instead of turf. If the stakes warrant it, they escalate honestly. Once the decision is made, they commit to it visibly. This practice exists to prevent the battle being fought through subordinates.

At team scope the manager deals with the team's product and design partners and with the stakeholder pressing for a date. The work is to translate, raise bad news early and set expectations that can be beaten. At organisational scope the counterparts become department-level partners and executives who need trade-offs explained. Communication turns into negotiation: the cost of every ask is stated in numbers, and sideways alignment rests on shared outcomes and joint planning. At executive scope the audiences are the board, the chief executive and peer executives, and engineering's standing in the company is at stake. Investment is argued as a staged business case, vague pressure is clarified before anyone answers it, and disagreement on the merits is followed by commitment. The pattern is in How Judgment Scales, and the economics behind the arguments are in 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 and in numbers, and gets the choice made explicitly. org
• Puts a price on priorities that change every few weeks, and negotiates a stable planning horizon with a fast lane for real emergencies. org
• Frames an investment plan to executives around business outcomes and the cost of not investing, instead of the feature list or the technology. org
• Builds alignment with product and design on shared outcomes and joint planning, producing one plan instead of two treaties. org
• Resolves a conflicting partner roadmap jointly, at the level where priorities are owned, instead of through a proxy war between teams. org
• Failure mode: heroically absorbing asks until delivery fails. org
• Failure mode: flat refusals heard 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, and checkpoints for each stage. exec
• Answers "why did headcount grow without faster output" with what the scaling bought and with outcome measures, instead of 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, with "yes, and here is the cost" as the default grammar. exec
• Changes the system with a peer executive, for example an explicit gate for custom commitments, instead of fighting sales deal by deal. exec
• Disagrees with a peer executive directly and privately, on evidence and company outcomes; escalates honestly; commits visibly once the call is made. 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" become engineering's public vocabulary. exec
• Failure mode: fighting peer-executive battles through subordinates. exec

Candour versus standing. Raising a risk early can make engineering look like the bearer of bad news yet again. Hiding it protects standing until the moment it destroys it. Options resolve this, because bad news delivered with choices comes across as control instead of 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 honours both: 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 carrying that detail loses the listener. The judgment lies in knowing which details would change the listener's decision, and keeping the rest available without delivering it.

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

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

In front of two sales colleagues, a product lead asks a team's manager when the new reporting feature will ship. Last week the team estimated six to ten weeks. The width of the range comes from an unresolved dependency on the data platform and from 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.

There are two easy answers. The manager could say eight weeks, which becomes a commitment as soon as it is spoken and will be defended against the evidence for two months. Or they could repeat that the team cannot give a date until the dependency is resolved, which is true and, in front of sales, makes engineering look difficult.

The manager translates instead. To the sales colleagues, in their terms, they say the team can commit today to delivering the first version, covering the two report types the customer asked for, within ten weeks, and will know within two weeks whether it can be sooner. Sales can take that sentence to the customer, and it is true. To the product lead, in their terms, they explain that the width of the range comes down to two decisions. One is the product lead's own design question. The other is a dependency the manager will confirm this week. An answer on the design question by Friday narrows the range by itself. The manager offers to take the product lead through the two drivers in ten minutes after the meeting, away from sales.

They also do the early-warning work as soon as they can. The data-platform dependency is confirmed that week: it will land in week five instead of week three, which moves the range to seven to ten weeks. The product lead hears this on the day it becomes known, along with the option it creates, which is to hold the ten-week commitment or to descope one report type to protect eight. The product lead chooses to hold ten. The customer was never told eight.

The manager declined to give the number that would have made the meeting comfortable and turned the next two months into the defence of a date nobody believed. The honest answer cost a slightly harder conversation in front of sales. The other answer would have cost engineering its 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 raised upward.
• SV-4 Engineering economics: the economics behind an investment argument, covering 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 turn 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 stays the same, and the message is cut to what each of them 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. It sets out what the department will stop or slow, in numbers, with a recommendation, and has the person who owns the priority make the choice explicitly. A yes absorbs the work 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 in lost throughput and eroding trust, and negotiate a stable planning horizon with an explicit fast lane for real emergencies. That keeps the organisation responsive without 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 a picture grounded in evidence 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 bought (reliability, security, the capacity to run more products, risk retired) with outcome measures, instead of promising to make everyone busier. Growth that is not measured cannot be told apart 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 instead of turf. Escalate honestly if it matters enough. If the decision goes against you, commit visibly; do not resist quietly or fight through subordinates.

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