#16 Don't Surprise The Stakeholders
Sometimes when a project is kicked off and engineers are in deep focus, a critical issue comes up during development—a “warning signal” that the project might not finish on time or be delivered as expected. Some people tend to downplay these signals, assuming they aren’t significant and can be addressed later. However, this often leads to these warnings not being communicated to stakeholders early, resulting in surprises and raised eyebrows—something you definitely want to avoid.
In this post, I’ll highlight what these warning signals might look like by sharing two common project archetypes that often surprise stakeholders and sharing possible solutions to help you avoid them.
Introduction
Stakeholders can vary depending on the context, but they’re generally a group of individuals with a strong interest in the success of a project or business. At different levels, this can look like: a junior engineer stuck on a programming task might have the dev team as their stakeholders; a mid-level engineer designing a feature might have the tech lead, project manager, and teammates as stakeholders; and a senior engineer leading a project might have leadership, investors, and customers as stakeholders.
At the start of a new project, it’s essential to identify key stakeholders and understand their expectations. This helps you manage those expectations and establish a clear communication channel with them throughout the development phase.
Once a project kicks off and engineers are deep in their work, it becomes even more important to track progress regularly and share updates consistently with stakeholders to maintain alignment. This is one of the reasons we value Agile.
A common piece of advice I’ve heard from tech leads when owning a new project is:
Never surprise your stakeholders.
It’s better to over-communicate than to communicate too little. This applies at every engineering level.
Junior engineer: Don’t get stuck on a programming task for days without sharing updates—this can lead to surprises for your stakeholders.
Mid-level engineer: Don’t surprise stakeholders with an incomplete design document or poor feature planning.
Senior engineer: Don’t surprise stakeholders with an ill-defined project or hidden complexities.
So what are the symptoms of a project that tends to surprise people? In my experience, these typically fall into one of two common archetypes:
Lengthy Projects
Iceberg Projects
First Archetype: Lengthy Project
Lengthy projects are long-term initiatives that often extend over several months.
Any project I’ve worked on that lasted more than 2–3 months tended to be quite risky. Setting project goals far into the future makes the project vulnerable to change or missed deadlines due to unforeseen internal or external events. Internal events, such as development or QA taking longer than expected, and external events, such as competitors releasing new features or the company shifting priorities.
My ideal project timeline is 1–2 months. This allows some buffer in case of delays—if the project needs ~1.5x more time for any reason, it would only stretch by a few extra weeks, and that’s fine. But what if the timeline were 6 months? Stretching it to 9+ months could become unacceptable and would almost certainly lead to stakeholders raising their eyebrows.
Solutions for First Archetype
Aim to break any “large” project into smaller projects, with timeline set to 1–2 months. Define clear milestones for each project and outline the expected goals for each milestone. It’s okay to shift a goal from one milestone to the next during development if necessary, as long as progress remains on track and aligned with the overall objectives.
What’s the worst that can happen with a 1-month project? The team needs an extra week or two? That’s manageable.
It’s also a good idea to establish a strong communication channel for sharing regular updates. This ensures everyone stays informed about the current progress at the right level of detail while helping you maintain accountability throughout the project. Examples can be:
Weekly Updates (once a week):
How did we do this week?
Bi-weekly Updates (once every two weeks):
How did we do this milestone? Did we meet some of our goals so far?
Monthly Updates (once a month):
How is the project progressing? Are there any key metrics we should review?
These regular cadences help align the team and stakeholders while keeping expectations transparent and manageable.
Second Archetype: Iceberg Project
Iceberg Projects are semi-scoped projects that carry hidden technical risks.
Some projects might appear straightforward at first sight. However, these initial perceptions can mask underlying technical complexities—resembling an iceberg.
Skilled engineers have a good eye for spotting these icebergs. They can recognize when a project’s technical details seem shallow, carrying complexities that may not be immediately visible.
For example, I once worked on a project where I initially thought the proposed technical changes would be straightforward—and in fact, they were. However, the real challenges appeared in
Managing communication with customers,
Rolling out the changes within a specific timeframe,
Handling application statefulness for certain customers, and
Designing a rollback plan in case something went wrong.
These challenges weren’t visible at the start of the project but became apparent later, as I “bumped” into that iceberg.
One possible solution is to write down a proposal document ahead outlining:
Proposed changes
Clearly outline the changes. Mention the reasons behind them and specify whether they are breaking or non-breaking changes.
Customers affected by the proposed changes
Identify how many customers will be impacted.
Check if there are any special requirements per customer.
Rollback Plan
Define the rollback strategy in case of intermittent failures.
Identify how to restore the system to its previous stable state if something goes wrong.
Open Questions / Risks
Outline the risks associated with implementing the changes.
Check if there will be any downtime.
Confirm whether customers have been notified about the changes and if any of them have raised concerns.
By fleshing out these points in advance, the team can better prepare before starting work and reduce the risk of surprises down the line.
Solutions for Second Archetype
Before signing up for a project, take time to thoroughly review the technical challenges:
Identify Risks: Are there any risks associated with this project? Do you need to do any spikes?
Explore Alternatives: Explore possible alternatives and discuss the pros and cons of each for review. Stakeholders will appreciate you offering solutions and alternatives rather than simply saying no.
Cut Down the Scope: If the project feels too ambitious, break it into smaller, more feasible projects.
Get the Team’s Buy-In: Even if you’re not the project owner (i.e. tech lead), share your thoughts, ask clarifying questions, and seek feedback from other engineers.
Conclusion
I’ve shared with you two project archetypes that often surprise stakeholders and how we can resolve them:
1. Lengthy Projects: Projects that last more than 3 months carry the risk of prolonged commitments and missed deadlines.
Solution: Break the project into smaller, more manageable projects with the smallest deliverable value, ideally 1–2 months. Share regular updates with stakeholders consistently—don’t wait weeks to communicate progress.
2. Iceberg Projects: Projects that aren’t well-researched or scoped. Might appear “easy to achieve” at first but can carry hidden technical complexities.
Solution: Flesh out all relevant details in a design document. Conduct tech spikes to reduce risks. If the project feels too ambitious, cut down the scope. Make sure other engineers have reviewed the plan and are aligned with the timeline before the project kicks off.
I was already looking for your post! Friday's are Proactive Engineer post time :) You're Pavlov training my brain!