Buzzwords Bug Me… A lot

When you spend time thinking about and describing what you do, the words that you use and the phrases that you craft become of utmost importance. The reality is that this is a double-edged sword. From one perspective, you want to stand out and clearly differentiate yourself. From a different perspective, though, you are trying to signal inclusion and belonging—that you are one of the tribe, that you have mastery of the skills that matter and that you offer the expertise that people are looking for.

It doesn’t matter whether you are a consultant or a candidate, the sentiment holds true across the spectrum. Resumes get scanned by a mindless computer before they ever land on the desk of a potential recruiter. Proposals are reviewed for whether prospective consultants have an often surprisingly specific combination of skills, expertise and experience. In both instances, words matter. Choose the right words, and you might get sifted through to the next stage of scrutiny. Choose the wrong words, and you need not have tried.

As I have gone through a recent exercise of thinking how I define my role, explain my services and position myself to prospective clients, I have come to an interesting realization. There are a host of terms that I avoid using to describe what I do, how I do it or the results that I deliver. Many of these terms are recognized and popular. They are, for want of a better term, buzzwords. They theoretically represent popular and resonant ideas that are current and trendy. And I avoid them like the plague.

As I noted in The Cult of Labels, a webinar that I delivered last year, words have power. In particular, we use labels and terms to create in-groups and out-groups. Our adoption of terms and terminology is not just short-hand in explaining complex ideas, it is a way of signalling that we are part of a group. The adoption and use of specific vernacular signals knowledge of certain concepts and adherence to ways of working. It is argot-as-secret-handshake and parlance-as-private-password, signalling to the cognoscenti that we are one of them.

The consequence of this reality is that terms and labels applied to practices and concepts are obscure by design. They are intended to be opaque. They resemble regular words—in reality, they very often ARE regular words—but they are redefined in a way that connotes precise meaning and intent. Unless you are one of the initiated, that nuance will sail clear over your head and land far beyond your comprehension. That outcome is not an accident.

Obscure words and nuanced meaning have long been a feature of academic writing (and scholarly writers have legitimately taken a lot of heat for it, not that it seems to have made a difference). It is also the content that frames the high notes of “dog whistle” politics. Every profession has its terminology and its vernacular, although some make more of a fetish of this than others. With a nod do one of my favourite expressions, never use a big word when a diminutive one will do. Never use a clear and plain-meaning word when an obscure and loaded one will do. 

To give credit where credit is due, this rant was prompted by an article that came across my radar screen a couple of weeks ago. The author leads off with the following sentence: “I wrote an article a couple of weeks ago detailing the deprecating nature of scaling frameworks in agile organizations.” Putting aside the fact that this is an absolutely horrible opening line for any piece of writing, there is the fundamental question of what the sentence actually means. Speaking personally, I had absolutely no clue, and I’m quite happy to acknowledge my befuddlement. Clicking the link to the article provides no real assistance, as those words don’t appear anywhere. It seems the author thought this a well-intentioned and perfectly reasonable descriptor of his original piece. 

Figuring out the answer to the question of what this means takes work. More work than I would normally be inclined to do if I wasn’t motivated by indignation and determination to try to figure out what makes people write this way.

Let’s rip apart the sentence and try to make sense of all of this, shall we? “Agile organizations” is probably the most easily understood construct here, implying organizations that have in some way adopted agile practices (presumably related to software development). A closer read of the original piece, however, clarifies that what we are really addressing is organizations that are endeavouring to make agile work.

The use of “scaling frameworks” is a different notion. “Scaling” has become a ridiculously trendy word in recent years, originally in startup culture, and later co-opted by information technology in general, and the agile movement in particular. Common variations are “scale up” and “at scale,” both of which carry their own slight nuances. The essential intent of “scaling,” though, is simply to figure out how to still make things work when you move past a tiny core team, and try to do something at the level of an organization, an enterprise or even an industry. More particularly, “scaling frameworks” reference practices and prescriptions for how to accomplish this outcome.

The expression “deprecating nature” in the original quote needs some more work, though. What is not clear on the face of it is whether this is a buzzword, or simply the use of words in their normal meaning. The meaning of the verb “deprecate” is to express disapproval. “Deprecation” turns this into a noun, one that means “the act or process of expressing earnest disapproval.” The challenge is that this sense isn’t conveyed in the original article. What the author is writing about is the increasing ineffectiveness of practices as organizations get bigger. This leads me to suspect that not only is the sentence unnecessarily complex, but also uses the wrong word. “Depreciation” is the reduction of value of an asset over time, especially due to wear and tear; “depreciating”, then, would seem to better align with the writer’s intent. But then again, perhaps not; “deprecating” does have a specific meaning in technology about discouraging a technology or approach that is no longer considered efficient or optimal.

When all is said and done, parsing out the complexities of a difficult sentence gets us to a sense of meaning. What the author appears to have intended in writing his article is to describe, “The inadequacy of existing processes to support using agile as organizations get bigger.” It is beyond me as to why he couldn’t have just said that.

Part of my frustration with complex and obscure word choice is the simple lack of clarity. There is enormous value in communicating well. I spend a great deal of effort and energy trying to make sure that what I communicate is accessible, understandable and relevant. It annoys me when others don’t. But what especially frustrates me is when obscure representation is an intentional act.

This is where I find myself deliberately avoiding the use of certain terms. Amongst them are “lean,” “agile,” “wicked problems,” “design thinking,” and “PMBOK.” I also tend to have an aversion to terms within specific domains, like “scrum,” “cadence,” and “retrospective.” What my initial rant about an obscure article prompted was a self-reflective question of why I have an aversion to these terms. My response to most of these terms has become instinctive. It is always a useful exercise to check in on those sorts of reactions when you notice them.

I suspect the aversion comes across somewhat in my writing as well. There are those who have noted that I don’t seem to be a huge fan of agile, for example. To be very clear, I am not against agile. I think it is relevant and useful in certain contexts, particularly where requirements are fluid and flexible and you need to design your way to a solution over time. I also recognize that organizations look askance at some of its precepts, and sponsors are very uncomfortable signing a cheque for a project without a clear sense of the outcome it will deliver. Agile can be useful, but it is not the answer to everything. There are also times and circumstances, for example, where bog-standard traditional practices of design and development work just fine.

While I might not be opposed to agile (or lean, or design thinking, or any one of a number of specific frameworks) what I do react negatively to is the adoption of any practice as ideology. Advocates for many management approaches have an unfortunate tendency to portray themselves as being rabidly evangelical. This is, in part, human nature. Once we get exposed to a new way of working or approaching a problem that we have not experienced before, we can get enormously excited about it. We see all of its benefits, and don’t necessarily pay attention to its drawbacks or limitations. This is the methodological equivalent of, “once you have a hammer, everything starts to look like a nail.”

Part of my aversion is probably rooted in a contrarian instinct (one I will acknowledge as absolutely present). I’m not one for jumping on bandwagons and embracing ideologies unthinkingly. I value nuance. I believe in the importance of context. I have an aversion to best practices. My stock answer to most complex questions is, “it depends.” 

I do value innovation. I am open to new ideas, new approaches, new insights and new practices. I am constantly on the look out for better ways of doing things. But what I expect to find as better are ideas and philosophies that can be adapted and applied. I don’t expect it to take the form of fully crafted practices, defined in their entirety and wrapped up in a bow. Adoption of those ideas might shift perspective, and might even reshape thinking; that does not mean of necessity that it should require a redefinition of language. I shouldn’t need to re-learn familiar words in new ways in order to apply someone else’s framework.

My negative reaction to specific terms and terminology is that they are often used as code. They are shorthand structures, used not just to convey meaning, but also ideology. That is a default presumption that I need to be wary of. My expectation is that advocates for a particular approach think only in the structures of that approach. By extension, there is a perceived “right way” and “wrong way” of doing things. It is the reaction that gets generated, for example, when a team decides that they want to adopt the idea of focused, stand-up meetings as a way of communicating, but accused of  “not doing real agile.”

There can be value in using terminology, of course. Terms can be short-hand ways of expressing more complex thoughts where time is of the essence. It is why, for example, protective services personnel communicate in “codes” and medical professionals have a variety of short-hand expressions to manage triaging and emergency treatment of patients. When you need to communicate quickly amongst immediate colleagues, shorthand makes sense. There are other ways to explain those same notions, however, when you are trying to explain them to a lay audience. Given that even professionals get confused by acronyms and terminology, you are well served by explaining things clearly to them, as well.

Choose your words carefully. Be precise in your meaning. But please, above all, be inclusive in your communication and aspire to make it relevant to as broad an audience as possible. Start speaking clearly, and stop speaking in code. Please and thank you.