I’ve lead several multi-team, multi-quarter projects that have consistently hit stretch goals, often with reduced staffing and constrained timeframes. I’ve driven some of them from idea to getting executive buy-in to planning and execution to completion. Others have been turned around from failing to successful after I was asked to intervene.
These are some of the lessons I learned along the way, both from personal experience as well as from other folks with a mixture of experience leading projects at a fast-paced, high growth tech company. I’ve included notes from conversations with my tech lead, a staff engineer from another org at my company, a senior engineer from a different org, a former teammate and a workstream lead on my team.
Unhealthy projects can have different symptoms like being off-track for their goals, having the wrong goals, lacking alignment with leaders or key stakeholders, lacking prioritization, not having adequate staffing, engineers who are burned out or on track to be burned out, high attrition of key personnel, a lack of a plan, an outdated plan, repeatedly breaking commitments, not having commitments from stakeholders, mismanagement etc. A project with multiple symptoms will likely fail without intervention.
It’s essential to turn a project that is failing around quickly and immediately. Wasting time isn’t going to help you if things are as bad as they are. First figure out why this project shouldn’t fail and if there are no good reasons it’s okay to fail. Try to do this gracefully with limited impact to the folks on the project.
Once you’ve identified the problems with the project, privately share a frank assessment with the project’s sponsor and be upfront about needing their support to turn things around. Focus on symptoms and options for addressing the issues rather than blaming people or things you cannot control. If you do not have leadership support, work on something else instead - you will almost certainly fail without backing.
A situation where key personnel are contributing to failure needs to be handled delicately. If their impact to the project success is limited, find something that they can work on within the project that insulates the overall success from any potential failures of their work stream. Work with your manager on a plan to give them the support they need for success. If their impact cannot be constrained (e.g., they are central to the project), find something for them to do elsewhere and provide an explanation and recommendation to the manager accountable for the project.
If the project is failing due to a lack of clear prioritization, this should be the first thing you work with stakeholders to establish. Once you have an ordered list of priorities, explain to stakeholders that everything except the top priority will potentially be dropped. Everyone involved in the project should have a ten second summary in their heads of the main thing that will be achieved.
Work with an expert already in the project to figure out a safe timeline for that first priority and how many people would need to be involved. Once that’s done, also figure out what it would take to achieve the second priority once the first is complete. If there are no experts that you can trust already in the project that should be the next thing you fix. Identify the specific needs of the project and the best person for this. Talk to them about the opportunity and if they’re interested, work with your manager and theirs to get them onboard. As an aside, it’s helpful to have an internal list of folks who you know can deal with any problem and develop a good relationship with them (e.g., regular one on ones).
In my broader org we aim to spend a week or so to come up with a plan to get a project back on track. As a forcing function, plan to involve a leader and put time on their calendar for a week from when you start. If things have gone well you’ll have a plan to present to them, otherwise you’ll have a list of problems that are preventing you from coming up with a plan and can ask for their support. It’s better to quickly admit that you are out of your depth and need help than stay off-track indefinitely.
Trust is especially important in a failing project. Let people in the project understand that they have your full support and let your stakeholders know that you will work to earn their trust. Figure out the outcomes you want and then see what processes can help with that. Stakeholders outside the project will likely have trouble trusting that things will get back on track and will potentially require process related changes. Agree to the process requirements that will help but push back on the ones that will hinder progress. Give folks working on the project a safe space to bring up any concerns with you in private because unnecessary process can kill a failing project. The staff engineer reminded me that “If you’re spending a lot of time on process, ask for robust support with those process requirements e.g., TPM assistance, explicit headcount requests, etc.”
There are broadly three healthy things you can do to get a project back on track: (1) ask for more time, (2) do less work and (3) utilize more people.
When discussing additional time there will be a temptation to ask for what you think sounds good rather than what you actually need. Don’t do that, missing a deadline extension will reduce trust in your ability to turn things around. It’s better to just be frank about how much time you need. The senior engineer helped me understand that “estimating work is hard when there are more unknowns and a lack of clarity around estimates makes it harder to evaluate risks”. The workstream lead on my team shared that proactively asking for an extension on a deadline makes for a more sustainable experience, even when the next point about scoping changes is utilized.
Doing less work has been the most successful strategy in my experience. A failing project cannot afford to spend time on anything that isn’t the most important priority. Within that top priority, figure out ways that you can achieve the same impact with less work. For example, avoid rewrites, extend existing systems or lean heavily on systems that have been built (or are being built) by other teams. When accounting for the cost of your changes to the plan don’t forget to include any long term costs or additional tech debt that you will have to pay down after the initial objective has been achieved. Make a plan for addressing that and get it funded now. Be extremely clear about any changes you’re making, document the reasons for doing so and the tradeoffs associated with the alternatives and get explicit buy-in from key stakeholders. My former teammate pointed out that when there are more asks than staffing can support it’s important to find out what sequence the stakeholders would like their deliverables to be provided in e.g., should all workstreams be worked on in parallel, do some deliverables need to be provided earlier than others, etc.
You’re unlikely to get more people until you start to show that things are turning around. Even if you got additional folks, it’s typically going to take them weeks or months to ramp up (there are some exceptions, see my note above on experts). Use this option only if the second priority cannot be dropped and cannot be scheduled after the first one. In my experience the best way to get more people is to take on a dependency of a project on another team that is already funded or nearing completion. It’s helpful to keep a running list of ongoing or recently completed projects in your head. Even if that system is not the perfect fit, it’s typically much less work (and investment from the org) to make tweaks to it rather than build an alternative specific to your project.
If one of your problems is the stakeholders involved, escalate to a private meeting with their tech lead or manager, in person if possible. Clarify that you are here to solve their problems and want them to understand you’re on their side but be frank about the problems you have encountered with them e.g., “I want to build a feature to support your system but engineer X on your team is not responsive because they have a lot on their plate and unhelpful because they don’t have familiarity with that system”.
Ask them for a specific thing e.g., “Please give me another engineer to work with or to support engineer X” and be upfront about the tradeoffs of not getting that thing you need e.g., “without timely and knowledgable assistance we will not be able to build this feature for you”.
I strongly recommend not viewing this as a conflict but as a challenging situation (for both parties) that you are partnering with them through.
On an unhealthy project you will almost certainly find that things go slower than expected. Spend your first few weeks analyzing progress to identify reasons for the slow down. If the engineers are overworked or have other responsibilities find ways to lighten their load. This can look like having a prioritization conversation with their managers and potentially a discussion with the project sponsor about the trade offs to the project. My former teammate said that in retrospect, a lack of clarity around where time should be spent should be addressed early with guidance from stakeholders.
In some situations you will find that the engineers do not have the support they need for the responsibilities they’ve been tasked with. Try to find that support for them (taking it on personally if necessary) and if you can’t, shuffle staffing around so that their responsibilities are more aligned with their capabilities.
I’ve found that when a large, important project is unhealthy there are typically systemic organizational issues in addition to other issues that are hindering progress. Making organizational changes is hard to do on a short timescale so your best bet is to look for ways to shield the project. If you have social capital in your organization (and you should prioritize building this), one approach is to insert yourself into the concerning situation.
As an example, if the organization has expectations like a heavy meeting load or status reporting process from engineers on your project, take the burden on yourself and explain that you will be the interface to the folks on the project. This is especially useful if you find engineers being asked to handle other responsibilities that are unrelated to the project (exceptional engineers are often in high demand). Ask to handle those responsibilities and loop them in only when you absolutely need to.
If there is organizational chaos (for example due to the external environment your company operates in) take on the hard job of stabilizing the situation as it relates to your project or at least limit the need for your project members to experience the chaos. Train yourself to become adept at planning to minimize disruptions from external situations. A recent experience involved re-scheduling things so that work that had limited risk of needing to be dropped was done up front, preferring to sequence more risky work after the organization had more information on the situation.
Aim to have a high level document on the project (one pager + FAQ section) in a few days that can be shared with key stakeholders. The staff engineer said “It was incredibly useful to think of an elevator pitch to describe the project in 20 seconds or less. Why are we doing the project, what problem does it solve and what will happen if the project is successful”. He also shared that sometimes it’s useful to write a quick prototype that works locally before producing docs or requesting reviews. This ensures there are no surprises meeting functional requirements and this skeleton can provide a solid base for more detailed work later. My tech lead agreed that a strategy of building an MVP is useful and noted the contrast with projects that wait for a complete plan, etc before writing any code.
Be humble when you get feedback on your plan and incorporate it ~immediately, asking clarifying questions if you are not entirely sure what the stakeholder meant. I say “just so I understand, you mean change X in this doc to say Y because of Z” aiming to be so explicit in that sentence that I can literally type it into the doc immediately after the meeting. The staff engineer shared that it was helpful to reach out to other teams that would be affected, to summarize the upcoming changes before they occurred and to bring any concerns out into the open.
A failure mode I’ve seen is for folks to plan for a long period, then go get feedback, misunderstand or ignore that feedback and plan for some more time before going back and getting the same feedback. If you see someone in your org struggling with this, put time on their calendar and pair with them till the feedback has been addressed. My personal strategy is if I have weeks to come up with a plan I give myself days to incorporate the feedback, and hours to update the plan if I get additional feedback.
At the end of planning, the staff engineer recommends having a written-down plan (even a rough one is better than nothing) with project metrics and OKRs. The senior engineer went further and noted that “doing a lot of planning upfront, spending time breaking work into tickets and working on estimates will be useful to figure out when things will be done”.
It’s important to figure out an investment that aligns with the project’s impact to your org. You’ll need to help the org understand the importance of the project and the tradeoffs you’ll need to make depending on how much investment it receives. My tech lead explained that support from the org’s leader was helpful to schedule a previous project against competing priorities. He recommends understanding how to get sign off on projects and not waiting around for someone to provide prioritization.
If you’re the only person on a project, evaluate whether this is because the project is not important to the org - if it that is the case, why are you doing it? The staff engineer was clear that a project that is solo for long stretches of time is generally not advisable and not something he or his team will repeat.
On the flip side, most of the engineers on the team shouldn’t be working on the project if it isn’t the main goal of your team. The senior engineer recommended working closely with managers to figure out resourcing and obtain clear commitments on staffing.
When folks onboard onto the project, have a private meeting and find out their career goals and interests. Figure out how their goals align with the project and see where they can be used best.
Figure out how to get org buy in on your plan and a show of commitment - this could look like a brief note in the updates provided to the broader org, passing an architecture review or similar, having the project listed in your org’s objective’s and key results or quarterly business review etc. The senior engineer shared that his org has a culture of managers working with leadership to decide priority and prevent projects from getting preempted.
My tech lead shared “Getting people excited [about a green field project] was very helpful. This resulted in folks sharing how they wanted to use it.” He also recommended having an internal page that folks can be pointed to when they have questions. “Don’t keep things in your head, write them down and share them. A single spot to explain the project can be a hub to put links to design docs, emails, discussion notes, status updates, etc.”
The workstream leader on my team recommended making JIRA tickets for every task you can think of and slot them into sprints. He also recommends planning goals at a sprint level (e.g., what will be achieved every two weeks) and keeping track of progress towards those goals. Additionally, getting comfortable adjusting milestones given new constraints and frequently communicating up and out.
Set up weekly syncs with your sponsor or key stakeholder and tweak the cadence as the project goes on. The workstream lead shared that frequent updates are very helpful to communicate progress, flag issues and request assistance where needed. If the key stakeholder or sponsor in your org is too busy for this, either the project is not a priority or they have a lot of confidence in you.
If it’s the former, have a brutally honest conversation about whether this project should be shut down, invested less in (e.g., do you actually need all those engineers working on something unimportant) or descoped (can you finish one thing this quarter and put it down?). If it’s the latter, consider meeting them on a less frequent cadence or providing updates in some other way. My tech lead explained that “over-communicating project status is extremely important”.
When building user facing systems try to get to a demo-able thing as soon as possible even if the demo doesn’t have to do anything. Ideally, have your sponsor or key stakeholder run the demo on their laptop. This is a forcing function to getting a working thing (even if it doesn’t do anything). You’ll find that you prioritize the user experience when your user is extremely important to your personal success.
Every week, aim to have one win, share the most important issue and request at least one piece of feedback. If you need assistance with something, try to unblock yourself during the week or at least come up with a plan. Be extremely clear when you share a problem as to whether you’re asking for help or not or just giving them a heads up. My former teammate mentioned that he’s been learning to communicate risks upward. He noted that there is sometimes pressure to only report good news but it’s very important to explain how stretched the he project is and how the deadline may be impacted as a result. In my experience it’s useful to remember that your sponsor or key stakeholder has agreed to meet with you frequently because they want to help. I recommend not being shy about asking for help if you actually need it.
Track who is working on what part of the project figure out where each workstream is every week. Ideally, do this on your own (I personally read PRs and logs from the system to see if feature X is complete) or have a low friction update from the workstream leader (e.g., I’ll ask them on my way to lunch or in our 1-1). Coach them to be able to give a 20 second summary of progress / challenges at any point - this is something you should also be able to provide anyone who asks you.
The staff engineer recommends maintaining a sense of the bigger picture and where the project is at regarding the overall arc: at any moment, be able to give a current snapshot of the project and a best-effort estimate of the project.
It’s useful to compile a brief technical update (one bullet point per workstream) every week even if none of your stakeholders care about this. The senior engineer shared that a large project they were in had an internal weekly sync to discuss estimates and evaluate them against the time remaining before the deadline. Even though estimating was challenging and there wasn’t always clarity about how accurate they were, this regular process allowed them to clearly identify when a project was at risk and surface this to stakeholders.
A dependency graph is useful to understand which workstreams of a complex project need folks and which ones are blocked until later. My former teammate shared that some of the workstreams on a project he lead met twice a week for about twenty minutes. They spent this time talking about what’s going well or poorly and used the meeting to help each other. This meeting was not just about reporting status and some weeks it was moved async instead.
If multiple teams have cross-team dependencies you should aim to get out of this situation in a quarter. In an ideal situation, each team is responsible for a certain part of the project that can succeed or fail on its own. TPM assistance has been helpful to get to this point in the past.
Periodically analyze the project and identify where you (or folks on the project) need help. If this involves work you are not excited about or equipped to do, request additional assistance early.
Escalate quickly if the project is running into friction with blocked dependencies. I give a Slack message about a day or so and a JIRA ticket a few days before requesting a meeting to unblock. Write out an agenda before the meeting with the key outcome you’re driving to and a list of questions you have to get there. Share the agenda early in case an async resolution is possible. It’s worth it to the org to have that meeting if half an hour of someone else’s time can save your project days and unblock multiple engineers.
Figuring out the person to reach out to is useful as well. If it’s an engineer on my project having trouble with an engineer on some other team, I help them set up the meeting but let them drive it, only stepping in to moderate the discussion and prevent things from going off track. If the project is running into trouble with an entire team, I will contact the tech lead and if necessary, meet privately with them or their manager.
Learning to complete projects well is as important as (or even more important than) the other parts. The staff engineer reminded me that it’s good to finish migrations even though later stages will take longer than you like. It’s easy to leave a migration at 90% but determination can make for a better outcome without tech debt. As a project shifts from writing a service to infrastructure buildout to a migration the scope and expectations around timeframes will become less clear. It can be challenge to develop a timeframe against which to evaluate project status but that can be mitigated by investing effort as a team.
I recommend wrapping up projects before the org loses interest / decides the investment is not worth it. At certain orgs things change pretty rapidly so do a periodic analysis (I do this once a week or two) about whether we should wrap things up soon or not. The senior engineer shared that having folks rotate in and out or having part time availability is a sign that the project should be wrapped up.
Aim to send out an announcement email, and have users use the new thing you built or roll out the new system in production. Have a retro and a celebration! This could just be a short meeting or a slot in one of your existing team meetings. If everyone is in the same office, consider bringing cake or some other act of thoughtfulness.
Take time to meet privately with the folks who worked on the project and express appreciation for the assistance they provided. Write feedback for everyone, remembering to include how they’ve experienced growth through this project and how they used their skills to make it successful. If applicable, make sure that this project can be used as an example for their promotion.