How to handle being the new guy with not much to do?

Question

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.

Answer 1

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.

Answer 2

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.