To a junior engineer, everything takes “a couple of hours”. It’s not that the senior engineer is slower; it’s that they are more familiar with the complexity behind their work and are thus ignoring many fewer factors.

Over and over again I found that there is one consistent ability that differentiates successful teams (and individuals) from those that struggle, and that is the ability to set and manage expectations, especially when it comes to how long things take.

At this point, many of you may roll your eyes. The phrase brings up the idea of a pokey project manager who keeps asking you when you’ll be done; or your manager asking you to sandbag expectations; or a frustration that everyone keeps talking about deadlines and estimates instead of letting teams “be agile”, or just “do their jobs”. I will admit that you are right to roll your eyes in that these happen far too often, but I would argue that they are simply bad practices in an otherwise valuable discipline. So if you don’t mind suspending disbelief, go with me on the journey to discover why expectations matter, and how to manage them, especially when it comes to delivery timeframes.

Expectations: What They Are and Why They Matter

Let’s start from the very beginning and define the concept of “expectations”. I find that often, the problem starts right here: different parties have different ideas of what expectations are and how they are communicated.

Expectations are assumptions that others are making about something they care about.

The operative word is “others”. Even though we talk about “setting expectations,” they are not something we communicate to others; they are something that others create and maintain for themselves after we share information with them.

The “something” in this definition is often probabilistic or ambiguous, and involves circumstances out of someone’s immediate control; it doesn’t really make sense to talk about expectations of events that are certain; and events that are fully within the other person’s control are rarely communicated to us as expectations.

What form might this “something” take? In technology delivery, the most common one is a belief around how long some deliverable will take to be completed, but it also often pertains to the product’s quality or specific features/characteristics of the end product.

By definition, expectations matter – not to you, but to the other party. I see teams fail to empathize with their stakeholders, customers, or other team members when faced with someone’s expectation. So let’s consider the following reasons why someone may care about expectations:

• Your PM keeps asking you when she should expect the work to be done: You are doing work that is a key part of their own work or deliverable. It’s easy to feel under more pressure because you’re closer to the finished product, but put yourself in the PM’s shoes. She can’t control much of the implementation of the product, but she is very much evaluated by its delivery.
• The business stakeholder asks how long the project will take even before you start writing code: Often they have context that you don’t, and if their assumptions are no longer accurate, they may decide on a different course of action that you don’t have visibility into. For example, if a project takes three times longer to develop, they may decide to pivot the work in another direction. Teams often fear this outcome, thinking that it’s equivalent to their stakeholder “quitting” on them. That’s where trust is essential. In teams with high trust, the various constituents come together to come up with creative solutions, knowing that every one of them will do work that maximizes their value added. If the ROI of a project is much lower than expected, an engineering team should insist on doing a different project instead of secretly pushing to do something that doesn’t maximize their contributions.
• We are human beings and we are affected by expectations. If we expect to go to a three-Michelin star restaurant and instead go to an excellent neighborhood joint, we will be disappointed even though in other circumstances, we would be really enjoying ourselves
• In domains where direct observation is difficult (stakeholders rarely go into the codebase), meeting expectations is seen as a proxy for whether the team can get the job done. It’s not an ideal measure, but often better ones are not available (for example, the team or the stakeholder is new to an area)

Expectations vs Predictability

There is a huge difference between expectation-setting and predictability. Something is predictable if you can clearly and accurately describe how it will play out. On the other hand, if one sets expectations properly, one simply minimizes surprises by describing the drivers, risks, and possibilities in front of us. For example, saying

Our work is likely to take between 1 and 4 months. The interval is large because we know relatively little about the key assumptions. We think the following factors contribute to the variance the most, including the following things that can’t be controlled, things that others control, and things that we can control. Here are the things we can do in the next week to get to a tighter interval.

sets clear expectations, but doesn’t force predictability where there is little to be provided.

My advice to most teams, most of the time, is to stop optimizing for predictability and instead, maximize their expectation-setting ability. Statements of predictability are easy to construct and understand (“It will be done next week.”); the expectation-setting process is nuanced, takes more effort to construct, and invites a conversation. And that is precisely why teams should be doing expectation-setting instead of offering predictability.

• When a statement correctly predicts a result, teams can plan well, but in the significantly more common scenario where the result is not predicted accurately, the stakeholders lose all signal from the team.
• Recall that expectations are generated by others, not us. Because of that, expectation-setting requires an understanding of the stakeholder’s needs, constraints and going-in assumptions. This results in a dialog that is richer and that, in turn, can provide the stakeholder with much more signal regardless of the end result

Unfortunately, a healthy expectation-setting environment requires trust and is a harder place to reach equilibrium. Usually, when teams fail to deliver, both sides quickly course-correct by both expecting and providing predictability the next time around. Forced predictability leads to more failures to meet expectations, which often results in a vicious cycle of diminishing trust and increased “gaming” of the process.

But that’s not the only failure mode that one might encounter. Let’s talk about some of the bad practices that teams tend to adopt.

Bad Practice #1: Buffers

When a team is faced with having to provide a timeline and they perceive the costs of missing it being high, they add buffers. In a particularly dysfunctional variation, they may sandbag – keep the buffer to themselves and use it up (on other work they perceive as more interesting, or simply by doing no work). Buffers are a bad practice because they hide actual factors that could lead to timelines expanding. Sandbagging, for obvious reasons, is an even worse practice. These constructs become a convenient shorthand which reduces the quality of information that the team can pass to its stakeholders. They become normalized in that there is little push to address any underlying root causes, and in general for teams to get better. They are also a way for teams to isolate themselves from a potential conflict or friction, which would otherwise be healthy to surface.

Bad Practice #2: Pressure and Other Tactics

I often see stakeholders keep “drilling” teams until they end up providing an estimate that the stakeholders are satisfied with. This is sometimes highly disingenuous and includes lines such as

“Two months is too long. But I’m sure there’s a range. What’s the best case scenario?” “Now what if we push the team harder since our CEO really wants this?” “You say this part will take two weeks, but you built something similar earlier and it only took a week” “Let’s say a week and if it’s a little longer than that, nobody should have an issue with that”

And my absolute favorite,

“I’ll just put a date here, but I don’t expect you to commit to it yet.”

These are all a great example of how the process of setting expectations is turned into a “game” with shortcuts and tricks, and with “winners” and “losers”.

Bad Practice #3: Teams Throwing up their Hands

Unfortunately, if unchecked, this process devolves into teams giving up and providing any estimate, just to make the stakeholder go away. In another variant, with a strong power dynamic, teams come up with something just to make the stakeholder happy. Here, teams stop engaging, thus reducing the process of expectation-setting to pure noise.

★ ★ ★

Now that we know what not to do, should exactly should we do to get better at expectation-setting? …

Set Ground Rules

I encourage teams to agree on the following “ground rules”:

• Teams communicate information, stakeholders reply with the expectations created by this information. These expectations are written down and both parties sign under it. Teams should never feel they have to provide information they don’t agree with
• Engineers, not the stakeholders, provide the estimates. This should really be intuitive, but it’s shocking how often it is violated.
• The stakeholders (and by extension, product managers) are honest about the sources of deadlines. Often, stakeholders invent deadlines in order to put pressure on teams. This may work once or twice but it erodes trust, normalizes meaningless deadlines (since nothing happens if a fake deadline isn’t met), and means that once an actual deadline comes along, teams are less likely to pay attention. I advise stakeholders to specify if a deadline comes from an external source, from an executive, or if it’s an internally-selected one. Teams should also discuss what happens if a deadline isn’t met.

Note that it’s sometimes a good idea to have internally-imposed deadlines. It helps teams stay focused and avoids rabbit holes. Sometimes, if multiple teams need to coordinate their activities (for example, Marketing needs to set up a campaign timed with a release of an experiment), deadlines are an easy way to do that. Again, being honest is key here

Look at trade-offs

Prefer discussing trade-offs; don’t collapse the decision tree for your stakeholder. It’s not helpful if a team says “this can’t be done”. It’s much more helpful to offer the trade-offs that are involved in various choices, within reasonable bounds. For example, work can be scope-boxed (“we have to deliver X functionality no matter what”) or time-boxed (“we have to deliver by date X no matter what”), or some efficient frontier of the two (but not both optimized at once).

A common trope is to draw a triangle for the stakeholder with “time”, “scope” and “quality” in each vertex and tell them that they can have any 2, but only 2, of these. I don’t like it at all. It trivializes the art (and science) of trade-offs, puts the three qualities on equal footing, and implies binary outcomes. In reality, projects are all somewhat time-bound and somewhat scope-bound, and more tightly but not absolutely quality-bound.

In this model, quality can actually be compromised on, but as part of expectation-setting teams need to discuss what they do with the resulting tech debt or higher chance of defects and budget the work for it. Will there be a fast-follow refactoring? Will the team halve its velocity in the month following release to address defects?

Even if you look at time, there are multiple dimensions of time to consider. Do we care about delivering the first phase of the work as quickly as possible? Or do we want to maximize our total velocity beyond the launch as well? Or maybe we care about maximizing our ability to course correct instead? These are in conflict. Very nimble teams aren’t as efficient as teams that “set sail” in one direction, but the latter take time to change course. A new product, with uncertain requirements, is better off tackled by a team that’s optimized for agility.

What if there is an actual deadline to hit? Doesn’t the above advice fall apart? Not at all. First, as we discussed, make triple sure that it’s a real deadline. In many cases, you will learn that it’s not. Go to the stakeholders and have them explain carefully, and with all the nuance, why this deadline exists, and what happens if it’s not met. The entire team needs to listen to this. Then, don’t let the existence of the deadline make you change your answer. If you believe the work will take you beyond the deadline, say so and spend the rest of the time creatively brainstorming a solution.

Accurate communication is key

I mentioned this briefly, but providing rich, nuanced communication helps set more robust, higher-signal expectations. This means that:

• First, convince yourself that you care. If you think setting expectations is a waste of time, you won’t be genuine and it will show
• “I don’t know” is a valid answer, as is “it depends”
• The “why’s” (the factors, conditions) are very important as they provide the stakeholders with a lot more information than anything else
• Confidence levels should be attached to unclear estimates
• Try to communicate universally. While normally, you should customize your message to the audience, any information (such as timelines) which leads to expectation-setting tends to be packaged up and shared outside of your control
• Don’t communicate on the defensive. You shouldn’t apologize for estimates. Remember, the process is one of discovery, getting as close as possible to the truth

Build a muscle

Set expectations often! Just like many other skills, it’s a muscle which can be trained. Part of the growth comes from doing regular retrospectives of expectations set in the past. Troubleshoot what you conveyed, just like you would code. The unsexy truth is that this muscle will make you a lot more effective as an engineer than if you picked up, say, another framework.

★ ★ ★

The topic of estimates, deadlines, and expectations is vast. This post just skims the surface. I encourage you to approach the exercise with energy and creativity that it deserves. Keep the time intervals wide, narrowing them over time. Focus on the factors, such as risks and early ambiguity. Discuss trade-offs, rather than end solutions with your Product partner. Focus on building trust, which will reduce the buffers (on both sides). Be connected to the hip with the PM, who will appreciate a rapid way to cut through a problem. Most importantly, overcommunicate. As a result, you will find yourself providing more and more useful estimates, building trust, and ensuring better overall outcomes.