I'm working as a software engineer / web developer intern in a start-up. After discussing with colleagues, I just realized that I am given unrealistic deadlines by my intern supervisor who is also the developers' manager.

He asked me to do a gantt planning to balance the workload in May but it had to be done by the end of the month. However, I just wrote specs last week (after he asked me to schedule) and I realize now that it's not realistic.

In 17 days worked, I am supposed to do :

  • a complex back-end, which involves deploying resources while leveraging git history to a specific store, while using several external services.
  • a simple front-end for users to interact with this back-end.

I am not giving too many details about the project as this is very specific but it is worth noting that it's an important project for the workflow of the company (correctness of data is crucial).

All should be thoroughly tested and deployed.

How do I know when deadlines are not realistic and how do I deal with it?

  • At the beginning of the internship I expressed my concerns about general project-management as no specs were written and he expected me to recall every detail in every conversation we had (some were 2 hours-long talk) with sometimes contradictory requirements. I managed to at least get that right but I did not have the opportunity to express this particular concern as he is on a business trip right now. Besides I don't know how to approach this! Commented May 14, 2014 at 16:53
  • 7
    This is a startup. A lot of things will be unrealistic and you'll be expected to work the hours necessary to make them happen. That's one reason I couldn't work in a startup! Commented May 14, 2014 at 16:53
  • 4
    You are doing this as an intern? I hope its a paid internship, and they are not just taking advantage of you as free labor. Commented May 14, 2014 at 17:24
  • Keep in mind that often in the workplace, especially at a startup, it's better to be popular than do a good job. So tell the boss whatever he wants to hear, do what work you realistically can do, and don't worry about the rest. Commented May 14, 2014 at 17:35
  • 1
    @GarrisonNeely - Most startups will offset up their unreasonable requirements with heaps of equity. The ones that are worth working for will, at any rate.
    – aroth
    Commented May 15, 2014 at 3:18

5 Answers 5


The job of you manager is to make demands and manifest expectations. This is the reason why he/she's your superior.
What happen to you happens to many. This because managers are not always aware of the implications at micro-level. And, if you give it a think it's easy to see that the person who needs to bear the responsibility of informing your manager about what can be realistically done is you.

  1. Carefully plan your work.
  2. Start implementing for a day or two and see where you find yourself after this period of time.
  3. When you are ready, go to your manager and help him/her understand why what was asked from you is humanly impossible to achieve in the previously specified time frame.
  4. Keep doing your work at a realistic pace. If your manager asks for the impossible just because he/she wants to squeeze the best of you that's fine. If he/she asks for the impossible in a passive aggressive mode, then it's time to start searching for a new job.

Best of luck!

  • In an engineering/development context, the job of a manager is more to remove blockers and manage the expectations of external stakeholders than it is to make demands. Usually a software manager who makes demands and ignores the technical advice of his team members is just a bad manager.
    – aroth
    Commented May 15, 2014 at 3:15
  • Thank you. All answers were helpful but I'll mark yours as best because it sums up everything. Commented May 15, 2014 at 9:27

I'm waiting for the "so what?". Will they not hire you if you fail or give a poor recommendation because you couldn't do the impossible? Is there a bonus involved? Take you behind the office and beat the crap out of you?

If there were dire consequences that they thought would give you the motivation/fear to complete this task, they will let you know.

It's a startup. You're their only hope (Obiwan). Maybe you will get it done. Maybe it may not be quite so robust so they have to be careful how they use it. They're taking a risk on you. Forget about failing. Do your best. Most people leave an internship and have learned nothing nor built anything. You will have something to put on a CV.

  • 1
    @AnonymousIntern - To many technical people when they hear "have it done by Friday" they think it means fully functional, tested, fast and looks pretty, when it really means "have something to show it works for the most part."
    – user8365
    Commented May 21, 2014 at 13:54

In 17 days worked, I am supposed to do :

To complete that sentence: “The impossible.”

Realistically, you should take what they want you to do and divide it up into realistic chunks. Project manage your own tasks. Meaning, after 17 days what can you realistically present of the larger project that is viable even without completing the whole project.

This to me is the best tact. Because realistically you—or anyone else—will not be able to complete the goals as outlined within 17 days. But if you can build a solid foundation that can then be built on, then while the formal deadline is not met you at least have a solid… Something… That can be built upon when reality hits the team 18 days from now.


He asked me to do a gantt planning to balance the workload in May

Have you actually done this yet? This is how your manager can see what is and isn't realistic.

When creating it you need to stick to the following.

  1. No item should be over 3-5 days (depending on length of project). For 17 days, I'd go with 3 day max limit for item.

  2. Anything over 3 days has to be broken down further.

  3. The Gantt chart should show what feature is dependent on another (ie. can't start before another is done, or can't be removed without removing other parts).

  4. Don't under estimate. Your boss will hold you to those numbers.

  5. You can pad some of the tasks, but don't over pad the numbers. Your boss will not believe the whole thing otherwise. If your manager is experienced, then they may pad the numbers internally (as few people believe a developer can correctly estimate how long a task takes. ;)

  6. You should detail stuff you may not think relevant. For example, machine setup, training, etc.

  7. Do not factor weekends/out of hours in your chart.

Once you have that, give it to your boss. It is up to them to drop, delay or get more resources (or discuss you working unreasonable hours).

  • I did. Right now there would be several items a day but he wanted to keep the gantt "high-level" (without breaking down into items...) Commented May 15, 2014 at 9:23
  • Is this list coming from your personal experience or from some sort of cookbook for project management? Thanks!
    – Cris
    Commented Dec 22, 2017 at 13:21

So the general answer to this is twofold - addressing the actual scoping and delivery part and the communication part.

As for scoping and delivery, make sure you are limiting yourself to the absolute minimum viable product that will accomplish the task. Don't over-engineer it, the goal is to get just enough working to get users on, and then change it based on their feedback. Your specs may or may not be 'right' and it's that user validation and refactoring that will reveal that. So limit your scope of work to delivering the minimum required with just enough go-juice. Ideally you would have broken your specs down into stories and tasks with some granularity and have worked with someone to rank them in priority so you'd know what could slip. And, of course, as others have noted, as an intern at a startup you're pretty much expected to churn code 20 hours a day.

This brings us to the communication part - if you're even bothering to talk to use first, there's not enough communication going on between you and your supervisor. You should be talking daily and expressing concerns and asking for guidance as you go. You may be overthinking it and he may say "look just slap something minimal together in dropwizard, put a bootstrap front end on it, you're done." I don't know if they have testing and deployment for any of their other bits or if you're the first to cross that chasm, but if not I'd certainly just adopt whatever framework they already have in place. But these are great questions for him. He may well be simply watching to see if you can develop the good judgement to not stick to some perfect plan in a time/resource limited environment - I have certainly let employees dig a hole to see if they can effectively recover or not.

  • I know there is not enough, but I feel like being judged as unskilled every time we talk about those issues whereas in my opinion it's bad planning and bad management. (I may be wrong!) Commented May 15, 2014 at 9:26
  • You're the one who came up with the plan - managers can't magically know everything you're doing and your issues. In general, especially in startups, management is about giving YOU the responsibility to deliver - delegating responsibility down is good management, and good engineers then ask for whatever mentoring/help they require.
    – mxyzplk
    Commented May 15, 2014 at 12:03

You must log in to answer this question.

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