Menu
Menu
Teaming with Talent

Teaming with Talent

A couple of years after he stopped working for Digital Equipment Corporation in Canberra, Bruce Kay fell critically ill in the US and was admitted to a Seattle hospital. By then Kay was working for Microsoft, but it was not his co-workers there who visited him in hospital then took him into their care when he was released, still as weak and helpless as a baby. Rather, it was a group of Massachusetts-based former colleagues from Digital, fortuitously working on the West Coast, who drove him around and tended his every need until he was well enough to cope on his own.

Kay may have broken his ties with Digital, but the bonds he'd formed with the US members of the virtual team he'd worked with for years had been forged in fiercer fires. The links between the former team members remain so strong today that many are still close friends. Most of them still network together and several of them are now working closely with Kay at IBM, where his Information Management Consulting company is delivering services.

Now that's a team. And with so much evidence of the strong bonds between the team members it comes as no surprise when Kay says that during its time at Digital the team was so effective it seemed to achieve "more than the sum total of the individuals" involved. Some teams are like that. While others pull themselves apart from within -- their individual members battling for power and position at the expense of the kind of unity that can achieve results -- high-performance teams work miracles. Like the characters in the Theodore Sturgeon novel More than Human, members of truly effective teams seem able to band together and form a kind of gestalt that can achieve almost supernatural things. And, of course, this should be the goal. It only makes sense to create teams when the group of individuals acting collectively can achieve more than the team members ever could acting alone.

To find out why some teams work brilliantly while others self-implode, CIO ventured inside four organisations to examine their best performing teams and to try to determine the magic ingredients that made them so.

Digital Equipment Corporation

The team Kay worked on, now disbanded, was formed in Canberra in 1986 at a time when Digital's business in the national capital was booming. In ramping up its software support staff Digital moved a "bunch" of employees to the federal capital. All newcomers to the city, the team members initially seemed to spend almost as much time together after hours as they did at work. "One of the things that happened was that as we moved to Canberra and they were trying to help us to find accommodation and such, we all stayed in a group of flats that were close to each other," Kay says. "We saw each other socially quite a lot in the beginning."

But it was much more than time spent socialising that made the team so effective. For a start, Kay says, the manager who put the team together was canny enough to avoid choosing people in his own image. "There was quite a wide variety of personalities and abilities and ages and we certainly had a lot of difference; we weren't all the same."

Manning teams with people who are very different by nature sounds like a ridiculously simple recipe for success, but it can make an enormous difference --Kay knows from direct experience. When a business process re-engineering project he once worked on was going poorly, management got in a consulting team from Melbourne to analyse the team members' personalities.

"They said to the woman who was running the team: ‘Well, one of the things that you've done is got everybody in your image, with the same personality'. They made a few small changes to the team, by just shifting a couple of key members out and getting a couple of other people who had completely different personalities in, and all of a sudden the project became successful," Kay says.

There were other factors behind the strong bonds that developed at Digital and the team's correspondingly high levels of success. Like the fact that the manager was prepared to let team members act autonomously, trusting their judgement implicitly. Like the hard projects where things went wrong, which gave the team members the chance to show that they cared enough about each other to bail each other out. ("Different people experienced high levels of stress at various times," Kay explains. "Whenever one person in the group was struggling, all the rest would do all these little subtle things to take pressure off that person until they came back around again.") Like the fact that Digital was a very good company to work for, with strong human relationship values -- values Kay says seem to have been lost in the late 1990s. And like the fact that instead of breaking up the team once the initial project was completed, Digital had the sense to keep the team together over the long term.

"One of the things I think that is important that we don't realise is that we pull people together for teams for a project, and there's all that ‘Norming and Storming' and all of that sort of thing that happens at the beginning of the project," Kay says. "And maybe the project is successful and maybe it isn't, but there's a lot of learning that happens between the individuals about how to work with each other. Then organisations tend to break the teams up and they never get together again. I think one of the things that happened in that group at Digital is that we worked on quite a series of projects over a long period so we got better and better at working with each other."

All up, Kay stayed with Digital for seven years, and at that he was one of the first to leave -- turnover was extremely low because of the strong bonds between team members. Indeed, he says "love" is not too strong a word to use about the bonds forged all those years ago.

Centrelink

When Government legislation was passed giving Centrelink just 12 months to change the way pensions were paid, the agency faced a huge task that ultimately required it to process more than 300 million triggers.

General manager major projects John Wadeson says the core technical team of eight operating as coordinators of the massive Payments Cycles Project had to work with about 25 application groups who were doing the bulk of the work. "It was a major IT project with a set end date determined by government legislation. It was a pretty massive job, but by and large we kept it together over all those application groups and got it all into the system on the one day, which was really remarkable in some ways, and with hardly a glitch," Wadeson says.

IT stakeholders meetings held every three or four weeks, sometimes over dinner or lunch, brought key stakeholders together and kept everybody informed. Team members travelled extensively to Adelaide, where the main testing area and user assurance facilities were located. Such coordination was critical, he says.

But Wadeson largely attributes the team's success to having the right balance of technical and project management skills. Of considerable importance was the fact that Centrelink kept two of its best architects on the team monitoring the whole project from beginning to end. "Usually if project teams get involved you'll have a couple of your leading IT people involved at times, but this time we actually had one of them in particular being part of the key implementation team." That team member was able to keep the different application groups constantly up to the mark and ensure the whole thing fitted together, Wadeson says.

"The thing about IT projects is that you're only as good as your slowest and weakest link . . . you can't afford to have anyone not up to the mark, because right through the project, if you've got to have the code ready for testing, everyone has to have it ready," he says. "That is one of the really difficult things where you've got large numbers of groups working on the one project. Coordination is critical, and you've got to find a way of demanding your timetables are met. That means a lot of persuasion and a lot of very active monitoring of what's going on -- you can't afford surprises."

Team leader Allen Kruse, whose job it was to drag separate IT development areas "kicking and screaming" into the fold, says he chose his team from those with the best specialist skills available --but also by carefully picking people he knew could work together. "Mostly success came from choosing the right people," Kruse says. "I virtually hand-picked them. They had to be able to work with me, and they had to be able to work with each other. And also I had to be able to trust them to do the work they had to do without my constantly interfering or looking over their shoulders.

"It worked very well; but I did have some rather exceptional people there," he says.

Telstra subsidiary NDC Limited

When NDC Limited project director Ron Slatyer was given the task of implementing SAP R/3's materials, projects, sales and financials across Telstra's network-building subsidiary, he started with a database of prospective team members' business strengths.

"We started with a database of the business strengths of these people that set out what sort of people we needed. And we did that in this manner. We worked out what was the business need -- in other words, each of the individual bits of the business, whether that's a design expertise or a project management expertise, or a delivery of projects expertise or a financials expertise. And we brought that into the team."

All those chosen for the 120-person project (not including 37 trainers) had to be able to work in isolation, since the teams were isolated from the everyday business. They had to be prepared to work solid hours of full commitment, focusing only on their area of expertise, apart from those few whose role was to look between functions in terms of business or in terms of application design.

NDC agreed to start the Bacchus project after contract negotiations at Christmas 1998 and went live on the first of July this year. Team leaders for the sales, materials, finance, projects, infrastructure and training teams all reported directly to Slatyer as project director. IBM GSA was the head contractor and Deloitte ICS was the SAP implementer. That meant Slatyer had to build a team of teams. "That was my role. I had to build the teams, then I had to get them all to work together and deliver, both in a functional and infrastructure sense."

Slatyer set up a structure and a process that made sure people could understand their small piece and how it fitted into the larger jigsaw. He did this via a series of planned functional meetings, planned leadership meetings and planned functional leadership meetings. Overriding all was a governance board to ensure the total integration for the business worked. "So there were people, a structure and a process, which was then closely monitored. And it was closely monitored in this way: it was monitored for its success, but it was also monitored for team performance, individual performance and the individual's good health."

How did he do that? The grey hair on his head speaks volumes, Slatyer says, but essentially it meant taking notice of and managing team members' personal and interpersonal requirements. "We set in place a professional approach not only to the way in which the business would look at those things, but to the way in which we socially looked at those things as well. We supported the business need by social functions, for example.

"We built morale from nothing to a lot; we built business expertise from a lot to start with to these people exceeding their limitations. And we set that up in an environment that was supportive in a HR sense and supportive in a business sense by providing them with the correct and appropriate tools to work with.," Slatyer says. "We had a zero tolerance approach to mistakes in that we let every mistake be a learning point. And we allowed the emotions of people to be displayed openly, frankly and to be dealt with at the time, with a high level of positive conflict resolution in place."

Slatyer says personnel were also allowed to explore and expand their intellectual capacity while they tried to sort through the business issues. "They worked in an environment that allowed that intellectual expansion to occur and they took advantage of that to promote their own self-awareness, both as a person and as a professional. And they grew from that quite dramatically."

CSC

In August 1998 a small team within CSC was charged with building a knowledge base and capability in applications maintenance (legacy systems support), as well as providing the foundations for CSC to more actively and successfully pursue applications maintenance outsourcing work in Australia.

As part of that work CSC put in place the foundations to set up and develop high-performance, self-directed maintenance teams, using a methodology developed by Peritus Software Services of Boston, Massachusetts. The Peritus methodology aims to optimise the productivity of maintenance teams by building them into self-directing units; providing them with a process that is specifically tailored to their work; and by supporting them with tools, techniques and extensive training.

Bruce Debenham, CSC's manager of application outsourcing, says the process has produced clear productivity savings, although it's too soon to quantify them.

Overall in Australia CSC's five trainers (who also work as a self-directed team) have so far trained 12 teams between them. Before the training, teams were typically hierarchical, each with a manager, team leaders and "gurus" with overall responsibilities. "It didn't lead to ownership from the individual team members; it allowed passing responsibility up away from the individual team members. And in some ways it stifled the career development of the more junior members," Debenham says. "It's fairly common in the IT industry that junior staff members get frustrated with hierarchies where they can't get to be team leader until someone dies."

Now senior CSC staff members act as mentors and coaches rather than team leaders. Junior members get exposure to all phases of a project, have opportunities to be leaders of small phases and get involved in what the company calls squadding -- that is, working closely with others.

"We have better cross-training of staff; early exposure to greater experiences for junior staff; and we have better change control, with the team taking responsibility rather than someone outside the team," Debenham says. "And I guess from the customer's point of view, we were able to move to giving them guaranteed deliverables that define prices, which they were much happier with than just working on time and materials."

Now, that's teamwork.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about A Consulting TeamCentrelinkCSC AustraliaDigital Equipment CorporationGSA GroupIBM AustraliaIBM GSAIT PeopleMicrosoftNDCSAP AustraliaTelstra Corporation

Show Comments

Market Place

Computerworld
ARN
Techworld
CMO