Technological Dysentery Disorder – A guide to coping

Have you ever met someone who blurted out random technologies or methodologies, at seemly random and inappropriate times? And furthermore, it seems like they are talking out of their you know what? If you are anything like me, then you have had the misfortune of having to cope with this.

Technological Dysentery Disorder (TDD) can afflict many people, from project managers, to sales, to executives, customers, developers, or even in rare cases, QA. Unfortunately, there is no cure for this disease, but simple coping strategies can help mitigate and alleviate the symptoms. It is especially serious when it affects QA, as a QA’s role often dictates that they bring sanity to the projects, and keep the rest of the team in line. When TDD strikes the QA, this is a worst case scenario, just like when illness strikes frontline healthcare workers.

One of the best coping mechanisms is to understand why the flare-ups are occurring. The two main causes of TDD are:

• A desire to appear intelligent in front of peers, subordinates, and/or vendors
  
• A strong fascination with technology, a fascination that is so strong that every single problem looks like a nail that needs to be bashed with the mighty hammer of technology
  

Understanding the underlying reasons for these outbursts will be very useful in helping you keep your patience when dealing with those afflicted.

Another important coping strategy is to refrain from engaging in debates or arguments about technologies or methodologies except when absolutely necessary. Engaging in debates on technology in sales or standup/status meetings is not ideal, you will end up going off on a tangent and wasting everyone’s time. Instead, focus on solving the underlying problem instead of focusing on the technology.

When you are dealing with a stakeholder who is suffering from TDD, try to guide the discussions away from technological, framework, or other non-important issue, focus on the problem, not the technology with which to solve it.

At the end of the day, an expert is a problem solver, not a technology implementer.