Breakdowns at Work (Requests & Promises)

Breakdowns – When Life Doesn’t Go the Way You’ve Planned

Last post, I wrote about breakdowns at work – when things don’t go the way you’ve planned – and what to do about them.  We examined a mythical case study about the ABC Manufacturing Company and their total failure with supplying parts to Boeing.  It didn’t end well for Boeing, ABC, and ABC’s other customers.  But what contributes to breakdowns?


The Effective Request

One of the most frequent, underlying causes of breakdowns is the lack of an effective request and/or the commitment underlying a promise – the response to a request.  Sally’s initial request (“meet our production schedule”), Joe’s response (“We’ll do everything we can”), Joe’s request of Fred (“Can you make it happen?”), Fred’s response (“I guess so… I’ll try”) all set the conditions that guaranteed the contract would run into trouble and experience minor and major breakdowns.

According to Julio Olalla, the founder of Newfield Network, an effective request has four, essential components:

  • A specific action to be performed
  • By a specific time
  • With what’s obvious to you (the requestor) that might not be obvious to the requestee
  • And your “conditions of satisfaction” (what it would take for you to declare the request was successfully completed)

Effective Requests Can Mitigate Breakdowns

What was missing from Sally’s request?  From Joe’s?  How would you have improved the request?  What would you have added or included?  How many times do you see something similar happening in your organization – and how often are you the cause?

Let’s take Joe’s request of Fred (the Production Manager) – “Can you make it happen?”

  • What’s the specific action to be performed? “Can you make it happen?”  What’s the “it?”  If Joe had involved Fred earlier in the process, he may have prevented several of the breakdowns that eventually led to disaster.  “Fred, will you review our proposed scope of work, production schedule, and deliverables before we sign the contract?” or “Fred, will you agree to the terms and conditions in the proposed contract for Boeing?”
  • By when? By 4:00 next Wednesday
  • What’s obvious to Joe that’s not obvious to Fred? “I’ve been working for the last several years, nurturing key relationships with Boeing, convincing them that we produce quality work, on time, on budget, consistently.  Boeing’s developing their next generation plane, the 787 Dreamliner, and have an initial production order for 100 planes, but their just-in-time production model means they’ll need our parts for the wing stabilizers on-time, every time.  If we can deliver on this, it will open a new host of opportunities and will fuel our growth for the next 10-20 years.  It’s a game-changer.
  • Joe’s “conditions of satisfaction” might be, “If you can review the scope of work, production schedule, and deliverables by next Wednesday at 4:00, and confidently share with me how we’re going to make that happen, I’ll be able to take the contract for signature on Thursday, Sally’s drop-dead deadline for submittal.”

While I wouldn’t recommend you do this for every request, if it’s something of importance, make sure you design the request in advance, using this basic model.

The “Solid” Promise

But what about once you, make the request?  What then?  There are four responses to a request (called a “promise” – a commitment to take a specific course of action):

  • “Yes.”
  • “No.”
  • A counter-offer (which establishes a new request and reverses the original roles of requestor and requestee)
  • A request for a specified amount of time to think about what’s possible, then a “yes,” “no,” or counter-offer

Fred receives Bob’s request and makes sure he understands it, asking clarifying questions before he responds.  He can’t make it an “automatic yes” (which we often do); he has to consider that, if he does commit, how will he meet this – and all his other commitments.

But Fred also has to avoid “sloppy promises” like:

  • “I’ll see if I can fit it in the schedule.”
  • “Let me see what I can do.”
  • “We’ll try really hard.”

Each of these is less than a commitment and is usually an indicator that the request won’t be met.

So Fred understands Joe’s request and may have said:

  • “Yes, Joe, I can see how we have capacity and experience to do this job and still keep our schedule on other jobs.
  • “No, Joe, we don’t have the experience, the equipment, or the staffing to be able to meet this deadline.
  • “Joe, we won’t be able to produce the amount of parts required in this job, but we have some high-quality subcontractors and partners we’ve used who could help us. Would that be acceptable to you if I explored that possibility?” (A new request from Fred to Joe)
  • “Joe, if you can give me the rest of the day to talk with my team, you and I can huddle at 4:30 and I can give you a better answer.”


When we enter into half-hearted promises or ones where we don’t feel we have a choice (where it’s really a disguised “order” or declaration), there’s always a higher chance of breakdown because the commitment is replaced with compliance or obligation.  When commitment isn’t present in both parties, trust begins to break down.

Managing the Cycle of Promise

Managing the process doesn’t end with the “Promise.”  It only starts the process, or what Bob Dunham calls the “Cycle of Promise.”  There are two roles in this process: Customer (the person making the request) and Performer (the requestee).  Both play a vital role in creating a satisfactory outcome.

Here’s an outline of all the steps that might take place:

  • Customer: Clarifies what he or she is asking for, specific standards, and conditions of satisfaction and makes the request
  • Performer: Clarifies the understanding of the request and declines or, ultimately and conditionally, accepts. This generates the “Promise.”
  • Customer and Performer: both initiate check in’s to clarify how things are going.
    • If the promise is in jeopardy, the Performer notifies the Customer as soon as he or she becomes aware of this condition
    • If the Customer experiences any changes in the request, conditions, standards, or timeline, he or she notifies the Performer as soon as known
    • When conditions change, either party should renegotiate the Promise to clarify understanding
  • Customer: makes assessments of the finished result, compared with the original agreement At that point, the Customer issues an expression of satisfaction (appreciation) or dissatisfaction (complaint)
    • If we arrive at the due date and the Performer has met all conditions of the request, then the Customer declares satisfaction with the work and expresses appreciation
    • If the due date arrives and the Performer has not met the conditions, then the Customer uses conversations for complaining. When we do not use the conversation for complaining, we run the risk of allowing our personal and professional standards to be compromised.
      • Check your understanding of the agreement/commitment in a conversation for clarity
      • Assuming there is a shared understanding of the agreement, establish the fact that what was agreed to has not been done (true assertions)
      • State the damage that has been done as a result of this commitment not being met (assessments and assertions)
      • Restate the request

Questions to Consider

  • What are some typical requests you or your colleagues make at work?


  • How are do they differ in importance? How would you categorize them?


  • Think of an important request you recently made, or you were aware of that didn’t turn out as hoped for. What happened and why?  Evaluate the request with above criteria.  How could you have improved the request?  The promise?  The cycle of promise?


  • What’s the cost to your work and your relationships of ineffective requests?

© Geoff Davis 2/7/20

Leave a Reply