Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

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

Finally, for the last 4 months, I was assigned 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 take my work?

share|improve this question
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 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 at 17:02
1  
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. –  thursdaysgeek Mar 25 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 at 18:06

9 Answers 9

up vote 1 down vote accepted

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.

share|improve this answer

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. Further more, 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 avoid a couple right now, for instance). They still must be done.

share|improve this answer
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 at 14:39
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. –  Dave Johnson Mar 25 at 14:46
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 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.

share|improve this answer
1  
To a naive manager who doesn't know how to read case-studies, perhaps. –  aroth Mar 25 at 22:03
1  
Which is like... all of them, right? In the real world at least. –  Jasmine Mar 26 at 21:58

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

share|improve this answer

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 $$$$"
share|improve this answer
2  
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. –  RemcoGerlich Mar 25 at 20:57

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
Isn't he being asked to document other people's code? –  martin f Mar 25 at 16:15

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.