The impact of conversation smells

What if we applied the same approach that we use for our code smells to our spoken and written language?

As an experienced developer, recognizing code smells is one of the easy parts of code reviews. If your organization is large enough, you might have a static code analysis tool in IDE such as ReSharper, or in your SDLC pipeline such as Sonarqube, to help with identifying and recommending solutions automatically. These tools not only catch the problem, but they teach by recommending a solution with supporting evidence. Isn’t automation great? 

For those wondering about what code smells are, they are code that indicates there is an underlying problem: be it inefficient code, misused coding principles/patterns, or duplication of code. While the code works as is, it indicates that the author may have some misunderstanding of the impacts of their intent. Down the line, this code may cause confusion when read by someone else, or tech debt resulting in code refactoring.

Let me define a few things conversation smells are not. Conversation smells are not microaggressions. Microaggressions target a person because they belong to a marginalized group. Microaggressions are insults. 

It’s also not using exclusionary language, e.g. gendered pronouns such as “guys”, when referring to groups of people or using male identifiers in all of your examples. That is a topic much deeper than what will be discussed in this article.

Conversation smells are the subtle and overt negative comments that hide in plain sight and can drag down morale if left unchecked. They are the office jokes against third party vendors; the undertone towards customers who need extra help with the product; and the slight jabs at coworkers in other departments. They are also present in some of the words we hear and use every day.

Since code is fundamentally made up of words, what if we applied the same approach that we use for our code smells to our spoken and written language? Would we see that there are also conversation smells? Let us examine a few statements often heard in conversations around the office to see if there are any smells and what we can do about them. 

People are not resources

‘Do we have enough resources on this project to complete it on time?’ said the product owner. 

Why is it a smell? First it is vague as to what is needed for the project. Is it funding? Servers? Bandwidth? Or is it referring to people? Referring to people as resources reduces them down to a consumable good, a commodity, to be used to serve a purpose. Your coworkers, subordinates and the like are not such things.  Moreover, this term is usually only used to refer to people beneath the levels of the speaker. When was the last time that we needed more management or c-suite resources? When speaking about them, using words reserved to mean human beings, employees, staff, developers etc., shows that you understand these relationships and respect the people you are speaking about. It also subconsciously shows others the same sentiment. 

What to do instead. Be specific. If hardware or funding is needed, then they can be quantified easily. If it is people, then things get a little more complicated. More physical bodies working on a project does not necessarily decrease its completion time. (See The Mythical Man-Month for more details on the topic.) 

Corrective actions. In the moment of utterance, it would be best to seek clarification, even if it is obvious that they mean people. ‘When you say resources, do you mean developers?’ This is because you want to get to the root of their concern. There may be a skill gap that is lacking with the team and the belief is that an additional person would solve this. If that person does not have the needed skills, then it’s just complicated the matter. 

Customer apprehension

‘(Sigh)…This customer again? They always call at the end of the day!’ said the support representative.

Why is it a smell? Customers are the reason we have jobs, period! They are not interruptions to our day-to-day duties, even if we do not deal with them directly. For those on the frontline however, they receive the brunt of the direct feedback, often in real-time. When that flow of feedback is negative it can build resentment. The customer just wants the product to function as expected and we want to get them back to that state so they can be productive once more with the value we provided them.

These types of comments often become the office joke. In unhealthy organizations, it can spread like wildfire between employees if not extinguished. Imagine if a customer was hired into an organization only to discover this is how they were being referred to; or an employee going to your competition and telling them that this is how your customers are talked about behind closed doors.

Also, remember that your team may be responsible for the woes of the customer, and the negative comments could in turn be directed inward at your team.

What to do instead. Focus on the issue itself. Ask questions about the issue to gauge its scope: have any other customers reported the issue? Is this the first time it has been reported? Some customers are savvy enough to be our beta testers. This customer may be a good candidate for that program in your origination if one exists. 

Ask to speak with the customer directly to address their concerns. Speaking with someone outside the normal channels often puts customers at ease because they feel that they are being heard outside of the support world.

Corrective actions. This can be tricky because it could be cultural to the team, department, or organization. Try to avoid asking who the customer is. This can reinforce the categorization of the customer as a “bad apple”. And it can add others within earshot of the conversation to that association. 

Be prepared to speak with the lead of the offending team (or higher) to express concerns of negative comments towards customers. Explain that you do not want it to spread amongst the staff, especially to new team members. When having this conversation, focus on what was said without naming names. That way it can be addressed with the staff in general and the entire team receives the same message.

Vendor aggression

‘I can’t wait until we get rid of this vendor. Do they even know what they’re doing over there?’ said the developer.

Why is it a smell?  The choice of a vendor is not usually done out of haste. The choice of vendor can be made due to personal reasons such as a friend, or a past professional relationship. Or maybe someone felt that this was the direction to go in whether others liked it or not. Openly critiquing the company could put an employee in an awkward situation should this be the case. 

Like with customer apprehension, it can become company culture to complain about vendors of the company. But there is typically a good reason for doing business with them whether we understand it or not. The value of the relationship may be more than just using their services.

Within our industry there is a subtle phenomenon I like to call “programmer shaming”, which serves no good purpose. Bugs, data breaches, website hacks, existence of certain technology (deep fakes, banner ads etc.) all point to programmers. A former coworker would say “those programmers” whenever something in the news would point back to technology. The irony was, she herself was a programmer. And she was right in a sense, a programmer most likely wrote the code. Rarely do we call out the hypocrisy in these statements. 

What to do instead. Gather constructive information about the issues being experienced rather than just listening to the complaints. Ask those complaining to express what they expected to happen vs what is actually happening so that it is clear where the issue lies. 

Try to highlight the value of doing business with the vendor. It may not be easy to see why they are being used. Having more insight will help to understand why they were chosen in the first place. 

And have them suggest alternatives. By redirecting their energy, you may find that a new competitor has entered the market and is worth comparing. 

Corrective actions. Report any issues you are experiencing with a third party immediately through their bug tracking system. Utilize any direct contacts you have within the company to seek resolutions to your issues. Do not resort to social media to air concerns, and discourage your team from doing so as well; it may appear to get results in the moment but in retrospect it will look bad on the person doing the posting. 

Track the issues you experience to quantify their occurrence. More impactful issues see the light more than recurring ones. The one large issue you had may seem impactful, but pales in comparison when stacked up against the several small ones that happen every day. This will give you the leverage you need to switch vendors should it be a concern. It will also give you a line of questions to ask when looking at their competition.

Policy validation

‘We have this restriction in place because people kept getting it wrong and I don’t want to have to always fix it,’ said the systems engineer.

Why is it a smell? The underlying issue is not being addressed. Instead a policy or procedure has been put in place to prevent someone from needing to take further action. Though it may be that the staff are lacking sufficient training or documentation around how to perform a certain action.

For example if staff are prevented from accessing a specific blog, it could be that the engine running the blog has been compromised in the past, which led the IT team to block all sites detected to use that engine. Most blog engines now add their version to the html, which is then sent to the browser to help prevent all users from being blocked. Thus, making it easy to identify problem sites. Your systems engineers could be utilizing an outdated technique just because it “works”.

There are times when blanket approaches are taken when precision is needed. For example, hardening a development environment to the same extent as production. Hardening procedures may need to be tested prior to deploying them to production but development may not be the best step in the SDLC to set it up. Freedom is often needed to do the ‘R’ in R&D as we discover the best way to do things. Doing so with such tight restrictions may hamper those efforts with unnecessary delays.

What to do instead. Educate the staff on why restrictions are there in the first place. This can be accomplished with discoverable, written documentation so that information isn’t tribal knowledge. 

Find out more information about the task attempting to be performed to see if there are other ways to accomplish it. Speak with those responsible for the policy/procedure to see if there is documentation. It may need to be updated or no longer needed.

Also speak with the systems engineer to find out what their frustrations are with the team and how to mitigate them. Reaching an understanding on how to proceed going forward together to release valuable software should be the ultimate goal. 
Corrective actions. See if training can be implemented to remove the need for the restriction. Policies and procedures are often put in place in lieu of training because it is a quick fix. 

Work with the systems engineers to see what the consequences are of removing the restrictions. Talking it through will help them to understand the problem being solved. Ask if there are newer ways of solving the same problem, or if the policy is still needed. 

Silently agreeing

‘…’ said the development team members.

Why is it a smell? No news is not good news when it comes to our teams. Feedback is key to the successful growth of self-organizing teams, so when your team is silent, it can be an indicator of several factors. One of which is a lack of psychological safety. This is when people feel that they can’t express themselves without fear of negative consequences being imposed upon them or their careers. When an environment is psychologically safe, it allows for people to say how they really feel, professionally of course, about a given topic or question. 

You do not know if they are silent because they agree, are afraid to disagree, or are afraid to admit they do not understand. Being afraid to disagree is common because those with a higher position are often viewed as being the ones who are always right. Some people are also wary of appearing to challenge authority. You as a lead are that authority. As leads we should never seek this perception. We should be seeking to guide those we lead to being effective at their jobs. It does not mean that they are right or wrong. Effective is understanding what is necessary to know and seeking answers when we do not know.

One additional cause is a lack of being tuned in. This is harder to mitigate because it could be caused by personal or professional issues experienced by the individual. Therefore, it is vital to have regular 1:1s with individual members of your team to have a grasp on their situations without prying into their personal lives. 

What to do instead. Silence can work both ways. We get uncomfortable with silence during conversation, so use it to your advantage. Ask a question, then pause to wait for the answer. Someone will speak up and when they do, ask the others if they agree. 

Try not to ask closed questions as that can be viewed as limiting what is acceptable. Instead, end your question without suggesting solutions, or preface it with something to the effect of ‘here are my thoughts, what do you think?’ This will let you be vulnerable along with the rest of the team.

If this is a habit amongst your team, ask a question then call on those who are silent occasionally. This will cause people to be on their toes in the future and to have answers ready to suggest as they will not know when they are going to be called on. Eventually they will start to offer their thoughts on their own.

Corrective actions. Have a frank conversation with your team about psychological safety and silently agreeing. Let them know that they are free to express their thoughts without repercussions if they aren’t directly attacking someone. Even if their ideas are not directly accepted as presented, they will help to further the conversion. They should not seek to be right themselves, they should seek to help the team make effective decisions. 

Daydreaming happens but we should do our best to mitigate it during meetings. Make sure your team has the materials they need for discussions: proper calendar invite subjects and summaries, reading materials, or points of reference beforehand if necessary.   

Conclusion

As leads we must set the example for our team members and others in the organization. Curtailing these conversational faux pas are a must to ensure that our team members represent our organization values within, as well as outside the office.

And when new hires join us, we want them to come into a positive environment. We bring in new members to help foster and grow our culture. No one wants to start at an organization only to find that their new coworkers subtly have resentment for those around or their jobs. 

Addressing conversation smells can help to positively transform the culture of your team and the wider organisation, and it’s easy to do! When you put into practice some of the suggestions in this article you’ll be leading by example, and that will be picked up by your colleagues.