Co-operative Unit

Rapid Fire Question - What comes to your mind when I say “Co-operative unit”? I was curious to know what people would come up with and tweeted this question. Below are the only 3 responses I got:

1. A team located in the same premises, cooperative bank, a team cooperative with each other (vipsgupta)
2. Football (lnsimha)
3. Amul (sdhanasekar)

I was expecting “Team” as an answer.

Over the years, I watched many teams perform. Some excelled, some merely existed while the rest fell asleep. What is a Great Team made up of? Unity? Collaboration? Strict Manager? A Great Team is made up of Great Individuals who believe in Team Work.

Couple of months ago, I was chatting with a friend who said something like this: “I want to hire a great team” My response was: “You can’t hire a great team, but you can build one”. Building teams is serious business today. We may solve millions of business problems, but if you leave one people problem unsolved, that is good enough to bring down entire business. Here’s a sneak preview into few good/bad/ugly teams.

Real life example: “Solo Ownership”
Solo Ownership team consisted of team members with sole ownership for anything and everything

Key features of the test team
a. Each tester owned a module based on his experience and knowledge of products
b. Not a single tester looked into someone else’s module [even if his module was tightly integrated with some other module ]
c. If a tester found a bug in a module other than his own, he would not report it. He would not even mention it to the original owner [The attitude was “it’s not my problem”]
d. If a reasonably responsible tester found a bug in a module other than his own and reported it, he would be reprimanded. His reporting manager would ask, “Why are you spending time on someone else’s module?” The other module’s manager would ask, “Why are you testing our module. We have our own test team to do that”.
e. Testing happened in isolation most of the time
f. Integration/System testing happened at the end of the cycle during which severity 1 bugs poured left, right and centre.

Real life example: “Young Entrepreneurs”
Each one in this team felt young and believed in entrepreneurial thinking. It comprised a mature set of individuals who thought not just about getting their work done, but helping others to get their work done too.

Key features of the test team
a. Every tester was a primary owner for one module and secondary owner for another module.
b. Every tester reported bugs in any module of his choice as long as he completed testing his module within stipulated time.
c. Testing happened over the shelf – people walked to almost anyone in the team or outside the team if they had questions or concerns
d. Integration/System testing started pretty early in the testing cycle.
e. Job oriented trainings - mostly conducted by members internal to the team to facilitate quick learning curve for new hires in the team.

Real life example: “Mind your own Business”
This team comprised mostly of senior testers with several years of testing experience in their kitty, yet behaved like a bunch of egoistic people. There were a few good people, but tried hard to appear bad because good deeds weren't respected. In fact, good people would often be taken for a ride.

Key features of test team
a. Each tester would do what he liked – mostly after threatening his reporting manager to quit if things don’t improve [by the way, this happened just before the end of each quarter during which bonus numbers would be decided].
b. If critical bugs were found early in the test cycle by a colleague, some team members would say “Dude! It’s no big deal. You are doing your job. After all, that is why you were hired”
c. If a cosmetic bug was missed and customer reported it, team members crucified the corresponding tester and ask, “Were you sleeping? How did you miss such a simple bug? You should get your eyes checked” in a mocking tone.
d. Any delay in dropping builds to testers was OK, but deadline was NOT negotiable.
e. It was mandatory to work extra hours every day. Anyone who consistently spent more than 14 hrs a day in office was a rock star tester and a dedicated team member [Notice the word “spent”]
f. Every problem reported by the customer in any tester’s module meant his bonus would be reduced by 20%. Five such problems and zero bonus. Simple Math.
g. Testers attend trainings so they can sleep for a while and occasionally shout from the top of their voices to show off that they are more intelligent than the rest.
h. And there is no end to this story. It goes on and on …..

Real life example: “We are Family”
Truly a family. There is no distinction between programmers, testers, managers, technical writers and other immediate stakeholders within the organization. Everyone was important and was encouraged to make some unique contribution. Each team member worked closely with rest of the team to meet commonly set objectives. These objectives were directly aligned with organizational objectives.

Key features of the team
a. There was no single rock star team member. All were star performers and pushed each other to excel and perform better.
b. Every complex activity happened in pairs or in groups – which encouraged group learning and on the job training.
c. Team members met at regular intervals to discuss the state of the project they were working on to ensure everyone is on the same page.
d. Programmers highlighted risks pretty early in the life cycle and testers would test early builds to provide immediate information to them.
e. Product owners wrote/re-wrote/reviewed requirements in detail at the beginning of any project and reviewed/modified them periodically with customers and engineering teams.
f. Customers were given monthly demos of working features to solicit early feedback.

Closing comments
While writing this blog post, I wrote a little section called Outcome for each team and how those teams excelled or disintegrated. During review, I realized everyone who hears about these teams knows the outcome. Why bother calling names? Let's bother about building teams. Eh?

My ex-manager Dipankar Roy had tremendous influence on me with regard to team work. His belief in team work helped him build not just extraordinary teams, but amazing professionals as well. He once said “Any team is only as strong as its weakest link”. It doesn’t matter how many are star performers, how many won quarterly awards or how many excelled. Even if one team member is slow or not on par with rest of their crew, the entire team slows down and heads downhill. The key to any strong team is to empower ‘weaklings’ to become star performers. Remember, these so called ‘weaklings’ are not on par with the rest simply because they don’t know that they don’t know. You read it right. They don’t know that they don’t know (MOSTLY). The moment, they are nurtured and valued, they’ll outgrow the best of star performers. Empower people to transform as stars. Whether they shine or become dust is their choice.

Regards,
Parimala Shankaraiah

P.S.
Weakling is an offensive word. The reason I used it here is to emphasize how people who are slow/passive in the team are considered almost worthless by their immediate leads/managers. These very same weaklings can deliver beautifully if mentored by true leaders who believe in people power. Some leaders create magic with people. They value each person’s interests, ambitions, goals and help align team goals such that every team member feels respected and contributes to the team. Only true leaders can do that.