GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.
Underpromise, overdeliver: Set reasonable expectations and knock them out of the park.
The saying has become something of a mantra when it comes to delighting customers — these promises arise out of split-second decisions when communicating directly with customers. However, this strategy has transferred to our internal work, to when we are collaborating with a partner, a coworker, or our boss.
And that’s a problem.
Setting reasonable expectations is a great skill to develop. Not promising things you can’t deliver is smart. That’s being realistic and modest. But when we go on treating our colleagues with this UPOD mindset, we are ignoring a perilous bug in our organization’s trust and psychological safety.
It speaks to a type of organizational dysfunction
where it is better to appear to be kicking ass than to have reasonable and realistic discussions about expectations. About what we can and can’t do, and about what is or isn’t in our control.
I often hear “underpromise, overdeliver” as a way of impressing management, where there’s this underlying fear that internal stakeholders will take advantage of the team if they promise too much. The team feels that it’s better to be predictable than to strive for more.
And on the other hand, there are the stakeholders who believe that the team will “get comfortable” if they set realistic (but harder to reach) goals and aren’t required to exceed those goals.
It won’t take long for an employee to figure out whether they ought to game their goals for self-preservation, or if it truly is safe to set challenging targets.
This pressure forces teams to be conservative, to “game” the goals, to set targets they know they can knock out of the park. Anytime you see this symptom, ask yourself, “What does this tell me about the organization surrounding that team? And what does this tell me about the risks of failure?”
Setting reasonable expectations and limiting work in progress is powerful. But an organization striving for predictability over outcomes — for optics and success theater over impact — is walking a dangerous tightrope.
Flipping UPOD on its head
What would an organization look like if teams promised to do their best, and management pledged to support their teams? These promises cut to the core of what the organization stands for.
Would you want a manager to “underpromise” their support for a team?
Now, a manager can “promise” she’ll do her best to remove an impediment, which is different from claiming she will do things that she perhaps can’t do. The promise to do her best (while being vulnerable and transparent) is powerful.
Ideally, your organization will strive to create a safe place where…
- Team members can set meaningful goals — stretch goals even — without fear of “losing” or “failing” in the eyes of their coworkers. They shouldn’t feel it is necessary to game goals to get ahead in a work setting.
- Running into roadblocks is okay. In a pull system, new work starts when other work is finished. There aren’t “promises” in the sense that people agree to pass a batch of work through the system in a set time-box. The promise is that the team will do its best, and make their work transparent.
I’ll often see a less experienced developer get excited about different ideas and make too many commitments. Sure, this can set the wrong expectations. And yes, they tend to learn over time that too many commitments (or promises) will bite them. But isn’t it cool that they’re excited? I’ll take an enthusiastic person who has to learn to limit in work progress any day over someone who is gaming the system because they’re afraid of taking risks in the current environment.
“Realistic” is acknowledging that there is variability in the system. “Reality” isn’t creating a false sense of predictability by padding goals to give the impression that the team is regularly exceeding expectations.
Ultimately, teams tend to UPOD when they’re incentivized to “do what they say they are going to do.” Is that really what you want to incentivize? Maybe predictability is core to your organization’s needs. But if not, would you rather UPOD and go slower, or would you rather take advantage of momentum when it comes (and support teams through the lows)?
What would “Keep Promises and Deliver” look like?
It’s about making promises you can keep. It’s about saying “we’ll do our best on this” instead of “we’ll do this small thing and impress you.” Imagine the average meeting. Consider all of the “promises” that tend to spin out of the process. “I’ll follow up,” “I’ll look into that,” “Oh, that’s a good idea.” Our coworkers expect something. We’re making commitments to each other, and those are commitments we should keep.
So, make smaller promises. Down-promise, perhaps, which is different from saying you should under-promise. And promise to learn based on those promises.
The promise is to be transparent with our work, to do our best, to support our teams, and to “work small.” Small batches are a built in way to under-promise provided we stick to them. Promising you’ll get an increment out to customers in 1w is a promise to “do your best” and “work small.”
When we adopt the “underpromise, overdeliver” mindset, we tend to lose touch with the meaning of a promise. We tend to not take commitments seriously.
Promise to focus, to take pride in your work, and to learn. When we UPOD, we tend to lose touch with the meaning of a promise. We tend to not take commitments seriously. We tend to make too many promises, and then things start to slide.
Promising to do the right thing must be modeled from the top. If your senior leaders don’t keep their promises to support, lead, and do the right thing, then this will fall flat. None of this will have any resonance.
“Keep Promises and Deliver” is about building respect, and trusting that our colleagues are doing their best work by agreeing to focus, and to help each other focus. We hold each other accountable to learning.
Think about the words “promise” and “deliver” in your organization’s context. Are these things purely about “to-dos” and deliverables? Or can you take things deeper to address trust, safety, support, and delivering outcomes to customers?