What’s the secret of success?

Welcome to my first article for Software Project Rescue! I’m really swinging for the fences with this one, but it’s the most important thing I’ve learned. To be clear, this isn’t the only secret to success, just the biggest.

The secret to success is managing expectations.

Danger: you may interpret this like my grandfather (a professional investor) interpreted statements from economists: “They tell us something we already know, and it’s completely irrelevant!”

I know it seems like a platitude. However, there is a real depth and richness to this truth. To borrow a phrase from sports, managing expectations isn’t everything – it’s the only thing.

I learned this from consulting. Maybe you’re not a consultant, but you know when you’ve been disappointed by one. I’ll confess, I learned this from a client very early in my career. When a client tells you that you need to manage expectations, they’re softly saying you screwed up. Lucky for me, it wasn’t anything major, and this client learned it from his client, so he was understanding.

Most employees have a performance review centered on “Meets expectations.” So everyone has an opportunity to screw up. I think author Anne Lamott (Bird by Bird) said it powerfully:

“Expectations are resentments waiting to happen.”

People can resent you for their expectations. That’s scary but motivating. And there is something we can do about it.

The folks who think this is obvious and unhelpful hear “setting expectations.” I doubt they are even doing that well, but managing expectations means being proactive. Reexamining and adjusting them.

I was going to write that programmers are bad at this, but really all humans are. Because managing expectations is often lowering them. Nobody wants to be the bearer of bad news. Maybe it will get better on its own!

Except when it doesn’t, you’ll be resented for withholding information. This can bite you in surprising ways. Senior managers at a former employer once got in trouble when we came in well under budget for the customer. They were very unhappy. “You saved how much? When did you find out about this? We could have spent the excess on hardware upgrades – now it’s too late!” A legitimate complaint.

But as the client, you can help more than you think. Communicate your expectations which are, I’m afraid, assumptions on your part. Many times I’ve heard managers complain that something should have been “obvious” to the vendor or developer. Sometimes I agree, but just as often it was A) only obvious to domain experts or B) an incorrect assumption based on faulty knowledge of software engineering.

In other cases, I’ve seen engineering set expectations, but a very harried client, over time, regresses to their original (incorrect) assumptions.

“This can’t be that difficult!”
“Don’t you remember, we explained why this is hard?”

No, they’re busy and don’t remember. It’s a very human trait that can cause strain in the relationship and unhappiness on both sides.

For a partnership to work, engineering needs to clearly set expectations for stakeholders, and stakeholders need to communicate their assumptions. And this communication must be continually reiterated, even when nothing changes.

I’m writing these articles to give you reasonable expectations about software development. You’ll have way fewer disappointments and make smarter decisions. If you have an example where your expectations weren’t met, tell me about it below.