How to Become the Best Project Manager in the World

May 25, 2018

Dealing with software engineers as a project manager can sometimes suck. Likewise, dealing with project managers as a software engineer can also suck.

I did a little bit of research with my team and online to see why this relationship can be difficult, and this is what I got:

  • Estimations - “My project manager keeps saying yes to things we just can’t deliver”
  • Priorities - “F*cking everything is due today”
  • Knowledge - “I know more about the project than my project manager”
  • Meetings - “Everything has to be done in a meeting”

Some of the points above are things that you may have already heard.

In the next bunch of words, we will go over what I think are the main causes of the problems between software engineers and project managers, and potential solutions.

Additionally, we will lay out skills required to become the best project manager in the world.

Please do not get hung up on the words “project manager”. If your job is to make sure a project is completed as expected, then you are a project manager.


I believe the estimation of when a project will be complete is the biggest communication problem between project managers and software engineers. The project manager’s job is to commit to specific dates when the software will be complete, and to make sure it happens.

The problem here is that it is extremely hard to accurately estimate when software will be complete due to uncertainty, risk, complexity, and amount of work needed to complete each feature.

Software engineers can’t be expected to give up their lives in order to make the deadlines. That is simply not sustainable.

The project needs to be separated into features. These features need to be split into tiny tasks (stories). Now that we have a list of tiny tasks to complete, the team needs estimate each task in relation to other tasks. More on this later.

Tip: Break down a task until it cannot be broken down any further. This will make estimating each task much easier.

When going through the exercise of estimating each of the tiny tasks, the team needs to be aware that engineers typically underestimate each of the tasks.

If you have an engineer that thinks a task will take a small amount of time and an engineer that thinks the task will take a medium amount of time, try to go with the upper value. This goes hand in hand with the principle of “under promise and over deliver”.

As always, use your best judgment.

Categorizing Tasks

Categorizing each task in terms of time is plain stupid. Let’s admit it. When you are dealing with a project that is unfamiliar and has many unknowns, saying that a task will take 30 minutes, 2 hours, or any amount of time simply does not work.

In the world of software, it is extremely rare to look at a task and know exactly how long it will take. This is where using relative estimation comes in.

Agile development introduced the concept of estimating by comparing each task to the rest of the tasks. When estimating each task, the team should be thinking about the following four things in comparison to the rest of the tasks in the project:

  • Uncertainty - Do you know what to do?
  • Risk - How likely is the task to put the rest of the project in danger?
  • Complexity - How difficult is the task?
  • Amount of work to do - How much busy work is needed for the task?

I typically use the “point system”, which uses the following values to categorize tasks: 1 point, 2 points, 3 points, 5 points, 8 points. The smallest type of task is 1 point, and the biggest type of task is 8 points.


  • A task with low uncertainty, risk, complexity, AND amount of work to do, in comparison to the other tasks, should be worth “1 point”.
  • A task with an extreme uncertainty, risk, complexity, OR amount of work to do, in comparison to the other tasks, should be worth “8 points”.

In the end, these “points” will have to eventually translate to time so you can communicate a project delivery date to your client.

Example: Every week your team will complete a certain number of points. If the features in the project require 100 points of work, and your team completes 20 points every week, then you can assume the project will be complete in 5 weeks.

100 points total ÷ 20 points per week = 5 weeks.

As the time goes by, your team will know the product and the code better, so the number of points completed and the accuracy of the points per week should increase.

In the above example, I would give myself a buffer of 1-2 weeks. This way you will reduce stress and burnout amongst your team.

Remember, it is much better to under promise and over deliver, than to over promise and under deliver.


Prioritizing is hard, but it’s the most important thing you can do with your team.

Before agreeing on a set of features that the software needs to have, project managers and engineers should be in agreement with the client about what the software should and shouldn’t do. Please note I said project managers AND software engineers.

It is of extreme importance that software engineers are part of the prioritization process because they are the ones that will be down in the trenches to bring those features to life.

When prioritizing, think MVP (Minimum Viable Product), the minimum set of features that a product must have to be useful.

It is the project manager’s responsibility to make sure that there is an agreement with the client regarding the must-have features of the project.

Once the must-have features have been defined, and each of the features has been estimated by breaking them down into tiny tasks, give each feature an estimate with hard values (time or money) so as to help the client know what they can afford. This will dramatically help with prioritization.


The time you make your team spend in meetings is the time that they cannot spend writing software.

My intention is not to say that all meetings are evil, but for a meeting to be effective, there has to be a well-defined structure and plan. The meetings that the team attends should have time constraints and everyone involved should know what the meeting is about.

Project managers need to know that software engineers resent attending meetings for things that could have simply been communicated over an email, an instant message (with Slack, for example), or through a project management tool like Jira or Trello.

If the meeting can be done easily through the methods mentioned above, then save your team some time and do it that way.


One of the hardest parts of being a project manager is that the role requires the person to own the product and to protect the team from the outside world.

This protection involves defining product requirements, answering tough questions, avoiding feature creep, prioritizing new requests, and saying “no” where it is necessary.

If the project manager fully owns the project and protects the team, the software engineers will be able to do their best work.

Be Humble

As a project manager, you need to recognize that the software engineers will typically be more knowledgeable about the technology used in the project.

Project managers should use the team’s expertise to their advantage. This means they need to be humble and ask for advice from their team whenever necessary to better help the client.

Being a humble project manager also involves asking, not telling. For example, “Would it be possible to…” will sound much better than “I need you to…”.

Being the project manager doesn’t make you the boss, it makes you part of the team.

Other skills

There are several other skills I’ve seen in the best project managers. Some of these skills are:

  • Aware of time, budget, and resource limitations
  • Organized in the process and workflow
  • Committed to the client, the team, and the project
  • High on enthusiasm and energy
  • Knowledgeable of the technologies being used in the project and their purpose
  • Trust in the team
  • Focused on the end goal

Don’t Be That Software Engineer…

The responsibility of a healthy environment and a great product isn’t only on the project manager. Software engineers have a big role to play in helping project managers put forth their best work. Here are some of the ways in which great software engineers help:

Bring it down a few levels. Although a great project manager is aware of the technologies used in the project, you can’t expect them to know as much as you.

If you want the project manager to understand why something is taking longer than it should, then bring the technology down to a level that they can understand. They are not stupid, but they have not devoted their career to understanding programming like you have. Doing this will help your project manager to better communicate to the outside world exactly what is going on.

Making teamwork more efficient. Communication flows, meeting structures, or project flows are often defined by the project manager. If you don’t like something, do something about it, don’t just complain!

If you believe that there is a better way, then put it on the table. Explain your idea and teach it to the team.

Be very communicative. Keeping a high level of communication means to ask a lot of questions so you can know the ins and outs of the project. Knowing everything about the project makes it easier to assess the situations in which you will be involved.

A high level of communication also involves telling your project manager if you think there is anything that will impact the delivery date of the project. Do it sooner rather than later. This will save you a headache down the road.

Be respectful. Being mutually respectful is key to a successful project. Understand that the project manager is under a lot of pressure from the outside world to deliver any given project. They are just trying to do their job.

In Conclusion

The work of a project manager is hard. They have to manage the interests of both the clients and the software engineers. Each party has different communication styles, workflows, and deliverables.

The responsibilities of a project manager can be made easier by implementing the techniques discussed in this blog post, and by recognizing that each team member can make unique contributions to the team that will make a software project successful.

Share this blog post with every project manager and software engineer you know so that together we can continue to create amazing software.

Written by Victor Dozal who lives and works in Austin, TX. He enjoys building useful things, writing about his journey as an engineer, and consuming lots of coffee. You should subscribe to him on YouTube :)

Need help with your project? Struggling with a problem? I'm at your service.