Setting and Resetting Expectations

Person A: Hey. Could you [do a task] for me?
Person B: Sure!
Person A: Thanks!

The hazards hidden in those three short lines are significant.

Engineers, designers, product managers, marketers, administrators, and company leaders all rely on one another — they have expectations of one another. Giving, receiving, and negotiating those expectations are key skills for an organization to hone in order to work together well.

These are often regarded as “management skills.” But if you strive for autonomy and collaboration, as we do at Manifold, everyone needs to work on them. The number of opportunities to “manage expectations” can explode with the possible combinatorial intersections of the people in your company.

In the example dialog above, when does person A expect the task to be done? What does the task need to accomplish? Is there anything to avoid? Should person B drop what they are doing and switch over to the new task? If the task takes longer than person A expects, will person A know? How?

Sometimes the answers to these and related questions are implied by context, and everything moves along fine. Other times they are controlled by a rigorous process. A lot of times, though, expectations are set in simple conversations. If the participants are not skilled in handling them, the expectations are landmines of surprising frustration and missed opportunities for the future.

CARDS for your CREDO

At Manifold, we’ve lately encountered several examples of these challenges, in and between our teams. How should we handle them?

My recommendations for best practices in setting and resetting expectations can be summarized with a couple of mnemonic acronyms: make CARDS for your CREDO.

C: Collaborate.

Talk and be open. When someone tells you that they need something done, or when you need to set or reset an expectation, this is not the delivery of a foregone conclusion, but a dialog in which both participants want success.

Use the advice process and local owners (e.g. Product engineer, Product manager, etc.) for guidance.

If you are resetting expectations, actively revisit relevant past decisions to see if they still make sense.

A: Agree.

Agree on your “CREDO”: Constraints, Rationale, Expectations, Dates, and Ownership.

“Constraints” are what not to do. “Rationale,” “Expectations,” “Dates,” and “Ownership” equate to why, what, when, and who, respectively. “How” is usually a question for the person working on the task.

As I’ll mention again below, at Manifold, clarifying dates and ownership has caused more friction for us lately than the others.

R: Repeat

Ask the message recipient to repeat back what they heard and confirm agreement. This step might feel the most awkward, but it can be very helpful. Examples are below.

D: Document

Share a succinct collaborative description of the agreement in a written system of record.

S: Subscribe

Establish a clear, fast, lightweight, reliable way to reach out to one another going forward. This might be your system of record, Slack pings, or whatever both sides agree to make work.

As soon as you see a probable change to the agreement, reach out immediately to the other party over the subscription channel and restart this process with the new information.

I chose the word “subscribe” to clarify that the communication is a two-way street. Both sides need to reach out, and both sides need to listen. That’s sometimes not as obvious as you might think.

Examples

Make CARDS for your CREDO: two interlocking mnemonic acronyms for fun and profit! They may be a bit cheesy, but I hope they help you remember these ideas better.

I’ll now walk through some example conversations to try and show it more in practice. All of my examples are of people talking to each other, because that’s the simplest story. If a team has established a system for asynchronous requests and it works for the askers, that’s a great approach! Everything I’ve said still is pertinent.

I focus the examples below on the date aspect of CREDO (Constraints, Rationale, Expectations, Dates, Ownership) because these are the problems I’ve seen most lately at Manifold. I see us doing consistently well with Constraints, Rationale, and Expectations, in particular.

We’ll begin with a problematic conversation, similar to the one at the start of the post.

Conversation 1: Collaboration problem

Person C: Hey. Could you [do task] for me right away?
Person B: Sure!
Person C: Thanks!

Person C proposed a time — now! Person B immediately agreed — very accommodating!

But…is that Collaborating? Person B was working on something before Person C came along. Should she just drop it? If Person C has organizational power relative to Person B, or if they share a strong relationship, or if Person B has a wonderfully strong sense of integration, collaboration and shared urgency, that might well happen.

Putting a task aside loses context; multitasking adds stress; and interrupting tasks is mathematically provable as an inefficient pattern that eventually leads to nothing ever actually getting done. Moreover, treating an interruption as a problem pattern to be solved reveals operational problems in the organization that we can solve, improving our velocity. Instead of interruptions, we almost always want everyone working on short tasks, delivered quickly, one at a time, with an agile ability to start something else soon, after having delivered value.

The person on the receiving end, Person B, didn’t really do anything about that. Person C might not actually want Person B’s current task to stop. When you “Collaborate,” that doesn’t mean we capitulate. Both participants work together, and in the larger context of other agreements in the organization.

Now let’s look at a few successful conversations.

Conversation 2: Successful Collaboration and Agreement

Person A: Hey. Could you [do task] for me?
Person D: I’d love to. When do you need it?
Person A: I’d like it as soon as possible.
Person D: This task seems like it’s small enough for me to fit into the week without affecting anything else I’ve agreed to with others. If I get it done by the end of the week, is that fine?
Person A: I don’t need you to drop everything, but could you get to it sooner?
Person D: If I wrap up my current task, that should let me get to it tomorrow morning, and I think I’d be done by about mid-day. How’s that?
Person A: Perfect, thanks!

These people Collaborated. They Agreed on the CREDO — at least the date aspect, which is what I’m focused on in these examples.

That’s the first two letters of “CARDS.” We’ll add in “Repeat” for the next example.

Conversation 3: Successful Collaboration, Agreement, and Repetition

Person C: Hey. Could you [do task] for me right away?
Person D: I’d love to. I’m not sure how big that task is, and it would be better for me to get some advice so I can help my [squad/team] slot it into our work. I’m [the Product Engineer/other role], so I can help you with that. Could I tentatively schedule the planning for next week?
Person C: Why can’t we just get it done now? You just need to [perform task], right?
Person D: That might be right, but I’m not sure. Can I investigate it tomorrow morning after I finish my current task, and get back to you to talk about it by end of day tomorrow? Or is this an emergency?
Person C: No, investigate tomorrow and let me know what it looks like by end of day. Thank you.
Person D: OK, cool. Could you give me a quick idea of the pressure behind this task, so I can think about it when I make a prioritization proposal? I’ll get your advice before I commit.
Person C: I need it because [of a pressing opportunity or challenge].
Person D: Got it, thank you.

Hey, that was a bit tricky! Nicely done. They Collaborated and Agreed on the CREDO — this time looking at both the date and the rationale. Also, it was simple and fast, but person C Repeated the plan: “investigate tomorrow and let me know what it looks like by end of day.” (We’ll see another, more interesting example of “Repeat” in conversation 4.)

A few notes.

• First, if person D wasn’t someone with ownership of the larger local commitments (like a Product Engineer), she would have needed to say something about bringing an owner into the conversation. If the owner isn’t available, person D would have had to negotiate the level of urgency, and gotten some advice on what to do about it. Don’t be blocked, and don’t be a silo.
• Second, if Person C had said that this was an emergency, once the emergency was resolved, that would have triggered a request from me to talk about why we had an emergency. As I said above, interruptions typically are symptoms of organizational inefficiencies. If we can talk openly about what we can do to reduce them — after the emergency is over and calmness has returned! — we can often get our jobs done faster and with less friction and stress.
• Lastly, person C might have come across as a bit pushy. That might be true: person C could have been more skilled in his communication (watch out for the word “just”!), and more initially empathetic towards person D’s in-progress work. These communication skills can be addressed, as a separate topic. The behaviors also often happen for good reasons, though: there’s probably an important opportunity or risk that is driving person C. Person D gave the benefit of the doubt, and person C responded by giving some space.

Conversation 3 continued: Document and Subscribe

There’s still some danger lurking. Person C and D set and confirmed some clear expectations. But life doesn’t always go according to plan. Where are A and C going to track the agreement? What will D use to represent the expectation?

Person D: I’ve made an issue in [my/our team’s system of record], with the timeline we agreed on. Here’s a link: [link]. You can ping me on the issue or in Slack. If I need to adjust your expectations, I’ll sketch it in the issue, and also ping you in Slack to set up a time to talk about it in more detail. Sound good?
Person C: Sounds good. Thanks.
Person D: Thank you!

The first thing that Person D did here was record the agreement. If we’re not tracking the expectation, there’s a high likelihood that it will get lost, in my experience. Person C’s work is relying on his request to person D. If we are not able to meet those needs, this might be a big deal. It also would quite possibly represent an organizational problem that we need to discuss.

In some cases, particularly if the task needs some additional details to be specified by the asker, the receiver might request that the asker create the issue. If your system of record is not comfortable for the asker to work in, the receiver could also create a skeleton issue and request that the asker fill it out.

In engineering, our system of record is Github issues, connected with Zenhub. Other teams at Manifold use Trello, Asana, Pipedrive, and spreadsheets. It could be as simple as notes on a shared document, which is what I sometimes use for private 1:1 commitments. We ideally advertise those systems to one another, but if we at least give links at the moment of request, that can work too.

Person D also established a subscription between the two of them for updates: Slack and Github, plus a scheduled conversation if the expectations change. Our last conversation will explore just that circumstance: expectations have changed.

Successful Conversation 4: Triggering the Subscription and Restarting CARDS

Suppose Person D investigates Person C’s task and discovers that it will take multiple weeks. Starting it soon will therefore cause us to interrupt large scale existing work and trash the value from it. We therefore decide that we intend to push person C’s task out to a couple of weeks away. It’s time to trigger that subscription that Person D set up, and redo the CARDS steps.

Let’s try a hypothetical version of this conversation that tries to introduce some real-world challenges. In particular, notice that Person D

• collaborates, by proposing a way forward but asking for person D to help shape the next steps;
• agrees on CREDO, in particular by talking about the dates;
• asks Person C to repeat the agreement;
• documents the problem before the conversation, and commits to documenting the agreement after the conversation; and
• refreshes the subscription that they had agreed on before.

Person D: Hey. We looked into the task you asked me about. As you might have seen in the issue I shared with you, it’s going to be bigger than you hoped because [of very succinct reasons], and we’re in the middle of delivering another project. My proposal is to finish [our in-progress project], which will take us about three more weeks. Then we’ll be able to start this one, moving out our [previously planned work] farther. Our fast, cheap, and maybe wrong estimate is that we can get something to you in about four weeks after we start. Will that timeline work for what you need, or do you have any other suggestion or concern?
Person C: That’s really inconvenient. [I have a pressing need.] I’m frustrated that we can’t do it sooner.
Person D: We can if we stop work on our current project. That’s going to waste time and work, and make it more likely we just throw away the last few weeks of work. The current project had high priority from [a stakeholder] and support from the advice I got from [other stakeholders], so my proposal is to keep it moving and then put your task in front of the next bigger project we had scheduled. That will affect [other priority from other stakeholder] but I understand why you need this soon from our last discussion, and [the other stakeholder] told me she could adjust. Would you like to talk about trying to find a very small deliverable that we can fit in sooner, while you are waiting?
Person C: No, thanks, I think I can [keep the pressure off]. OK, I’m not sure I agree about the prioritization of what’s going on, but I trust you and the people you talked with.
Person D: OK. I want to make sure I’ve communicated the plan to you. Could you let me know what you heard?
Person C: You’re finishing your current project in three weeks, and then you’ll be done with [my task] after another four weeks.
Person D: That’s our current estimate, yes. I’ll update the issue now with it. I’ll let you know as soon as I see any change to that, and we can revisit this discussion.
Person C: OK, thank you.
Person D: Thanks!

Great job, Person D.

I suggest you particularly look at how she asks Person C to repeat and confirm her plan, and how she corrected it afterwards. This simple approach has been really valuable to me over the years.

Wrap Up

I hope this is clear and helpful. Following these simple guidelines is easy to forget, but I believe that using them will really help you improve the way you work together. Thanks for reading!