I was hired at the end of April to fill a role for project that is just now starting to ramp up. The first two weeks on the job I spent time completing administrative tasks and various new-hire hr requirements. After that, however, until this week there was not much for me to do but wait until I was needed as a project contributor. I periodically asked our project leads for work or ways to contribute, but was simply told to wait it out and study up on documentation. I guess my question is, what is the best way to remain productive during times like this and demonstrate value to the company? I don't want to come off as unproductive to coworkers passing by, but also don't want to pester my superiors for work and come off as someone who can't create value (which is especially hard a a new hire). I realize the answer might be industry specific, but there has to be some way to properly handle genuinely not having much to do. If this question is too broad I apologize! Thanks!

Edit: This is no longer a problem, but wanted to know in case this happens again in the future.

  • 5
    I always used to tell the new hires to enjoy the relative calm while they go through the new-hire activities, because 4 weeks from now, when the chaos and panic kicks in, they will be looking back on it as the good old days :) Jun 10 '15 at 18:59
  • As this is no longer a problem: how did you sit it out?
    – Pieter B
    May 18 '17 at 7:16
  • @PieterB I took the advice of HLGEM (accepted answer) and studied the project's documentation and the project it was replacing. This was extremely helpful in the long run May 30 '17 at 13:48
  • Why is "study up" not considered productive? There might be a LOT to learn. Dec 15 '18 at 15:50

This is the time to go in depth into any existing databases you might be planning to use for the project. Really get to understand the stucture and, more importantly, the meaning of the data. It also might be the time to go through code for other related projects not only to get a feel for how they design and code but also to start building a memory bank of what stuff means.

If you have users at your work location that you can talk to, now is the time to really start to understand the needs of the business and how they will eventually relate to what your project does. Talk to them and spend some time observing how they work.

If your project is in some way a replacement for another project, look at what that project does and what underlying assumptions you can find. Look for documentation of earlier projects and requirements documents for the upcoming one. Find out what problems you are trying to solve with the new project and why they are important to the users.

If you have competitors in the same business, check out what you can of what they are doing. What features are they selling? Think about what can make your project stand out over them.

Do some thinking about testing and how you can effectively design tests or if you can support QA in creating test cases for them. If they have them already, they read over them.

Work on building relationships in the organization. Find out who is the expert on anything you might need. Find out who you go to for differnt kinds of problems. Make friends. Find out what people do and how they approach their work. Get out of the dev world and see what others in the company do especially if you are not in a dev only environment.

If you provide apps or software for people outside your organization, spend some time learning what those types of users want. Read their professional journals or go to the websites where they hang out and listen to what they are complaining about or wishing they had. Start to understand their perspective.

  • One element of things to "study up" may be the Office Apps (Outlook or other emailer, etc.) that you basically know, but could know better -- I've been trying to solve some annoying issues with Styles/Lists in Word, and Outlook leaves me cold, so I've been trying every week to explore those more too. Not part of the "core" system of what you're hired to do, but an integral part of the interfacing with the rest of the company. Mar 13 '19 at 14:25

First, you have to realize that "study up on documentation" is legitimate work. It may be boring and not much fun, but it is probably necessary for you to do and ultimately good for your productivity in the long run. You're not wasting time, you're learning, and they're paying you to do it.

As long as you make it clear to your boss when you're done with whatever assigned task he has given you, then there is not much more you can do. If his answer is "go read another manual", then go read another manual.

Of course reading manuals is only the start to learning. You then have to apply what you've read about to make it stick better. Instead of just reading a manual, sit down and try to use whatever the manual described. Unfortunately you don't say what these manuals are about or what your job is, but go play with the equipment described, write some code, set up a test, or whatever. Then go to your boss and say something like "I've read the Dominator-2000 manual, then hooked it up to the frommulator and got it to babulate. I couldn't get the variable grommulus to work at first, but hooking it to the fribomatic worked. I think I've got a pretty good grasp of the Dominator-2000 now. What do you want me to do next? I think I could interface the Dominator to the test platform for the new project now.". It's hard to say, but maybe even this is what he's waiting to hear.

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