For those companies, (and for startups for that matter) the future technical debt of moving fast creates major problems.

We see this in Facebook itself as in 2014 the company walked back the mantra, switching to “Move fast with stable infrastructure.” Not as catchy. Not really the thing that can be shouted on the rooftops of silicon valley justifying poor development in the name of “proving out an idea”. So… was it adopted by venture capital folks? Of course not— investors, to this day, are still quoting the original. For them, and for the larger companies that want to mimic the environment of startups, I propose a new mantra: “Move fast and break things… deliberately.” Breaking deliberately means deciding what to break—and, just as crucially, what must stay intact.

The analogy I’ll be using in this article will compare tech debt to car maintenance. I was skeptical it would work at first, but I like of like it.

TL;DR

• Mantra upgrade: Move fast and break deliberately—speed is good, aimlessness is not.

• Tech‑debt flavors: deliberate, accidental, bit‑rot, documentation, testing, architectural.

• Rule of one: tolerate exactly one debt bucket when moving fast and document the deliberate debt you’re accepting.

• Don’t accept more than one type of technical debt at a time

• Bottom line: plan the mess you’ll clean up later, or the mess will plan your roadmap for you.

What Is Technical Debt?

(As always skip this section if you’re familiar with the general breakdown of technical debts)

Technical debt is the future cost of today’s shortcuts—refactoring time, bug fixes, lost velocity.

I believe technical debt comes in six flavors, and they’re each handy for a product manager to be familiar with as they are asking their development team to rapidly deploy things.

• Deliberate Debt – chosen shortcuts for speed with a cleanup plan.

• Accidental Debt – low‑quality code from inexperience or unclear requirements.

• Bit‑Rot (Outdated) Debt – aging frameworks, libraries, or stacks that lag behind standards.

• Documentation Debt – missing or stale docs that slow onboarding and maintenance.

• Testing Debt – sparse automation that raises bug risk and manual effort.

• Architectural Debt – structural compromises that strangle scalability and performance.

How do these debt types map to cars?

• Deliberate Debt – “I can drive a few thousand more miles before an oil change.”

• Accidental Debt – A buddy promises they can paint your car a new color using oil paint. Occasionally, (hopefully not often) you drive through the wall of a grocery store and start a fire that needs some help from others (fire fighters or SRE’s).

• Bit‑Rot Debt – after years on the road, newer cars boast better mileage and features.

• Documentation Debt – not registering your car on time, misplacing service records, or forgetting tire size at purchase time.

• Testing Debt – skipping regular tune‑ups and safety checks.

• Architectural Debt – fitting diesel parts in a gas engine: everything goes brrr… broken.

Which Debt Is Worth Accepting?

Rule of thumb: never incur architectural debt. Architectural debt is a sign of moving too fast and breaking too many things and is likely the key reason Facebook changed it’s mantra to the 2014 mantra of, “Move fast and code with good infrastructure”. Architectural debt can force heavy rewrites and will thwart all future efforts of moving fast in the future. Move fast… but don’t put nos in your engine when you have a 1992 Honda Civic.

Accidental debt happens, and will happen more if you go fast, but it there’s not much we can do about it, so ignore it in the calculus.

Otherwise, choose one other debt bucket to tolerate; guard the rest ruthlessly. This is important. It will feel like you can accept more than one of the debt types while you are coding, but doing so will stymie your ability to move fast in the future.

Option 1 – Documentation Debt

Skip docs only if code is future‑proofed and well‑tested.

Choose this when…
• Your domain logic is stable and unlikely to pivot next quarter.
• You have rock‑solid unit/integration tests catching regressions.
• The team is small and tribal knowledge can spread over coffee.
• You can schedule “doc‑catch‑up day” before the next big hire.

Red flag: Multiple time‑zones or imminent onboarding? Don’t trust on tribal memory—write the docs.

Option 2 – Bit‑Rot Debt

Ship disposable experiments quickly; document them and keep tests green so you can revert safely.

Choose this when…
• You’re A/B‑testing UI tweaks or feature toggles with a short half‑life.
• Market fit is hazy and learning speed beats code longevity.
• Your rollback plan is tested and one‑click.
• The experiment lives behind a feature flag you can yank at will.

Red flag: Core domain or revenue‑critical path? Build it to last, otherwise you’ll be moving too fast and will be too highly depended on in order to go back and fix the… choices your team made.

Option 3 – Testing Debt

If tests are costly now, invest in rock‑solid design and thorough documentation. Buy time today; plan automated coverage for tomorrow.

Choose this when…
• Setting up CI/CD or mocks would delay a funding‑critical demo.
• The codebase is modular and manual QA can cover edges for a sprint or two.
• You have veteran engineers who write defensively and log obsessively.
• You’ve budgeted a “testing sprint” on the roadmap (and leadership signed off).

Red flag: Rapid‑fire releases or multiple parallel feature branches? Skipping tests will bite—invest early.

The Gamble of Stacking Debts

So what if you throw caution to the wind and accept two—or (you daredevil) three—debt types at once?

A table for those of you considering this… novel approach.

Your debt stacks multiply. If you accept more than one of these technical debts in a project, cognitive load rises, bugs hide and won’t be found via testing, and every roadmap estimate secretly inflates. Stack too many and your “move fast” turns into drive through a lake and wish you had a boat.

My Garage is Already Messy

The goal of this isn’t to remove tech debt entirely, but it is to document it and ensure that it falls into the “Deliberate” tech debt scenario. If you are about to touch a section of code that already has say, poor documentation, then as you move through it you will already have to take time to understand it… why not add that documentation as you go? Fix, or iterate, on the major sections of tech debt as you perform spikes for the next section of code where you want to move fast. You won’t be able to break things deliberately if you don’t know the full scope of the code you’re about to break.

Documenting (from a technical perspective) the deliberate debt you want to incur during the move fast period is key. That way when you hop back in you know exactly where the deficiencies are and you can continue down the path of that single deficiency (if you absolutely have to) or you can perform micro improvements on that dataset as you figure out the next deliberate thing you want to ignore.

It’s important to note that when you move fast, you do make sacrifices. The ideal situation is that you can handle all aspects of these debts as you go, via “boom” and “bust” periods of development. Think of it like the seasons and code quickly in the sprint, and slowly in the winter.

That way your repos engine won’t shut down right as the warranty expires.

For the purposes of this article, your product manager and tech lead have taken the time to refine; they’ve added every edge case to the acceptance criteria (AC) of each ticket, and the team has agreed on appropriate story points for each ticket to accomplish those ACs.

Now that we have that hypothetical scenario (no matter how unachievable it is to have perfect tickets), how do we take those tickets and plan them out for a sprint? There are some common errors when it comes to sprint planning, and I think they parallel nicely with the errors a kayaker might make.

TL;DR

If you are one of the few who blindly accept advice without reading the rationale, here’s your section. But the kayak + sprint planning analogy below is fun - so give it a read.

1. Assess the importance of specific tickets included in the sprint

   • Make sure the highly important tickets are distributed across all team members so they can work on them in parallel

   • Pair mission‑critical tickets with your most experienced engineers to protect timelines.

   • Assign low‑priority tickets to individuals who have less experience in the area

2. Focus on impact rather than achievement

   • Don’t aim to close out your sprints with 100 % completion on all tickets (This is the core concept I outline below)

3. Systematize getting rid of the chaff

   • Evaluate all overflow tickets (tickets which have carried over from the previous sprint) and remove unnecessary AC or execute on them with priority at the start of the next sprint.

What is sprint planning?

(Skip if this is familiar to you)

Sprint planning is a core agile planning ceremony where teams commit to work for the next iteration. The sprint planning is the assignment of tickets to engineers to complete within the sprint window. It is a key component because it offers the product team insights into what might be completed at which time & it allows them to escalate those timelines to their constituents. It also is the key point where agile offers engineers the opportunity to expand their knowledge. Assigning the same tickets (ie: salesforce tickets always go to Sally) to the same people allows for specialization, but that comes with its own risks.

The completion percentage of these assigned tickets will be used at the end of the sprint to assess the “Sprint Health,” and the story points completed will help the team figure out their relative velocity. These metrics anchor both agile planning forecasts and stakeholder confidence. If your team doesn’t use story points (they can be pretty hotly debated in their value) read my upcoming article on their value & failure points.

Kayak Style Planning: Ride the Current

There is no better comparison (there may be, but I’m unaware of one at the point in time) than comparing the serenity of kayaking to sprint planning. Back in 2010, I went on this sea‑kayaking trip in North Carolina’s Outer Banks. It was my first time kayaking for any long period of time and I didn’t realize how it would help me to understand sprint planning later on in life.

Don’t close out your sprints

Aim for 70–80% completion with your sprint tickets each sprint.  When you’re kayaking across a river, you choose a single point on the opposite river bank and you mercilessly aim for it. If you aim directly at it, you’re not going to hit it. You have to take into account the current of the river.

But the river’s current is fluid; it’ll change season by season and even if you nail the current exactly, you still might miss the point because you forgot to take into account the wind.

Let’s say you’re an expert kayaker and you nail both wind and current estimates perfectly; in that situation you may hit the other bank exactly where you’re aiming… but was it worth it to spend the time calculating the exact speed of the wind and the exact change in the current in order to hit a specific point on the other side of the bank?

I doubt it. The same holds true with sprint planning.

With every ticket, you are going to come across situations, edge cases, pieces of the ticket which need to be rewritten, or CSS fluff that doesn’t necessarily lead to a better outcome. Don’t let the idea of hitting all of the AC’s be the overall goal of every individual ticket. If you do, you’re going to over‑plan your sprint.

But engineers (myself included) are notoriously terrible at getting their heads out of the weeds when they start driving through acceptance criteria. In a ticket made of 10 small things, doing the next small things isn’t going to make a terrible difference, but a team of team folks doing one small thing that isn’t really necessary to make sure the kayak hits the other bank isn’t a good use of time.

So how do we force engineers to efficiently prioritize? How do we force them to question the value of AC’s and ensure that their goal is to generate the most impact possible in a ticket following the spirit of the ticket, rather than having a goal of completing each and every AC?

Deliberately over‑commit so the team normalizes healthy, data‑driven misses. Every single sprint, we are going to fail to meet our goal of closing out every ticket. We are going to talk about what we miss, and we are going to see which misses were justified and which need to be carried over into the next sprint. But you should never give them tickets that are expected to be 100% completed. That ensures that you are going to waste time doing things that are not necessarily worth the value.

If we set goals that are not achievable, we are still going to make it to the opposite bank, and then afterwards we can discuss if we can take into account the wind or the current a little more in the next sprint. Not with the goal of reaching 100%, paddling that last 30% is the most exhausting because no matter what you are going to be going against the current at some point. It’s the final‑mile problem of delivery trucks manifesting in the sprint planning process. So over‑plan, under‑deliver, intentionally.

On that kayaking trip, when we hit the other bank, we didn’t care if we landed at the exact point we aimed - we only cared that we landed in the general area we were hoping. And when we missed our that exact point, we certainly didn’t carry our kayaks up the bank to make sure we camped there.

Priorities change and should be re-evaluated, and the process of planning should change too. When you have 1 acceptance criteria absent out of 7 at the end of a sprint, that single acceptance criteria can now be evaluated against the value of the new tickets that can be prioritized. If you are running a quick and iterative agile process, new tickets can be (and should be) prioritized over that missing AC.

But can project timelines be calculated?

Velocity. Even with this strategy, your velocity will not adjust negatively.

We have three driving forces that expedite velocity with this approach.

1. If an engineer completes tickets early, they know exactly what to work on next.

2. It fosters healthy conversation during active development about the cost/value of specific AC’s

3. It doesn’t impact impact planning if velocity used.

The key factor that all product managers should use when planning is velocity. How many story points can the team complete on average every sprint? That value would in no way be adjusted if you over-assign a sprint assuming 80% completion.

As long as the PMs use velocity as the key metric, and acknowledge all tickets planned will not be completed (outside of that velocity), planning is in no way negatively impact.

Conclusion

Hitting an exact point on an opposite bank is a waste of time. Aim at a general area, get there, and evaluate if it’s a good enough spot to set up camp. If it’s not, move a bit, if it is… set up camp and don’t think about it again.