Evangelizing Mainframe
Print Email

Are Teams a Good Thing?

We’re in the middle of the Rugby World Cup and everyone can see that playing as a team brings more success than just having talented individuals wearing the same color strip. Wouldn’t it be great to apply those kinds of teamwork ideas to the mainframe staff at an organization. Wouldn’t it be great to see improvements in staff performance and enjoy greater success all round?

If two men take 20 days to build a garage, how long will five men take? This simple problem implies that having more people is better. But what if it said, “how long will 100 men take?” That’s our first rule of teams—that size does matter. If each person needs to link to every other person in the team, then the more team members there are, the number of connection needs to increase exponentially. And that begins to have a negative effect.

The thing about a rugby team is that they have a clear goals and boundaries. Every member of the team knows exactly what it is they’re trying to achieve. And yet, research suggests that for many teams in an organization, team members are quite vague about the boundaries.

It’s well known that the more a rugby team practices together, the better they play in a match. Is the same true of a business team? Do they perform better when all get to know each other well and can relax in each other’s company? The research seems to show that they do.

In rugby, you want to unleash your faster runner to get to the touchline and score a try. You want your heaviest and strongest players to push through the opposition’s defense. But some work-based teams value being a team player so highly that people are prepared to self-censor contributions so they won’t disrupt team harmony. As a consequence no one will be prepared to ask those difficult questions, no one will take the ball and run round the blind side creating a massive scoring opportunity.

And what about the team captain? Should they lay down the law or should they go with the consensus? As soon I have a better answer than “it depends,” I’ll let you know. Leaders are usually people who are prepared to tell you what they think in a difficult situation—whether that’s the best thing to think or not.

But in the real world, the world of computers and programming, how do we get the best out of our IT team? Let's have a look at some examples taken from the book "Quiet: The Power of Introverts in a World That Can't Stop Talking" by Susan Cain. The book describes the results of an experiment carried out by Tom DeMarco and Tim Lister to see whether programmers should be put together so that they could interact with each other like a team. They found that programmers with 10 years of experience were no better than people with two years of experience. And the salaries of the half who performed above the median average earned around 10 percent more than the half below the median—even though they were twice as good. Programmers whose work had no mistakes in it produced that work in less time than people whose work was “buggy.” The clue came from the fact that programmers from the same company performed at the same level; it was something in their environment. The top performers, overwhelmingly, worked for companies that gave their programmers the most privacy, personal space, control over their physical environment and freedom from interruption.

Many people like groups because they are useful for brainstorming sessions—coming up with innovative ideas. Cain's book describes an experiment performed by Marvin Dunnette to see whether people came up with more ideas when they worked in a group (and were stimulated by others) or when they worked on their own. 23 out of the 24 groups in the study produced more ideas when people worked on their own than when they worked with others.

Steve Wozniak, Apple’s co-founder, was stimulated to work on his ideas for computing after a meeting of the Homebrew Computer Club. However, after that meeting, all his initial work was done alone. All the ideas, the deep thinking, were done without interruption by others, without having to attend meetings.

Now, I’m not arguing that teamwork doesn’t work, because clearly in sport it does. And clearly in business it does, too. What I am arguing is that we shouldn’t think that teamwork is the only way to work. To get the most out of our mainframe programmers, we need to give them space, and time to think about the problems we’re facing and to come up with new and innovative solutions. Next time we’re interviewing and ask someone whether they’d describe themselves as a team player, perhaps we should be pleased if they no, they’re an ideas person.


Trevor Eddolls is CEO at iTech-Ed Ltd, an IT consultancy. A popular speaker and blogger, he currently chairs the Virtual IMS and Virtual CICS user groups. He’s editorial director for the Arcati Mainframe Yearbook, and has been an IBM Champion every year since 2009.

Posted: 10/20/2015 12:30:30 AM by Trevor Eddolls | with 2 comments

Print Email

Please sign in to comment.

Sign In


Comments
You're quite right, Kathy. I was focusing on the need for space and privacy when carrying out work. Certainly, mainframers not only need to share what they've done, but also make it clear just how much mainframes can do.
Posted: 10/20/2015 9:52:01 AM by Trevor Eddolls
Trevor, I would agree that Mainframe developers need time to concentrate and simply put their heads down to solve a problem. However, I think it is IMPERITIVE that mainframe programmers share their results with colleagues who are not Mainframe programmers. Otherwise, the walls within organizations stay in place, critical knowledge of the application environment is NOT shared within the organization and people with varied skills do not broaden their perspective. There are times when a team needs to be gregarious, and times when the players need to be efficient. Information exchanges are a critical element in building effective enterprise solutions.
Posted: 10/20/2015 8:56:49 AM by Kathy Bazinet

Join Now!