Codify how engineering answers sales - bugs get fixed, out-of-scope features get a no, and the only next step is Product not re-escalation

July 27, 2026 at 11:54 PMoperationalhigh

Situation

Coming out of the LG episode Peter laid down the operating rule in writing in the temp-lg channel: Engineering will respond to sales requesting a fix for a bug and will deliver that bug fix without product involvement. Engineering response to a sales request for a new feature that falls outside currently supported builds or plans is no. The step after that is for Product to get involved. In the meeting he attached three companion rules: re-escalation after an answer has to stop, engineering should stop saying you can try it and it might work in favour of that is not supported, and CIQ must present a unified front so no internal voice tells a customer something is a bug after engineering has ruled it is not. He also drew the line between discussion time and decision time - internal deliberation should not be shown to sales as if it were still open.

Reasoning

Peter diagnosed the LG drag-out as a process failure rather than a technical disagreement. Sales asked, got an answer, escalated, got the same answer from him, and escalated again - which teaches the org that persistence changes outcomes. He explicitly does not want to discourage sales from asking, so the fix cannot be punishing the question; it has to be a defined path with a terminal node. Routing the terminal node to Product rather than back to Engineering puts the cost-benefit call with the function that owns it, and keeps engineering out of relitigating. The stop-saying-you-can-try-it rule is a response to compounding fog: when language, culture and timezone gaps already exist, a hedged answer is read as a soft yes. The unified-front rule targets the specific harm of internal disagreement leaking to a customer.

Additional Context

Ryan asked Peter not to put a pin in this and requested a shortened escalation path for sales. Justin pointed out the real failure was earlier - the initial hedged answer was never escalated for a decision, and the later escalation happened only after the predicted failure occurred. Peter attributed part of the problem to five years of CIQ saying yes to close deals, and said the untraining will only happen through some pain.

Observed Evidence

Written doctrine posted in-channel plus three separate spoken formulations in the meeting - the escalation-must-stop rule, the not-supported messaging rule, and the unified-front rule.

Matching Patterns

50%
Protect Engineering Focus Through Process(2 keyword matches, same category (operational))
50%
Reclassify to Route - Decide Who Owns It, Then Give a Criterion Not a Verdict(1 keyword match, involves Ryan Smith, Justin Haynes)

Confidence Breakdown

34/35
Evidence
26/30
Pattern
20/20
Source
14/15
Corroboration

Reasoning Depth Analysis

Org Signal:The answer is the answer. Escalation is a routing mechanism, not an appeal mechanism.
Who Affected:Product inherits the terminal node and now owns every out-of-scope customer ask; Support stops absorbing the ambiguity; APAC account teams lose the 24-hour telephone game as an excuse.
Precedent:Direct extension of the 7/21 Product-Engineering operating model decision - this supplies the inbound-request half of the same contract. Any future sales ask now has a named path with a defined end.
Consequences:Real and immediate; Peter said the untraining will only happen through some pain and accepted that.
Timing:Now because the LG case produced a clean, expensive example everyone in the room had just lived through - the teaching moment was live.

Related Context

💬
#temp-lg-uplus-rhel-ol-ciq-packages-support

slack

Engineering will respond to sales requesting a fix for a bug and will deliver that bug fix without product involvement. Engineering response to a sales request for a new feature that falls outside of our currently supported builds/plans is no. The step after that is for Product to get involved.

🎥
LG - Next Steps

fathom

They asked the questions, they got an answer. And then they asked, well, we do not like the answer. How do we escalate? And they escalated up to me and they got an answer and they did not like the answer. So then they said, how do we escalate? That is got to stop.

🎥
LG - Next Steps (unified front + not-supported)

fathom

I actually do not think it is helpful for us to say, yeah, you can try it, it might work. I want the message from engineering to be, that is not supported. ... There is a difference between discussion time and decision time, and they do not go in the same buckets.

Outcome

Applied live on the Everfox question Jul 31 - pass it off to Dieter for an answer, and unless we have trained Sales on the answer that question rightly comes to us or Brady.

Rating: 4/5

Decision ID: de73388b-56d0-45fc-92c8-d6d90b563eaf