We techies have a hard time building and maintaining credibility with our stakeholders. High expectations are hard to manage. Bugs happen. And we get blamed unfairly for all sorts of things that are out of our control.
But we also have a habit of making things worse, undermining our credibility inadvertently and unnecessarily. Probably the most common of these unforced errors comes in the form of two simple words.
Stakeholders have a variety of emotional responses to hearing us utter these words, none of them productive.
Some respond with excitement and gratitude. “Thank goodness! I’m saved!” If you’re dealing with issues that have no explicit definitions of “fixed,” such as performance problems, their imaginations run wild. They conjure fantasies of systems that work as they wish they would, faster, easier and more reliably than they really do. But these raised expectations rarely survive contact with reality, and when stakeholders’ dreams are crushed, we lose credibility. It wasn’t really “fixed” after all. They feel foolish for having had optimism and blame us for making them feel bad. Even if the problem is clear cut, like an error message, sometimes “fixed” isn’t really “fixed.” They still get the error message, or a new one. And they feel disappointed.
Others roll their eyes in skeptical disdain. “Yeah, I’ve heard that a million times before.” Having been let down too many times, they protect themselves from the pain of disappointment by crushing any hints of optimism. And they judge us as responsible for their negative reactions.
It doesn’t help that we usually tell them, “It’s fixed!” with infectious enthusiasm and pride. We’re problem-solvers by nature and love the feeling of having solved a puzzle. We feel that we’re helping our stakeholders. We feel competent and powerful. And our excitement intensifies their reactions, raising their expectations or triggering suspicion and cynicism.
To avoid triggering these negative responses, you just have to remember one simple principle:
It’s their job to declare something fixed, not yours.
If they declared that something was broken, then it’s their job to declare that it is no longer so. Your job is to invite them to decide. You may have to influence the criteria they use to decide, helping set their expectations about what is possible, and how “fixed” something can be. But you don’t get to make that call. They do.
Instead of declaring something fixed, do three things:
- Tell them what you did in language that they can understand. “We found two places where we tried to speed up database queries.” “We changed one of the system configuration variables.”
- Describe your observations. “It seems much faster now.” “We don’t get the error in the test environment.”
- Ask them to try it out. “Can you test it out and see if it looks better to you?”
By asking them to decide, you avoid all the emotional damage wrought by those two seemingly innocuous words. It’s hard enough to build credibility with stakeholders. You don’t need to make it any harder.
Paul Glen is the co-author of The Geek Leader's Handbook and a principal of Leading Geeks, an education and consulting firm devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. You can contact him at firstname.lastname@example.org.