Wednesday, March 11, 2015

Not My Job And The New Definition Of The Superstar

Recently, I attended a training course in "Fierce Conversations". The course is based on the book by by Susan Scott that bears the same name. A very worthwhile course for anyone managing and/or leading a team. There was a lot to learn about the different types of conversations and how to go about having them in order to achieve the best results. The conversations under the coaching and delegation sections were specifically of great interest to me.

As a part of the course, we had to identify our trigger words. Words that make us get upset when having a conversation with someone. Beyond identifying these words, we were asked to pair up, share our trigger words with our partner and then use them with each other in conversation. My partner got through almost our entire conversation without reacting, but his last trigger word almost made him flinch. When it was my turn, I found out how much my trigger words have changed since I started working with teams that are trying to embrace Kanban and flow. I always thought the trigger word that affected me the most was "Calm Down", but I quickly discovered that the phrase "That is not my job" evokes a stronger reaction.

"Not my job" is the enemy of flow. What it means is that you are more interested in living in your box and working on what is your area of expertise rather than helping the team out where the flow of work is getting interrupted. This means programmers helping out the QAs, if the testers are getting backed up. This means QAs helping out the BAs if there is not a lot to test, but requirement definition is moving slowly. People moving around till everyone becomes a utility player who can plug and play in any area is, in my opinion, the future of teams.



This does not mean that we completely get rid of specialization. You will have folks who are primarily developers and those that are primarily UX designers and those that are primarily QA, but everyone on the team picks up skills in every other area. This means that resources can be moved around to free up any blockages that might be propping up in the team's flow. If an individual works in only one discipline, they are great at what they do. These same folks are rewarded very well for being good at the one discipline they have, which in turn leads to creation of a certain type of Superstar. Unfortunately this definition of a Superstar, while great for a team working in a waterfall model, is counterproductive to a flow-centered agile team. It seems that a lot of organizations have moved to being agile shops, but still reward waterfall Superstars.

What we need is a new definition of the Superstar. The superstar in a flow/agile world is not a master of just one discipline but an expert or almost expert in multiple disciplines. An amalgamation of multiple skills that can help the team regardless of what specialization the team needs help in. The new superstar is not a tester, an analyst or a programmer, he/she is just a developer. A great one at that. One that can help out the team to effectively maintain flow and remove blockages. A Superstar who not only helps the team finish work, but also pairs with every other team member to help them learn and to learn from them. I have been lucky to work with a few individuals that have been Superstars and the team is just rocking and rolling when they are in stride. Rewarding this behaviour and encouraging it is the key to making sure that it becomes more prevalent.

Think of it as a video game where your character's stats determine it's effectiveness. Lets say our players(developers) have three types of statistics - Analysis, Programming and Testing. Now imagine a player whose stats are along the lines of Analysis = 6/10, Programming = 7.5/10, Testing = 7/10. For me, this individual is clearly more valuable than the Superstar from the Waterfall era. They can help the team in the majority of the work the team deals with in all respects. If the business analysts are stuck then our all-rounder can help get some stories ready for the team. If the developers are stuck and the testers are idle, the all-rounder can code some stories and make them available for testing.

The stats of a waterfall era superstar would look more alone the lines of Analysis = 1/10, Programming = 9.5/10, Testing = 2/10. This person can code a lot of stuff, which can lead to a backlog in testing, but cannot help remove that backlog. This can make it hard for the team to achieve the ideal flow efficiency.  These experts are not necessarily all bad news. Experts are great for guidance and knowledge transfer. Pairing them with individuals who need their skills further developed, might be the best way to get those two things accomplished. Experts can be very bad for the team as they can create knowledge and skill silos. The more we let them work in their ares of expertise by themselves, the deeper those silos get. The trick is to not reward them for their individual contributions in their areas of expertise but for how much they have been able to bring the team's average statistic in their area of expertise up.

The idea is for everyone on the team to hone their all-round skills. There is a great amount of flexibility, agility and flow efficiency to be gained here. Some of us are better at gathering requirements, others at programming and others at testing. We all have abilities in every other discipline and in an ideal team, we will all be at level 10 in all disciplines. That might be a pipe dream, but, just like everything else we can strive for the ideal. As long as we keep raising our levels in all disciplines, we are making progress towards the new agile Superstars.

It all starts with hiring the right people and training the existing ones. Your job postings should look for developers who work on teams, rather than BAs or Programmers or QAs. Hire people who love to learn and who love to be involved in all aspects of the story. Train, encourage and reward your existing team for cross functional expertise and dissuade silos. It is time we start hiring team players and not superstars. People with the urge to grow, and the desire to help everyone else grow. There will always be the very few who would go into the expert role, but those should also be team players who are willing to teach.

The old definition of the Superstar needs to be removed from the books. It belongs in the waterfall era where churning out work in just your discipline was the key.  We need the new definition of the superstar to become the norm. Reward people for their versatility and their learning and teaching abilities. It is time for us to move our personnel and our hiring practices to the next stage, where we have moved our teams. We need to hire people that increase the agility and cross functionality of the team, not those that might hinder it. Hire, encourage and create the Superstars of the agile era teams.

2 comments:

  1. While I agree with your basic premise - that superstars are the ones that go beyond a title. I did have trouble with one specific comment – “The superstar in a flow/agile world is not a master of just one discipline but an expert or almost expert in multiple disciplines.” Instead I believe your superstars are the ones that regularly go beyond their discipline. One need not be an expert (especially when one considers that the standard definition of an expert is someone who has put in 10000 hours), merely someone who time and again doesn’t let a job title inhibit them from pushing their team forward.

    ReplyDelete
    Replies
    1. Sounds like we agree in principle, but not in precision of the definition. I do believe that if you are regularly going beyond your prescribed discipline(what about not having a prescribed discipline), you will spend enough time in every discipline to become an expert. Usually those considered "Superstars" are folks who pick up and mater things a lot quicker than others do, I expect these folks to become experts in the multiple disciplines as well if they keep working in all disciplines.

      Delete