The PM’s Dilemma: Influencing Execution Without Direct Control
Effective Techniques for Steering Projects From the Sidelines
During a video call with a senior PM friend from my Google days, we discussed his struggle with a project delay. Despite ‘handing off’ a mini Product Requirement Document (PRD) to his team three months ago, a feature estimated to take a few weeks was still incomplete.
In the chat before our call, he asked,
“When do you know it’s time to expand your engineering team?”
His question hinted at frustrations with the team or project dynamics. His team consisted of a UX designer, a researcher, a tech lead/manager, and four engineers (two front-end, one machine learning, and one back-end).
TL;DR: You can improve teams' execution by understanding common reasons for execution delays, such as scope issues, process inefficiencies, and technical unknowns, and by embracing collaborative strategies such as swarming and improved communication.
After experiencing similar situations many times where things took longer than expected and tensions arose between PMs and engineering teams regarding execution pace, I shared what I learned to help.
I started by discouraging him from rushing to expand the team. Larger teams require more communication and coordination overhead and often yield diminishing returns. Before considering an expansion, assessing and refining team dynamics and processes is better.
Most Common Causes of Software Project Delays:
Reflecting on my experiences, several common causes exist beyond team size for software project delays. The most common ones are scope issues (including technical unknowns) and process inefficiencies, which I’ll focus on. Let me clear out the first one and dive into the process issues.
Scope Issues and technical unknowns are widespread:
- Often, features turn out to be more complex than expected. Studies show developers tend to underestimate the time and effort required, leading to delays.
- Product managers and business analysts tend to miss requirements or assume the team knows the user's needs. This gap often goes unnoticed until the developer marks the work as done. Upon PM review, they may be confused as to why the work hasn’t been completed to their expectations. Communication is crucial.
- Technical unknowns, or ‘unknown unknowns’, are unexpected problems that can’t be anticipated with preemptive research, unlike ‘known unknowns’. This is where someone thought there was a way to do what the designer/PM asked for, but when they got to work, they failed. In large companies like Google, when you want to integrate with another team’s work, you find out you need approvals (that take time), or the framework doesn’t support what you need it to do.
Process Inefficiencies
In my experience, the most common cause of delays is process inefficiencies, mainly due to siloed workflows and communication issues. These factors are often connected, so addressing one can help resolve the other. A third source of hidden inefficiency is when teams juggle multiple features simultaneously, progressing in all but completing none — a common execution trap.
Siloed workflows occur when specialists (e.g., ML, FE) work sequentially rather than collaboratively, leading to integration issues, gaps in functionality, and repeated revisions.
Here’s how my friend’s team is likely working: the machine learning specialist develops a model. She hands it off to the back-end developer, who does her part and finally sends it to the front-end team. When these steps are done with minimal or zero collaboration, it often results in back-and-forth adjustments and a drawn-out development process.
What Other Options Are There?
There are (at least) 3 alternatives: Swarming, improved communication, and breaking PRDs by specialty:
1Simplest and best alternative is what the industry calls Swarming.
‘Swarming’ is a collaborative development flow where engineers from different specialties work together in tight synchronization on a single piece of user value. Instead of passing work sequentially like a factory line, everyone integrates their expertise collectively from the outset.
In a swarming model, the machine learning, backend, and frontend engineers aren’t siloed into separate phases. They co-create the feature, continuously sharing context, addressing dependencies, and making integrated decisions. This real-time collaboration minimizes costly handoffs and rework down the line.
2 Since many engineers were trained to dislike swarming (my standing theory is that the bad reputation attached to Scrum/Agile has negatively impacted the perception of swarming), you can “patch” the silos with improved and frequent inter-specialist communication.
3 When push comes to shove, PMs can make changes by breaking user value into specialty pieces. This means the PM will write up the needed ML, BE, and FE functionality with clear acceptance criteria to minimize integration issues between specialists. That said, swarming tends to be the most efficient way to reduce integration costs (e.g. BE/FE).
As for unknown unknowns, frequent cross-functional communication is the best solution. You need to have a venue—place and time—to alert the PM/Eng mgr/UX about new information that is causing a change in the plan and augment the work plan accordingly.
Influencing Execution Without Becoming a Project Manager Nor Undermining the Dev Manager
It sounded like he didn’t have great visibility into the daily workings and progress of the team. Knowing his thoughtful nature, I figured he was careful not to buzz into what he considers the engineering manager’s territory, yet he was keen to drive the project forward.
My friend felt stuck despite working with his engineering manager peer for many years. He didn’t want to sound like he was complaining about the engineering team — because it’s likely to cause friction and thus isn’t productive. On the other hand, he felt he couldn’t jump in and try to manage the execution because he didn’t want to set a precedent for owning that type of work. This is common: the PM-Engineer Manager relationship is often a delicate balancing act.
So… what can my friend do?
I recommended he’d take two parallel strategic approaches:
Collaborative Problem-Solving:
Engage directly with the engineering manager. Start with a non-confrontational prompt,
“I noticed this PRD from early February is still in progress. We initially estimated it would take just a few weeks. Could we review what’s happening together?
This approach both fosters partnership through joint problem-solving and design thinking — start with symptoms and investigate underlying reasons.
Prioritization and User-Centric Focus
Leverage the PM's superpowers to set priorities and focus on user needs during daily standups or similar meetings.
- Emphasize the importance of completing the most critical features first and encourage swarming — where multiple engineers collaborate intensively on one feature to reduce handoffs and accelerate completion.
You might think it’s obvious that one feature at the user’s hand is better than 4 in progress on the team’s Jira board. It’s not. Most teams I worked with overestimated their speed of progress and underestimated the importance of putting things in the users’ hands. - Break the features down by function in the PRD to get thin slices of testable user value. If you can’t get the team to swarm, split the PRD into small user journeys composed of small functional pieces so you can get things in the user's hands earlier, enabling learning and value creation.
***Note about external prioritization: when discussing prioritization, it’s important to remember that part of the PM's job and superpower is to “protect” the current work plan to let the team deliver their current commitment. If my friend allowed future or unplanned items to sneak into the current plan, it’s reasonable for the team to delay delivery of that 3-month-old PRD.
When is it Time to Expand the Engineering Team?
After doing what you can to improve the current process — by focusing on the priorities, delivering serial user value to avoid having all features in progress and breaking the features down by function to enable thin slices of testable user value — then you monitor for any bottlenecks. Are any of your functional experts blocking the queue? If yes, that’s where you start expanding the team. I would add about two more people for a four-person team and then spin up a new feature team. I recommended setting them up by feature teams, not divided by FE/BE/ML, to focus on delivering user value faster.
So, How Can You Influence Execution While Staying in Your PM Lane?
- Joint Problem-Solving Sessions: In your 1:1s with your engineering counterpart, discuss ongoing projects and identify symptoms and bottlenecks together.
- Frequent Communication of Priorities: Ensure your team and your peers know the work priorities you set and the logic behind them. Do this over email, chat, documents and in team meetings. It doesn’t have to be exhausting. You can simply pull up the same slide and speak through it quickly.
- Focus the Team on Value Adding: Whenever possible, share input from user research, what you see in the product analytics and, best of all, honest user feedback. The goal is to create empathy for the user’s needs and pains.
So there you have it 🙂
Every project and team is unique, and continuous learning and experimentation are key to mastering influence and project management.
What strategies have you found effective in your role? What challenges have you faced in influencing outcomes without stepping over into direct execution?
Share your thoughts and experiences in the comments 🙏
If you feel stuck and need a listening ear, reach out. I’m always happy to speak through problems and share the knowledge accumulated over the years and many teams.
