So I am working on a small Project at my company, I am a mere trainee engineer (halfway through a Software Engineering degree), where we are developing an intranet - based project management and people management system - it incorporates Employee appraisals, personal skill management and development and so on.

Ive been working on this project for a little while, under the direction of a more senior engineer and there has been another trainee working on it too.

However soon, a big contract is coming up and the other two have been press-ganged for some of the work, which will tie them up for a long, long time.

This leaves me alone to work on this (really fun and full of learning) project alone. Dream come true! Or is it?

I've been worried about how I'm simply going to manage the work of three people, are there techniques, tools I can use? The more I think about it, the more intimidated I am (but still relishing the idea of a good challenge).

I have to think about planning, diagramming, release notes, test specs and my own hallways testing (where I grab a random person and say "break it!"), not to mention the actual programming work!

So in short, how can one person adapt to taking on the workload of three people?

  • 3
    If it really takes the workload of three people then unless you're also allowed to take at least three times as long you just can't do it. There are only 24 hours in a day, and you shouldn't work much more than 8 of them for any long stretch of time. Commented Apr 26, 2013 at 10:06
  • This would be better on Workplace since people in other professions can have the same problem.
    – Blrfl
    Commented Apr 26, 2013 at 11:12

3 Answers 3


Make sure you get input from the more senior member regarding security. Employee information is not public record.

Here are some time savers:

Management Brains - Are they aware this started as the 3 person job and is now down to one? Someone has to do the math and adjust.

Existing applications. There are a lot of ways to build an app, but some of your coworkers are going to return to this project (formally or informally) and review your work. Try to use some of the best practices they've already included. The reasoning is part: Don't reinvent the wheel, they may have addressed needs that your infrastructure and/or company rules require, don't let their personal bias towards certain techniques/frameworks cloud their judgment of your work.

Requirements Adjustment - the app you're building could probably be bought off the shelf, so make sure you understand what your company needs that the other products don't offer. Make these your priority and adjust the other requirements along the way. You don't have to include all the bells and whistles they wanted upfront.

Team Overhead - You will have some advantage of not working with a team. You don't have to sit in meetings and debating your decisions. This will save time, but you do lose the input from what may be better devs/two heads are better than one. They may not be on the project, but do what you can to get some code review even if you have to treat them to lunch.

Time, Energy and Resource Management - Figure out when you perform the best and schedule the difficult programming tasks for those times. You will feel a little drained, so use those times to do some of the mundane administrative tasks. Don't forget social niceties and treat your hallway testers like gold. Listening to them talk about their cat is NOT a waste of time. Be the person they will take their time to help even though they have a full inbox.

Planning is good, but you have to get something built. Do the work and make plans, but don't spend too much time between coding. Good luck with your first app.


If you mean that the distinct types of tasks were first divided among three, I suggest you request a weekly session (several hours) with the senior engineer to discuss progress, issues, ideas. It would be very unwise from the company standpoint to let you do it all alone, regardless of your level of expertise.


This could be difficult.

I think planning is your key. Do you have a project plan that the three of you are working to?

If not, I would suggest you come up with one before your colleagues jump ship. At the very least this will be a list of all the tasks you need to do on the project. The more detail the better (up to a point - but just saying "develop such-and-such a screen" is probably not detailed enough). Also include things like documentation and plans.

This is the top priority.

You should go through every task on the list and satisfy yourself that the time allowed for the task suits you. Its no good one of your colleagues estimating a day for a particular task, if its something you know nothing about and would likely take you a week. Also be aware that developers tend to be optimistic about timescales - since you say you have little experience in this area you will likely fall into this trap. Unfortunately the main thing that will help you there is experience, but some "rules" that spring to mind could be:

  • nothing takes less than a half-day. Even if its a one-line code change. Because you'll lost the time elsewhere
  • however long you think it'll take, double it (this isn't one that I use because it cannot stand up to close scrutiny, but it may help you starting out)
  • if a single task takes longer than a week, you haven't defined it well enough. The reason for this is simply that if you have a 20-day task its near impossible to say with any certainty that you're 75% complete.

Depending on how important it is that you fit in with existing standards, you should add tasks (for other people) to review things like documentation, test plans and of course code. And you should add tasks (for yourself) to refactor your documentation/plans/code following these reviews.

If there are certain aspects of the project that you simply cannot do, or cannot do within a reasonable timeframe, or need training to do, say so.

Do not budget to work evenings or weekends. If you do this, and you slip, then you have no hope of making up the lost time. It may be that you feel the need to put in these extra hours, but you should use them to play catchup. Keep them up your sleeve, as it were.

Make sure your boss knows about this new plan, and is aware that delivery will take x weeks/months longer. If they want it more quickly, its up to them to either sort more resource or to descope parts of the project. This is important because if you don't communicate these things to your boss, they will be expecting you to deliver things when you're nowhere near ready.

Lastly, keep on top of your plan. If you are starting to slip, make sure you are the first to know. Now, whether you say anything to anyone or keep it to yourself will have to be a judgement call. If you're confident you can get the time back, then there's probably no point saying anything.

Bottom line is this: don't let yourself be stitched up. If you find yourself missing deadlines, your only defence will be if you can say, "Look, I highlighted this as a risk x months ago."

  • Has saying "look, I highlighted this as a risk x months ago" ever saved anyone's job/reputation in the real world? Commented May 1, 2013 at 18:44
  • @AmyBlankenship so what would you do? It's not particularly about losing your job, it's about you doing everything you can to make the project succeed. But often (and especially on larger projects) there is only so much you can do before you become dependent on other people. The sooner your boss knows this, the better. And if they choose to do do nothing.....well, you did your best.
    – PeteH
    Commented May 2, 2013 at 6:55
  • Yes, I am still trying to figure out how to deal with this. One of the reasons I stay where I am is that one of the problems it does not have is people pointing fingers. But I don't expect this will be the last place I work. Commented May 2, 2013 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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