Dealing with "buzzword creep"

Question

I am an employee with 1.5 years of total experience leading a team of 5 others, 3 of whom have 6 months of experience and 2 are peers.

The accountability of the project lies with the team, but I am responsible for the overall success or failure of the project. (The project is a web portal for internal use)

3 of the 5 are quite normal to deal with, the remaining 2 seem to throw more buzzwords that you can keep up with.

Just to refer to a recent discussion, one of them raised a concern that "We are not agile enough and need to have a backlog", the other followed on with "our UI needs to be more Modern"

The words in bold are what I perceived as buzzwords.

I asked them to clarify what they meant when they used these words (not too politely, I'll admit that was my fault), the response I got was that Modern means we should have tiles everywhere, even if its a list of 300 items, it should be shown as 300 horizontally scrollable tiles.

For Agile and backlog he wasnt really able to frame a sentence but essentially said "I dont know what they are but we should have them"

I have faced similar situations earlier, and managed to diffuse them with a combination of asking people to explain what they mean, and asking them to sometimes put down a few objective points in writing why they want to do something. Usually this has worked out but is there a better strategy.

This method sometimes ends up in shouting matches

Answer 1

Firstly, if you are in software development, I strongly recommend you find out what 'agile' means. Go and read some simple, professional articles on what 'agile development' entails, and then red an in-depth book.. It may or may not be appropriate for your situation, but a good developer, especially a team lead, should know about it. In doing that you will find out what a 'backlog' is.

Considering buzzwords in general: encouraging your team to think of ways your process could be improved is good. However you don't want to jump on every bandwagon. I recommend getting the person who suggested these things to write down a paper explaining:

• What the things they are suggesting are
• How they might be implemented in your specific case
• What benefits and disadvantages they might have

Then review the suggestion and see if you agree. If the team is a close knit one you might try getting them to make a presentation to the whole team, rather than just writing a paper. With something like this the initial paper/presentation should be followed up with more investigation. However make sure this isn't delaying the actual production of software. Make sure the investigation is happening in spare time, or using onnly a small fraction of their available time.

A switch to an agile methodology is not a small thing, and there are plenty of risks. Make sure you understand the process thoroughly, get training, and try it out at a time when you aren't doing critical work.

Answer 2

First, congradulations on openly admiting you don't understand a word/phrase/concept and ask the person to explain. Many people lack courage and are afraid everyone will think they're not smart. Your collegues may be use to people not calling them out when they try to bluff their way through a technical discussion. I think if you keep doing this, they're less likely to use words they don't understand.

Second, there are a lot of ideas people, but don't want to do the work and take on the responsibility to make things happen. Someone wants to be more "Agile" that's great, but not if they don't know how to go about it. If they find that they're accountable for their suggestions possibly to the point of becoming the local expert, they may stop with the baseless suggestions.

What you're currently doing will discourage this behavior but start thinking about more tactful ways to respond. This is very important when in front of others.

Answer 3

So, I think your general approach of asking (politely!) for explanations and justifications of jargon-laden ideas is right on. There's no shame in admitting you don't know, and asking people to elaborate on their thoughts is a way to be respectful.

Some additional strategies that may supplement this generally good approach...

Keep meetings/discussions moving and on target

If you're brainstorming how to make a process more efficient, then a description of agile and backlogs is right on topic. If you're talking about new developments for your next wave of GUI development than a Modern GUI may be worth a good 10 minutes of chatting. But if your original issue was "how do we fix this bug?" - then you've gone VERY far afield with either conversation. Rather than start with a "please explain that idea you just mentioned" - you may need to back up and say "is this relevant to our current topic? No? Then let's make a note and get back to that later". That gives you time to catch up with the jargon speakers later and get a better idea, without making everyone in the discussion live through an off topic tangent.

Realize that for people with a different background, it's not a buzzword, it's a way of doing things.

The word "buzzword" tends to have a negative connotation. Many people use it to mean "trendy ideas" or "ideas that senior management things engineering should do" (with an overtone of doubt and dislike). The word "jargon" is a similarly laden word, but can be often taken to mean "specialized language spoken in a certain field that isn't general for all language users" - which is a little more open ended and less negative. Either way, these three sentences can be perceived differently:

• I don't understand that word - please explain/define
• I don't understand that jargon - please explain/define
• I don't understand that buzzword - please explain/define
• (most extreme) - What's with those buzzwords?? That makes no sense!

If you have contentious discussions, it's a time to watch your language carefully to make sure that in asking what is (in essense) a fair question that you aren't sounding like you're already prejudiced against the idea.

Ask for a bit of history or connectedness..

As other answerers have said - agile & backlog come from a set of ideas around Agile Development methodologies - a pretty widespread practice in some industries. It's a concept that is over 10 years old and has a big enough following to be called an industry practice.

Modern was a new one on me, but I'm willing to buy Mark Chapman's definition and realize that it's not a judgement call (modern = nicer, than legacy) and is rather a specific term used to describe qualities associated with a specific product.

Sometimes the question is not "please define this term" but rather - where did this idea come from and how can I learn more? It's another subtle but important nuance to asking these questions. Why and where a term came from can be a really helpful insight into whether or not it's useful in the current circumstance.

Learn how you learn and use it

As the team lead, you do need to be aware of the concepts and practices your team is raising. While getting an explanation from team members is a great place to start, you're also going to want to get your own opinion from getting outside perspective. To do this, fall back on how YOU learn, and make sure you have resources and time dedicated to keeping up with the topics. You don't have to be smarter than your team, you just have to have the ability to use their ideas as a way to help gain your own insights.

Combining your own research with follow up described below in the 1 on 1 format can be extremely powerful in a good way. Taking the time to research and learn something yourself, and then following up privately tells the person your working with:

• I trusted your ideas enough to take my own time to learn something
• I consider your research and thoughts to be worthwhile, so I'm asking you what you know
• These ideas are valuable enough that I haven't forgotten about them
• I want to give you ownership if we decide to change - please show me that you have ideas and plans on how to make your idea a reality.

If they didn't take the time to research, it must not be very important, and saying something - "I'll wait for you to get back to me with your thoughts" - pretty clearly says, "if you can't take the time to research more, then I won't justify spending more time on this."

Set a tone of "no idea is a bad idea, as long as you can explain it"

You can't move forward on empty words - just reading an article and collecting tentative ideas isn't enough. Get your team into the habit of doing research on topics that interest them and raising well-though-out points. The only thing that strikes me as amiss is that you have someone raising ideas that he can't justify with more than "I don't know what it is but I know we need it". No idea is a bad idea.. unless you don't have enough insight into what you are suggesting to back it up with some thoughts on first steps and the impact of the change (for the better and for the worse).

How to show research

I'm not a really big fan of paper writing or presentation giving in a formal sense - I find that this puts a damper on good ideas... but you want to get the team past shooting out empty words. If I'm faced with someone who knows a term but doesn't know the meaning, I generally turn that into an assignment immediate - go figure out the meaning and impact of this idea, and then let's talk offline. Given that I also love 1 on 1s, that makes a good point to follow up on casually. If I see numerous cases of the same individual throwing out concepts that aren't decently thought out - I may raise it in a more formal way of saying "look, I need more than just the word, I need to know why it matters" - this may be a more direct and forceful point of feedback when dealing with a more senior engineer. I expect junior engineers to have less well enunciated ideas, I expect senior engineers to be more eloquent and knowledgeable. I expect very senior engineers to be wiser than I am on what the impact could be to engineering processes and the time and effort required - that's a form of technical expertise that I'm looking for as people become more experienced.

Answer 4

You should know your jargon, and if you don't, get up to speed. (Oh, really? Yes, really. Why? Because it's a job related skill set that speeds up the exchange of information in a domain specific area of discourse (by a lot)) If you're not up to speed, then asking certainly won't hurt. In fact, I'd say it is almost mandatory as someone who makes decisions on how to proceed. You need to always make sure you know what is being discussed. If this isn't possible, for example because you don't have the time to go through a lengthy explanation, you should postpone final calls on decisions until you know what is on the table, but perhaps tentatively allow or deny some kind of action based on the short description that you might get from your co-workers if they explain it to you. Always ask.

As a side note, it seems that you're confusing buzzwords and jargon here and there. There's a difference between buzzwords and jargon:

• Buzzwords usually are terms that cover topics only shallowly or are meant to hype things. To me, buzzwords are words that make boring stuff sound interesting. They're usually derived from marketing speak and their use will fade or change after a while. like ubiquitous computing which has changed into 'the-internet-of-things', both marketing terms. Both are meaningless and don't have much substance.

• Jargon on the other hand is comprehensive language that adds to a domain related discussion by providing hooks to common concepts.

Sometimes buzzwords will become commonplace for something substantial, or that concept really takes flight and enters the jargon.

Modern, if used in the MS way, is a buzzword to me. Tiled interface would cover it much better. Agile was a buzzword, but nowadays it is the name for a concept regarding software development practice.

Answer 5

Buzzwords are a huge part of work in technical jobs, especially those as fast moving as software development. Get used to it and try keep up as we all do. Buzzword creep can be a pain but any you don't know you should discuss in weekly or fortnightly team meetings and share the knowledge of what these buzzwords are, how useful they are and whether you should go on using them as a team.

That being said, I'm a little worried -like others- that you consider agile and backlog as buzzwords and worse, that you don't know these words. Agile is a huge part of every position I've ever worked in and most agile methodologies -such as scrum for example- a backlog is required to do it correctly.

Answer 6

The buzzwords are the symptom, not the core problem. The problem as you present it is that (1) people are presenting vague ideas that you can't easily comprehend and perhaps neither can they and (2) people are suggesting ideas due to popularity rather than the value they will produce. So what you want to do, is get people to practice being more precise and objective and to more consciously assess the reasoning and outcomes associated with taking on a task. I'd say something like:

"I've been looking at how we communicate as a group and I think there are a couple of things getting in the way. First, it can be difficult to discuss very broad ideas and it can waste a lot of time. I'd like it if you come to the meetings with more precise and actionable forms of your ideas. When you bring an idea in, ask yourself, 'Could two people hear this and produce different outcomes?' If so, try to make it more specific so that we all know exactly what you are trying to suggest before we talk about it. If something is subjective or vague, I'll kindly ask you to hold it to the next meeting when you have time to make it more unambiguous. Second, try to really ask yourself why each suggestion should be followed in specifically our context. If you spend $1000 of your salary time to carry out a plan, I'm not interested in whether the plan leads to something better than we started with. I'm interested in whether we end up with something MORE THAN $1000 better than we started with. I'm interested in the fact that in that $1000 worth of time, there wasn't some other idea that would have made the value go up even more. So when you mention an idea in a meeting, be ready to immediately and explicitly justify why your idea is worth taking away time and effort from other tasks that could be done. If you're not able to say that right away, again, we'll save the comment for another meeting."

At first this might be a little bit annoying. Setting those two rules and sticking by them gives people a predictable expectation. Soon after their ideas keep getting deferred, they'll either start coming to the meeting with those justifications which solves your problem, or they'll stop bringing up their buzzword ideas.

Answer 7

Not really buzzwords, I can explain:

1. Agile/backlog: Agile is a set of development methodologies using short iterations of development, examples are Scrum, Kanban. The backlog is simply the list of outstanding work, which is usually in a prioritised order.
2. Modern: modern (formally metro) is the name of the ui used in win 8, using an active tiled interface.