You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 6 minutes
Key takeaways:
- Advocating for your team and advocating for a project are not the same thing. Defending a struggling project can deprive your team of the chance to work on something more impactful.
- A shared rubric turns a painful conversation into a principled one.
- Kill the project before it kills momentum. Making the call early doesn’t damage morale – it comes as a relief.
Most engineering leaders have learned to advocate, tenaciously, for the projects their teams work on. We tightly couple our team’s success to the success of every project we ship. That instinct is right, but only to a point. Left unchecked, it becomes a trap.
Our job is to be the strongest advocates of our teams. Not of our projects. It took the loss of a project I had defended for years to teach me the difference.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Mistaking tenacity for engineering leadership
Several years ago, I was leading a project at Google that started with very ambitious goals and strong executive support. I had the great fortune to work with a strong team to build a new vertical search experience for an underserved travel sector, get partners excited, and help users find the great vacations they were looking for.
However, a couple of years into the project, we were facing a number of external and internal headwinds. The initiative wasn’t failing, but it wasn’t quite winning either. I instinctively kept advocating for it, thinking that was the best way to serve my team through that period, until an external crisis – the COVID-19 pandemic – forced the cancellation.
Over the following months, I spent a lot of time processing what had happened. I felt disappointment initially, and I focused on helping everyone on my team land good opportunities – partly to avoid processing my own grief. However, the more I thought about it, the more I realized I had mistaken my tenacity for leadership.
I didn’t feel defeated. I felt guilty. By advocating so effectively for the project, I had unintentionally deprived my team of something more precious: the opportunity to work on something more impactful.
Building a rubric for project decisions
Years later, I had another opportunity for a fresh start. I was asked to build a team to tackle a set of broad sustainability objectives within Google. We were given extreme autonomy while embedded in a product organization that had different metrics and objectives. The mission attracted exceptionally talented individuals who were excited by the purpose of the work, a luxury hard to come by – even at a company like Google.
As is often the case with a dream team working in an unconstrained domain, the danger is not lack of ideas: it is an excess of them. This was especially true as the team grew. We were no longer constrained to an individual project; we were an organization pursuing a long-term objective.
When it became clear we needed a way to choose between ideas – many of them dear to team members and stakeholders – I spent a few hours sketching a “back-of-the-napkin” rubric for evaluating new projects.
I didn’t want to introduce more bureaucracy, but I believed the team needed shared logic and vocabulary for debate. This enabled us to balance passion and rigor. Anyone could propose a new domain. A quick review would assess whether the idea had legs, and the rubric gave us a shared way to compare options.
The team evaluated a wide range of ideas, from helping users gauge the environmental impact of their travel, find better answers to their recycling queries, locate EV chargers on road trips, and pick more sustainable restaurants, to helping commercial airlines trial strategies to avoid forming condensation trails.
For each new idea we’d run through a standard set of questions. We’d keep the answers brief. We didn’t want anyone to get too invested in an idea that we might not pursue.
More like this
Some of the key questions we’d ask were:
- Theory of change: what is the specific causal link between this project and the outcome we care about? How does our technical work connect to the ultimate goal?
- Metric: which of our key metrics is this project supposed to move? For metrics that we can’t observe directly, can we establish leading indicators to tell whether it’s working?
- Why us: do we have a unique lever here, or are we just playing startup?
- Opportunity cost: what are we giving up to pursue this? Do we have to divert attention or staff from other high-priority work?
As is often the case, the hardest part was the people. Engineers often sense when a project is a “zombie” – a project that isn’t yielding results, but keeps absorbing time and resources as the team chases “one more idea” rather than stopping – while product and UX partners, rightfully invested in the vision, tend to be slower to let go.
Thankfully, the rubric shifted the conversation from personal bets and pet projects to collective impact, letting us disagree on specifics while agreeing on principles.
As we had done the work of aligning on the outcomes we cared about, the criteria for evaluating opportunities, and the goals we chose to pursue, we could debate the merit of individual projects while staying mindful of the team’s scarcest resource: time.
Making the call before it’s made for you
The rubric got its hardest test when the team was a few quarters into a highly visible initiative. We wanted it to work, but the experiment metrics weren’t promising. The team was staffed around the project, and we consistently had “one more idea” we wanted to try for months.
Every time I looked at the team’s portfolio, I thought about my experience years earlier. I didn’t want to be responsible for a team pouring their energy into an area I was beginning to doubt.
Thankfully, we had the rubric. I flew to Zurich for our cross-functional leadership meeting and put the project on the agenda. I made the case: the experiments weren’t moving the needle, the next iterations kept hitting the same issues, and we couldn’t, in good conscience, keep asking the team to invest more. We needed to stop and redirect them to work on something more promising. There was a long silence.
There were plenty of reasons to resist – sunk cost, team identity tied to months of work, and stakeholders who expected us to keep going. The hardest reason was the fear of disappointing a team that had poured months of their careers into the initiative.
New York • September 15 & 16, 2026
Delivering AI results without a playbook?
Find what’s working at LDX3
As we walked through the rubric together, the case became clear: the theory of change was robust, but we weren’t seeing the metric move, and the opportunity cost was too high. We agreed to wind it down.
To my surprise, our decision to cancel the project didn’t bring the trauma I feared. Instead, the team responded with relief. They knew they were “limping,” and the cancellation gave them permission to pivot. Two years later, the same group is thriving on high-impact work.
I took that lesson with me. Our job isn’t to protect projects – it’s to protect the “impact-per-hour” our best people can produce. As team leaders, we’re responsible for noticing when our investments aren’t paying off, and refocusing the team’s attention before external forces make the call for us.
