By the time you read this, the Speed Team at IBM will have just about raced right out of existence. It has been a brief — but intense — journey. Last November, during dinner with some members of his nearly 200-person leadership council, Steve Ward, VP of business transformation and chief information officer at IBM, decided that saving time — making decisions faster, writing software faster, completing projects faster — needed “to be much higher up on the agenda.” To the hungry startups that were gnawing at the edges of IBM’s businesses, working in Internet time seemed as natural as, well, sitting through review meetings did to veteran IBMers. Ward was worried that if IBM didn’t reset its clock, those startups would clean its clock.
“One of the things that frustrates me the most,” says Ward, 45, “is the length of time between the ‘aha’ moment and the moment when you actually start changing the organization’s direction, getting it to where it needs to be.”
The length of time between Ward’s “aha” moment and his first action was less than eight hours. The morning after the leadership-council dinner, the Speed Team was born. Ward summoned 21 IBMers and gave them a simple assignment: Get the IT group — a staggering 100,000 people worldwide — moving faster than ever, with a focus on the fast development of Web-oriented applications. It was a huge responsibility. Unlike many companies, in which the IT group is considered a cost center and reports to the CFO, IBM’s IT team is considered so crucial to the company’s fortunes that Ward reports to J. Bruce Harreld, IBM’s senior vice president of strategy and one of CEO Lou Gerstner’s closest confidants. Translation: The Speed Team was going to be operating in the corporate fast lane.
The team’s coleaders — Jane Harper, 45, director of Internet technology and operations, and Ray Blair, 45, director of e-procurement — had strong reputations for pushing projects forward at a blazing pace. After talking to Ward about their mandate, the two leaders decided that the team should have a finite life span — roughly six months. “I think that we will have failed if the Speed Team is still together three years from now,” explains Harper. “Our plan, when we started this, was to come together, look at what works, look at why projects get bogged down, create some great recommendations about how to achieve speed, get executive buy-in, and try to make those recommendations part of the fabric of the business.”
Watch Out for Speed Bumps
Steve Ward built the Speed Team with IBM employees who had led groundbreaking projects that were completed in an unusually short amount of time. Karen Ughetta, 43, an IBMer based in Raleigh, North Carolina, earned a spot on the team because of her work on e-community, a Web-based platform that encourages collaboration among various teams. Gina Poole, 39, founder of developerWorks, a Web site launched last September to help IBM forge stronger relationships with software companies, was drafted for how quickly she’d gotten that site up and running.
Since the group was made up of people who had been associated with success stories, it decided to use those stories to begin its efforts: What were the shared characteristics of fast-moving projects within IBM? “Every day, we do really good things in this company,” says Harper. “We wanted to know why some projects happened more quickly than others. Then we wanted to look at those slower projects and ask, ‘What were the barriers to speed?’ We started calling those barriers ‘speed bumps.’ “
Members of the Speed Team talked about how they had managed to avoid speed bumps in their own projects. Blair, for example, had devised a set of Web-based systems known within IBM as e-procurement. Starting from ground zero in early 1998, he created processes that enabled IBM employees to use the Web to search for lower airfares and to find ways for IBM to work with its partners to ensure that the company was getting the lowest possible price on parts. As Blair was building those applications, he found that many of the rules governing application development at IBM “were bound to slow things down.” Those rules had been created with perfectly good intentions — mainly, to keep the quality of the company’s software high — but few of them distinguished between different kinds of software projects. “One size just doesn’t fit all,” Blair says. “But we had a single process that all applications went through, whether they were simple or complex. We had to tailor the process to each project.”
Blair worked with his supervisors to leapfrog several steps of the official application-development process, and by the time his e-procurement project was one year old, he had moved a remarkable $1.8 billion worth of IBM’s purchasing to the Web — and had saved the company $80 million in the process. This year, he predicts that the company will save about $250 million. The speedy creation of e-procurement has accelerated life in other parts of the company as well. Thanks to e-procurement, the turnaround time for approving purchase requisitions is down from 2 weeks to 24 hours.
Harper was no stranger to fast-track projects, either. Back in mid-1994, Harper had helped John Patrick, IBM’s VP of Internet technology, to build IBM.com, the company’s first Web site. She had also been a key player in developing IBM’s Web sites for high-profile events, such as Wimbledon, the U.S. Open, the 1996 Olympic Games in Atlanta, and the chess matches between Deep Blue and Gary Kasparov. Now, among her other responsibilities, Harper runs the 20-person WebAhead lab, in Southbury, Connecticut, which prototypes new technologies.
The WebAhead lab is itself a prototype for how IBM teams can work together efficiently, seamlessly, and quickly. The Speed Team mined the lab’s culture for a number of its major insights. WebAhead employees work in a single shared-office setup, not unlike that of a high-school computer lab — long tables of several employees arranged in rows. The overall atmosphere is informal, even messy. A sign on the door reads, “This is not your father’s IBM.” The lab’s purpose is simple and liberating: “Our team is funded to do cool stuff for IBM,” says Bill Sweeney, 42, a WebAhead manager. “We don’t have to think about increasing sales of a product line. We just have to think about the next important thing that might hit us.”
In December 1997, the WebAhead group was first to explore how IBM could benefit from instant messaging, a technology more commonly associated with teenagers zapping one another from all over the world than with business. Last year, WebAhead began distributing an instant-messaging client to IBM employees, and before long, 200,000 employees — including CIO Ward — had adopted it as a way to get quick answers from colleagues. “People think nothing of messaging me,” says Ward. “That technology lets me reach down several levels in the company, and it lets others reach up. It’s an important tool that allows me to sniff out a problem quickly.”
All members of WebAhead are passionate about their pet projects, whether it’s IBM systems infrastructure specialist Judy Warren talking about a new wireless-networking setup for the lab or Konrad Lagarde explaining how he and some colleagues are devising a way for employees to use their cell-phones to access the IBM intranet. Lagarde shows off a Sprint PCS phone that can find an employee’s phone number, determine that person’s location, and then send an instant message, electronically or by phone. He says that voice recognition using IBM’s own ViaVoice technology is the next step.
How long did it take Lagarde and his coworkers to put together the system that translated Web data into phone data? “Maybe a day or two,” he replies. “And we went to lunch both days.” Other group members have created animated characters that walk around a Web page, directing users to relevant content (total development time for each character: three hours) and a project called the Video Watercooler, which, when completed, will link WebAhead staffers in Southbury, Connecticut to colleagues in Cambridge, Massachusetts; Somers, New York; and Evanston, Illinois. Instead of forcing users to schedule times for formal videoconferences, the Watercooler will encourage more frequent, informal interactions among employees — brainstorming or simply talking about what they’re working on.
But even people who always drive in the passing lane occasionally hit a speed bump. In late January, that’s what happened to the Video Watercooler project: The servers required to process the hefty stream of incoming and outgoing data hadn’t arrived yet. “It’s embarrassing, but hardware is sometimes a constraint,” Harper says. “We’re waiting for boxes.” Customer needs take precedence over internal requests. After a moment, Harper adds, “We’re making lots of phone calls.” But she doesn’t sound happy about the situation.
Through her work with the WebAhead group, Harper had already unlocked several of the secrets to speed. One such secret: Speed is its own reward. Employees were encouraged and energized when they saw their pet projects being deployed in a matter of weeks, rather than months or quarters. Harper made sure that those pet projects were pertinent to the company by issuing a clear mission that itself focused on speed: “We’re interested in things that help people collaborate faster, message faster, and make decisions faster.”
Harper learned something else from the WebAhead experience: Companies don’t move faster; people do. And not all people, whatever their technical credentials, are cut out to move at the speed that’s necessary to keep pace with Internet time. Which is why Harper is serious about turbocharging the recruiting process for all of IBM’s leading-edge Internet groups, which include alphaWorks, Next Generation Internet, and WebAhead. Last summer, she helped start IBM’s Extreme Blue internship program for software engineers in Cambridge, Massachusetts. This year, Harper will expand that program to a second location: Stanford University’s campus, in Palo Alto, California. There, interns will live together MTV Real World-style in a fraternity house while working on high-profile projects.
Extreme Blue helps IBM reach the most fleet-footed engineers before Internet startups do. After last summer’s pilot in Cambridge, the program is already starting to feed the ranks. By late January, WebAhead had offered jobs to five Extreme Blue participants; several other promising interns had decided to stay in college for an extra year to get their master’s degree. “We get them during holidays and vacations, though,” Harper says.
Fast Talk: It’s about Time
After examining many fast-moving projects, including e-procurement, the Speed Team began outlining what those projects had in common. It then created the “Success Factors for Speed,” six attributes that all successful projects had in common: strong leaders, team members who were speed demons, clear objectives, a strong communication system, a carefully tailored process (rather than a one-size-fits-all approach), and a speed-oriented timetable.
Put simply, the Speed Team found that going faster is all about how you relate to time. If you treat time as a tangible resource, as you do money and people — the traditional metrics of performance — then naturally, you’ll wind up moving faster. “Like most big companies, IBM tends to measure such things as reliability and cost,” says Blair. “We ask questions like ‘How long will this application last? How much downtime can we expect? What will it cost to get it up and running?’ But if you want something done fast,” he continues, “you need to ask different question: ‘What does this save you? What kind of advantage does it give you? How many transactions are being done electronically, versus over the phone or by fax?’ And of course, ‘How long did it take to do it?’ “
So the team started compiling time-saving recommendations in two categories: quick hits that could make a difference right away and long-term initiatives that would require changes in policies, procedures, and perhaps even values. The team’s suggestions, while urgent, were also delivered with a sense of humility. Blair and Harper emphasized that their group was offering examples of what people could do to eliminate speed bumps and move faster. It was likely, they said, that even better ideas would come from other members of Ward’s leadership council and from the IT group as a whole.
“Too often, initiatives are delivered by a voice from above,” says Blair. “You’re asking people who are doing their jobs correctly to start thinking about something new — speed.”
The Speed Team decided that it needed a medium for gathering fast feedback — a democratic forum for soliciting ideas from non-Speed Team IBMers. The group seized upon the Web as the right tool for that forum. In early January, the Speed Team held a weeklong online “town hall” meeting. The goal was to encourage other employees to “open up and discuss what’s wrong and what opportunities exist,” explains Karen Ughetta, the meeting’s coordinator.
Visitors to the online town-hall site were greeted with an audio clip of Steve Ward explaining the Speed Team’s mission and underscoring its high-level support, as well as an essay titled “The Speed Imperative,” which, recalls Ughetta, “described what the Speed Team was all about — and what we mean by ‘speed.’ A lot of people hear that word and think that we want them to keep doing the same thing, only faster, harder, and for longer hours. But we’re really about getting people to change the way that they do things, about blowing up the process and discussing ways to avoid speed bumps.”
Some of the suggestions that began to fill the message boards of the online town hall overlapped with ideas that the Speed Team had already developed. Town-hall participants confirmed the Speed Team’s opinion that many projects wound up in the breakdown lane because of overly rigorous measurement.
“People complained about breaking down 13-week projects into 13 phases and having to produce measurement reports at the end of each week,” says Ughetta. But there were also plenty of fresh observations. “One thing that the Speed Team hadn’t talked about,” she continues, “was how information overload can slow people down. Newsletters, email, and the intranet can create lots of duplication and mixed messages. We discovered, through the online town hall, a need to focus and funnel information to people, rather than pointing the fire hose at them.”
Race to the Finish?
In the early months of this year, the Speed Team began implementing both its “quick hits” and its long-term initiatives. But even the longest of the long-term actions, according to Ward, was set to extend for only 90 days. The best ideas, by design, were those that could be implemented quickly.
Quick hits included things like creating a “speed rating” for employee-performance reviews and getting all leaders, from Ward on down, to articulate more clearly their time-oriented priorities. Long-term initiatives involved addressing the occasional disconnect between finance-department employees who supervise the funding of company projects and those employees who actually run those projects. It’s an age-old trade-off: time versus money. “Often, by the time a project gets to the deployment stage,” says Dan Forno, 49, a Speed Team member and vice president of business information solutions at IBM Global Services, “the money needed to complete that project has been cut. So we wanted to make sure that the finance department was more connected to our projects and to our priorities.”
There were other long-term issues — for example, baseline measurements: How fast is fast enough? “What’s the difference between making good time and making great time, when it comes to getting a Web site deployed?” asks Jane Harper. “Is two months good time, or is two weeks good time?” Forno worked with the IT team’s deployment experts to determine how long it should take, on average, for an application such as a Web site to be rolled out to a group of users within IBM. If you want to race faster, suggests the Speed Team, set some expectations for how long it should take to cross the finish line.
One of the legacies of the Speed Team is a communications program designed to illustrate the power of speed in action. The program features lots of examples of blazingly fast projects that emphasize the importance of pursuing speed through teamwork, clear goals, and work processes that are tailored to the individual project. The central message: In the era of e-business, every company has to move faster than ever before. And IBM, having catapulted the term “e-business” into the mainstream, is bound by honor to remain the world’s leading example of a fast-moving e-business. IBM can’t just walk its talk. It has to run its talk.
The Speed Team will hold its final meeting in June. But its members, along with CIO Ward, are convinced that the end of the Speed Team as an officially sanctioned unit won’t mean the end of its influence inside IBM. “These people will work together for years, whether you call them the Speed Team or not,” Ward says. And by getting executives and rank-and-file employees throughout the IT team to think about flattening speed bumps, Ray Blair says, members of the Speed Team, and those who contributed ideas to it, have begun to think of themselves as “part of the solution — part of the community that comes up with ideas for getting rid of speed bumps and part of the formula for getting things done faster.”
“Our evidence of success is that our changes have been adopted by the organization,” Blair continues. “People have begun to think about the need for speed in their work. We’re no longer necessary. Our job was to be catalysts, and catalysts can’t linger around.”
Meanwhile, Ward is already thinking about the next team that he’ll create from his leadership council. As the clock runs out on the Speed Team, he muses about the many small, scrappy, Internet-savvy competitors that IBM must confront and how IBM can leverage its powerful brand and its global infrastructure to compete more effectively with the competition. It sounds as though perhaps the Momentum Team will be Ward’s sequel to the Speed Team: “Momentum is speed times mass,” he says, “and we need as much momentum as we can get.”
Scott Kirsner (email@example.com), a Fast Company contributing editor, is based in Boston’s North End. He works fast. For more information on IBM’s Speed Team, contact Jane Harper by email (firstname.lastname@example.org).
Sidebar: How to Stay Fast
The Speed Team examined an array of projects within IBM that had progressed more quickly than usual and then identified six shared characteristics that it dubbed the “Success Factors for Speed.” Says Jane Harper, director of Internet technology and operations: “None of our discoveries were great revelations, but we felt that outlining them would help other teams focus on the things that could speed up their projects.” Fast teams have strong leaders. Leaders of IBM’s fast teams viewed their job as twofold: They were responsible for keeping the team focused on its goals and for knocking any barriers out of the way. You can’t go fast without knowing where you’re going and having the determination to get there.
Fast teams need speed demons.
Fast-moving teams don’t just draft talented people; they draft the right kind of talented people — people with a mix of skills, experience, and tenure at the company.
Fast teams need clear goals.
“Team members need ultraclear priorities in order to work fast,” says Steve Ward, IBM’s chief information officer and VP of business transformation. “You need to say, ‘Our goal is to sell $2 billion a month on the Web,’ and then work with our team to achieve that goal.”
Fast teams thrive on fast talk.
Instant messaging, teleconferencing, and videoconferenceing form a foundation for teamwork. An ability to minimize administrative overhead — and to deal with the overhead that couldn’t be eliminated — was also a common thread among IBM’s fastest-moving teams.
Fast teams make fast adjustments.
You can’t have good quality without strict processes. But, says Harper, IBM’s fast-paced projects were staffed with people who tended to act “within the spirit of the process, not by the letter of it. If you’re a smart cook, you don’t have to measure every teaspoon of salt; you just take a few pinches.”
Fast teams expect to finish fast.
“With the right metrics, you’re acknowledging that the entire business competes on speed,” says Ray Blair, IBM’s director of e-procurement. “Can you take a product and get it to market faster than anyone else? That’s what the game is about, every time.”
Sidebar: Faster Meetings
Talk about time management! The members of IBM’s Speed Team were charged with balancing their regular responsibilities with team-related tasks that could very well consume a hefty chunk of their day. So, when it came to meetings, they didn’t want to waste a minute. A set of rules quickly evolved to govern the Speed Team’s gatherings. “The nature of the people on this team is that they’re always thinking about acceleration,” says Ray Blair, the team’s coleader.
Here are the five rules that Blair and his team followed to conduct faster meetings.
Do your homework.
Every meeting required some preparation work on the part of attendees. There were documents to read and issues to consider, so that team members could reach decisions more quickly once they convened.
Although the Speed Team’s mandate was broad, Blair made sure that meetings were structured and that they stayed on topic. Email and other electronic mediums were used to explore possibilities and to bounce ideas off of other team members; the face-to-face meetings were intended to keep the project’s momentum strong.
Make fast work of the peripheral issues.
“Sidebar” matters that arose during meetings and seemed to warrant further discussion were handled later in conference calls by a small subset of the full group.
Don’t mind your manners.
Politeness wasn’t required. “Anyone could just say, ‘Move on,’ or ‘Go to the next point,’ ” explains Blair. “Ninety percent of the time, everyone in the room was already in agreement with the speaker anyway. By allowing people not to mind their manners, we were able to cover a lot more ground.”
Encourage fast follow-up.
Meeting notes would be compiled immediately and posted to a database within an hour, so that team members would have a clear idea of what steps to take next. “You wouldn’t want the embarrassment of being called the Speed Team and doing things slowly,” Blair says. “Everything about the meetings and about the follow-up was designed to move things forward.”