How do you expose your need for team interaction without sounding like a slacker?

Question

I have been working at internships on and off for the past 2 years, and at least twice I have been in the situation of having my own project to myself.

The first time it happened, I was doing something I like a lot more (software development) and had a superior who I could count on to help with issues at any time.

After that, I got a new project where I was doing stuff on my own, but the project involved more people, so there were opportunities to collaborate and help out on tasks that were not initially assigned to me. Even though I had gripes with the way things were run (not very organized) the fact that I felt I was learning and was part of a team made up for it.

However, for the last 4 months, I have been working on a project that was on the backburner for a long time, and I am tasked with kick-starting it, starting with "documenting stuff". Unlike my first experience, however, documentation is not something I particularly enjoy doing (especially of work not done by me or anyone in my vicinity) and my boss always seems to have something more important to do.

I am committed to stop this from happening again, and I have the "stuff I enjoy doing" part covered, but every time I try to think of a way of explaining I work best with a peer, I keep imagining people will think I am trying to slack off on other people's work.

How can I explain to management/contractors that I work best in a team environment without sounding like it's an excuse to get someone to do my work?

Answer 1

Keep it real simple. A lot of the comments here are abusive, overanalysis or marginally offtopic. You don't need to articulate a manifesto for pair programming, etc. However you do need to distill what your point is, and succinctly make the case to management why it's in their interest to give you such assignments. (They don't care if you're having fun or not).

• You mean 'need for team interaction' not 'teamwork'. It is perfectly ok to prefer tasks with team interaction, rather than sitting in a corner working solo on a project which is considered unimportant.

• Your complaint was not that you personally considered writing documentation menial, but that the company considered that task unimportant and you wouldn't get much recognition. Also as you say, you find documenting other people's work less satisfying.

• So when you talk to management, you want to say something along the lines of:

> The project assignment I most enjoyed was a team project where I could collaborate and help other (more junior?) people.

>I felt I learned a lot (specifically what? team psychology? project management? how to mentor? specific technical things? etc? - You need to be clear what you learned and make the case to management why assigning you that sort of thing is good for them, not just fun for you.

You don't want to just say something vague and slackerish-sounding like: "I enjoy working on tasks not initially assigned to me." because that makes you sound hard to manage.

So what's your point?? Boil it down to terms management will care about:

• "I thrive on mentoring junior people"?
• "I found I'm good at project management"?
• or what? You need to figure that out

You want to prepare for this conversation a little. Figure out your points, make them real concise, then bounce them off a friend or mentor to check you're getting your point across.

Answer 2

Put simply, "documenting stuff" happens a lot. Documentation is an important part of software development (funny link about software documentation), so it is best to learn how to do it early in your career. Furthermore, the best way to handle these kinds of projects (which from what I have seen is a common occurrence) is to pour through it and document what it does.

As to your specific question, I think you are missing the point. You should not be trying to find a way to get management to have someone else do your job. As you progress through your career, people will see that you are that person that avoids real work like the plague. Your career will be filled with tasks that you do not want to do (I am avoiding a couple right now, for instance). They still must be done.

Answer 3

You could speak with your manager and express a desire to trial pair programming, perhaps.

From your description it sounds like your current organization isn't following any particular/structured development methodology (such as scrum, or more general agile development processes). You can use that to your advantage to avoid "sounding like a slacker".

Approach it along the lines of "I've been doing some research on different development methodologies and I think it might boost productivity if we were to adopt pair programming. Would it be okay if I trialed this approach for a few weeks with <name of your preferred peer>?". Then instead of a slacker, you come across as someone who is 1) interested in helping the company be more efficient/productive/successful, 2) knowledgeable about the industry at large and 3) willing to experiment with new things to see if they work. All of those are good things, particularly if you're looking to step up from 'intern' status.

Answer 4

I think you need to have a clearer explanation on "why". While there are cases where pair programming is considered the ideal setup, it isn't often connected to the needs of documentation. And being assigned the work of documentation cleanup is fair work in the software industry. It's generally not fun, and not glamorous, and I don't know anyone who loves it, but it is necessary work in some environments.

So - I think you need to answer for yourself - what is the benefit a peer will provide? Would this be someone who has knowledge you need? Someone with a different skill set who can help with more well-rounded, higher-quality output? The answer lies in what isn't getting done, or isn't getting done well because you don't have the resources (time, skills, knowledge, access) to do it?

Unfortunately "interest" is not one of the things you can cite as a reason for needing a partner in the effort. Being bored is part of working, and just because you don't like the work or don't find it interesting in this moment is not a reason to avoid doing it. If that is really the only thing that you lack, you're going to have to find a way to motivate yourself to get through the boring times... although it is fair to ask - if the documentation work becomes never-ending - when the scope will be finished and when you'll be able to move on to something more fun.

The other trick is to be able to ask for something that isn't too hard to deliver. While having a tech writer to proof your work may be a possibility in a place that has a real investment in people with writing skills, in a company with only a few (or no) tech writers, this is a real battle and not one you are likely to win. However, asking for someone from QA to give your work a review, or another engineer to make sure you covered all angles - is a fairly easy request in most teams...

Answer 5

You write "backburner for a long time, and I am tasked with kick-starting it, starting with "documenting stuff"" and I read "unimportant, no one really cares, doomed from the start".

Breakdown of my argument (take this with a grain of salt):

• "backburner for a long time" -> Important things tend to get done. If some task sticks around for a long time in the backburner, there is something wrong with it. Either it's not important or it's boring or everyone knows that getting their names associated with it is a certain career killer.

• "I am tasked with kick-starting it" -> Important things aren't handed to interns. If they are important, the best people on the team work on them. It's just too dangerous to risk failure because someone with not enough experience or knowledge works on it.

• "documenting stuff" means "do something. I don't know what or how; you'll figure it out. And if you don't then you're obviously incompetent, so I should fire you".

If my assumption is correct, then no amount of team work will save you.

So what can you do? Here are some suggestions:

• Since the project is doomed from the start, you can make it a learning experience.
• Try to learn how to ask questions and write documentation. It won't save the project but it will be a useful skill for you later, no matter what.
• Learn how to compile and present information. Start with an overview, break it into details. Get a feeling how to break down complex things. One of the most important skills in software development IMO: Being able to explain something insanely complex to a manager.
• Learn new tools: Word processors, reporting tools, mind maps. Anything that might help in your project will also always be a nice bullet point on your CV.
• Improve your language skills. You want me to write documentation? There is this nice Oxford English course for $$$$! No? Maybe that one for $$$? Nice! Another point for my CV.
• Learn to ask questions. If someone can't explain something complex, you need to be able to ask the right questions. That includes learning patience and working with difficult people (= people with a lot of stress, little time, little patience, awkward or no social skills or simply no time to be nice). How do I get that information out of Mr. X without wasting his time?
• Do you already know everything that you need to know to write useful documentation? If not, then you'll need to learn to arrange meetings, find out the correct people to invite, etc. It's a kind of team work, too.

What you shouldn't do:

• Whine. They pay you money for this so suck it up. And nobody likes a whiner.
• Spend 99% of the day surfing on the Internet. That will only get you into trouble.
• Stop enjoying your work. That would be just a waste of your time.

What you might do:

• Argue. If you have good reasons that this project is a waste of time, maybe you should create a presentation of what you learned and tell people. "I just saved the company $$$$"

Answer 6

Create/be your own peer?

Use the agile approach, pick a piece of documentation work, break it down into tasks till you have enough for a sprint and focus on delivering/finishing work in small steps.

Working alone requires a lot more self discipline and it is easier to "wander" and not be focused on what has to be delivered. Something like the agile methodology can help keep you focused and you will be getting experience valuable for your CV when you apply for a new job where you actually work as part of a time and don't sit in the corner mumbling to yourself.

I find it frustrating producing documentation for the people with the checklists when said documentation will probably never be read, has very marginal benefit and where it does have benefit the documentation belongs in the code or in the UI.

And don't get me started on the XML comment noise produced en masse in code to state the obvious when your methods and classes are properly named.

Answer 7

Ask for diversification of your way of working.

You work on too many projects on your own and want to change to experience teamwork and interaction with peers.

Answer 8

By the sound of it, 'kickstarting' the process of code documentation means 'no one really wants to do this, so please, PLEASE get started so that others can follow along'.

I keep a document of all my code changes updated with each new code build we do, and I know my co-worker does the same. Simply put, this is a task you must do, and quite possibly a task ONLY you can do (for whatever reason your boss might think), so there are a number of reasons you might need to do it alone.

Answer 9

I think you are "overthinking" this. The point is that you want to be good at your job, and your manager wants to be good at his job.

So you need to get information you consider relevant to the manager's job to him. You are thinking of how to sugar-coat it.

The manager metrics involved here are the following:

A and B together get more things accomplished than A and B on separate tasks. That's the metric for whether to let people join forces.

The difference between what A will accomplish together with B over what A can accomplish alone is more worth than B's salary. That's the metric for whether it's not easier to just let B go.

You have relevant experience for that. Getting that information timely to the manager helps him employing you more efficiently. He might still take chances, and you need to make sure that you are not turning your predictions into self-fulfilling prophesies by turning them into a "told you so".

The problem is that it's not always clear that there is an actual A that will prefer this working style. There are people who are bogged down by teamwork without that being caused by having to take up slack.

So it is a good idea finding someone who'd actually appreciate the idea of teamwork here.

Answer 10

Once you have a reputation for working hard, it's much easier to not be labeled a slacker or being lazy when asking to work on a different type of project or environment. Most people think of lazy as someone who doesn't work hard at anything. You're just asking to work on things you enjoy. Good employers should always look to get people who enjoy the tasks they need to get done, but it's rarely a perfect match for everyone. You picked up the slack and took on a project that nobody else wanted. They should consider themselves fortunate that you're doing it, there's no reason to expect you want this type of work all the time.

There was a project you liked and now you have one you don't like. There's nothing wrong with letting your boss know you would like the opportunity to work on more projects like the first one. Hopefully, they could find people who would rather write documentation or at least consider this with their next hire.