Team Performance Self-Diagnostic

Very often, I’m contacted by prospective clients who are seeking “help with <insert technology here>.” After some discussion, the truth often surfaces. While clients might want help with a particular technology, what they usually need is completely different.

Many of my best clients believed that implementing a popular technology, product, or process will cure all that ails them. In reality, it’s one of many possible team performance issues that require correction, and not a technology problem.

How many of the following issues resonate with you:

  • Frequently missed deadlines and commitments, either internally or externally
  • Cutting features or adding people to a late project in order to make a date
  • Skipping testing steps to save time
  • Reopening bugs that were marked as tested, but in reality were not
  • Frequent regression testing failures
  • Team members working overtime
  • Developers and testers don’t communicate or work as a team
  • A “brilliant jerk” on the team whose toxicity erodes team morale
  • “Job security through obscurity” where developers write vague, uncomment, or hard-to-understand code in order to maintain their perceived indispensability
  • Blame shifting on a team or across teams or departments
  • Source code control and configuration management are unused or used minimally
  • Frequent rewrites of major pieces of functionality
  • Your bus factor is 0 or 1
  • Poor root cause analysis or plus/delta assessments after major outages

This list is greatly abbreviated, as these issues are seemingly endless. However, they represent some of the most expensive problems that face your organization. What’s interesting is that there are few, if any, technologies or products that can solve these problems.

If you experience any of the issues on this list, you need help.

© 2016 by Mark Richman. All rights reserved.


comments powered by Disqus