Designing for Drift: How to Keep Complex Projects on Track

Building a system that embraces uncertainty, distributes ownership, and surfaces risk early

“Ali, you need to get better at escalating.”

The words from one of my company execs landed like a gut punch as I sat in our virtual meeting room, stunned. One of my major initiatives was approaching a free fall and I was at a loss.

Just a week earlier, I had every indication that we were on track. Now, all our milestones were red, leadership was not happy, and I felt like I was stuck in the middle of a slow-motion train wreck - trying to wrestle us back on track even as the wheels were flying off.

How did we get here?

The Illusion of Green

“How did you go bankrupt?” a character asks in Hemingway’s The Sun Also Rises.

“Two ways,” comes the reply. “Gradually, then suddenly.”

It wasn’t one big mistake that took us down, but a series of small misses and assumptions that snowballed into something unmanageable.

Our integrations product was complicated: layers of back-end work invisible until months down the line, a variety of user types and scenarios demanding a flexible front-end, registration portals, integration guides, partnerships, bleeding-edge standards development - you get the idea.

Despite this complexity, I felt reasonably comfortable. I’d done the market research, conducted interviews, ran mockups by our end users, even gone in and touched the code myself. The engineers appeared confident too - consistently reporting green on our milestones week after week.

As these things go - everything looked great - until it didn’t. Near a critical ship date, one of our engineers stumbled across a single line in the standards specification, a footnote we had previously glossed over.

Digging into it revealed the need for a critical feature that hadn’t surfaced in user research - and one we weren’t even sure was technically possible to support.

At the same time, our estimates began to slip. November turned into January, then February, then March. Plus as it turns out, not hearing from leadership when things were green didn’t mean they weren’t paying attention. As I communicated the delays upwards, my inbox flooded with confused and urgent messages.

I turned to my engineering team, desperate for answers, a new plan - anything - which is when I discovered that we weren’t even aligned on what our status colours meant, let alone that the status was being broadcast up the management chain.

To my team, “green” meant the proof of concept was working. To me, it meant customer-ready. Making matters worse, because the team had observed that non-green status stressed me (and by extension the team) - status was often reported as “green” even when the targets were risky.

Well well. A mighty big hole we’ve dug ourselves into.

Specs Drift. Plans Break.

The truth is, no matter how much you plan, projects drift. Requirements change. Estimates slip. Surprises emerge.

You can try to plan everything up front, but if you want 100% certainty, you’ll essentially have to spend as much time planning a project as you would just building it. Even then, changes are all but guaranteed when the rubber hits the road.

At the time, our development process followed what I understood to be a traditional agile approach: a mega PRD at the outset with major milestones spread across biweekly sprints.

The responsibility for identifying risks, communicating status upward, managing interwoven timelines and resources, and absorbing scope creep rested almost entirely on me (and by extension, my Engineering Manager).

In retrospect, it’s easy to see why a system that piles the burden of managing drift onto one person is doomed to either make that person’s life miserable, implode, or, in my case, both.

So… we threw it out. (Mostly.)

Designing for Drift

We asked ourselves: if drift is inevitable, what would it look like to design a system that embraces it instead of denying it?

1. Redefined Milestones, Status, and Ownership

Though Product still defines the milestones - and Engineering still owns the technical plan, we needed a better way to align on what we were shipping, distribute risk management, and communicate a clear sense of progress - without drowning folks in meetings or process.

To start, every milestone must now have a clear exit criteria - aligned with delivering on actual impact/scenarios as opposed to completion of engineering work. No more “rolling bucket of miscellaneous tasks” epics. Instead of “make integration more reliable” - we divvy it up into specific projects, each with a measurable impact.

Next, no more emotionally-loaded coloured statuses. Instead, Engineers report on ETA with a +/- confidence window. Rather than saying “Yellow for August 15th” - we would report “August 15 +/- 2 weeks”, or “August 30th +/- 3 days”. This puts the engineering team much more in control of their timelines and also makes it easier to assess progress, risk, and communicate status.

Finally, to mitigate potential meeting creep or micro-manage-y update polls - we implemented an asynchronous reporting system. At the end of every week, engineers report on their milestones, their ETA, work completed - and critically, any forecasted risk they anticipate to the milestone or overall timelines.

The combination of these ingredients is crucial - we remove the emotional burden & ambiguities of status colours, distribute the ownership & thinking around risk management, and are all aligned on impact-focused exit criteria.

2. Asynchronous Sprints & Self-Managed Tasks

We observed that our daily syncs had become time sinks. Paying attention in a virtual stand-up is challenging at the best of times, and when one project starts to slip, we’d rat-hole into debugging, causing the rest of the meeting to suffer.

So we looked around the company to see if anyone had cracked the code - and found our answer. Instead of mandatory virtual stand-ups, we spun up an offline check-in channel on Slack. Every morning, both engineers and PMs share what they’re working on, what’s next, blockers, risks, and discussion topics.

Discussions that actually require live conversation happen in daily parking lots, with a weekly one-hour slot reserved for spec reviews and deeper technical topics.

Finally, at least as a PM - I don’t bother with story points or micromanagement. As long as all work is captured in JIRA, and our epics are well defined per the previous section - I trust engineers to manage tickets.

My role is to watch the milestone updates and make decisions based on the risk forecast.

3. Decision Logs

Big specs don’t survive the reality of drift. In fact, I’m increasingly of the opinion that large specs are less of a roadmap and more as a tool for understanding the problem.

Nonetheless, complex projects inevitably involve decisions that aren’t captured in the original spec. And just like contracts in real life, you can’t cash a handshake or a verbal agreement at the bank.

Capture updates to your thinking, plan, or product in decision memos—and compile these memos into a decision log. Paired with the milestone format, this creates a single source of truth.

4. Get Signal Early, Get Signal Often

One of the biggest mistakes in our project was waiting too long to see evidence that things were actually working. With so much back-end work, I was mostly relying on engineers’ word for whether features would function - or waiting for the front-end to catch up before we could even test. This made decision-making nearly impossible.

The fix is simple: expose the back-end as early as possible - through the front-end, a console, a simple interface, or even Slack updates. Encourage engineers to post proof of progress asynchronously as they work. Early, frequent signals let you validate assumptions before they become problems.

The same principle applies to users. Validate early and often. Don’t wait to ship a “perfect” product - you risk missing something critical, or worse, building something no one actually wants.

5. Be Kind

While working to get the project back on track, I drafted a retro on the missteps we’d made. When I shared it with a few close stakeholders, one of them said something that stuck:

“If someone else wrote this about you, it would be cruel.”

And they were right. It’s easy to fall into the trap of self-blame, especially as a leader - but projects are a team sport through both the good and the bad.

Drift is inevitable, surprises are inevitable, and mistakes are inevitable. This is how we learn. Being kind - to yourself, and to your team - isn’t a luxury. It’s part of building a sustainable system that works.

You Can’t Make People Smarter, But You Can Make Systems Smarter

No project runs perfectly, and no plan survives reality. Drift, surprises, and misalignments are part of the game.

The goal isn’t to eliminate uncertainty. The goal is to build a system that can absorb it without collapsing. For us that meant leaning in to everyone’s strengths; distributing the tasks of ownership, risk forecasting, and reporting across the team - and responding to surprises with both kindness and a written plan of action.

Although our integrations product did inevitably get delayed, this system helped us work together and get the train back on track for a Spring release. I’ve since taken this playbook with me to other companies - and with some minor tweaks it has continued to serve me well.

If you’ve experimented with drift-resilient systems - or built your own - I’d love to hear about it! Please feel free to comment or reach out.