I was at a meeting a couple months ago . . .

. . . and I decided to amuse myself by writing down all the management-speak words I heard:

“grappling”
“early prototypes”
“technology platform”
“building block”
“machine learning”
“your team”
“workspace”
“tagging”
“data exhaust”
“monitoring a particular population”
“collective intelligence”
“communities of practice”
“hackathon”
“human resources . . . technologies”

Any one or two or three of these phrases might be fine, but put them all together and what you have is a festival of jargon. A hackathon, indeed.

19 thoughts on “I was at a meeting a couple months ago . . .

  1. Not to make this a contest but I used to work for an unnamed company (let’s just say it’s in your wallet) where we were routinely told to gather learnings and maximize impactfulness.

  2. The only phrases on your list that rang my buzzword bingo bell were

    “technology platform”
    “data exhaust”
    “communities of practice”
    “human resources . . . technologies”

    though the last one doesn’t sound like a phrase.

    Where are the “best practices”, “leveraging our capabilities”, “sustainable competitive advantage”, and their friends?

  3. Sure, but what _isn’t_ a jargon-fest? Here are some words or phrases from your most recent blog posts:
    “hypothesis generation”
    “model checking”
    “deductive inference”
    “reference distribution”
    “conditioning”
    “point estimate”
    “posterior predictive distribution”
    “expectation”
    “expected frequency distribution”
    “mean square test”
    “chi-squared distribution”

    I could, of course, go on.

    • Phil:

      Here’s the difference (as I see it): When I use jargon, it is to convey information efficiently. It would be silly for me to define terms such as “expectation” and “chi-squared distribution” from scratch. These other people were using jargon to represent technical thinking without actually doing it.

  4. Of course, the meeting sounds like something out of Dilbert.

    However, some of the words actually do have specific meanings when used by some people, the problem being when they are repeated by people who don’t really understand them.

    “early prototypes” is a fine term, with a long history, even in software, especially after “fast prototyping” became popular in the early 1980s. In well-managed engineering organizations, senior managers understood this perfectly well. These days, something like this is called Agile Development.

    “technology platform” is fine, also, if it has something specific with it. Again, people have long used that in software to mean the collection of operating systems, languages, tools and libraries that would be used to build some application. In well-managed places, it was generally preferred to pick an up-to-date platform and then stick with it a while and eschew constant changes. I used to lecture in the internal Bell Labs course on software project management, and that was one of the messages.

    The term sometimes get used in VC pitch meetings, i.e., if didn’t say so: “What technology platforms are you targeting?”

    “building block” might be psycho-babble, or it might refer to the idea of building software out of components, rather than writing it from scratch. That was articulated early by Doug McIlroy ~1968 at a NATO conference and the thinking led to programs built by connecting UNIX commands. In chip design, it might refer to a pre-existing synthesizable block of logic, perhaps licensed from someone else.

    “your team” I’m not sure what the problem is with this. Most industrial development is strongly team-oriented.

    “hackathon” is just the newest name for a collective activity in which a bunch of programmers get together to work on some code together, usually forbidding the presence of any marketeers (if the programmers happen to work for companies). The Wikipedia page mentions Sun Connectathons, in which programmers from different competing vendors got together in a big room for a week to make sure their implementations of Sun’s Network File Systems inter-operated. This sometimes meant that competitors were helping debug each others’ code, which is why marketeers were forbidden.

    In the early days of SPEC, we had “Benchathons” for the purpose of sorting out unportabilities of benchmarks among computer vendors. I think Hackathons are a bit less structured. All these things are geared to support low-overhead communication and rapid interaction, without minimal interrupts and letting people dive deeply into something, get it into their short-term memories, without startup overhead. This is in some sense a return to “the old days” when people did not even have terminals in their offices, but went to a “terminal room,” and quite often worked together there.

    Google: hackathon mountain view … MV alone has lots, Google is fond of them.

    • Along the same lines as “your team”, I’m not sure what’s wrong with “grappling” either. “human resources” and “technologies” may not appear in academia as much, but they’re kindof hard to avoid in industry. I don’t see the problem with “monitoring a particular population” either. This all just sounds like English to me.

      As John says, some of these (e.g. “hackathon”, “prototypes”) are abbreviations for things that would take longer to explain if jargon wasn’t used, even if they aren’t sophisticated concepts. ”

      Other things like “collective intelligence” and “data exhaust” are indeed annoying buzzwords.

    • John, Revo:

      As I wrote above, any one or two or three of these phrases might be fine, but put them all together and what you have is a festival of jargon. I don’t have any problem with any of the expressions by itself, but in the context of the meeting they were being thrown around in a way carelessly. For example, yes I’d heard of hackathons and indeed the term was used correctly by the participant in the meeting—but I think it’s highly unlikely that the proposed hackathon will ever come about. It seemed to me that they were talking about things that weren’t going to happen.

      • “It seemed to me that they were talking about things that weren’t going to happen.”
        But that’s orthogonal, so that two separate kinds of problems have been conflated.

        1) The words may or may not be a problem. Places can be filled with jargon, and at least these were English words. I’ve often been in meetings where much of the conversation was composed of acronyms and TLAs. All this may or may not be good communication, depending on circumstances.

        2) More important, is it *effective*?
        a) It may be incompetence, in that people may wish to accomplish something and get wrapped up in babble.
        b) It may be competent sabotage of something somebody *doesn’t* want to happen.

        I’ve seen both in corporate experience and sales situations. In the former, I was trained to look for such and either
        try to help people perform better, or especially in 2b) get them out of there. Companies sometimes have “turkey farms” for that purpose.

        BUT: I offer an analogy in the use of statistics.
        BTL’s view of statistics was influenced by John Tukey.

        On the other hand, I’ve certainly seen:
        a) Incompetence use of statistics, or just wrong statistics in many cases.
        b) But perhaps worse *from a Tukey-esque view), use of statistics to mislead, cause confusion, increase uncertainty.
        would have approved. He sometimes uses the term “mathturbation” to describe b).
        (Put that in his search box).

        Sometimes a) manifests itself as people getting completely wrapped up in detailed statistics arguments while forgetting what they are trying to do. I’ve sometimes seen that happen in computer design studies, which are fairly quantitative these days.

        Anyway, I think the degree of jargon is not the real issue, but whether the group is using it effectively.

  5. Well Andrew, to any outsider all kinds of terms will seem like gibberish. All of the above terms might be very useful, depending on the context. A blog post like this not only highlights your incompetence concerning management terms (which is fine, we can’t know everything) but it also highlights that you don’t know that you don’t know such terms. Knowing what you don’t know is a key thing in life <– the main message of Socrates.

  6. Well, that post actually undermined your original blog-post. You initially tried to say that it was nonsense to have these terms in one session. In the later post you just pointed out that it wasn’t done appropriately in this particular setting.
    I would be more careful about how to generalize youre particular observations – a topic I would assume you are an expert on.

    I could use the above cited statistical terms in one session – and it would be a fuzzy, incoherent jungle. That doesn’t mean that it’s not doable and that the terms in themselves are not useful.

    Basically: You are trying to attack management as a perspective. I would try to do a much better job, because right now only people that already are agreeing with you, would find the post interesting. Are those the only readers you want to “catch”. If so, I’ll be happy to stop reading this blog.

      • I have a different interpretation:

        1) Bad meetings are bad meetings whether they use careful terminology or a surfeit of jargon, but good meetings can be filled with jargon even more incomprehensible to outsiders.

        I think the underlying problem was the badness of the meeting, but one of its manifestations was jargon, an easy thing to recognize and poke at. I pointed out the possible conflation.

        2)”You are trying to attack management as a perspective.”
        Do you conflate jargon with management? I don’t understand that.

        Back when I was a line manager and/or corporate troubleshooter:

        a) If the meeting was a big one, the goal would either be to get it fixed, or ignore it, or make sure people didn’t waste time going to the next one.

        b) If the meeting was a small one, one would be identifying why it was bad and fixing that, whether it was training somebody, moving them elsewhere, or if it was some little task force that was hopeless, getting rid of it or at worse, moving it to turkey farm territory so it did no damage.

        *Good* management worries about this stuff. We often used to discuss such team dynamics at merit review time, if necessary moving people around. Likewise, I often had to assess possible cooperative efforts and decide to participate and/or fund them (and recommend such to some executive), in part based on group effectiveness.

        Maybe Andrew will say more about the general nature of the meeting. Small? Big? Focused on some task? Tutorial?

        The way I’d put it, the relevant critique is not that the jargon might have been bad, but if the meeting was ineffective, that is somebody’s management problem.

  7. My least favourite piece of management jargon is “going forward” as if there is an option of “going backward” [in time] – or maybe I’m missing the meaning of the phrase entirely.

    If only we had a time machine, then all management problems would be trivial, no?

Comments are closed.