RE: Team Player Definition

[Chuck Martin <CMartin -at- serena -dot- com>]

> -----Original Message-----
> From: Seigler, Sherri A [mailto:sherri -dot- seigler -at- eds -dot- com]
> Sent: Tuesday, February 01, 2000 8:59 AM
> Subject: Team Player Definition
> 
> Please, people... all they want out of a team player is 
> somebody who can
> attempt to get along with everybody, not create conflict, and 
> maybe every
> once in awhile do something that is beneath their skill level 
> (like take
> minutes of a meeting or go get the coffee).  Why do you guys have to
> overanalyze everything?    Yes, everyone has their own skill 
> level and yes,
> they are expected to pull their part as the team.  They are 
> not expected to
> do something that another person with a different level of 
> skill sets does.
> But if they can learn something and help in another area out of their
> expertise, it should be done.  
> 
OK, I was going to try and stay out of this discussion. I guess I've failed
at that goal. The phrase "not create conflict" got to me.

I have never been in a development team where conflict was not the order of
the day. Everyone involved has their own goals, and those goals typically
conflict. That's not to say that everyone doesn't also have similar goals as
well, such as releasing a quality product. But the VP or Director is
sensitive to schedule and wants deadlines met, and also is close to company
stock price and profit figures. The project lead is the one who develops
deadlines and schedules and strives to look good. Programmers want to write
as little code as possible to met specifications. QA folks want a bug count
of zero. Technical communicators, as user advocates, want usable software.
And so on.

When I am involved on a project and see poor design, I will indeed create
conflict. I will raise the issue, open a bug report, and push for
resolution. That resolution will not always be to my satisfaction, because
the goals of all these other players must also be met. But I'll also make it
clear that programming shortcuts and poor design hurt the user, makes more
work for both users and the development team, and costs both the company and
the customer more money in the long run.

To stand by and do nothing (to "not create conflict") in the face of a
shoddy product is not at all being a team player, it's being a lemming.

-- 
Chuck Martin
Sr. Technical Writer, SERENA Software

"People who use business software might despise it, but they are getting
paid to tolerate it....Most people who are paid to use a tool feel
constrained not to complain about that tool, but it doesn't stop them from
feeling frustrated and unhappy about it."
          - "The Inmates are Running the Asylum" 
            Alan Cooper


***********************************************************************
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. Any unauthorized review, use, disclosure or distribution 
is prohibited. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original 
message. 
***********************************************************************