When Teams Break Down, Business Loses - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Enterprise Applications
02:30 PM

When Teams Break Down, Business Loses

What happens when team members don't work well together?

What happens when team members don't work well together? A decade ago, when I consulted at AVS, a company that makes data visualization software, there were multiple ways to access its database. Think about it--a database-oriented product with multiple ways to get and put.

Several years before, two senior managers couldn't agree on an approach to access the database, so they formed two competing teams and implemented their respective ideas. By the time I arrived, the multiple library calls were entrenched in the product, and customers weren't happy because the calls to the database were different. Likewise, the developers were unhappy because it was difficult to incorporate new features into the existing, disparate calls. So they simply kept creating new calls. When my engagement ended, sales were down, staff cut, and the company was trying to recreate itself. It now has new management and a new look for its legacy products.

The competing teams contributed to AVS's stumble. Customers depend on companies to be consistent with their products, and AVS's product was inconsistent.

I've also done some consulting at a large insurance company that has a huge Agile program aimed at unifying all products under one umbrella to let agents sell anything, anytime, anywhere. The project teams at first refused to synchronize their iterations. Some teams wanted two-week iterations, some wanted three-week ones. After several iterations, it was clear the program wouldn't meet the first deliverable, so the program manager mandated that each team move to two-week iterations and synchronize their work. They finally released the first chunk--a month late.

A senior VP estimated the company lost up to $100,000 per business day that the system was late. That's a cost of $2 million for a one-month slip. That's a high price to pay for teams that couldn't agree on iteration length.

Sometimes it's difficult to separate technical teamwork from bad architectural and requirements decisions. But those decisions are part of teamwork, too. When we don't pay attention to teams and how they work, we risk alienating customers, losing business, and being unresponsive to the rest of the organization.

Johanna Rothman is a management consultant and author of Behind Closed Doors: Secrets Of Great Management.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Flash Poll