How To Execute On Time & Look Great or: A Project Management Guide for Junior Developers

I was hired for my first job out of college as a software engineer at a large FinTech company.

In my mind, they were paying me to write code that in some way made their business money.

For a variety of reasons, a few months later I left to join a startup. In my mind, my job was still to write code that helped the business make money.

However, when I was assigned a task I rarely executed it within my originally estimated amount of time.

On the one hand estimating is hard, especially as a relatively junior developer. Developers know this, and cut juniors slack accordingly.

On the other hand, I really hate feeling incompetent. Every time I blew through an estimation, I felt that in some way I had failed.

This post is about the project management techniques I have learned over the last year that have helped me dramatically improve my ability to estimate and execute a task in the estimated amount of time.

1. Insert Yourself As High As Possible in the Product Lifecycle

Broadly speaking, in most companies product development goes through three phases.

Phase 1: Product works with executives to define a direction and high level goals.

Phase 2: these goals are translated into actionable tasks.

Phase 3: a developer takes on/is assigned these tasks and executes them.

If you as a developer are first seeing or hearing about a task in Phase 3, chances are high that you have already failed and will not be able to create an appropriate estimate for the task. You will need to spend time digging into the task to ensure that it has been groomed and spec’d out appropriately, understanding product’s perspective and priorities, and finally implementing the task.

Juggling all three of these things in Phase 3 represents a broken process. However, even if your team’s processes are broken, you can still get around this problem by inserting yourself as early as possible in the product lifecycle.

In my experience it is difficult to insert yourself into Phase 1 as a relatively junior developer.

Instead, focus and push hard with your seniors and leaders to become a driving force in Phase 2 of the product cycle.

Once here, you can observe and discuss product’s goals and intentions and become a part of the translation process between those goals and actionable tasks.

The net effect of all of this is that you become the person defining/writing/specing your own tasks.

This means that you are able to not only able to exert significant influence over the tasks you execute but also their definition of success. More on this later, because it is very important.

2. Manage Your Leaders’ And Seniors’ Expectations

In most organizations, completing a task will ultimately require approval from someone. In the engineering world that typically means a code review to ensure your work meets the acceptance criteria and aligns with the company’s technical standards (code review, etc).

There is nothing worse than working hard to execute a task only to have whoever reviews your code shred your design choices and effectively ask you to start again from zero.

You can mitigate the risk of this happening by gathering buy-in on solutions as you define the tasks.

Because you are already involved in Phase 2 of the product lifecycle, this is relatively straightforward. As you define new tasks and outline solutions for them, simply schedule meetings with the individuals who will ultimately sign off on the task.

If there are a lot of people on your team who will have strong opinions about how a solution is implemented, it may be wise to set up a recurring weekly meeting. This way if there is disagreement about the best solution people can argue directly with each other rather than indirectly through you.

One caveat here is that you need to make sure your thinking is ahead of everyone elses on a subject. You cannot sit back and let these stakeholders define a solution for you because this is effectively the same thing as waiting until Phase 3 of the product lifecycle to interact with a task.

You need to take ownership of the solution. This meeting should be you walking the team through the detailed solution you have already devised. Accept feedback and give pushback where appropriate. Learning how to do this can be hard, and is one of the areas I have struggled most in.

Do not be hard on yourself if all of this does not fall into place all at once.

By employing these processes you can significantly mitigate the risk of needing to re-work a solution from scratch.

3. When Things Go Wrong, Communicate Loudly

Despite your best efforts, it is likely that you will continue to estimate some tasks incorrectly.

Sometimes this will occur in your favor and you will have extra time on your hands.

Other times it will not.

Unless you enjoy working 60+ hour weeks, when this happens simply communicate the issue as early as possible to both your senior engineers and whoever is responsible for your product. These conversations can be embarrassing, but as we saw in technique number 2, success is largely a function of managing expectations and gathering buy-in.

In these conversations, explain the issue you encountered and provide a few alternatives. Typically you will end up:
a) altering the original task requirement
b) committing to a smaller slice of the original task requirement
c) dropping the task because the deliverable is not worth the time

These are all perfectly fine outcomes, and will hopefully allow everyone to move forward feeling good about their decisions.

4. Get Concensus From Your Leaders and Managers Around Your Time Allocations

One nice aspect of the Agile development process is that everyone gets this technique applied to their workflow for free out of the box. When planning and committing to a sprint, you are effectively getting concensus among the people above you around how to spend your time.

However, for those on teams not practicing agile, managing the demands and expectations of multiple different people can prove challenging.

The best way I have found to do this is by keeping a centralized document – a spreadsheet, trello board, etc – that contains all the demands people place on you. When someone brings you a new ask, you can add it to this board and show them your tasks and what you currently have prioritized.

From here, politely ask where their task should fit in terms of priority.
People tend to think their own work is the most important, so expect that they will ask to be put somewhere near the top.

If this person is your CTO/high level executive/etc, just say yes and do it. The people whose tasks you bumped will understand.

If the person is slightly lower in the organizational hierarchy though, you can politely ask them to confirm with whoever’s task they are displacing that their new incoming work is truly more important.

By doing this, you can drive concensus around your time allocations across all your stakeholders/leaders/managers. Ultimately this means less work and stress for you.


Applying these techniques in my work has changed my life. If you follow them, you will find yourself defining your work, that work’s definition of success, and bringing all your key stakeholders along through this process.

Instead of choosing between missing a deadline and staying late at the office, you can create a world where you leave the office early and hang out in a park.

You can have your time back. And at the end of the day, is there anything more valuable than that?

Leave a Reply

Your email address will not be published. Required fields are marked *