I wrote last time about some cringeworthy comments overheard from developers talking to stakeholders, and I promised a follow-up that did some exposure of the “other side.” So here goes: rather than focus specifically on cringeworthy comments from stakeholders (I’ve covered some of these here and here), let’s talk a bit more generally, about ways that I’ve see stakeholders contributing to overall dysfunctionality in the workplace.

The anecdotes below are, of course, taken from real life. I should hasten to add that I have a self-imposed moratorium on writing about my clients. I’ll wait a minimum of two years, usually more, before I’ll mention a real-life incident or even general issue in a blog post here. And when I do, I change key details to avoid finger-pointing, while still using the overall incident to make the key point.

At one large client a few years back, I came to see some clear commonalities (dysfunctionality) in the culture of how people worked together. It started by observing various day-to-day behaviors that were enormously impacting overall productivity and results. These dysfunctional behaviors came chiefly from business stakeholders, but I also observed IT people feed right into them and perpetuate them by playing along. I’m talking about behaviors like these, taken verbatim from my notes at the time:

Dysfunctionalities observed

• No one is willing (or at least inclined) to write anything down. Then, anger inevitably emerges at having to re-explain it. And, since explaining things just via a conversation actually makes it easier to hand-wave about complexities, the complexities tend to go underanalyzed and then unanswered.
• Preference is for hallway conversations over solid documentation. The view of what constitutes “work”, for many people who work here, seems to be (at best) just coming to meetings and declaring one’s opinion.
• Basic business etiquette doesn’t exist. No one shows up reliably at meetings, or on time. Meetings don’t get accepted on the calendar, so you don’t know for sure who’s really going to be there. And when the meeting takes place, it’s common for people to come late and then even insist on a reset of what’s been discussed so far.
• Emails go unanswered, even if beggingly marked PLEASE RESPOND etc. in the subject line.  

If an email isn’t answered within 15 minutes, in fact, it’s rare for it to be answered at all. In desperation, I’ve taken at times to marching a printout of email down the hall, so I can sit in a stakeholder’s office to get specific answers to critical questions. Of course, when I do that, it’s all just a verbal exchange; it doesn’t become a real commitment by that person to the answer that is provided at that specific time, and it of course (perhaps intentionally) avoids the benefit of having those answers discussed (and sometimes challenged) in a wider forum of major stakeholders.

• People work from their own memory and strong opinions, not documents. Even when documents are actually available.

For example, I saw a stakeholder ask another stakeholder what his main needs for the next application development phase would be. Rather than refer to the existing document that had been carefully gathered, documented, organized, and group-reviewed, he simply expounded on his main needs off the cuff, just going on memory, and in the process omitting some major aspects and getting others slightly wrong. He was winging it. Did he still want (in the system under construction) the features and capabilities he was leaving out in his impromptu list? Of course, and he was the first person who would feel let down if those needs went unfilled.

One core reason for this behavior: people simply don’t review documents, no matter how pressed or nagged. Careful, heads-down review of deliverables rarely seems to be included in their personal definition of “work”. And this is a problem all up and down the manager/employee chain.

• Finally, underneath it all, there’s a high cultural ethic placed on everyone being positive, meaning that the raising of red flags or warning signs is seriously frowned upon. Amazingly, then, pure cheerleading is valued over careful, thoughtful feedback. It’s a short-term “everyone feel good” emphasis, rather than a long-term outlook that recognizes the benefit of catching issues or mistakes early.

Solutions, or at least a plan of attack

All of this brings us to what should always be the operative question in such matters: we can complain about these things, but what can we actually do to help alleviate them? What specifically can YOU do to help institute a culture (or turn one around) that will largely eliminate the above dysfunctionalities?

Here’s how: by zeroing in on what is the undeniable commonality, the cultural cornerstone, of all these dysfunctionalities: the negative repercussions that occur because people are just winging it.

What do I mean by “winging it”? It’s when people throughout a dysfunctional organization, facing any issue of difficulty or especially of controversy, often come to rely on off-the-cuff responses, glibness, desk pounding, and strength of personality, rather than on careful, facts-based, reasoned logic and argumentation. And for such folks, you know what the great thing is about glibness, desk pounding, and strength of personality? It’s that little or no “work” or preparation is needed. These dysfunctionalities allow people the extraordinary luxury of being reactive, not proactive, in virtually every way.

But as I am fond of saying, it turns out there’s no good substitute for tedium. Rigor matters. Rigor pays off. So, instead of falling into step with this cultural wasteland mentality of winging it, turn it around through ongoing example. Model the following behavior, both personally and for any team you lead:

• Establish the touchstone (context) for all discussion, in the form of a defined, documented plan of record.

• In other words, write things down, and proceed from facts, as captured and reflected in that written word. Look skeptically on those folks who dismiss the critical importance of documenting your basic tenets: goals, objectives, scope, approach, timeline, etc.

• Any issues that emerge need to be examined and discussed in terms of their potential impact on the plan of record (with adjustments to that plan made as necessary). Insist that your projects and your co-workers use that written word (appropriately succinct, of course, and suitably well-crafted) as a collective touchstone for your project overall, rather than succumbing to the inclination to wing it.

• Establish the ground rules. Let’s start with something I personally witnessed Jim Barksdale emphasize repeatedly: “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” I watched Barksdale declare this, flatly, in a room filled with table-pounding senior VPs, and to my surprise, it actually had the desired effect of focusing the group and tamping down the grandstanding and rhetoric.

Doing all that requires active leadership, training and coaching, cajoling and relentless reminders, but really, what of value doesn’t?

Don’t fall into the trap, as many do, of the easy finger-pointing at counterexamples.

• One frequent one that’s trotted out: we’ve all seen people who abuse the email system by hijacking threads, making unfocused remarks, etc. But to overreact to that by shunning email entirely would be a great disservice.
• Another example: we certainly see abuse on Twitter, where bombast and poor behavior proliferate (and often prevail) over more sober, reasoned voices. A large subset of folks on Twitter don’t even seem to be able to differentiate between a loudly voiced sheer opinion and a carefully reasoned argument, and they behave accordingly. Leadership in the workplace needs to actively combat that trend: recognize that bombast doesn’t have to prevail, and work to keep things focused on rigorous, solid analysis.

Amazon’s Jeff Bezos’ alternative to winging it

Jeff Bezos apparently agrees strongly on the need for such a touchstone in business endeavors. Here’s one description of how Amazon functions: 

In senior executive Amazon meetings, before any conversation or discussion begins, everyone sits for 30 minutes in total silence, carefully reading six-page printed memos. Reading together in the meeting guarantees everyone’s undivided attention to the issues at hand, but the real magic happens before the meeting ever starts.  It happens when the author is writing the memo.

What makes this management trick work is how the medium of the written word forces the author of the memo to really think through what he or she wants to present.

It’s clear: Amazon has realized that winging it doesn’t get you there, from an organizational perspective. It just gets you strong opinions and decisions that are made principally from power positioning, rather than using the innate power of verifiable facts and solid reasoning.

Don’t get me wrong, here: I’m not arguing against spontaneity or for analysis paralysis; far from it. The thing is, it’s good to be spontaneous. It’s good not to be too regimented. But anything taken to an extreme runs the danger of going too far. And the unfortunate tendency in many companies is to let the spontaneity run rampant over any form of solid planning.

So, don’t succumb. When you’ve spent time and energy (as you should) defining the project plan of record and capturing the solid reasoning behind it, don’t let people freelance in meetings. Pull them back to that written touchstone, and insist they make their remarks in that context.

Because, after all, winging it is for the birds.

Lagniappe:

• CTO/CIO Perspectives, “Why reading and writing both matter more than you’ve been led to believe”