Finally I am done reading the book! Very long reading indeed, usually I spend very little time in reading, and skim through most of the content, but this one I thought was time well spent, and I was right. Here is what I got out of the book:
1. Performance is the single most important driver for excellent team output.
2. You can not force team to be high-performing, you can only create conditions for them to prosper by defining clear, measurable, specific performance goals and specifying how they will be measured.
3. High-performance teams are rare as you go up org heirarchy, but they are more important at that level.
4. Studying examples of high-performing teams, talking to those who have been part of such teams, or watching them as they unfold around you, are the best ways of learning how teams work well, reading theories will not do you much good.
The book also helped me compare my experience with another great team I was fortunate to be part of, and it was insightful too, to see what we could have done in the team and we didn’t.
When I joined this company, I was the first employee of the india division of this group and our charter was to take an existing product in the domain of video conferencing and make it enterprise quality. My first task was to hire a small team (this was a small company then) who can work on this. The technology was VC++, VB, networking, audio/video stuff, and hence hiring wasn’t that easy. However, within 3 months, we were able to hire a core team of 5 engineers who would work on this product for about 1.5 yrs or so. The team’s charter was very clear: make the existing non-usable code to enterprise quality and give out releases to customers who already had other products from our company. Also, while hiring, we tried to make sure we hire for talent, ability to think outside the box and challenge status quo, and work well with others. Importantly, we didn’t try to hire for exact match to the technology skills we needed because it was anyway difficult to get that in the market for a company of our size. All this meant that we got a bunch of go-getters who had a clear agenda for product delivery, and an attitude to fix anything and everything in the world. Also, given the fact that everyone else in the company used a different technology to build their product, and also the fact the revenue from our product line was negligible to start with, our team got very clear message from most of their peers in the company that this team is doomed to fail and that the company doesn’t care about its success. Instead of deterring the team, it seemed to spur them into action and they formed an extremely tight-knit team which wanted to show how wrong every one was! Some motivation!
Over a period of 1.5 yrs, we had almost 10 releases of the software, could claim many esteemed and large clients, and when the product got shelved (yes it was 😦 ), it was extremely hard to get some customers stop using the product!
When I compared this story with the lessons from the book, here are some things we seemed to have done right, almost accidentally:
1. Clear, and tough performance goal – taking a software that doesn’t work even for couple of users, and make it work within 6 months for enterprise quality users with concurrency numbers of 150-200. This was tough, if not impossible!
2. Small team with complimentary skills – we had windows , unix and embedded systems skills, and also technology exposure to audio/video networking and client-server programming, and also QA. Given the fact that we are talking of 5-6 people here (to start with anyway), this was remarkable broad, and many overlaps existed which helped too.
3. Fear of failure spurring team – There wasn’t much encouragement from outside the team, and everyone thought we would fail. This motivated the team and made them come close and they really went all the way in helping each other so that we succeed as a team. It wasn’t unusual to see the devs doing QA work or QA helping debug dev code at midnight.
4. Confidence from those who matter: US team and the managers there always had confidence on the team, and our manager was always there to do whatever it takes to get us out of soup, whether it is by implementing some tricky portions of code, or shouting at those who tried to show the team in bad light. This enabled the team to do their work without lots of external interruptions.
After initial 9 months, we did go ahead and doubled the team size, and this extended team worked very well and effectively as a team (way better performance than rest of the company), but they were still an extended team; it was apparent that making a large team equally high-performing is extremely difficult and we faced some of the same challenges that the stories in this book have shown.
The fact that this team didn’t produce enough results to warrant a continuation of the product line can be held against the success of this team, and I guess it will be true to an extent. One of the vital skills we missed as a team was customer focus and taking hard decisions that would have helped customers faster, and who knows, the results might have been way different.
However, this shouldn’t take anything away from the spectacular success that this team enjoyed, they were truely phenomenal. In addition, given the fact that none of them were from IIT (premier tech institute in India) goes on to prove that individual brilliance or academic credentials are not necessary (and maybe detrimental sometimes) for team successes. I am yet to work in such a high-performing team again, and everytime the extended team members meet, they relish the experience they had working together. Hopefully we will get the chance to see that magic again!