Setting Expectations

Apr 1, 2007 Michael Wurzer

I read an article in the New York Times the other day about e-mail overload, and the author suggested using the codes NRN or NTN for “no reply needed” and “no thanks needed” to minimize the need for people to reply when unnecessary. At first, this struck me as simply lazy and impolite. After all, how long does it take to delete an e-mail that says, “Thanks!”?

But then I thought about it more and I started to warm to the idea. Saying NRN or NTN is polite. You’re simply letting the recipient know that you don’t expect a reply. Setting expectations is a sign of respect. This idea of setting expectations is exactly what we try to live by at FBS. Here’s the first paragraph from our internal Workflow Guidelines:

The following document is intended to guide you in your day to day decision-making in your work at FBS. The document is intended to cover the basic expectations of every employee at FBS. Those expectations can be summed up as:

Make timely promises and live up to them.

In our business of software development, making a promise most often means setting some sort of due date for when the programming will be done. Unfortunately, setting due dates for programming projects is a bit like trying to predict the weather, there are just too many variables. Our Workflow Guidelines try to address this difficulty as follows:

The reason a due date needs to be established for every issue assigned to you is that, without a due date, the issue will more than likely languish on your “assigned” list without action. That’s just human nature. The “due date” most often will be the date the project will be completed and ready to move to the next stage of the workflow. In the case of complex issues, however, the “due date” may simply be one step in the process towards resolution. For example, in the case of a programming issue, the programmer may need time to think about the proper resolution. In this case, the “due date” would be the date by which you would expect to have that initial analysis complete. When you establish this due date, it is important that you let the reporter know that what they should expect on this date is not completion but another due date. The idea here is to let the reporter know when the “next action” will be taken on the issue. Essentially, you are making a “promise” to the reporter that you will take the action indicated by the date you specify. This is simply common courtesy, letting people know when you intend to do what you say you will – letting them know where they stand.

We also acknowledge the reality that there will be times when due dates are not going to be met:

Undoubtedly there will be issues for which you are assigned or assigned yourself due dates that you will not meet. The key issue here is to be looking ahead to your due dates and pre-informing the reporter that the due date won’t be met and needs to be re-set. This way, the reporter can let the client know before the project is overdue. This “re-setting” of expectations ahead of time is crucial to our success. Everyone should know where they stand at all times. It is only when a due date comes and goes without any information that people (our team members and clients) become disappointed. According to Webster’s, disappointment means to “fail to meet [someone’s] expectation or hope”. The two key words here are “expectation” and “hope.” First, you are in control of people’s “expectation” as long as you keep them informed. Second, if you fail to keep them informed, the human tendency is to infer an expectation or “hope.” More often than not, the “hope” is far more aggressive and less achievable than the “expectation” you would set if you could. In other words, keep people informed or you will disappoint them, because their “hope” is that it will be done immediately and if that’s what you intended you would have had no problem informing them in the first place.

We believe these principles of setting expectations are central to respecting each other and our clients. These principles are common courtesy. At the same time, I’m constantly amazed at how difficult these principles are to live up to every single day. Hiding from failed promises is so tempting. Even more tempting is simply refusing to make a promise in the first place. But that just isn’t right. Our daily lives are bound up in promises and trust in each other to live up to those promises. The deluge of reports regarding crappy customer service are the result of people hiding from these basic responsibilities.

We can, however, help each other do better. Setting expectations is not a one-way street. We can let each other know what we expect and we can be honest about our expectations. Too often, we all negotiate too hard, fearing that if we don’t, we’ll leave something on the table. However, that tug and pull isn’t necessary and it strains relationships. Instead, we can be gracious with each other more often, letting each other know what we expect, no more and no less. So, next time you send off an e-mail, let the other person know what you expect, NRN or NTN.