Find yourself all too familiar with the project manager vs software engineer lack of good coexistence?
It’s no secret that developers and project managers don’t always see eye-to-eye. In fact, many developers will tell you that their PM simply sucks. Probably the opposite happens, as well. We turned to r/webdev to try to figure out why.
Here are some of the responses we got:
- “Everything is a f*cking priority”
- “Knows less about the project than I do”
- “Meetings. They all love meetings. Way too many meetings”
- “Not being able to take “no” as an answer.”
- “Not being able to say “no” to clients”
You may have heard these gripes or even uttered them yourself. While these sound like surface-level complaints, they represent a core problem: the disconnect between software engineers and project managers.
Even if your job title is not “project manager,” you may be performing some of the duties of the role. Whether you are hiring and managing freelance developers, are a startup up founder, or an engineering manager, the bottom line is this: if you are overseeing the execution of a software project, you ARE the de facto project manager.
In this post, we’ll go over some of the common causes of friction between devs and project managers, outline some project management skills, and propose remedies for both sides. We will write from the perspective of project managers and developers working on clients’ software projects, but much of we discuss is applicable to product teams as well.
Below are some of the most prominent sources of the project manager vs developer divide.
Looking to hire the best remote developers? Arc can help you:
⚡️ Get instant candidate matches without searching
⚡️ Identify top applicants from our network of 350,000+
⚡️ Hire 4x faster with vetted candidates (qualified and interview-ready)
Try Arc to hire top developers now →
Scope and Requirements
While estimating time and resources needed for projects may be the bigger pain point, determining the project scope and requirements will help head off estimation issues. Before agreeing on project scope, project managers and developers should have a clear understanding of the client’s business objectives.
Note — that’s project managers AND developers. The developers will be the ones writing the code that will bring those business goals to fruition, so it’s important that they are invited to participate in the scope and requirements planning.
Once all parties are well versed in the project’s business goals, the client should be asked to prioritize features. It’s the PMs responsibility to make sure the client knows that must-haves features are those that are considered core to the project’s success.
Project managers and clients reach an agreement on project scope and feature priority not by deciding must-have and nice-to-have features — but by attaching dollar and time amounts to those features. This forces clients to categorize features into practical categories of must-have or out of scope/over budget.
Don’t underestimate the importance of bringing in developers on this early stage of project consultation. When the experts building the product have a better understanding of its purpose and goals, they can advise PMs more mindfully, minimizing future hiccups and miscommunications.
Estimation
Time estimation is likely the biggest sticking point between developers and project managers. PMs are often under pressure to commit to firm deliverable dates. The trouble is, software development is innately difficult to estimate accurately. Developers cannot be expected to work nights and weekends to overcome changing circumstances and meet unreasonable deadlines.
The ideal story is one that cannot be broken down any further.
To come up with more accurate estimations, ego and emotion should be taken out of the equation, both of which cloud judgment. Be practical — the project should be broken down into features, features should be broken down into small stories, and each story should be estimated in relation to its complexity and the available resources.
The ideal story is one that cannot be broken down any further. Also, PMs beware….your devs tend to underestimate (they’re a confident bunch). As a rule of thumb, many teams multiply by a factor of 1.5 to compensate for assumed overly ambitious estimates. This is in line with the principle of under-promise, over-deliver.
Categorizing Stories
Under Agile Development practices, many teams use relative estimates rather than absolute estimates. Relative estimates rank user stories not by the amount of time, but by the comparative level of effort required. Relative estimation is most useful when taking on an unfamiliar project with many unknowns.
Since absolute values are not given, any unit that the team prefers can be used, for example, t-shirt sizes, gummy bear colors, animals, cities, etc. For these arbitrary units to be useful, you will need to calibrate them against a baseline story that your team is familiar with. What matters is the relative size and difficulty of the story, which should be based on the following:
- Uncertainty and risk
- Complexity
- Amount of work to do
If your team is estimating familiar stories, you may be able to use absolute estimation and assign a number of hours or workdays. The purpose of both absolute and relative estimates is to reign in the size of your stories, reduce complexity, and make stories in your backlog more manageable. For absolute estimation, this means if you are getting higher numerical values, you need to further break down your stories. For relative estimation, say for gummy bears, if you are getting red gummy bears, (and red gummy bears are calibrated as a higher level of effort), you need to further break down your stories.
Whether you are using absolute or relative estimates, when working with external clients (as opposed to internal product teams), time values will inevitably be attached to your estimates. As your team goes through more sprint cycles and better refines your story ranking system, time estimates will become more accurate.
If you are dealing with clients who demand exact estimates rather than a range, estimate a range internally and give the client the upper end of that range. Don’t be afraid to tell clients “no” if they are insisting on unrealistic timelines. You will save yourself and your team a lot of pain down the road. Remember — under-promise, over-deliver.
Meetings
“I survived another meeting that should have been an email,” commented one Reddit user. Time spent in meetings is time not spent doing what you are meeting about.
Time spent in meetings is time not spent doing what you are meeting about.
That is not to say you should do away with all meetings. There is a time and a place for meetings — but it’s important to have a structure and a plan. Some teams have daily scrum meetings or weekly stand-ups. These meetings are time-boxed and everyone knows in advance what questions may be asked and what they are supposed to report. Scrum meetings are facilitated by a scrum master, who may be the project manager.
Here at Arc, our dev team has daily 15-minute standup meetings where every member reports what they are working on, what’s up next in the pipeline, and what issues they are having. Emphasis is given to current issues so that roadblocks can be removed.
Project managers should be aware that developers resent being called into meetings for simple communications or updates that could have been done asynchronously via a project management tool, instant message, or email. Reddit user u/mattaugamer commented, “Note that a “status update” meeting is both annoying and insulting and you will lose an eye each time you hold one.” With that in mind, please don’t hold more than two.
To avoid unnecessary or unproductive meetings, use a task-ticketing system to organize your backlog. Tasks can be ranked and pulled from an ordered list, such as a Trello board. You can also use Standuply to hold asynchronous stand-up meetings on Slack.
Using project management software will keep everyone informed, in real-time, of when tasks are pulled, in progress, and completed, cutting down on unnecessary meetings.
Read More: How to Be More Productive Working From Home
Arc is the best place to find great remote jobs. Find great remote jobs at top startups and tech companies. Freelance and full-time remote opportunities are available.
Sign up here
Ownership
When management is on your back, clients are edging close to feature creep, or deadlines are stretched, it’s easy to just blame everything on the devs! Don’t be that guy (or gal)!
In a sense, the PM is the team leader. It’s their job to protect the team. When management comes down with tough questions or requests, don’t throw the devs under the bus. The project manager should deal with those tough questions so the developers can continue doing their job. Likewise, when clients are getting pushy with deadlines or are encroaching on project scope, push back!
While it is the PM’s job to shield their team and put out fires, these less pleasant aspects of the job can be minimized by taking ownership of the project. Convey updates, delays, and changing circumstances to all parties in a timely fashion. Consult with developers regarding any change requests from the client. Make sure time tracking and work logs are properly filled out before (not when) they are due. Tools designed specifically for software project management can help streamline this busy work as well as facilitate communication: Jira, Active.Collab, LiquidPlanner, PivotalTracker, and SprintGround.
Be Humble
Sorry project managers, but it’s your job to take the blame, not the credit. While it is the PM’s job to lead and shield the team from outside distractions, they should not imagine that their contribution is any more important than anyone else’s. This should go without saying, but PMs and developers should be working in concert toward the same goals, not antagonizing one another.
PMs should recognize that the developers are the software experts. In most cases, the developers will be more knowledgeable about the tech than the project manager. PMs should use this dynamic to their advantage by taking every opportunity to seek advice from their developers, through the project’s development stages, to provide the best value to the client.
When there are change requests or shifting circumstances, PMs should ask, not tell. In case you forgot your 4th-grade manners, “Would it be possible to…..” is going to come off much better than “I need you to …..”
Remember, having the word “manager” in your title doesn’t make you “The Boss.”
Project Management Skills
Now that we have gone over some faux pas of project management, what makes a good project manager? Good project managers are:
- Mindful of limitations, including time, budget, and resources.
- Organized in process and workflow. Has a plan to move a project through all stages and sticks to it.
- Committed to the project, the team, and the client. Never short on energy or enthusiasm.
- Knowledgeable about the tech stack and its importance to the project’s business goals.
- Trusts the team members — is able to effectively delegate responsibilities and then get out of the way.
- Focused on the big picture and end goal, and is able to keep the team on track.
Developer Tips
No, the responsibility for efficient workflows and a healthy environment doesn’t fall only on the project manager. Developers have a role to play too. Here are some ways developers can help close the gap between themselves and PMs.
Speak a common language. As much as PMs should be knowledgeable about the tech and be fluent in “engineering,” developers will have an easier time getting through to their PM if they speak their language. If you want your PM to understand why one feature is taking longer, why refactoring is necessary, or any other technology-related delays, explain it to them in terms of business objectives.
This will also help your PM explain the current circumstances to the client and why particular actions are necessary or beneficial to their project. Assuming the developers were involved in initial project consultations and understand the intended purpose of what they are working on, this should not be a problem.
Facilitate more efficient collaboration. If you are dissatisfied with communication flows or meeting structures, don’t just complain — do something about it! If you have a better way, propose it and teach it to the team. Introduce a project management tool, propose a structure for time-boxed meetings, or suggest a kanban process, etc.
Ask and Inform. Ask questions during a project’s initial stages. Make sure you know the purpose of the features and the reasoning behind user flows and stories. It will help to align your goals with those of the PM and the client. If you see any potential risks or problems with the requested requirements, speak up about it, sooner rather than later, and suggest alternatives. This will save you the headache down the road.
Respect. As in any working relationship, mutual respect is key. While at times developers and project managers are pulled by different strings, realize that everyone is (most likely) just trying to do their job. Pass this article to your PM so you can do it together.
Recap
The divergent interests of developers and software project managers come down to different workflows, communication preferences, and different levels of responsibility to the client.
All of these things can be mediated by working more closely together from the outset, fine-tuning estimation strategies, agreeing on better communication structures and tools, and recognizing each other’s unique talents and contributions to successful software projects.
Developers and PMs should make great software….not enemies.
You can also explore HireAI to skip the line and:
⚡️ Get instant candidate matches without searching
⚡️ Identify top applicants from our network of 350,000+ with no manual screening
⚡️ Hire 4x faster with vetted candidates (qualified and interview-ready)
