Chapter 28: Stakeholders and Embedded Collaboration

Adapted public course. Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

Lesson explanation

28.1 The Value and Boundaries of Co-location: When You Must Be Physically Present

Chapter 27 established the timetable: several days on site for scoping, remote improvement during validation, and several days a week on site during delivery. It answered when to go, but not the more fundamental question: why send your body rather than your camera?

Co-location physically changes several things. First, information bandwidth. In a minute beside a user’s screen, you see a hesitant cursor, an avoided menu, and a sticky note on the monitor that no remote meeting conveys. Second, contact density. In the customer’s office, you can be pulled into a three-minute corridor conversation containing the project’s most important hidden information. Third, speed of trust formation. People trust someone who has sat beside them and examined real problems faster than an avatar on a screen. Delivery’s difficult work — obtaining permissions, cooperation, and changes to other people’s processes — depends on that trust.

Co-location also costs time, travel, and continuity with the team back home. It therefore needs boundaries. Three situations require presence:

First, ambiguous requirements. Chapter 27 explained why scoping needs presence: actual problems live in frontline complaints, and the gap between intended and actual processes can only be measured in the field. Second, dense stakeholder coordination. Around launch, approvers, network administrators, supervisors, and on-call managers each hold a veto. A day’s coordination on site can take two weeks of remote scheduling. Third, sensitive data. When the rule is “you may inspect it but may not take it away,” the customer’s internal network is your entire working environment. Presence is itself a constraint, not a preference.

Conversely, most validation work can and should be remote. Building evals, iterating solutions, and improving against evaluation sets require deep work, protected asynchronous collaboration, and uninterrupted focus, as Chapter 30 explains. Start with weekly or fortnightly on-site checkpoints as this book’s methodological assumption, then adjust to data access, risk, and customer feedback; this is not an industry frequency standard.

This addresses a tension within the book. Chapter 30 strongly emphasizes “async first, public by default”: synchronous work is expensive, asynchronous work is normal. Here we emphasize embedded presence and intensive synchronous interaction. They govern different collaboration surfaces. Chapter 30 concerns collaboration with your own team, protecting colleagues’ focus and retaining information in public channels. This chapter concerns delivery with the customer organization, where trust is not yet established, hidden information is dense, and you cannot impose a collaboration culture. Internally, you can set asynchronous defaults; at the customer site, you are a guest and interactive work is central. Neither setting dictates the other: internal async practice does not justify demanding that customers leave written messages, and daily customer meetings do not justify importing that rhythm into your team. Chapter 30’s concluding “customer-site exception” provides the corresponding statement and cross-reference.

Presence is a means, not a gesture. Ask whether the necessary information, trust, and permission can only be obtained by being there.

28.2 Stakeholder Engagement by Level: One Role, Three Languages

There is no single entity called “the customer” on site. There are people with distinct positions, languages, and concerns. FDE failures often come from using the wrong language: architecture diagrams for business stakeholders or ROI for frontline supervisors. Chapter 27 layered scoping interviews into frontline, middle, and senior levels. Here that becomes a project-wide engagement strategy.

Three core groups — technical teams, business stakeholders, and executives — each need a language and suitable artifacts:

Stakeholder	Concerns	Communication language	Suitable artifacts	Common mistake
Technical: IT, data, security	System boundaries, data destinations, security responsibility, maintenance after launch	Architecture and data: interfaces, deployment topology, permissions, failure modes	Architecture with data flows, deployment plan, ADRs, operations handoff checklist	Treating them as helpers rather than co-owners; bypassing their constraints
Business: process owners, department managers	How workflows change, metric definitions, what staff must learn	Processes and metrics: current versus future workflow, time and quality at each step	Workflow comparisons, metric-definition table, user instructions, training plan	Discussing model capability instead of outcomes; starting before metric definitions agree
Executives: CIO, business VP, sponsor	Return on investment, risk exposure, organizational politics, external narrative	ROI and risk: hours saved, risk added, when numbers will appear	One-page status with red/amber/green, milestones, decisions needed; risk list	Reporting detail without judgment, or good news without the scale of risk

Use three disciplines.

One event, three translations. Suppose accuracy on the same versioned evaluation set under comparable settings rises from 82% to 91%. Technical teams receive failure attribution, category results, and regression protection. Business teams hear: “Errors on this evaluation set fell from 18% to 9%; a pilot must test whether that represents production.” Executives receive a proposal: “The results support requesting the next controlled pilot, with wider rollout conditional on safety, latency, cost, coverage, operations readiness, and customer approval.” These teaching figures describe the test set only; they neither guarantee halved production errors nor promise a full-rollout date. Translate to the level of information needed for the other person’s decision, not a different numerical precision. Senior leaders need judgment, middle managers need to manage, and frontline staff need to act. Artifacts serve those actions.

One primary contact at each level, not a web of direct links. Establish a technical contact, usually an architect or IT lead; a business process owner; and an executive sponsor. Route cross-level communication through these contacts where possible rather than connecting yourself directly to everyone. This respects organizational order and prevents knowledge vanishing when you leave as the sole information hub. The contact mechanism is part of sustainable delivery.

Executives receive a regular one-pager, not unlimited availability. They need a sense of control: a fixed cadence, perhaps fortnightly, and fixed structure of status, milestones, risks, and decisions needed. The last field is essential. Decisions needed give executive engagement its value: extra budget, cross-department coordination, and compliance exceptions may require sponsor authority. Without that field, executive contact becomes ceremonial reporting.

The levels will conflict. Business metrics require data the technical team cannot obtain; technical hardening needs time executives will not approve. The FDE is a translator who proposes resolutions, not a messenger. Translate disagreement into shared facts about availability, effort, and risk, then make a reasoned proposal. That leads to the next section.

28.3 Autonomous Decisions Under Ambiguity: Authority, Records, and Customer Proposals

The most uncomfortable embedded moments are when nobody tells you what to do, but action is necessary. A customer contact is on leave: should a data-export exception use a workaround? A process owner cannot confirm and has endorsed two field designs? The sponsor is at a board meeting, but no answer today means a wasted week of validation?

A traditional engineer waits; a traditional outsourcing project asks and then waits. FDE value lies in shortening decision latency. Yet autonomy is not recklessness. It requires an agreed boundary.

Authorization-boundary matrix. At kickoff, or no later than the end of scoping, align face to face with the sponsor on what you may decide immediately, report afterward, or must ask about beforehand:

Category	Decide immediately	Report afterward, in writing the same day	Obtain prior approval
Technical implementation	Eval composition, prompts and model parameters, code structure, internal tool selection	Introduce dependencies or external tools, adjust noncritical interfaces	Architecture changes inside customer systems, changes to data-write paths
Scope	Select demonstration/validation samples, refine evaluation metric definitions	Tradeoffs among features within validation scope	Commit to new business scope, change milestones
Data	Read and analyze within the project environment	Use and destroy temporary data copies	Any data leaving the customer environment, access to a new data domain
Communication	Routine coordination with contacts	Add cross-department contacts	Any disclosure beyond the customer

Negotiating the matrix is valuable itself. The sponsor discovers hidden authorization gray areas in an AI project; you discover differences between stated and actual risk tolerance. Once agreed, ambiguity changes from guessing what the customer thinks to knowing which lane you occupy. The former drains attention; the latter requires execution.

Decision records: the customer version of an ADR. Chapter 12, Section 4, gives ADR criteria: difficult to reverse, surprising without context, and resulting from a real tradeoff. They apply doubly here, because future readers include the customer’s receiving team and a replacement contact a year later. Reuse Chapter 12’s structure with three extensions. First, write context in the customer’s language: their architect should understand why option A was rejected. Second, record the source of authority: immediate decision, afterward report, or prior approval, identifying the matrix cell. Third, store it in a shared document space, not only personal notes, mirroring Chapter 30’s requirement to return conclusions to the group. A good record lets successors reconstruct every important decision during handoff or contact changes.

The customer version of “propose rather than ask.” Chapter 12’s architectural principle — bring reasons and alternatives rather than asking from an information imbalance — becomes a default communication stance on site. Two extensions matter.

First, information asymmetry is two-way. You do not know the customer’s unwritten organizational rules; the customer does not know technological boundaries. Therefore state assumptions explicitly: “My proposal assumes expedited approval is possible, historical data formats have not changed for three years, and the supervisor will support the pilot. If any fails, the plan needs adjustment.” A rejected assumption is a useful output, not a failed proposal: it makes both parties’ unknowns visible.

Second, repeatedly sending customers multiple-choice questions accumulates the impression that you cannot decide. Once trust acquires that label, every subsequent approval becomes more expensive. A proposal does not decide for the customer; it makes their decision less costly. Chapter 12’s principle has direct financial consequences at the customer site.

Together, the matrix defines your lane, decision records preserve each junction, and reasoned proposals guide lane changes. They answer one question: how to act quickly and accountably with incomplete field information. Traditional delivery roles pass ambiguity upward; FDEs translate it into a structure that supports decisions. Chapter 29 explains how those field patterns return as team assets.

[Exercise] Translate Ambiguity into Three Tools

Task: Continue Chapter 27’s dental-clinic case. In delivery week three, you discover that the clinic director verbally chose summary template A last week, while doctors generally write records in template B’s style. The customer’s IT lead privately says A has rendering-compatibility problems that the director does not know about. The director is away at a conference and replies only by email, one day between messages. Produce: (1) the issue’s position in the authority matrix and why; (2) a customer ADR including context, assumptions, and authority source; (3) a proposal email to the director, no more than 200 words (the Chinese edition uses 200 Chinese characters); both editions explicitly state three assumptions and a default action such as “Unless you object, I will proceed with B on date X.”

Guidance: Notice two transformations. First, dissect ambiguity: the director lacks compatibility information, IT will not bypass hierarchy, and you know everything but lack decision authority. The three tools turn “What do I do?” into assumptions, boundaries, and a proposal. Second, a default action changes reply effort from choosing to objecting, avoiding a wasted week in asynchronous executive coordination. Its prerequisite is crucial: the matter must actually belong in the afterward-reporting cell. Otherwise the default action exceeds your authority.

Reference direction for instructors: Check three things. The placement analysis should recognize a compound event: template choice may need only an afterward report, but withholding compatibility information from the director involves organizational relationships and requires judgment beyond mechanically selecting a cell. The ADR should incorporate IT’s private information without naming the person or compromising their position. The email must propose rather than ask. Turning three assumptions into three questions, such as “Do you prefer A or B?”, simply returns the whole decision to the director.

---

Sources for the industry facts in this chapter: This is a general-methodology chapter. The on-site cadence of scoping and delivery comes from The Pragmatic Engineer’s August 2025 interview with OpenAI’s FDE leader, cited in Chapter 27; co-location as a forward-deployed mode also comes from that interview. The stakeholder table, authority matrix, customer ADR extensions, and customer proposal method are this book’s methodological development. ADRs reuse Chapter 12 and internal async-first collaboration reuses Chapter 30. These are the book’s own material, not descriptions of a particular company’s internal practices. No additional industry statistics are cited. Unsourced cases, proportions, amounts, email waiting times, and checkpoint frequencies are teaching assumptions, not customer measurements or industry benchmarks.

---

Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save chapter-28.md with versions, decisions, evidence and gaps.

For business, technical, user and operations stakeholders, record concerns, authority and artifacts, then propose a mix of onsite and asynchronous work.

Required chapter artifact: stakeholder responsibility network

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

• O1: The stakeholder responsibility network names an owner for each of business owner, engineering team and security and governance
• O2: The stakeholder responsibility network defines at least two interfaces with inputs, outputs and authority limits
• O3: The artifact records three positions, decision rights, evidence and escalation route for one dispute

Reveal reference feedback (answer first)

Reference feedback

Business approves rules and value, technical owners review architecture and access, users validate workflow, and operations accepts handover. Use onsite work for hard-to-observe workflows and record decisions in an approved space. Coordination does not let an FDE approve everything.

Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.