Wednesday, July 24, 2013

Why teams are slow or fail? - My personal thoughts

I read this recent article by SVPG (click here for the article). I really liked it but wanted to also share my thoughts on what slows the team down
  • Unnecessary Changes - Change happens. We know that not every product manager can anticipate the whim of every customer or sales person. But unnecessary changes or churn can cause a lot of challenges to getting team to really form, focus, and finish! I've seen companies constantly move developers in and out of teams like musical chairs. I've seen product managers bend to the whim of sales winds and drive their teams nuts with constant changes or lack of clarity or depth in requirements. Change happens, but keeping the team focused on the "why" and solving that problem will result in much faster delivery of true customer impact.
  • Lack of customer empathy which causes a lack of urgency - I have seen a lot of teams (especially development), not really feel connected to the customer or to challenges of support, etc. As a result, they lose that drive to fix an urgent issue, simply because they don't know the challenges it causes. There are a couple of quick fixes. Ask your product manager to truly be the voice of the customer, share the data, share the stats, record a customer interview about an issue and play it back for the team. I've heard of other companies asking folks in product development to spend an hour a month listening to support calls, etc. As a product manager myself, I typically use the release or sprint boundary to share the "why" and get the team on board with the work in front of them. Don't forget to follow-up with the team afterwards. Nothing improves morale more than hearing the words of a thankful customer or see a graph of support volume dropping off after a fix!
  • Poor Team Composition - Although this one is listed last, it is by far the most important. In my career there have been several instances where someone on the team just didn't fit in or get along well with the team. In one instance, we had a developer who was super smart, but very loud and it was his way or the highway. Eventually management wised up and he took the highway. In another team, we had a experienced team member, but he was always so negative. It took so much time and energy from me to constantly keep him engaged and not drag down the whole team. Thinking about who should be on a team and what they bring is a critical success factor for the team and for their ability to deliver results quickly.

Thoughts? Did I miss something?

1 comment:

  1. Great article that I can relate to, Peter. Poor team composition can really affect outcomes, and it can be one of the easiest or hardest things to change.

    But the best takeaway for me is the reminder to follow up with the team after a feature or bug fix goes live. Seeing thankful customers or support members can really be a good morale boost, and it reminds us all why we're doing what we're doing. It's one of the reasons I went into Product Management in the first place.

    ReplyDelete