As most of you know, Tony and I went to the AYE Conference last month in Phoenix. AYE stands for Amplifying Your Effectiveness. While I hate to say it I don’t have as many wow moments to share with you as I would have liked, I do have a few examples of interesting workshops that were run. Most of the workshops we attended ended with Tony and I realizing that we (Intelliware) are very good at what we do and that our process shields us from many of the communications problems that larger companies struggle with. I’ll provide a separate blog posting on the previous sentence. First I’d like to share our first workshop with you.
The first AYE workshop that Tony and I attended was called “The Savvy Project Manager: Dealing with Multi-Tasking”, presented by Johanna Rothman. Based on the workshop name Tony and I were expecting some really cool ways to deal and cope with Multi-tasking. In the end the workshop dealt with the cost of context switching.
The main exercise in the workshop was pretty simple. We were split into 5 groups of 4 or 5 people. Each team was asked to pick a project manager and then given a simple 3 piece by 3 piece puzzle. Don’t be fooled by the word simple, in my group we had some big brains from MIT, Google and Microsoft yet we couldn’t solve the puzzle in the time given (20 minutes). In fact, none of the groups solved the puzzle; it was solvable by the way. However, solving the puzzle wasn’t the actual goal of the exercise.
Once we were given our assignment each team rigorously went ahead trying to solve their puzzle. During the exercise Johanna went around the room and randomly switched team members. This happened once or twice to each team. One team actually requested extra people thinking that adding more people might help them solve their puzzle faster.
What struck me about this experiment was that in it seemed very simple. How could putting together a puzzle help me understand multi-tasking? In the end it didn’t help much in terms of multi-tasking. However, it was a very real simulation of team dynamics and context switching within and across teams.
The first thing that I noticed when we lost our first teammate was how distracting this was for our Project Manager. At first our PM was a major contributor to our puzzle but as soon as that first teammate was gone you could see the loss of focus on his face. He wasn’t sure what to think or what to do. Now I don’t have total insight into what happens when we have people switch teams and how that affects the project managers. I do know that they talk about this kind of thing on a regular basis so it doesn’t happen as abruptly as it did in our workshop. If you were dealing with a situation where time pressures were real and you abruptly lost one of your contributors the person in charge of delivery would surely become distracted by many resulting issues. Fortunately at Intelliware we don’t have this happen very often, and if it does happen we try to plan accordingly.
Shortly proceeding losing our first team member we gained a new teammate. Now imagine 4 people scrambling to solve a puzzle and having a new person arrive. We gave her a brief talk about what we were trying to do and what our strategy was but that was it. We clearly didn’t welcome her appropriately because later on in the debrief portion of the workshop we found out that she had previous experience solving similar puzzles. She could have been a huge asset but we never took the time to identify skill. We were too wrapped up in what we were doing to take time to make sure our new teammate was welcomed to the team properly. Have you heard that before? I know on my current project we talk about the process for welcoming new folks to the team and we try to help them become assimilated but it never seems to be enough. I’d be interested to hear how other projects at Intelliware welcome new team members. On my current project we usually have a “Welcome to the Team” lunch, also included is some sort of introduction to the domain and technologies that are being used on the project. We’ve also tried to develop some good reading materials but the development of those materials tends to fall to the side as other items take priority.
As I mentioned earlier, one of the teams thought that if they could add more people to their team they would be able to perform their task quicker. That team didn’t have a 3 by 3 puzzle; they had some kind of sorting card game. They thought that because it was sorting they could divide the sorting up across more people and this would be faster. Can you guess what happened?
In most cases, adding people doesn’t help. I can think of the odd case at Intelliware where it has worked but as a general rule it will usually slow a team down more than speed a team up. In this case the team was pretty frustrated because with more people they had more communication barriers amongst the different streams sorting. When they were given new team members they had a tougher time bringing people up to speed because they were the only team with a sorting puzzle. So it was a bigger context switch for the person coming in. Most of the people that were being switched were being switched between teams with a 3 by 3 puzzle, the only difference being that the puzzles across those teams had a different theme. When the sorting team received someone from a puzzle team they had to explain something that was totally new. So not only were they explaining how they were solving the puzzle but they had to explain what the puzzle was.
Here at Intelliware you can think of some pretty concrete real life examples of this, for instance, going from one pharmacy application to another related pharmacy application. There is some crossover in the domain and the technologies used are pretty similar. This type of switch wouldn’t be nearly as involved as going from a pharmacy application to a financial application. There’s a new domain to learn and probably a new technology stack. It’s a much bigger leap and in the case of the sorting puzzle team they were expecting the extra person to speed them up. In the end it was very hard and stressful on the team as well as the individual being swapped. The person being swapped felt like they couldn’t contribute as much as everyone else on the team because there was a learning larger learning curve.
So you can see that a very simple exercise proved to shed light on some very interesting real life problems. I think that here at Intelliware we are pretty in tune with what can happen to individuals andor teams when it happens too often. Obviously there are times that are less ideal than others due to project pressures but I believe that the effect of switching people from team to team is usually taken into consideration. Unfortunately the blog postings from Johanna were pretty out of date so I’m not including them in this post.
I’ll try to post some more on how our experience made Tony and I realize that we are all very fortunate to be working at Intelliware…..