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?

  • "project that was on the backburner for a long time, and I am tasked with kick-starting it, starting with "documenting stuff"" I know that feel, bro. Literaly what I'm doing right now.
    – RyanS
    Mar 25, 2014 at 14:12
  • 1
    @JoeStrazzere I meant I am committed to make clear on next ventures that I am at my full potential working with peers on the same project, not sitting in a corner writing documents.
    – ravemir
    Mar 25, 2014 at 14:58
  • 3
    If you're feeling any pain from the folks at TW, let me state "i feel your pain". TW has to have some of the least friendly/constructive, hypocrites in the SE family.
    – Martin F
    Mar 25, 2014 at 17:02
  • 2
    I think I worked with someone like you. On a team, he thought I should do the documentation, because he didn't like it. Well, neither do I! I'll do it if it has to be done, but I'll push back if you're just trying to get all the fun parts for yourself - that's not teamwork. Mar 25, 2014 at 17:47
  • 3
    OP meant 'need for team interaction' not 'teamwork'. It's perfectly ok to prefer tasks with team interaction. He was not asking to slack off.
    – smci
    Mar 25, 2014 at 18:06

10 Answers 10


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.

  • I think this is (ironically) to the point: I should stick to past experiences (and why it worked then) and what benefits will it bring to the table (both accounting my satisfaction and that of other colleagues)
    – ravemir
    Mar 26, 2014 at 10:55
  • @ravemir: most employers don't give a **** about how happy you are, so coming across as "Hey man I don't feel stimulated doing this" is not at all persuasive. In general you have to persuade people in their terms, not yours.
    – smci
    Mar 26, 2014 at 14:00
  • @smci I would say many employers do care about your happiness... so long as it doesn't cost them something. (Then it depends on your company culture) But yeah all business interactions your goal is to satisfy the other person, hopefully in a manner satisfying to you. So if you want to shift gears, you need to make them want you to shift gears, otherwise you'll just be pressured back into what they think will benefit them the most. (Sad fact, very few people enjoy documenting. At best the accept it as a necessity to avoid later suffering. It's also a great place to learn though...) Dec 22, 2014 at 17:53
  • @RualStorge: in other contexts, perhaps, but in the context that some poorly-understood legacy POS needs to be documented, and somebody's gotta do it...
    – smci
    Dec 22, 2014 at 18:08
  • @smci I agree, I was making the point it's like countless other things that very few enjoy, but understand will save them grief later. When it falls behind someone unfortunately must sit down and get it done. The good news is doing documentation is sometimes the best way to learn the ins and outs of an application. Dec 22, 2014 at 21:22

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.

  • 1
    I think I phrased the question wrong: how can I say that I work best in a team environment without sounding like it's an excuse to get someone to take my work?
    – ravemir
    Mar 25, 2014 at 14:39
  • Also, I don't have a particular problem with documenting stuff (especially not software projects): it's the fact that it's a stale, abandoned project that makes it unmotivating. Basically, stare at this old box nobody cares about and describe everything you see.
    – ravemir
    Mar 25, 2014 at 14:43
  • 5
    @ravemir: Every company has demotivational projects on the back burner. That tends to be specifically why they are on that back burner. And, as you have found, they are perfect to hand off to interns, since no one else wants to do them. Many times projects do not require a team. I think your best bet is to succeed at this crappy project, and when you are finished point out that while you are obviously capable of single-person projects, you greatly prefer the team environment. Mar 25, 2014 at 14:46
  • Thanks for advice! Part of me is just afraid I am losing my flow for the last months, I guess...
    – ravemir
    Mar 25, 2014 at 14:54
  • 1
    My question was actually referring to how to articulate this aspect of myself: that I work better with peers, even if they are not working on the same specific task as me (same project, or hell, even the same subject will do)
    – ravemir
    Mar 26, 2014 at 10:39

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.

  • LOL, to a manager... "pair programming = half the resources"
    – Jasmine
    Mar 25, 2014 at 21:58
  • 1
    To a naive manager who doesn't know how to read case-studies, perhaps.
    – aroth
    Mar 25, 2014 at 22:03
  • 1
    Which is like... all of them, right? In the real world at least.
    – Jasmine
    Mar 26, 2014 at 21:58
  • Depends on the aspirations of said company. I come from a place where software development is not a glamorous career, but I still uncovered a couple of places where it was an adopted practice. Curiously, some of those examples also cared for employee satisfaction more directly (premium equipment and environment, snacks, conference attendence, etc.). I admit they are rare, though...
    – ravemir
    Mar 27, 2014 at 17:30

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...

  • Unfortunately, I think that is the case: I feel unmotivated because my job looks both boring and irrelevant. Having a peer would help because it would provide me with someone to discuss the work to be done and feeling involved overall. Is this naive/selfish?
    – ravemir
    Mar 25, 2014 at 16:34
  • A bit. Having a conversation of "what is it we REALLY need to do?" is something you should be able to have quickly with your boss, and not something that should require days and days of someone else's time. It comes down to the cost - if someone is being your partner on this, then the company has doubled the cost of the manpower. The cost has to be worth it to the company, and not just you. If two people can work for X days, where it would take you alone MORE than 2X days to get it done, then it's a useful trade. If not, then it gets debatable. Mar 25, 2014 at 18:00
  • Also - into everyone's life some boring, useless work will fall. The best answer of all is if the work is REALLY useless - get it done fast with the minimum that is absolutely required. Then at least it has taken up as little of your time on this planet as possible. Mar 25, 2014 at 18:01
  • So, if I understood your point correctly, if I can't understand the point of my work, I should be trying to clarify this as much as possible with my boss, right? Optimally, this should result in motivation for understanding end goals more clearly or a mutual agreed steering of the project towards something more useful.
    – ravemir
    Mar 27, 2014 at 17:35

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 $$$$"
  • 3
    I agree 100% with your assumptions, and I'd add to the list of things he can do: actually kickstart the project. Find out who actually wants this project and why, and make those people your "team mates" (just talk to them every chance you get). Think of what would really need to be done to get the project off the ground, and get them in motion. Write down more than you normally would so you have documentation to point at. At worst you may find out why it's necessary to start with documenting stuff. Mar 25, 2014 at 20:57
  • Nice answer and comments. Also, yesterday I found out a document I partially wrote back in January might actually be useful again, as someone managed to convince my manager to take an approach I proposed to him back in January. Finally, finding someone who wants to take this with me might be challenging on my environment, but it's definitely a good idea.
    – ravemir
    Mar 26, 2014 at 10:39
  • @RemcoGerlich: +1 That's an important point which I completely missed :-) Mar 26, 2014 at 11:05

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.

  • Loved the agile methodology, and I think it might help me get past the "wandering" rut. I think I might just do this. Thanks, it might not answer the original question, but it's still helpful.
    – ravemir
    Mar 26, 2014 at 10:23

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.

  • Hi and welcome to The Workplace. Would you mind expanding on how this is a different approach from the other suggested solutions and why it will work out? Brevity is generally accepted in answers, but longer, more detailed answers will see more appreciation from the community.
    – CMW
    Mar 29, 2014 at 7:11

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.

  • 2
    Isn't he being asked to document other people's code?
    – Martin F
    Mar 25, 2014 at 16:15
  • Good point...so if that is the case, anyone else SHOULD be able to do it...editing
    – Zibbobz
    Mar 25, 2014 at 16:48
  • That is kind of it: part of the project involves a PHP portal, developed in-house years ago. But the whole is a VM firewall appliance, developed by a FOSS community.
    – ravemir
    Mar 26, 2014 at 10:33

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .