IT developers and PMs: have you ever heard a colleague say something to a stakeholder that just made you cringe, knowing how the stakeholder is likely hearing it and reacting negatively? I have.
Heck, I’ve even been that developer, especially early in my career. But fortunately, enough of getting smacked upside the head (usually metaphorically, thank goodness) by one or more irate constituents tended to clear my thinking on these matters, particularly over time. But yet, I continue to overhear such cringeworthy remarks on a regular basis in IT circles, and I wince in sympathy with the stakeholders when I do. So let’s do some smacking. Metaphorically.
First off, I should note that communication skills always need work. Always, and for all of us. We all can improve. And of course, I know that none of the examples I provide here is usually said with any ill will (and I do recognize that many of them often have certain grains of truth behind them), but that still doesn’t make them defensible. It’s pretty important that none of them ever be heard by a stakeholder.
As I go through some concrete examples, try to hear each of them through the stakeholder’s ears. Anticipate what the stakeholder might be thinking, feeling, and perhaps assuming from your words, from the situation, and even influenced by what they’ve experienced before from you or your brethren. And if you hear one of these gems dropping from the lips of a colleague, pay it forward: say something.
Here are among the worst things a developer/PM can say to a stakeholder. And yes, these are real-life examples; I’ve heard every single one of them, usually many times.
Let’s look at these statements grouped into some clusters (admittedly somewhat arbitrary, and admittedly somewhat overlapping), with a few annotations on why they’re undesirable:
Process and professionalism:
- It’ll be done when it’s done. Stop asking me when.
- That’ll go out in the first release after launch.
- We don’t even look at a reported bug unless it’s marked urgent.
- I just changed one little thing; there won’t be any impact. I don’t even need to test it.
All of the above statements serve to undermine a stakeholder’s confidence in your general dev process and (frankly) your professionalism. Because here’s what people justifiably tend to expect: professionals should be able to give some indication, at least more often than not, of likely time frames and confidence level. Professionals (in a project that has any reasonable scale to it) never freelance their way and make arbitrary process-free promises like “that’ll be in the first release”, just to shut the stakeholder up. Professionals don’t telegraph to stakeholders that users should arbitrarily mark bugs as urgent to get any attention. And professionals don’t shoulder-shrug at the possibility of ripple effects from seemingly minor changes.
Boasting and bluster:
- Trust me.
Don’t ever ask stakeholders to accept anything on faith, based on your solemn declaration that it is so. Unless you’re truly infallible (and, news flash, you’re not), it’s insulting. Show them, don’t tell them. And figure out actual, meaningful ways to show them, rather than appealing to their innate optimism or relying on your personal magnetic charm or relationship with them. Demonstrable results are what count, not your ability to “sell” them your personal representation of reality.
- We focus on producing code, not documentation.
- My code is self-documenting.
- Just read my code; it shows you exactly how the functionality works.
- “You must not be very technical, I guess.” (This is often said in defense, when the stakeholder complains of not understanding how the software is intended to work)
To the stakeholder, statements like the above translate to essentially the following: “we don’t really care all that much whether or not you can USE the software. We don’t care about explaining it. And, we’re pointing you to the code as an answer to your pesky question, because we basically aren’t interested in doing the hard work of translating the answer into clear business English. Explaining what’s going on, apart from the code itself, just isn’t fun, plus (did we already say this?) it’s hard work, so we, well, we just don’t care.”
You may not think you’re saying that, but that’s what stakeholders often hear when you say one of the above remarks. Don’t ever ask stakeholders to be at anywhere close to your level of technical knowledge in order for them to get an answer to a basic business question. Don’t (ever) ask them to read your code. And certainly never tell them that any problem they’re experiencing with running your software has to do with their supposedly deficient level of technical ability.
General denial and dismissal of problems/bugs
- The system is actually up; it’s just that the users can’t reach it.
- It works just fine on my machine. <shrug>
- “That’s not a bug. The dollar amount is correct in the system; it just shows up wrong on the screen.”
None of the above, when I’ve overheard them in the wild, has been stated with even the slightest touch of irony or self-awareness. Let’s call them what they are: excuses, dodging of accountability, and complete (and staggering) inability to see the situation from the user’s point of view.
- That’s not a bug, that’s a feature
- That’s not a bug, that’s a feature request.
- “Bugs aren’t a quality measure” — an idealistic (but sadly and inexcusably tone-deaf) way of stating that not all bugs are weighted the same in impact and import, and that they are imperfectly and inconsistently gathered, so simply counting them doesn’t necessarily work well as a comparative measure. But think here beyond the idealism: what do you suppose stakeholders hear when they hear you say that “bugs aren’t a quality measure”? Do you really imagine that they’ll be inclined to tune into your lengthy theoretical explanation (i.e., what you really meant to say) after that?
If you think about it, you’ll note that there’s often a common theme to many of these: don’t hold me to stuff. Don’t blame me. Problems aren’t my fault. We know what we’re doing, and you don’t. We’re the experts, and you’re not. So, stop pestering me. Consider the stakeholder’s likely reaction to these kinds of (perceived) pronouncements, and don’t be that guy/gal telling them such things. Trust me. <grin>
OK, developers, I can hear you thinking: “but but but, what about them?” All right, I grant you: stakeholders too have been known to say some facepalm-eliciting things to developers and PMs. Let’s leave those for a follow-up post. Feel free to offer your own examples of such stakeholder remarks in the comments, and I’ll see what I can incorporate.
Lagniappe:
- CTO/CIO Perspectives, “How not to get what you want from IT”.
- CTO/CIO Perspectives, “Astounding IT sayings: the inaugural post”.
- CTO/CIO Perspectives, “More astounding IT utterances”.
Speak Your Mind