or some engineers, there's no other way to work. "You can't do big things without teams." To others, teams are "a total waste of time." "When the topic is specific, it is faster to go to the person most qualified to give the answer," a design engineer writes. "Otherwise, it is talked to death and no solution is agreed upon." Whatever your opinion of teams, they're how most design and development engineers carry out their work. Just under three-quarters of our 700 respondents belong to designated teams. But the distribution of our engineers and managers on teams is highly uneven. Only two of the eight vice presidents of engineering reported being on a designated team. Also poorly represented were chief engineers, with only five out of 15 on teams. This is understandable. Top executives aren't often assigned to a development team (though two presidents said they were). Their job is to oversee entire departments-and groups of teams.Well-represented on t eams were software managers, with 11 out of 12 belonging to one.Among our larger groups of survey respondents, 80 percent of senior engineers and 86 percent of principal engineers said they belonged to teams.

For the most part, those same engineers are members of all-technical teams. Only 29 percent belong to multifunctional teams, made up of employees from different departments, and a mere 6 percent participate in multicompany alliances. This suggests that while teams have become the norm in the electronics industry, they remain largely segregated at the middle and lower levels of engineering.

One possible explanation for the continued separation: Managers-especially our higher-level people-are more likely to belong to a multifunctional team than engineers, who make up most of the sample. For instance, 44 percent of the usually higher-ranked principal engineers are on multifunctional teams, compared with 28 percent o f the senior engineers.

Some two-thirds of our readers lead, or have led, teams. The percentage is even higher among the management segment. Eleven out of 12 technical directors have been team leaders and all the vice presidents have, too. So have 10 of the 11 section heads and 20 of the 22 group leaders. It doesn't mean they're on a team now-but there's a correlation between people who have led teams and those at the top rungs of the promotion ladder.

Heading a team allows engineers to demonstrate leadership skills. It calls for compromise, tact, coordination and, sometimes, whip-cracking.

"We essentially had two teams, working at odds with each other," one member of the technology staff told us. "There needs to be a project dictator."

But a paper presented recently at the Portland International Conference on the Management of Engineering and Technology in Portland, Ore., cautioned against dominant team leaders who effectively suppress participation by team members. Effective leaders encourage participation.

Our team leaders encountered challenges at every project phase.

At the startup, this engineer found "finalizing the project objective" his toughest assignment on the multifunctional team that he led.

"Meeting marketing's unrealistic targets" was named by a Delaware engineer, while "delegating the work load" proved to be daunting for a Texas reader.

Several team leaders cited "getting access to resources [people and equipment]" as their top concern.

Once past the initial phases, team leaders ran into other roadblocks.

"Solving problems in the field during final integration with the system" tripped up a Florida team leader.

Others found the mechanical team-management tasks daunting.

An Arizona group leader's project is becoming more typical, as the team is made up of both outside personnel and insiders. His most difficult task was "establishing time lines in coordinating various segments of project between in-house systems engineers and su bcontractors."A North Carolina principal engineer found "coordination of multinationals (North American, European and Asian) over multiple time zones" to be his most difficult challenge. Thank goodness for e-mail. Some companies purposely locate sites in, say, the Central time zone, to allow American team leaders to talk with Europeans as they end their day and with Asians at the beginning of theirs.

"Meeting customer's schedule when they continue to request changes to design features" proved the biggest hurdle for one California project engineer. "Feature creep," of course, is a classic designer's nightmare, one that a team doesn't banish. Having everyone agree on the specs is one thing; getting them to adhere to those specs is quite something else.

Being engineers, many readers haven't had formal training in how to handle "people issues." Our team leaders often learned on the job, on the fly.

"Task: Final build of a 14-processor system with new people," one group leader writes. "Challenge: Train while directing new work and testing complex algorithms-it failed its original objectives."

This Texas chief engineer had to keep his team "motivated despite 'Dilbert' managers."

"Conflict resolution" absorbed a California principal engineer's time, including "deciding what weight to give the opinions of each of the conflicting specialists."That's the polite assessment. One vice president was less circumspect: His job was "keeping the idiots in marketing from killing the jerks in sales or the morons in accounting."

"Interdepartmental fighting" kept one Michigan team leader scrambling, and a New Yorker named his biggest challenge as "communication with management at VP level and above."

"Getting senior management to understand unique program requirements where 'standard' team processes do not help" challenged an Indiana manager.

Lest you think the ball ends up in the management court all the time, engineers share some blame for team snarls. A vice president of engineering o ffers a top-down view of dealing with engineers on his team.

His biggest hurdle? "Negotiating standoffs between hardware designers and software designers."

A principal engineer had to crack the whip in "getting overworked software engineers to spend time on it and get it done!"

One team leader complains that a "key member of the team [is] a prima donna, not a team player."

Technical issues remain, as always, prominent barriers to making deadlines and staying within budget.

This software engineer cites "meeting schedule constraints while dealing with a constrained embedded system" as his chief hurdle as team leader.

Respondents gave mixed reviews to team effectiveness.

The highest agreement came on whether teams "increased the quality of the end product": 70 percent agreed that having software talk to hardware, and having designers understand manufacturing's problems, ironed out kinks along the road. Engineers, at 72 percent, were slightly more convinced of the quality b oost than their bosses, at 67 percent.

Most managers and design and development engineers think teams "saved time." They agreed, also, that teams shortened the design cycle, though managers were more emphatic about it. Close to three-quarters of the design and development managers believe teams cut design time, while 63 percent of engineers saw it that way. The 9-percentage-point difference is one of the sharpest divergences in this question.

Half the sample said teamwork "increased customer satisfaction." But less than half said teams "reduced bugs." Managers, especially, at 37 percent were the most skeptical, probably because they hear about every one of those bugs along the way.

And you still need to persuade engineering that teamwork saves money. Only four out of 10 respondents buy that.

Other respondents cite less-quantifiable benefits.

"Teamwork brought people together, so that even after the project was ended, the members felt cognizant of each other's skills and eager to make use of each other to get insight into hard problems," a software/hardware engineer from Oregon told us in the Web-based "Salary Survey Opinion Poll." "So, it improved the networking of professionals within the organization, and as people left the company, networking outside the organization."

Don't look for teams to solve inherent problems, says an Albuquerque, N.M., design engineer. "Teamwork results when well-trained people are focused on a common goal. Many companies miss the point. They provide team training and downplay individual contributions."

This can lead to "reduced accountability, which can lead to total chaos," he continues. This engineer is skeptical about teams that have been selected from a pool of candidates. "I have never witnessed successful 'artificial' team synthesis. I have seen it occur and be successful when it evolved on its own."

Free Subscription to EE Times First Name Last Name Company Name Title Email address   Click here for your Free Subscription to EETimes Europe