- Duration: 60 minutes
- Prerequisites: M04: Influence Without Authority; M05: Objection Handling
- Primary Metric: Discovery Audit
- Frameworks: 4 (Anti-Pitch, Extreme Ownership, Red Update, Up-selling Ethics)
The migration that is going to slip and the customer does not know yet
You see the integration complexity that the implementation team has not yet flagged. The VP of Operations expects delivery by quarter-end. The temptation is to wait for someone else to deliver the bad news. The trusted advisor delivers it Tuesday morning, with options: not Thursday afternoon when there are no options left.
The opportunity to close a deal that should not close
The customer is ready to sign. You know the SKU does not actually serve their stated business need. Your account team is already counting the booking. The Anti-Pitch is the move that costs you the quarter and earns you the next five years of the account: if you can deliver it without making the customer feel naive for being ready to sign.
The post-mortem on a failure that was partly your fault
The implementation went sideways because a discovery question was not asked. The customer is angry, the implementation partner is defensive, and your account team is already working on a counter-narrative. Extreme Ownership is the move that prevents the relationship from being the next casualty of the project.
Common Misconceptions About This Module
- "Radical transparency means saying every hard thing immediately." No. It means delivering the relevant hard truth, with options and a recommendation, in a timely way. Volume of candor is not the same as quality of candor: an architect who shares every concern is not a trusted advisor, just exhausting.
- "The Anti-Pitch is for cases where you would lose the deal anyway." If you only Anti-Pitch deals you would lose, you are not Anti-Pitching: you are rationalizing. The credibility move only works when you would have closed the deal and chose not to. The customer feels the difference.
- "Extreme Ownership means accepting blame for things that were not my fault." No. It means owning the outcome and what you would do differently, regardless of fault attribution. The customer is not asking who is at fault; they are asking who is going to lead the recovery. Extreme Ownership is "I will lead this": not "this was my fault."
- "A Red Update damages confidence." A poorly delivered Red Update damages confidence. A well-constructed one: with the data, the impact, the options, and a recommendation: reliably increases confidence, because it demonstrates the architect sees the same risk the customer sees and is leading the response.
- "Up-selling and trust-building are at odds." Only when up-selling is grounded in revenue rather than customer value. The trusted advisor identifies up-sell opportunities the customer has not seen yet and names them with the same neutrality they would use to recommend a competitor. The test is the no-incentive thought experiment.
Anti-Pitch
The Anti-Pitch is when you recommend against the sale you could make. It is the highest-leverage credibility move available to an advisor. By voluntarily telling a customer “our platform is not the right fit for this requirement,” “this project is not ready to start,” or “a competitor will serve this use case better,” you earn a level of trust that no pitch deck can purchase. Anti-Pitch opportunities are rare, must be used judiciously, and must come with a specific alternative recommendation:not just a negative.
The Anti-Pitch breaks the customer's default assumption that everyone who works for a vendor is selling them something. That single moment: "they recommended against the sale": reframes you from vendor to advisor for the rest of the relationship. The customer's pattern-match changes; future recommendations carry weight that no demo can produce.
When the SKU technically works but does not serve the stated business need. When timing is wrong (the customer is not ready). When a competitor genuinely serves the use case better. Never invent Anti-Pitch opportunities: the customer can tell. If there is no real Anti-Pitch available, do not manufacture one.
Extreme Ownership
Borrowed from Jocko Willink: the advisor owns the outcome of the engagement, not just their individual deliverable. If the architecture was technically correct but the implementation failed, Extreme Ownership means understanding why, presenting what you would do differently, and leading the correction:not deflecting to the implementation team, the customer’s internal processes, or the vendor. Customers forgive failures. They do not forgive deflection.
The customer is not actually asking who is at fault: they are asking who is going to lead the recovery. Extreme Ownership preempts the political pattern of blame distribution by making it irrelevant: when the architect leads the response, the room reorganizes around the response rather than around fault attribution. That move is what produces the durable trust.
Any post-mortem on a project that did not land as expected. Any moment where the room is reaching for blame. After a discovery gap surfaces in implementation. Avoid in cases where a clear blame narrative is being assembled by a third party against you specifically: in those moments Extreme Ownership reads as confession, and you need a Red Update structure instead.
Red Update
A structured format for delivering difficult project status with clarity and without softening the data: (1) what was expected, (2) what actually happened, (3) what the business impact is if unaddressed, (4) what options exist, and (5) what you recommend. The Red Update is not a confession:it is a demonstration that you see the same risks the customer sees, and that you are actively working on them. Customers who receive a well-constructed Red Update trust the architect more, not less.
The Red Update structure removes the two failure modes of bad-news delivery: minimization (which destroys credibility when reality surfaces later) and catastrophizing (which damages confidence without producing decisions). Forcing each section produces a delivery that is calibrated, decision-supporting, and proves the architect is leading rather than hiding.
Any project status that is materially worse than what was last communicated. The first Tuesday after the slip becomes visible: not the Thursday before the executive review when there are no options left. Use proactively rather than reactively; a Red Update delivered before the customer asks for one is what produces the trust upgrade.
Up-selling Ethics
The trusted advisor is alert to when a customer need exists that a different or expanded product could genuinely solve:and navigates the ethics of raising it. Up-selling Ethics is the framework for distinguishing genuine customer value creation (raise it clearly, name the value) from revenue optimization at the customer’s expense (stay silent or reframe needs to fit what you sell). The test: would you make this recommendation if you had no financial incentive to do so?
The no-incentive thought experiment ("would I recommend this if I had nothing to gain?") makes the test internally falsifiable. If the answer is no, do not raise it: the customer will sense the misalignment even if they cannot articulate it. If the answer is yes, raising the up-sell is itself a trust-building move because it demonstrates the advisor sees opportunities the customer has not yet seen.
When a customer's stated business outcome would clearly be better served by an expanded scope or different SKU. Frame the up-sell in customer-value language first, financial framing second. If the value framing collapses without the financial framing, the up-sell is not ethical: it is revenue chasing.
An eight-week slip, a Red Update on Tuesday, and a CIO who upgraded the architect's authority instead of revoking it
Situation
Mid-market P&C insurer, $2.1M Azure modernization. Eight weeks in, the architect identifies a regulatory data-handling pattern that was not surfaced in discovery. Honest re-estimation: 6–8 weeks of additional work, $340K incremental cost, and the original quarter-end commitment to the CIO Patricia Owen and her board is now infeasible. The implementation partner is preparing a narrative that blames the customer for not surfacing the pattern earlier. The account team is asking the architect to "manage expectations gently" through Q4 close.
Move 1: Resist the soft-landing pressure, schedule the Red Update for Tuesday
The default path was a Thursday afternoon "informal heads-up." The architect chose Tuesday morning, a 30-minute structured slot with Patricia plus her CFO. Tuesday because it gave Patricia three working days to absorb, decide, and brief her board before Friday. Soft-landing on Thursday would have left her no decision room.
Move 2: Open with the data, not the apology
Architect's opening: "We committed to quarter-end go-live. Current state, with the regulatory data pattern we surfaced in week six, is mid-Q1 at the earliest. Business impact if we hold the original date is uncontrolled risk on the regulatory exposure. Three options exist." No apology. No softening. Patricia's first-minute reaction was visible relief: she had suspected the date was at risk but had been told by the implementation team that everything was on track.
Move 3: Three options, with a recommendation
Option A: hold the date, accept regulatory exposure (architect: do not recommend). Option B: extend to mid-Q1, $340K incremental, full regulatory scope (architect's recommendation). Option C: descope the regulatory module, deliver core platform on date, separate workstream for regulatory in Q1 ($420K total but cleaner go-live narrative). Patricia took 40 seconds and chose Option B.
Move 4: Extreme Ownership of the discovery gap
Architect: "The reason this surfaced in week six instead of week one is that I did not ask about regulatory examination history in the discovery sessions. Patricia, what I would do differently is a separate regulatory discovery loop with your compliance officer at engagement kickoff. I am building that into the protocol now." No deflection to the implementation partner. No mention of the customer's disclosure obligations. The architect owned the gap.
Move 5: Resist the third-party blame narrative in writing
The implementation partner's written status update that week attributed the slip to "customer-side data complexity surfaced late." The architect rewrote that section in the joint communications: "The regulatory data pattern was not surfaced in our discovery. We are extending the timeline to address it correctly." First person plural. No third-party fault attribution. Patricia noticed.
Outcome
Patricia approved the $340K incremental and the timeline extension within 48 hours. She named the architect as her go-to for the next platform decision (a $5M document AI initiative) before that initiative had even been scoped. Six months later, in a Microsoft executive briefing, she described the architect as "the only vendor who told me the truth on a Tuesday." That sentence is the trusted-advisor relationship made operational. The Red Update did not cost trust. It produced it.
The Anti-Pitch that cost $800K and earned the next decade of the account
Situation
Mid-size logistics customer ready to sign on Azure Synapse for an analytics workload. Stated need: real-time route-optimization scoring under 400ms latency. The architect, in a final design review, realized Synapse's batch-leaning pattern was a poor fit for the latency target. A purpose-built streaming product (in this case, a competitor's offering) was a better technical fit. The deal was effectively closed; the SOW was waiting for signature.
Move
Architect, in a 1:1 with the VP of Analytics two days before signature: "I want to flag something. The latency target you set in week one is at the edge of what Synapse will do reliably under your peak load. There's a different pattern: a streaming-first architecture: that will land it more cleanly. It's a different product family, and honestly a competitor delivers it better than we do today. I'd rather you know this before signature than discover it in production. Here's a specific recommendation."
Outcome
The customer paused, ran a parallel evaluation, and selected the competitor for that workload. Eight months later, when an unrelated $4.2M data-platform decision came up, the same VP called the architect first: before publishing the RFP: and said: "we're starting with you because you told us not to buy something once." The Anti-Pitch cost the architect's team $800K in immediate revenue and earned what became a $7M account over the following three years. The lesson is not that Anti-Pitches always pay off financially. The lesson is that they always pay off in trust, and trust is the asset.
Extreme Ownership in the post-mortem of a project that was 60% the partner's fault
Situation
Regional healthcare system, EHR integration project that missed go-live by 11 weeks. The implementation partner had under-staffed the project. The customer's internal data team had under-prepared the source system. The architect's discovery had been thorough but had not stress-tested the partner's staffing plan. In the post-mortem with the CIO, the implementation partner was already presenting a deck attributing 70% of the slip to customer-side data quality issues.
Move
Architect, in the post-mortem: "There are several contributing factors here, and one of them is that I didn't validate the partner's staffing model against the integration complexity I had estimated. That's a discovery responsibility I want to own. What I will do differently going forward is a staffing-readiness review as a deliverable on every architecture I produce. For the recovery, here is what I recommend." The architect did not contest the partner's deck. The architect did not litigate fault percentages. The architect stayed in their own ownership lane.
Outcome
The CIO Helen Carrera ended the meeting by asking the architect to lead the recovery directly: bypassing the implementation partner's project manager: for the remaining 14 weeks. The customer assigned the architect's recommendation as the operating plan. The implementation partner was eventually replaced on a follow-on engagement. Extreme Ownership did not absorb fault for the partner. It claimed leadership of the response: which is the only authority the customer is actually trying to assign.
Up-selling Ethics: the no-incentive thought experiment in real time
Situation
The architect, deep into a contact-center modernization, recognized that the customer's stated reporting needs would be substantially better served by a Power BI Premium capacity than the per-user licenses currently planned. The incremental ARR was meaningful for the account team. The customer had not raised the question. The architect's quota would benefit if it landed.
Move
Internal thought experiment: "If I had no quota, no incentive, no compensation tied to this expansion: would I still recommend it?" Yes: the per-user model would cap their analyst growth in 18 months. The architect raised it with that framing first: "This is not a need you raised, but I want to flag it. With your analyst hiring trajectory, the per-user model will hit a ceiling before year-end. Premium capacity removes that ceiling. Here's the math, including the year-three break-even."
Outcome
The customer approved the upgraded SKU within two weeks. Equally important: the architect did not raise three other potential up-sells from the same engagement, because they failed the no-incentive test. That selectivity is what made the Premium capacity recommendation credible: the customer learned to trust the architect's restraint, which made the rare recommendation carry weight.
Red Update Drafting
Use the Red Update Template (M06_Red_Update_Template.docx) to draft a difficult status communication. Time yourself: the draft should take under 15 minutes. The remaining 10 are for delivery practice.
- Choose a scenario: a migration that is running 8 weeks behind schedule due to an underestimated integration complexity that you failed to surface in discovery. The customer believed it would be done by the end of the quarter.
- Complete all five sections of the Red Update: (a) what was expected and committed to, (b) what the current state actually is, (c) what the business impact is if the timeline is not recovered, (d) two or three realistic options with their trade-offs, and (e) your specific recommendation.
- Read it aloud as if you are delivering it in person to the customer’s VP of Operations.
- Ask a peer to listen and answer: did that sound like accountability or like blame-shifting? Did the VP learn what they needed to make a decision? Would they trust you more or less after that conversation?
| Section | Content |
|---|---|
| 1. What was expected | Quarter-end go-live (Sep 30), full regulatory module included, $2.1M total cost. |
| 2. What is actually happening | In week 6 we surfaced a regulatory data-handling pattern (NAIC examination protocol) that was not in scope at kickoff. Current trajectory puts realistic go-live at mid-Q1 (Feb 15), with $340K incremental engineering required to handle the pattern correctly. |
| 3. Business impact if unaddressed | If we hold the original date and ship without the regulatory pattern, exam exposure on the next NAIC review (Q2). If we hold the date and rush the pattern, we ship code that we will rebuild in Q2 anyway: net cost higher, plus reputational risk. |
| 4. Options | (A) Hold the date, accept regulatory exposure: not recommended. (B) Extend to mid-Q1 with $340K incremental, full regulatory scope: recommended. (C) Descope the regulatory module from go-live, separate Q1 workstream at $420K total: viable but creates a second go-live event. |
| 5. Recommendation | Option B. The single extended timeline is cheaper, cleaner from an exam standpoint, and avoids the second go-live's coordination cost. Decision needed by Friday to lock the engineering capacity. |
What to notice: no apology in the document. The apology, if any, happens once verbally at the start of the meeting. The document is a decision-support artifact, not a confession. Sections 4 and 5 take the customer from problem to decision in 90 seconds.
Common drafting failure: burying the impact in section 2 ("the regulatory pattern is complex and the team is working hard"). Effort language belongs nowhere in a Red Update. The customer needs data and options, not effort narratives.
Anti-Pitch Practice
Practice making the recommendation that costs you something. This exercise builds the credibility muscle that can only be built through use.
- Choose a scenario from M06_Anti_Pitch_Scenarios.pdf: a customer scenario where the available solution technically works but is not the best fit for the stated business need.
- Partner A plays the customer, who is ready to move forward and expects the architect to close the engagement.
- Partner B (the architect) must deliver the Anti-Pitch: acknowledge what could work, name the specific gap between the solution and the true business need, and offer a specific alternative recommendation:even if it means recommending a competitor, a delay, or a reduced scope.
- Partner A: report how your trust in the architect changed during and after the Anti-Pitch. Did you want to work with them more, or less?
- Discuss: what would have to be true for you to make the Anti-Pitch in a real engagement? What is stopping you?
Failing version (vague, hedged): "There may be some considerations around latency we should think about. Synapse should work for most of your scenarios, though there are also some other options if you want to explore them." → The customer hears: "this architect is not confident, but they're not actually telling me to do anything different." Signature happens. Production fails. Trust collapses retroactively.
Passing version (specific, bounded, actionable): "I want to flag something before signature. The 400ms latency target you set in week one is at the edge of what Synapse will do reliably under your peak load: meaning, in your November freight surge, you'll see 600–800ms responses on the route-scoring queries. That degrades the optimization decisions enough that I think a different pattern is the right call. Specifically: a streaming-first architecture handles this cleanly. Honestly, [Competitor X] delivers it better than we do today on this exact use case. I'd rather you know this Tuesday than discover it in production in November. Here's a specific recommendation, and here's an introduction to two of their solution architects if you want to evaluate."
What to notice: the Anti-Pitch is specific (400ms target, November surge, 600–800ms degradation), bounded (this exact use case, not a general recommendation against the platform), and actionable (named alternative, named contacts). It does not apologize. It does not hedge. It treats the customer as someone capable of receiving the data.
The credibility math: the Bramley deal cost the architect $800K in immediate revenue. Eight months later the same VP brought a $4.2M decision back. Three years later total account value crossed $7M. The Anti-Pitch is a present-value sacrifice for a future-value asset. Architects who cannot do that math should not Anti-Pitch: the calibration would be wrong.
Trusted Advisor Timeline
Map the trust arc of a real or hypothetical customer relationship from first contact to trusted advisor status.
- Draw a timeline on paper: left end is first contact, right end is “the customer calls you before they know what the question is.”
- Mark 5 to 7 moments along the timeline where trust either grew or could have been damaged: the first meeting, a difficult decision, a missed commitment, a successful delivery, a moment of candor.
- For each moment, write one sentence: what was the signal the customer was giving you about their level of trust, and what was the right response?
- Identify the one moment where you earned the most trust. What made it work? Could you replicate it intentionally?
- Identify the one moment where you nearly lost it. What saved it?
| Moment | Trust signal | Right response |
|---|---|---|
| Month 1: first technical review | CIO Helen Carrera tested the architect with a constraint she had not raised in pre-call (HIPAA examination cycle). | Acknowledge the constraint, ask three diagnostic questions to understand its scope, surface that you had not asked about it. Discovery gap owned in the moment. |
| Month 3: missed staffing-readiness check | Implementation partner under-staffed. Architect did not flag it pre-kickoff. | (In hindsight, the moment trust could have been preempted but was not. Document the gap, build into protocol.) |
| Month 6: the slip became visible | Helen sent a brief, neutral email asking for a status. The neutrality was the warning. | Same-day Red Update offer. Tuesday meeting scheduled. No softening. |
| Month 7: post-mortem with the partner's blame deck | Helen watched the architect's response to a third-party blame narrative. This was the test moment. | Extreme Ownership of the staffing-readiness gap. Did not contest the partner's percentages. Stayed in own lane. |
| Month 9: recovery led, project landed | Helen began copying the architect on internal-only emails about the next initiative. | Reciprocate the trust signal: bring forward an Anti-Pitch on a feature she expected the architect to recommend. |
| Month 14: new $5M initiative scoping | Helen called the architect before the RFP was published. | Discovery from a position of trust. Surface unstated constraints she would not have shared 14 months earlier. |
| Month 18: executive briefing | Helen used the phrase "the only vendor who told me the truth" in front of a Microsoft VP. | (That is the trusted-advisor sentence. The 18-month arc was made operational in that moment.) |
The earned-trust curve: month 1 was performance. Months 6–9 were the test (hard moments handled well). Months 14–18 were the dividend. Architects who try to deliver an Anti-Pitch in month 1 generally fail because the trust collateral has not been built. The Anti-Pitch in the Bramley case worked because there was already a thread of credibility: not because the technique itself is universally effective on day one.
The Discovery Audit for this module is a trust marker: you pass when customers share unstated business constraints with you that they have not shared with other vendors. That level of candor does not happen without the behaviors this module builds. Rate yourself on the evidence, not the intention.
Trust-building self-assessment is the most over-rated assessment in the program. The behaviors feel obvious in retrospect; the actual delivery is where most architects under-perform their self-rating. These are the three most common inflations.
Mistake 1: "I delivered hard news, therefore I delivered a Red Update."
A Red Update has five sections: expectation, reality, impact, options, recommendation. Telling a customer "we are going to slip 4 weeks" is not a Red Update: it is a status complaint with no decision support attached. Rate Ready only if your last difficult delivery had all five sections in writing or in spoken form, and a peer can confirm none of the data was minimized. Most architects who rate themselves Ready on this indicator are rating their willingness to deliver bad news, not the structural quality of the delivery.
Mistake 2: The Anti-Pitch self-attribution problem.
"I have made an Anti-Pitch before" is one of the most common Ready ratings on this rubric and one of the most likely to be wrong. The clean test: did you recommend against a deal you would otherwise have closed, with a specific alternative, in a way the customer can articulate back to you afterward? "I told them this might not be the best fit" is hedging, not Anti-Pitching. If you cannot point to a specific named customer where the Anti-Pitch cost you a quantifiable amount of money in the short term, rate Developing. The framework is a sacrifice move: if there was no sacrifice, the move was not made.
Mistake 3: Discovery Audit confusion: voluntary disclosure vs. extracted information.
The Discovery Audit indicator for this module is specifically about voluntary disclosure: the customer shared a constraint with you that they had not shared with other vendors, and you did not have to dig for it. Architects routinely mistake "I asked good questions and got good answers" for "the customer trusted me with information they were withholding." Those are different. Rate Ready only if you can identify a constraint the customer told you they had not previously named to anyone else: including their account team. If the disclosure happened because you asked the right question, that is M01 (Discovery), not M06 (Trust). The module's metric is specifically about the latter.
The when-in-doubt rule: trust-related ratings should be calibrated against an external observer's confirmation, not your own felt sense of the relationship. The most common trust-overreach pattern is mistaking a customer's professional courtesy for trust. If a peer or manager who attended the relevant conversation cannot confirm the trust marker independently, rate Developing.