What does it mean to be a team player? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

开发者_如何学编程

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

We are beginning work on a software project and are hashing out the important details while working on the smaller ones. A few different times big things have come up that will drastically effect the project one way or the other. I am vocal about the way I think things should go and I back my reasoning up with facts. As such I have been labelled as not a 'team player'.

Well, what does it mean to be a 'team player' on a software project? Does it mean to go along with ideas you think are quite bad and will make things difficult in the future? Does it mean to not share opinions? What does it mean?

Edit: I am new to this team as of about 4 months ago and was brought on to work this project.

Being a team player means prioritising the goals of your team before your personal goals.

There are different ways to do this, and raising potential problems early is one of those ways. But being diplomatic about it is often a good idea - you have to consider how other team members will react to your observations and phrase concerns carefully to avoid offending other team members who may take things too personally.

Working as a team does mean knowing when you need to stop arguing and instead make compromises - you can't always expect to have everything go your way. It's important to know which battles are worth fighting (because a wrong decision will make a major impact to your project) and when it's best to back down and let someone else have their way, avoiding a conflict.

This is really hard for me because I am often in the same situation.

What is probably going on is that you aren't recognizing when you are antagonizing someone else.

Their labeling you as not a team player is simply a way for them to tell you that what you are doing is making things difficult for the rest of the team.

You are probably right, but trying to explain your point can come across more antagonistic than helpful in many cases.

In meetings I used to constantly chant under my breath "KYFMS", keep your mouth shut. It gave me something to concentrate on rather than the incorrect information being presented. Often I could then take care of it outside the meetings one-on-one which was sometimes more successful and also avoided wasting the time of people who may not even care.

Sometimes the problem even got resolved without my input. Also I can always mention it the next day.

Not arguing the point too much helps too. I would listen to a fellow programmer pose a design question, think about it and respond "Okay, here is the answer to your question, and here is the actual redesign that you will need to actually make it work". They would go and implement the answer I'd given them, but in the back of their mind they could see the advantages of the better way I'd outlined and would often end up making the decision to take that path themselves.

Another case might be where you have been thinking through a problem, solved all sorts of sub issues and reached a conclusion. Someone else says "Let's do it this way", you say "No, that won't work, we have to do it this way". This is completely unproductive because they are not in your frame of reference any more. You actually have to backtrack and lead them through your discoveries. Let them suggest something you've already realized will fail, then say "But what happens in this case".

It all comes down to the fact that good programmers are almost always very bad at reading other peoples feelings. Practice trying to figure out what the audience is thinking. Try to read their body language (It can take effort for us--for most people it comes naturally). You might even let them lead the conversation and just pose questions to poke them in the right direction.

If this answer sounds reasonable to you, you might find a good explanation of why in The Programmer's Stone

How are you vocalizing your objections? Are you taking over meetings and being overly dramatic on choices? Are you being passive-aggressive in how you object so that it is at the last minute you have a problem but not earlier when there was a much better chance of it being accepted? Are you merely saying, "I don't want to do it this way," and not offering alternatives so that it is seeming like you are merely obstructing rather than being productive in getting the project done? For example, one could look at the U.S. Congress time and time again and see where one political party prevents the other from getting anything passed.

There are probably another 101 objections I could list as scenarios where you could be the "squeaky wheel" and thus you aren't part of the team that doesn't ask questions, fight back or resist for lack of a better word. To the extent you have facts, are these accepted facts by everyone or are there statistics in this that make some assumptions? For example, I'm not sure there are many people that would argue that the U.S. Federal Government has some created a lot of debt. However, if someone were to say that the debt would be gone in 5 years because aliens will come down with trillions for the American government, that may not quite go over so well even though it couldn't be proven that there is no chance of such aliens existing, right? Yes, this is may seem like an over-the-top example that is rather extreme, but how would you argue that such aliens don't exist? If you can't prove that, how would you show that I'm wrong with this assertion other than waiting till 6 years later and then saying, "See, the aliens didn't come after all?"

Patrick,

Being a team-player is all about contributing your creative energies, so that you are offering the best combination of skills, experience and knowledge. Some times that means going against the grain, but if you are supporting your ideas (as you already stated,) then there is nothing wrong with what you're doing.

Unless I'm missing some integral part of your team's working agreement, it sounds like you're suggesting alternate ideas (with supporting reasoning) and that is exactly what I'd expect from my team members. Like Mark suggested, always be respectful with the ideas you contribute.

If your project manager(s) or peers are not receptive to your ideas (especially ones that differ from the current plan,) your team doesn't sound to be looking for team players...