Paul Glen: Check your work, or else
Computerworld - I often wish I had a time machine so I could go back and prevent technical people from taking their first step toward client relationship hell -- where all interactions are tainted by the sense of mutual discomfort and mistrust that often emerges when geeks mix with business people.
It frequently starts with one small, wholly unnecessary misstep.
One of the most common complaints I hear from business people about us geeks is that we deliver things that don't work. You might be thinking that I mean "don't work" as in "don't meet some unarticulated requirement that users become conscious of after using what they asked for." Unfortunately, I'm talking about basic stuff like reports without data, buttons that don't do anything or unintelligible error messages.
For us geeks, these are trivial events, since they are usually easy to fix. It's just a small oversight: a misplaced comma or a typo in a variable name. We don't even feel embarrassed, since small adjustments are part of implementing technology.
But you probably have no idea how badly relationships can be damaged when these things happen, because end users have an entirely different experience of that same small glitch.
Imagine it from their point of view: You just told them that their long-awaited technology is ready for them to try. Excited and relieved, they begin to fantasize about all the productivity they're about to unleash. Then -- Bam! -- instant failure.
What seems like a minor setback to you is a major, emotionally charged disappointment for them. Think about the sequence of thoughts and feelings they experience:
1. Self-doubt. "Oh crap. I broke it. Maybe I'm too stupid to use this."
2. Anger. "They told me this was done! What kind of bozo would deliver this?"
3. Resentment. "They're just wasting my time because they're too lazy to test this and they expect me to do their job."
From then on, every encounter with us is tinged with the memory of that bad experience. And every human mistake we make is further evidence of our incompetence. It truly is the road to hell.
Having been on both sides of this situation, I can tell you that this usually happens because of our good intentions. Most IT people are earnestly eager to please their business partners. We respond to their constant sense of urgency with a zeal to deliver quickly, which often leads to inadequate testing and sloppy, silly mistakes.
We can easily avoid such situations by taking these steps:
1. Set expectations. If they want to see it before it's ready, tell them that they're likely to find bugs and tell them what to do when those bugs appear.
2. QA your work. Have someone else check for you. A quick look with fresh eyes goes a long way.
3. Be available. Don't just toss something over the wall. Wait by the user's desk or connect via video chat while he does his first inspection. If something goes wrong, he won't feel so alone.
In the end, we must transform our eagerness to please into eagerness to help. These might sound the same, but they're quite different. Trying to please often leads to unrealistic promises, half-thought-out solutions and poor quality. Helping often means delivering difficult truths, managing expectations, sharing challenges and limiting the scope of what we take on. In the short run, being helpful often means displeasing our business partners, but that's what they want and need from us.
Paul Glen, CEO of Leading Geeks, is devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. His newest book is 8 Steps to Restoring Client Trust: A Professional's Guide to Managing Client Conflict. You can contact him at email@example.com.
More by Paul Glen
- Paul Glen: The benefits of an unstructured career
- Paul Glen: Motivating the mercenaries
- Paul Glen: The gifts and costs of working with 'them'
- Paul Glen: How can you wield influence if you don't know what it is?
- Paul Glen: For geeks, avoiding blame is a silent career killer
- Paul Glen: When you've had it with a stakeholder
- Paul Glen: Nobody wants you to be a technology vending machine
- Paul Glen: Geeks love problems, so give them some
- Paul Glen: The secret to keeping processes vital
- Paul Glen: How to deal with a toxic team
Read more about Management in Computerworld's Management Topic Center.
- Why Projects Fail CIOs are expected to deliver more projects that transform business, and do so on time, on budget and with limited resources.
- Why Today's Software Development Projects Fail By establishing more accountability for quality with developers, organizations are able to improve their software quality outcomes in more effective ways than traditional...
- Review: Box beats Dropbox - and all the rest - for business Box trumps Dropbox, Engyte, Citrix ShareFile, EMC Syncplicity, and OwnCloud with rich mix of file sync, file sharing, user management, deep reporting and...
- AIIM SharePoint Industry Watch AIIM surveyed its 65,000 community members to look at how the enterprise is reacting to social aspects, why organizations are exploring social, who...
- Leveraging the Cloud for Dev/Test This video discusses some of the key considerations that IT organizations should take into account when moving test and development projects to the...
- Cloud Knowledge Vault Learn how your organization can benefit from the scalability, flexibility, and performance that the cloud offers through the short videos and other resources... All Project Management White Papers | Webcasts