Breaking the News: A Blueprint to Communicate Timeline Changes in Engineering Projects
A template how to tell your stakeholders that your team won't meet the project deadline, without burning bridges.
Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or so) I write a newsletter article on tech industry careers, practical leadership advice and management how-tos.
At some point in our careers, we will all contribute to a project that will miss its original timeline. If you've already been through it, you know that sharing such news can be stressful. In an organization with a healthy culture, hopefully, such an event won't turn into a "blame game". But it will undoubtedly create debates and throwaway work.
After being through it a couple of times, I've found a good recipe for communicating project timeline issues. I recently used this approach as a newly minted engineering manager, so I'd like to document it here. You are going to have to do this sooner or later, and this can help out.

I strongly prefer to communicate such issues in writing. So, here’s a blueprint on how to communicate project timeline delays and changes in writing.
The blueprint is five sections long:
Non-negotiables
Current project status
Remaining work
The problem, or why we won’t meet the deadline
Going the extra mile
After each section I will add a real-world example of a document that I’ve written on a project whose timelines were delayed. The sensitive information from these examples is removed, but the main points and argumentation remains the same as in the original document.
Section 1: Non-negotiables
It's a humble beginning: I share my principles and priorities, or things I wouldn't compromise on. Knowing my principles in that situation requires some preparation and iteration. Some examples of principles are sustainable pace, team well-being, product quality, technical excellence, compliance, security, etc. Take your pick.
I make sure to call out each one of them. By clarifying my principles and priorities, I tell my readers where I am coming from and what's important to me and my team. This section is necessary because my principles show the readers what lines in the sand I've drawn for my team. It creates a transparent playing field within which we can negotiate.
You might think the principles should be evident, but others won't know what drives me or what I stand for unless I tell them. Think about it: how many of your work peers' principles or beliefs do you genuinely know? Few, at best. Sharing my principles is like setting the stage for a play; it provides the backdrop and context, helping others understand the scene and characters better. Without this, they might completely misunderstand my intentions or the storyline of our project.
An example from an actual document I’ve written:
1. Guiding Principles
We want to unblock the ‘Project Aurora’ by:
Not compromising operational excellence and system reliability: we want to avoid creating liability for ourselves (i.e. incidents or maintenance work)
Sustainable pace and engineering happiness: avoid burning out engineers by applying too much pressure and causing team attrition
Being open-minded and willing to change operating model: we are happy to hear ideas, feedback and change the way we work to achieve the project goals
Section 2: Current project status
This section is where facts are everything. What I do here is to set the context for the reader on where the project is at that given moment. I specify the goal the team has set out to achieve (and has failed to within the original timeline). The background has to be rock solid, rooted in pure facts with zero assumptions. If I misreport the project's status, it will be misleading and undermine me and my goal.
This section is like steering a cruise ship. A small mistake now can lead it far off course. In short, I could end up writing about a topic disparate from what I planned.
An example from an actual document I’ve written:
2. Background
The Phoenix team communicated earlier in Q1 that we will ship the alpha version of ‘Project Aurora’ on May 8, 2022. The motivation behind the Phoenix team taking on the work was to help with the complexity of Entity importing logic and unblock the Core team to ship an alpha version of ‘Project Aurora’ project by end of Q2 2022.
The work breakdown and dates were communicated via the Project Aurora Work breakdown & timelines document.
Section 3: Remaining work
After displaying the project's current status, I share the project's remaining tasks. At this point, the reader understands the project's status, so they must understand the remaining work. By sharing, I aim to show the reader why the team can't complete the project within the time allotted. This section is where punctuality is crucial, as the reader will scrutinize the task list. Some readers might even attempt to descope tasks to make the project fit within the timeline.
I don't mind it - it's theirs to try, but I want my team's plan to be rock solid. For this section to be crisp and full of signals, whatever I put in it gets cross-checked by the engineers on the team. Any assumptions or wishful thinking is a failure mode here, so I keep it 100% real.
Another thing I avoid is adding needless detail that can create throwaway back-n-forth. It's like navigating a ship through a storm: adding too many complex estimates is like focusing on the turbulent waves instead of steering the ship safely to harbor. We aim for the reader to trust the engineering team's ability to guide the project, especially in challenging situations, not get caught up in questioning every wave and wind gust.
The bottom line is that I keep this section to the point, without unnecessary detail or embellishments.
An example from an actual document I’ve written:
3. Remaining work
With the approval of ‘Project Aurora’ Technical Specification on Feb 3, 2022, the Phoenix team began to ramp up their hands-on involvement in the project on March 3, 2022 to catch-up to the latest changes of the tech spec.
Notably, the remaining work for the Phoenix team can be broken down in these major blocks:
Implement Entity Creation endpoint
This is the endpoint that will be invoked to create Entity objects in the system. This basic version would not handle the update case, nor would it persist data.
Prepare the Entity model and related data models to allow imported Entities to be ingested in the database
This involves data model changes and relaxing data model constraints.
Persist third-party Entities
Add persistence to the new endpoints and the Entity data models
Implement update Entity functionality
Assure quality of Entity importing algorithm specification in ‘Project Aurora’ Technical Specification.
We need to make sure the proposed algorithm works as expected, especially with all the properties in the data model that are derived from the Entity mapping engine
Add Entity importing logic to new service
Any added complexity to this step is dependent on the prior step
Operational excellence and quality: end-to-end test functionality, write runbooks, add monitoring, logging, etc.
Required preparations for onboarding alpha users
Please note, steps 4-6 are critical for the system reliability of our Entity system. Up to point no. 4, the code produced will not create issues with ‘Project Aurora’ invariants and data model, as the changes are just additive.
Section 4: The problem, or why we won’t meet the deadline
At this point in the reader's journey, they should have all the context, and it's time to uncover the vicissitudes to the reader.
There is no easy way to communicate this timeline change, so I get on with it. I say, "We won't meet the original timeline". Once that's out in the wild, I explain the reason(s) for the timeline miss.
To explain the reasoning for the missed timeline, I handpick challenging items from the list in section 3. I then elaborate on their complexity. I try to tell the reader, "You see these tasks? They're much more challenging than we originally anticipated!". The explanations of each task's unforeseen complexity must be succinct and to the point. It should be effortless for the reader to get to the "aha!" moment.
An example from an actual document I’ve written:
4. Not meeting the deadline
After looking at the major milestones, the unknowns and risks that we’re facing and the remaining time (i.e. 1 month), the Phoenix team does not have confidence that we can deliver the remainder of the work by May 8, 2022.
We believe that a more realistic timeline is the 1st half of June 2022.
The following tasks proved to be more challenging than we originally anticipated:
Integration Complexity: we needed to ensure seamless integration of third-party entities with the existing system. This turned out to be more complex than anticipated, due to data incompatibility issues.
Data Mapping and Translation: accurately mapping and translating data from various third-party entities to the existing system's format turned out to be more challenging.
Performance Optimization: Maintaining optimal performance while importing and managing additional entities turned out to be very difficult.
Section 5: Going the extra mile
I could stop after section 4. After all, I've communicated and justified the timeline changes. But this is where I believe there's an opportunity to shine. Section 5 is where I show my stakeholders that we are in this together. It's not my team against theirs. It's us versus the project's complexity that we are trying to navigate ourselves out of.
So, how do I go the extra mile? I explain to the reader what steps the team will take to ease the situation and ensure the new dates actually pan out. Some ideas:
Improve the engineers' focus time on the project. For example, reduce their meeting time to the absolute minimum — or hand over other low-priority tasks. I talk with every engineer involved and try to understand how they spend their time. I clarify my intentions: I am not trying to micromanage but to uncover and cut distractions.It’s like pruning a tree — carefully trimming away the non-essential branches to allow the tree to grow stronger and healthier.
I express a willingness to absorb more engineers in the project team. Adding more people to the project is a classic go-to for managers, so why not proactively mention it? Adding new people late in the project often isn't good because onboarding them can take longer than finishing the remaining tasks. So, I add this part only when approved by my engineering lead.
Provide better transparency to stakeholders. I set up communication channels to broadcast progress updates depending on the situation. A typical example is sync meetings once or twice weekly, where the team will share progress and flag problems or blockers.
Sometimes, I like to schedule retrospectives proactively. Proactive scheduling shows stakeholders that my team has a growth mindset and wants to learn from our mistakes.
Stop giving one-off tasks to the people working on the affected project. I either field those requests myself or reroute them to team members. Or even to another team altogether. Handling these tasks is like a gardener meticulously weeding a garden; by removing these distractions, I ensure the team can focus on nurturing the main project without being hindered by less relevant tasks. Examples of these tasks are requests from sales or tickets from customer support.
I postpone team-building activities to avoid distracting the team on the affected project. I use this approach thoughtfully, considering the team's makeup and location. For instance, remote teams that last met in person a while ago might have their culture affected if I delay such activities for too long.
Have you got more ideas or suggestions? I'd love to read them in the comments!
An example from an actual document I’ve written:
5. Proposal
We understand that this creates issues with the timelines of the project, but we believe that we should be looking long-term and build the right thing, instead of rushing things through, creating pressure on engineers and (possibly) exposing ourselves to liability.
What we are happy to do to help the situation:
Remove obstacles and distractions for the engineers contributing to the project:
No inbound one-off requests or on-call work for the involved engineers until June 2022
Off-board involved engineers from interviewing until June 2022
Maximize engineers’ focus time by reducing meetings to absolute minimum
Limit community building activities, i.e. onboarding newcomers, until June 2022
Establish high-bandwidth comms and tighter collaboration between the teams
More frequent check-ins until we ship alpha
Hand over the Entity importing logic work to another team (e.g. Quantum team) to parallelize work
Move team on-site from May 2022 to July 2022, to keep the team focussed on shipping ‘Project Aurora’
Bonus: Talk about Risks
In section 4, it's also very worthwhile to reflect on risks. When one project starts, the project team identifies risks. These things can potentially jeopardize the project—for example, execution complexity, stakeholder alignment, inexperienced staff, and operationalizing or scaling concerns.
Reflecting on risks in section 4 is like a chess player anticipating moves. When a project starts, it's like plotting strategies and foreseeing potential threats - some pieces might be lost to unexpected moves. Connecting the missed timeline with these risks is like a chess player admitting, 'I saw this challenge coming, but it was trickier than I thought.' It’s acknowledging that even in a game of strategy, surprises can upend the best-laid plans.
Hopefully, the team has shared and documented the risks with their stakeholders. So, I want to connect the reason for the missed timeline with the identified risks (where possible). Connecting the dots tells the reader, "We said this might be tricky, and it did turn out to be tricky". I list risks that have materialized and give a sentence or two of context.
In complex projects, we often discover extra complications (a.k.a. unknown unknowns) that can derail a project. While disappointing, I must call these out too.
What happens when there are no identified risks, yet the project misses its timelines? In such cases, I send the message that, despite our best efforts, our plan was too aggressive or optimistic.
An example from an actual document I’ve written:
4. Not meeting the deadline
After looking at the major milestones, the unknowns and risks that we’re facing and the remaining time (i.e. 1 month), the Phoenix team does not have confidence that we can deliver the remainder of the work by May 8, 2022.
We believe that a more realistic timeline is the 1st half of June 2022.
The original plan had a set of risks that we identified that might affect the timelines, and some new, that have since materialized:
[Known] The importing logic was well-defined in the tech spec, but we still need to make sure it will work as expected.
[Known] The implementation phase happens during high-season period which will slow us down and cause us to not be able to hit all target dates
[New] Complexity stemming from the source field constraints changing and downstream effects on data model
[New] Multiple high-impact incidents on the Phoenix team, and time-off on the Core team, slowed down progress on the project; we had a sync where both teams communicated “no update and progress”.
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.
Until next time,
Ilija