Login | Register
The Engineer's Place for News and Discussion®


Electronic Components

The Electronic Components Blog is the place for conversation and discussion about analog/mixed signal, discrete & power devices, processors, interface & logic, passives, and memory. Here, you'll find everything from application ideas, to news and industry trends, to hot topics and cutting edge innovations.

Previous in Blog: Is a Post-PC Era Feasible?   Next in Blog: Will Solar Photovoltaics Become Grid Competitive?
Close

Comments Format:






Close

Subscribe to Discussion:

CR4 allows you to "subscribe" to a discussion
so that you can be notified of new comments to
the discussion via email.

Close

Rating Vote:







2 comments

You're a Team Player, but What About the Other Teams?

Posted September 14, 2011 10:10 AM

So you're responsible for developing the firmware for the latest iteration of your company's hot product - or maybe you're doing the hardware upgrade - and you've always worked well with others on the product team. But what about those people on other teams? Are they writing checks your team can't cover? Are they making unreasonable delivery date promises to the C-suite or to customers? How often do you end up scrambling to cover another department's over-promising? How do you manage unreasonable development schedule changes?

The preceding article is a "sneak peek" from Electronic Components, a newsletter from GlobalSpec. To stay up-to-date and informed on industry trends, products, and technologies, subscribe to Electronic Components today.

Reply

Interested in this topic? By joining CR4 you can "subscribe" to
this discussion and receive notification when new comments are added.
Power-User

Join Date: Mar 2011
Location: Ground Zero of the Pompous and self important....Washington DC
Posts: 387
Good Answers: 7
#1

Re: You're a Team Player, but What About the Other Teams?

09/14/2011 10:53 AM

Every place I've worked such changes and features had been agreed upon prior to the start of the project. Otherwise you are faced with the impossible task of trying to develop something that can cover every possible situation someone might dream up.

If someone from other groups changes these without consulting anyone as to IF its even possible, Someones higher ups need to be going to someone elses higher ups or even someone higher up the ladder.

This is setting up the company to appear to be one that can't deliver on its promises.

Reply
Associate

Join Date: Apr 2009
Location: seattle
Posts: 47
#2

The other teams need to be part of a bigger team.

09/21/2011 6:34 PM

When I got started in electronics, I worked in companies that were so small that most coordination was done using informal conversations.

But then I switched to a larger group. I wasn't doing electronics any more, but I learned a lot about how a larger organization can stay coordinated. We used a nested team structure with coordination meetings that emphasized consensus-based decision making. How well it worked depended on how well all the participants knew what their responsibilities were and stood up for their group in the meetings.

I have worked in traditional corporate settings where I didn't have a clue how coordination and decision-making took place at the higher levels. But in this group, all staff were expected to be familiar with these mechanisms, and were trained on them. The nested group structure was key. Each group had to have an I/C (In-Charge) and that person was responsible for representing his or her group at the (usually daily) coordination meetings. And each coordination group, in turn, had one I/C who was responsible for taking any unresolvable issues up to the next level and try to get them resolved with peers representing the other larger production groups in the organization. It was an intense communication process, and could break down if someone, at any level, failed to communicate something important to the I/C or at a meeting.

So when coordination fails and bad things happen, it could be due to:

  1. Lack of, or breakdown of, a workable coordination structure.
  2. Lack of staff knowledge about how to use that structure.
  3. Communication breakdowns for all sorts of reasons.

To resolve a particular issue, you have to know what caused it, or you'll waste time fixing things that weren't broken.

__________________
l_e_cox
Reply
Reply to Blog Entry 2 comments
Interested in this topic? By joining CR4 you can "subscribe" to
this discussion and receive notification when new comments are added.

Previous in Blog: Is a Post-PC Era Feasible?   Next in Blog: Will Solar Photovoltaics Become Grid Competitive?