Most Project Delays Are Caused by Surprises, Not Bad Code
A practical guide to stakeholder management for engineers who want to ship without the last-minute chaos.
Someone Found an Issue Last Minute...
A few years ago, I was leading a project that was moving pretty smoothly. The team was making steady progress toward the release. We had finished development, passed QA, and started preparing for launch.
Then, a few days before release, someone from Product Security joined a review meeting and asked: “Has this gone through a security review yet?”
At that moment, we realized we had never checked with them. The feature introduced a new way to upload user-generated files, which meant new security measures around validation and storage. The security team flagged several issues that needed fixes before launch. It delayed the release for an extra two weeks. We had to explain to stakeholders and upper management. Some of them were not very happy about it.
If we had looped Product Security in earlier, we could have addressed everything in the tech design. That experience taught me an important lesson: Many delays come from missing stakeholders, not technical issues.
Goals: Alignment and No Surprises
In a software development project, many things can happen outside coding:
Requirements change late.
Another team suddenly depends on your API.
Product priorities shift halfway through development.
Most of these situations share the same root cause: stakeholders were not aligned.
The goal of stakeholder management is straightforward: keep everyone aligned so that nothing becomes a surprise later.
Alignment helps spot issues early. Fixes can be applied early as well.
This is why stakeholder management becomes an important skill as engineers become more senior. The goal is to make sure the work moves forward smoothly across people and teams.
Types of Stakeholders (and What They Care About)
Stakeholders are the people you work with.
Each stakeholder looks at the same project from a different angle. Understanding what they care about helps you communicate the right information to the right people.
Product Managers & Business Teams
Product managers and business stakeholders focus primarily on timeline and risks.
They are responsible for making sure the product delivers and aligns with business goals. Their questions usually revolve around:
Are we on schedule?
Are there any risks that could affect the timeline?
Do we need to adjust scope or priorities?
They typically don’t need deep technical explanations. They only need to know if we can deliver.
If there is anything that can impact the timeline, communicate early.
Other Engineering Teams
Engineering teams usually interact with your team in two different patterns:
Upstream Teams
Upstream teams are the one that your system depends on: platform, teams that provide APIs your service uses, etc.
What upstream teams usually care about is how your work affects their systems:
What new functionalities do you need?
Will traffic increase?
Any edge case your changes might introduce?
All requirements and risks need to be communicated as early as possible, ideally at the tech design phase.
Downstream Teams
Downstream teams are the teams that depend on your system.
They might be calling your APIs or integrating your service into their features.
From their perspective, the biggest risks come from breaking changes, including API or schema changes, behavior changes, and deployment timing. Even small changes can cause problems downstream.
Experienced engineers usually communicate upcoming changes early and give teams enough time to prepare.
Product Team Members
There are also stakeholders within the product development process itself. They care about different aspects of the development process.
These are the common roles and what they care about:
QA engineers: specs, spec changes, QA timeline.
Designers: usability & product experience.
Product Security: product risks, compliance.
Most teams don’t need regular updates, but they need to be included in the process when needed.
For example, QA teams need to know the specs and user stories to design test cases. After that, they only need to know if specs have changed, and the QA timeline.
These teams often surface issues that engineering might not notice during implementation. Looping them in early can prevent situations where problems appear right before launch, like a missing security review or a last-minute design change.
Keep Everyone Up to Date
Once you know who the stakeholders are, the next step is making sure information flows regularly. In practice, this usually happens in three ways.
Async communication: A short Slack message, project update, or ticket comment is often enough to share progress. These quick updates give stakeholders visibility without interrupting everyone’s schedule, and they help prevent surprises later.
Regular check-ins: These meetings are useful for discussing changes in priorities, trade-offs, or emerging risks that require input from multiple people. This is better than async communication when you need stakeholders’ full attention for discussions.
Ad-Hoc meetings: There are moments when a topic needs a quick ad-hoc meeting. This usually happens when issues need clarifications or a decision right away, such as a major priority shift, last-minute spec changes, etc.
The Right Mindset
Never Assume Alignment in Silence
People tend to respond with silence if they are still processing information.
That does not mean they agree with your idea. It means they are still thinking about it.
I now treat alignment as something that needs to be actively created and regularly confirmed, not assumed after one conversation.
A simple habit that helps: at the end of a meeting, write down a short summary. “Here’s what we agreed on. Here’s who is doing what. Let me know if anything looks off.” It takes two minutes. It catches misalignments early, before they turn into real problems.
Keep Written Documents
Memories can get blurry and verbal agreements are usually unreliable. What you said in last month’s kickoff meeting is not what everyone remembers today.
Written documents are your safeguard: BRDs, PRDs, and technical design docs. These are clear, living references that capture what you’re building, why, and how.
Update the docs as new decisions are made. Archive docs that are no longer relevant.
It helps keep everyone, including new joiners, up to date.
Over-Sharing Is Better Than Under-Sharing
I know this feels counterintuitive. Nobody wants to flood people with updates they didn’t ask for. But in my experience, the cost of over-sharing is almost always lower than the cost of under-sharing.
In a meeting, if there is any concern, share it. When stakeholders feel informed, they trust the team.
People can choose to ignore irrelevant information, but there are always moments when seemingly irrelevant information reveals risks in a project.
Think of proactive communication as a way to protect your team’s focus, not just a courtesy to others.
Bonus: Ask for Feedback Regularly
Most engineers focus on pushing information out to stakeholders. But there’s a direction most people forget: asking for feedback.
Stakeholders often have concerns they’re not voicing. Maybe they’re not sure if it’s worth raising. Maybe they assume you already know. A simple “how is the communication working for you?” or “is there anything you wish you were seeing more of?” opens a door that most people won’t open on their own.
It also signals that you treat the relationship as a two-way partnership, not a broadcast channel. That perception alone builds a lot of goodwill.
I usually ask for feedback from stakeholders every quarter or after a project is delivered. It could be a general Google Form or a Slack message. Most people say things are fine, but occasionally there is valuable feedback worth acting on, such as how we communicate, frequency, or meeting agenda suggestions.
Acknowledgement & Follow-Up
Use that feedback to improve how the team works with stakeholders. Remember to send a short follow-up after you’ve taken any action based on their input. This is how trust compounds over time.
Last Words
Stakeholder management is a core part of engineering leadership, and it compounds over time.
The engineers and managers who do it well build trust, reduce friction, and make the whole organization work better. That reputation follows you throughout your career.
Start small. Pick one habit from this post and apply it to your current project. A weekly async update. An early risk flag. A single feedback question at the end of your next check-in. Small, consistent actions add up faster than you’d expect.
That’s it for today.
If this way of thinking resonates, I write about senior-level mindset, ownership, and career growth for engineers.
I’ll see you in the next post.
Adler from Tokyo Tech Lead