When highly specialized individuals attempt to work together, there is a high risk of friction if things aren’t managed properly. We all know how frontend developers and designers can sometimes clash, and it’s not uncommon for engineers and software developers to have their fair share of disagreements.
But today, let’s focus on the potential friction between project managers and software developers. It’s a dynamic that requires attention and effective management to keep things running smoothly.
When you’re building software, the roles of project manager and software developer are equally important for the successful launch of your project. Productivity and output rely on both sides working together to produce the highest quality product for customers. Yet, time and time again, we see a divide between the two personas.
Poor communication and lack of respect can derail even the most talented teams. It’s vital that your company better understands the relationship between your software developers and project managers so that you can manage it appropriately.
Let’s examine these two important roles, where problems arise, and how you can bridge the gap between your software developers and project managers.
Software developers and project managers have very distinct roles and often times there’s a dotted line in the chain of command which can be a root cause of friction. Both are aligned on the output, but most are not aligned on how to get there.
Project managers are typically given projects by the company and are asked to manage the cost, the resources assigned and the timing of the project. They’re responsible for reporting to stakeholders and providing constant status updates on the project up until launch.
Software developers, on the other hand, are typically assigned tasks, essentially pieces of the project, by their managers. They’re responsible for reporting on iterations of the project, or what is known as “sprints.”
While part of the cause for friction is the dotted line chain of command, the other contributing factor is the fundamental difference in how each persona operates. Many might say the root cause is poor communication but, in truth, it’s the “how” each communicates.
Blaming the lack of collaboration on poor communication is not really a true cause. Everyone has their own communication styles and with so many SaaS tools available to us, workflow habits can change over time.
Based on conversations with many project managers and developers, I’ve created a short table on likes and dislikes from both:
|In person meetings, email
|Slack, Teams, Hangouts
|Excel, PM tools
|(would rather not)
|(would rather not)
|Repo tools like GitHub
The opportunity here is figuring out how to adapt to each other’s working styles. This is key when trying to manage a project efficiently and effectively. Because the project manager is ultimately responsible for the project, it takes most effort from the project manager to really step up to the plate and engage their developers.
So how do they get it done?
Every project has a purpose: to solve a problem. That problem could be anything from boosting market share by releasing a new product, enhancing customer satisfaction through a new feature, or developing an integration for a partner agreement. Whatever it may be, the demand for the project stems from a specific need or requirement.
Involving developers in the initial launch of a project can be a game-changer when it comes to problem-solving. When developers are included right from the start, it provides them with valuable context and understanding of why they’re being tasked with developing software within a tight timeline.
And how do you do it without an in-person meeting or email? If you’re using a tool like Assembla, you can post the project in a ticket and @ mention users that will be involved in the project. Or you can add it to your wiki and send a link to the document to all parties involved (preferably the communication channel your team uses).
If your team is using Slack, you should create a channel for the project and invite everyone involved. This gives the entire team visibility into the project even when they’re not involved with the everyday conversations.
A common scenario that can cause a rift between the two parties is the lack of understanding some project managers have for the time it might take for a developer to complete a task. I’ve seen this exact scenario pop up over and over in various organizations.
It happens in the marketing organization with frontend developers, in the product organization with backend developers and everything in between. Programming in a certain language is a very specific skillset and there are different levels of experience.
It’s the role of the project manager to sync up with their software development manager or most senior developer to understand what levels of experience the developers have, what language they’re coding in, how much time is typically spent on specific tasks and, most importantly, what tools and/or services can a project manager provide to the software development team that would help them work more efficiently and effectively.
This puts unreasonable pressure on the development team. Yes, a project manager needs to answer to the client or management, but they must also balance these expectations with the reality of the workload. Understanding the development team’s workload clears up a lot of assumptions and better prepares the project manager to address questions from stakeholders.
While it’s important to involve developers early on and provide them visibility into the project, it’s equally important to shield them from office politics or endless debates over small product changes. Change requests are going to happen, but often times before a change request is approved, there’s a lot of debate between stakeholders and the project managers before coming to a conclusion. Cost and timelines have to be taken into consideration and that can take time to sort through.
By shielding issues like these, a project manager isn’t just alleviating stress for the developer, they are building trust. If you can trust your manager to filter out unnecessary distractions for you, then you know they have your best interest at heart.
If you want to improve communication and work more efficiently, it’s crucial that the entire team on the project uses the same tools and services.
Slack has become a comfortable place for all personas on a team to work from. At Assembla, we use Slack and have created channels for different teams within our organization. As a project manager, decide on which communication tool everyone should be using so there are no excuses for why teammates are not receiving updates.
If you’re a software developer, you’re likely working out of a code repository tool like Github – a tool most project managers cringe at. And if you’re a project manager, you’re likely working out of a complex project management tool – tools most software developers typically cringe at. Software developers just want to manage code, and project managers just want to manage tasks. When you’re developing software launches, both are equally important.
Assembla is a tool that bridges that gap between project managers and software developers with task management and code repositories built in. We also have integrations with both Slack and Github making it much easier for teams to adapt. Imagine merging requests directly in tickets:
We’ve built Assembla from the ground up to help software development teams work more collaboratively. By bridging the gap between software developers and project managers, products and features will be shipped faster. A company’s success will also improve as the relationship between PMs and developers improves.