Social Networking Lessons – A class and a movie

I am pursuing a mini-MBA program from UW, and one of the classes we had recently was about social networks and how important they are for career growth and getting things done. One of the most basic lesson was that you should have open-ended network (networks where your people in your network do not know each other) when you are in brainstorming/information-gathering mode because it helps in faster information flow and diverse ideas, but should have a clique-like network (where your friends/network nodes know each other too) since they help in better execution.

Interestingly, I got another lesson on social network (a more subtle one) when I was watching a totally unrelated movie: Never Been Kissed. In case you haven’t seen it, the story is about a reporter who enrolls in her high school again to report undercover about today’s high school, finds it incredibly tough (again) to break into the network of  pretty girls and handsome boys, falls for a teacher and is then asked to shred him to pieces in her article.

There are the scenes when the protagonist fails to get into the social network (a clique) she wants to desperately get into, and has to get her brother’s help to get into one. The way her brother helped her get into the network was fascinating: he gets into it by being a natural at getting into such networks (he was part of such a network in his school), and then shows everyone how the protagonist is way cooler than him, and thus creating enough buzz for her to be accepted in a few days (of course this was a movie!).

This is very typical of a clique network: it is very tough to get into one of these if you are an outsider. One way of getting into these is to create (or revive) a link with one of the members of the network who can then help you get into the network, but this works very slowly. In workplace, you can find this phenomenon at work when there is a high-performance, well-knit team, and a new person gets hired or (worse), a new group needs to be part of this team. It is very tough to get these two to work together well, and many times it causes frustration for the new person/group. I can vouch for it from more than one experience. Managers can help create such a link first and slowly the new person/group can be accepted in the clique.

Do you have any experiences with such behavior?

Reading and thoughts on world-class teams – III

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!

Reading and thoughts on world-class teams – II

(Reposted from my anandoned blog)

Read some more, and found some parts very interesting. For example, the author contends that a working group is way more productive and useful to the organization than a pseudo-team. According to the definitions used by the authors, a working group is when each of the members work on their own strengths/skills and the sum of individuals is equal to the whole. A pseudo-team is when the members think that they are a team though they are not (because they lack one of the important ingredients of the team: small size, common purpose, challenge, complimentary skills, enthusiasm, clear performance goal), so their efforts in trying to behave as a team is actually detrimental to even their individual effectiveness, so the whole is less than sum of the individuals. He contrasts a working group with a potential team, and says their current contribution to be similar, but the potential team (as the name suggests) has the potential to be a real team and then the effectiveness will go up for this potential team.

This reminds me of my experience with one of the teams in my previous company. We were supposed to make a networking device (actually the software for the device) and the team consisted of 7-8 members, all eager and enthusiastic, very smart guys, who wanted to make a difference to the world. We used to indulge in lots of brainstorming and knowledge sharing sessions, and of course in writing code needed to deliver the software. We were definitely a potential team, and the effectiveness we had was much more than other such groups in the organization (there were 3 such groups, involved in 3 different product lines of the same suite). We were innovative all the time and everyone was trying to help others out even when that meant spending more time at office, again some of the vital ingrendients of real teams. However, the software we delivered was not enough to keep our customers interested in the product, or the company in black. When the company started going down, no one wanted to leave the company even when the writing was clear on the wall, primarily because they enjoyed each others’ company so much.
From the definitions from this book, we were on the verge of being real team. And when I analyze that situation given my understanding today (based on my experience with successful companies) and of course reading this book, we were missing at least two vital ingredients:
1. Common performance goal: We were always enthusiastically working on our and others’ work, but we were never given a charter of (and we ourselves never figured it out) what we were supposed to shoot towards, what was the common binding goal for all of us. As a result, we kept on working technically cool stuff, and kept solving business problems with good intentions but bad plans, and could never have a rallying cry for our common goal.
2. Complimentary Skills: Almost all of us were techies, and none of us every tried to recruit (or pick skills) for business understanding and what it takes to deliver a product (and it is not technology if you are wondering!). If we had, we would have immediately realized that our efforts were not helping the company in any tangible way and we could have done something about it.
3. Leadership: The book talks about leader of the team, and that it is necessary though not sufficient, and the fact that in exceptional teams, at various times, different members can play leadership role. In our team, even though we had designated leader, he was more of a manager than a leader, and we never thought we should take lead in solving problems.

Don’t mistake it: this team was one of the most effective teams I have seen, and I have seen many teams in last 11 years; this means it had many things going for it. The above points just illustrate what could have catapulted into the high-performance teams that the authors talk about. If only we had ready the book 7 years back!

Reading and thoughts on world-class teams – I

(Reposted from my abandoned blog) 

This is a great book:

The Wisdom of Teams: Creating the High-Performance Organization
by J. R. Katzenbach, Douglas K. Smith

I have read only first couple of chapters and stories, but I am already getting a feeling that I am going to like every single word here! Basically the book talks about what takes to build a great team and the authors’ hypothesize that giving a great challenge and setting very high performance standard is a must to get a good team and then set out to show by examples and logic to prove it (there are other facets of the team they talk about but I liked these 2 the most). In general, I like to think I am good at helping teams work well and I have my own thoughts about why some teams work and others don’t, and so this reading is also going to help me in understanding and contrast their thoughts on the topic with mine.

I have at least two great experiences working with teams that were exceptional in performance, teamwork, and cohesion, however neither of the teams were associated with successful market experience, and I wonder why. Hopefully this book will help me unravel this. I hope to post some of those lessons learned from here and would be very interested in listening to what others have to say about those.