Once, we were working on a critical update for a product tracked by stakeholders.
The update required strict timelines and a lot of coordination across teams — something the project manager (PM) handles. In this case, the PM was exceptional at organizing everything but struggled with some of the technical aspects, which is typical. She couldn’t explain the delays to anyone because she didn’t know those aspects, frustrating everyone involved.
So, as the engineering manager (EM), I stepped in to help her break down the technical challenges in a way she could easily communicate.
This is how it often works with EMs and PMs — you have very different responsibilities, but your work complements and supports one another. However, effectively doing this as an EM first requires knowing what PMs actually do.
What project managers do
I watched a documentary recently about how they built the tunnel under the English Channel from Britain to France. They had to use two digging machines from either side. As you can imagine, it was important for the machine operators to meet exactly in the middle.
Coordinating something at this scale required:
- Digging a little bit
- Measuring where they were
- Then digging again
One group of workers operated the digging machines. Another group specialized in understanding how far the machines had progressed and the adjustments needed to meet the machine on the other side. The latter group didn’t do the digging themselves, but they made sure the operators knew where they were.
This is a great metaphor for project managers. Usually, they don’t have deep technical expertise, but they coordinate the work across different teams to make sure the job gets done.
The work includes:
- Telling people when to do which task
- Learning new information from team members about their tasks at hand work
- Asking about delays so they can give someone else something to do
- Sharing next steps after a milestone is completed
- Adjusting the timeline to make sure the feature is finished before the launch date
- And so on
How you can help
If we go back to the digging metaphor, a PM cannot do anything if the machine starts putting out smoke. In that case, they’ll need to call in a mechanic.
The same is true if they need to replace one of the machine operators. The PM doesn’t know how the machine itself works, so they can’t accurately test an operator’s qualifications.
In other words, these are all technical problems. The PM needs someone who can:
- Come in and see if the machine can be fixed
- Whether it needs replacing
- Or if two smaller machines can do the same work instead
Obviously, we’re talking about software engineering and not digging. But these are all technical questions that you, as an EM, will be able to answer.
The PM doesn’t have the same insight, so they need your expertise. What’s more, they might not even know the right questions to ask in order to find out what they need to do.
But you have more to offer than just specialized technical advice. While areas like budgeting and resource allocation are officially within the PM’s sphere of responsibility, there are ways you can contribute.
1. Making the dream a reality or adjusting it to match
Imagine you need to make a delivery from Portugal, where I live, to Brazil. The original idea (however crazy) might be to build a rocket large enough to deliver everything in the smallest amount of time.
The PM would handle the logistics for taking care of the crew and coordinating their schedules, but they’d have no idea:
- How to build the rocket
- What construction requires
- And how long to realistically plan for it
You, as the EM, would explain what quality of fuel you need, what kind of engineers can build the rocket, and what problems they may run into that might cause delays.
In fact, you might even hint that the product team dreamed a little too big and suggest another route, like taking a boat instead. It’s not as fast (nor as sexy), but it’s more doable.
Setting limits to make projects possible is something you have to do as the EM. In practice, this means the EM will look at a projected feature and break it up into smaller, more manageable steps.
2. Budgeting (it’s about more than just money)
Once you’ve defined the scope and figured out how long a task will take, someone has to set a budget. For many, this means money. But I believe it’s more useful to think of a budget as the following two elements:
- The number of available people
- And the number of available hours
Properly budgeting then is getting the most value out of those limitations for the work you need to do. It can also mean determining if you need more people after discovering the work will take twice as long, for example.
This is typically the PM’s domain, but their lack of technical background will lead to disaster if they don’t consult with you first. Adding more people isn’t a solution to everything. And you know the technical requirements and your engineers’ capacities, so your participation ensures a more realistic and accurate budget.
3. Knowing your engineers and what they can do
If you’re going to dig a tunnel under the English Channel, you’re going to need a long supply line. Gasoline needs to enter the tunnel on a regular basis. Not to mention fresh workers, as well as food, water, and other necessities.
PMs take care of this resource allocation. If different teams come together to work on a particular feature, it’s the PM doing the dance so everyone has what they need to complete the job on time and within budget.
But, just like with other areas, they especially need the EM’s help with one of those resources: the engineers. That’s because each engineer has different:
- Levels of experience
- Kinds of skills
- And, importantly, personalities
Some are great coders but need help getting things in on time. Some are reliable but don’t take risks. Others are most engaged when they’re learning something new. As the EM, you have insight into who is best suited to what kind of task.
So, it’s always good for EMs to coordinate with PMs on this. You may need to be proactive about it as well because PMs might not even realize there’s a problem. And when there actually is a problem brewing, then there’s a risk they won’t be aware of it until it disrupts the workflow.
4. Minimizing risk through expertise and insight
The main risk we’re talking about here is missed deadlines.
This can happen for many reasons, including poor quality, poor communication, or lack of feedback. All require your help as an EM.
We had a situation in our team once where there was a certain amount of cross-team technical debt, and an EM from another team flagged it for the PM to take care of.
The PM agreed and took the following steps:
- Worked out a plan with the other EM
- Set a timeline
- And picked an engineer to do the work
They allocated two weeks to get it done. There was just one problem: they didn’t alert me.
As that team’s EM, I could have looked at the plan and said, “Hey, it’s possible to do this task in two weeks, but you picked an engineer who has a history of taking longer than normal when working with technical debt.”
But this conversation never happened and, unsurprisingly, the task wasn’t done on time. This caused a delay that led to more delays, and in the end, we didn’t have everything we needed done before the release deadline. They had to roll back all the changes, and it was rather painful.
It was good that the PM coordinated with the other EM, but they didn’t know enough about the engineers. You, as the EM, will have all the information you need to help your PM mitigate risks like this as much as possible.
This isn’t the only type of risk EMs can see and prevent, though. Maybe a few engineers are stressed out and on the verge of quitting, so they need less time-sensitive tasks for the sake of their well-being.
Or maybe the team is discussing introducing an OSS library that isn’t very popular and won’t be actively developed in the future. So, it might be out of date a year from now, causing problems down the road. You’ll need to suggest a more relevant library instead.
But, again, the PM won’t necessarily see these as the risks they are, whereas you will. So, it’s good to be proactive and help your PM get the insight they need.
5. Advising the hiring team and improving the process
Maybe you work on an ambitious team. Most of the teams I know are this way — everyone wants to take on more, sometimes even bigger projects. Often, engineers are already busy and can’t do the work. So, if you want to scale and do the work you want to do, you need to hire more people.
EMs can offer a lot of insight when it comes to the hiring process. An engineer may look like any other to your PM, but you’ll know the kind you need and why. For example, maybe you need one who is good at:
- Refactoring and working with technical debt
- Coming up with architectures and solutions
- Researching new approaches
- Creating their own libraries and frameworks
You can also help design the hiring process so it’s easier to spot the right people. For example, you can tell the hiring team:
- When the best moment is to add new members to the team
- Who precisely you need, and what skills they should possess
- How many new people you need in those roles
- Who you most need now
This doesn’t mean you have to commandeer the whole process, though. Just help nudge things in the right direction so the work runs more smoothly and efficiently at the end of the day.
The short version: better together
EMs and PMs do entirely different things, but the overall work requires all managers to operate in sync. By complementing each other’s strengths, you become a unit far more effective than the sum of its parts.
With that in mind, here are some areas you can contribute best to project management as an EM:
- Placing limits on project scope
- Creating realistic budgets
- Advising about what engineers are best for different types of work
- Managing and mitigating risks, such as unexpected delays
- Helping hire new engineers
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com