Soft Skills for Being a Team Player

This blog is in response to a survey comment. I got some great responses recently, and I’d especially like to thank Nevin in Ireland for some great topic suggestions! His specific question was, “What personal skills you should develop to fit in well within a big organisation or a team of writers?” I’m here to help (note: that might be skill #1!).

Most of the “skills” you need to work on any team are not so much skills as behaviors or habits. If an organization is large enough to employ multiple writers, that usually means that it has large jobs that require them. Sometimes those jobs require multiple writers working on the same project, sometimes the writing team has specific tasks parceled out to them. Either way, team playing requires a mix of social skills to ensure that the work assigned is carried out smoothly, professionally, and as/when the customers need it.

Let me help

Edith Keeler: Are you afraid of something? Did you do something wrong? Whatever it is let me help.
Captain Kirk: “Let me help.” A hundred years or so from now, I believe, a famous novelist will write a classic using that theme. He’ll recommend those three words even over “I love you.”
–Star Trek, “The City on the Edge of Forever”

Work in large organizations is usually delegated by management, but there might be individual tasks on a project that you can help your fellow writers with, like looking up a particular fact, making a phone call, proofreading something that needs to go out soon, or writing particular sections of a document while your coworker is “in the weeds” on a different part of the project. If you’re not as busy as your coworker at the time, by all means, make yourself available to help.

And while you’re helping, try to find it in your heart to do the work willingly, with an eye toward making the end product and the team better. Helping while grumbling is not a good way to build your reputation. Helping with enthusiasm (not bragging, mind you–see below) makes others more willing to work with or help you in the future.

If you are busy when you’re asked for help, you can (politely) ask if someone else can help, ask what the deadline is so you can help later, or work with your team leader to rebalance priorities so all the team’s work is done in a reasonable amount of time.

Avoid silos

This amounts to being generous with your knowledge of people, processes, or products. I have worked with individuals who believe that if they’re the only one who knows X, then that ensures their job security. Personally, I think that creates more headaches for you and the organization. If you’re the only one who knows something, that creates a single point of failure if you’re ever out sick or on vacation.

Keeping your knowledge to yourself is also not very helpful. Yes, it is easier sometimes to just do something rather than teach someone else how to do it, but I look at it from the lazy man’s point of view: if I teach others what I know or how to do what I do, there’s less chance that they’ll come back to ask me again because they’ll be able to do it, too.

Be willing to ask for help

If you don’t know something, look it up. If you can’t find it, find out who does know the answer. You might not care for the person you have to ask; that’s beside the point. They have the knowledge and you don’t. Ask politely and thank the individual for sharing once they’ve given it to you.

Communicate needs, roles, and responsibilities clearly

This skill is especially important if you’re working a multi-part project like a proposal, technical manual, or other big documents. Sometimes it helps to lay out a team charter stating who is responsible for what so that there are no gaps or overlaps in the final product. If there are questions about who is responsible for a task, go back and have that discussion. If there is a dispute about the roles and responsibilities, work with your team leader to iron out any difficulties with an eye toward keeping things running smoothly and professionally. You’re there to get work done, not mark territory.

Respect the chain of command

I failed on this spectacularly once or twice. This means doing what your leader(s) ask you to do and following the processes laid out for doing the work. If you encounter a problem resulting from your directives or processes, speak directly with the person responsible for making the decisions, and then respect their decision.

If you “know” what their answer is likely to be and you don’t like that answer, don’t go over their head to their superior in the hopes of getting the answer you want. If you have the discussion with the responsible person and the answer is not to your liking, politely request that the matter be elevated up the chain of command…but use this tactic wisely and sparingly.

Are you upset because someone is not doing something the way you want it done or because you believe that their decision creates serious safety, financial, or legal difficulties for the organization? If it’s the latter, by all means, move your issue up the chain; if it’s the former, suck it up and wait until the day where you get to make the decisions.

Follow up

This is a hot button for me, but I’ll try to keep it short. If someone asks you a question or makes a request of you, be certain to a) acknowledge that you have received the request and b) follow up and provide the answer. That means if someone sends you an email or text, it’s not enough to make a mental note of it and get back to them when you see fit. Take the time to respond to the initial request, even if your response is, “I am busy right now, but I will respond to you by [X time/date].” And then, of course, answer the request.

Be honest about assigning credit/blame

This should be straightforward, but it’s surprising how often it happens. Accept praise or thanks for the work you did. If you worked with others, acknowledge their contributions.  If others did the bulk of the work, be certain to point that out to whomever is giving out the compliment/reward. And for goodness sake, don’t take credit for work you didn’t do and don’t try to blame someone else for something you screwed up. It’s called integrity, and it will serve you and your reputation a lot longer and better than a quick-hit reward for one tiny project.

Do your best

Doing your best is related to integrity. In the end, the best way to be a team player is to do the best work you can. Maybe you’re assigned work you would prefer not to do. Do your best anyway. Take the time to wordsmith, proofread, or organize your work if it were your favorite thing to do. Your efforts will be appreciated and you are more likely to get better work in the future.

Be polite

To sum up, working on a team requires not so much a specific set of skills as a set of manners. Being considerate of others and your organization will help you go far toward being a “team player.”

About Bart Leahy

Freelance Technical Writer, Science Cheerleader Event & Membership Director, and an all-around nice guy. Here to help.
This entry was posted in leadership, personal, reader response, workplace. Bookmark the permalink.

2 Responses to Soft Skills for Being a Team Player

  1. Larry Kunz says:

    All of these are excellent. The one I like best is “Let me help.” Our manager has worked hard to position our InfoDev team as the ones who stand ready whenever anyone in the company needs help communicating something. I think it’s been a key to our success.

    As to the Star Trek reference: if Kirk’s prophecy is right, then (in our timeline) the “Let me help” classic will be written in the next 10 years or so. Maybe he erred when he said it’ll be a novel. Maybe it’ll be the book you’re working on, Bart.

  2. Bart Leahy says:

    🙂 Interesting notion. However, the rest of the exchange goes like this:
    Edith: Centuries from now? Where does he come from–uh, where will he come from?
    Kirk: Silly question. Want to hear a silly answer?
    Edith: Yes.
    Kirk: A planet…circling that far left star in Orion’s belt. You see it?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.