& Continuous Learning

“Should we require two PR approvals, or is one enough?”

I've heard this debate at three different companies, and every time it turns into hours of discussion, Slack threads that seem to scroll forever, and a well-intentioned tug-of-war between people who value code quality and people who are desperate to keep momentum. Yet we rarely do the obvious thing: try one approach for a month and see whether defects rise or throughput falls.

Jeff Bezos popularized a useful way to think about this by describing one-way doors and two-way doors: a one-way door represents a decision that is essentially irreversible once taken, while a two-way door is a choice you can step through, observe how reality behaves, and then step back from with minimal pain if the results disappoint you. Most software decisions are two-way doors, yet we act as if every change is etched in stone. The idea appears in Bezos’s letter to shareholders, but the underlying problem shows up in nearly every hallway conversation and backlog refinement session I've seen.

How to spot a two-way door

When a decision stalls out, I ask myself a few things.

Can we undo this in a sprint? Like actually undo it, not "well, technically we could but it would require Neil to work the weekend." If reverting means heroics, it's not really reversible.

Who gets hurt if we're wrong? If it's just our team looking silly in standup next week, who cares? But if it's going to break production for customers, that's different.

Will trying teach us more than talking? This one's almost always yes. You learn more from two days of real usage than two months of whiteboard architecture.

If you can roll it back, the blast radius is small, and you'll learn more by doing than debating, stop talking and start doing. The meeting you're sitting in right now? You could have already tried the thing and moved on.

When it really is a one-way door

Most choices in our day-to-day work are flexible, but some carry commitments that reach across years, teams, and budgets. We recently helped a client select a data store not for one service or a single feature, but for an entire pipeline that would reshape systems and infrastructure for a long time. That choice doesn't snap back in a sprint, and pretending otherwise is a good way to discover pain down the road.

So we slowed the pace just enough to learn deliberately before we committed. We ran spikes with real production-shaped data rather than carefully curated samples from someone’s laptop. We pushed the uncomfortable edges on purpose: large aggregations with skewed distributions, ugly join patterns that only appear at scale, and concurrency profiles that match our peak load. We didn't want an idealized demo or a slide deck; we wanted to try and break it.

We executed the same workloads across multiple options, measured p95 latency, ingest rate, and storage footprint, and noted the day-one operational friction. Only after we had numbers, failure modes, and operational notes did we make the call.

Some doors deserve more care, not because we're afraid to open them, but because we respect what sits on the other side.

The experiment that failed (and why that was perfect)

At Source Allies, our internal interview scheduling process had become a bit of a circus. A recruiter would post in Slack, “We need a teammate or two to interview a candidate, they're available Monday and Tuesday from noon to five, who can help?” When hiring increased... messages multiplied, conflicts appeared, and rooms or equipment inevitably got double-booked. It felt chaotic, so we tried to be clever.

We proposed a shared calendar where teammates would mark availability two to three weeks ahead, assuming that we could simply slot candidates into those predefined windows and enjoy a calmer, tidier process. We set up the calendar, announced it, demoed it, waited for the magic, and heard crickets. Teammates preferred the ad hoc approach because it let them step in when they had genuine capacity or when an interview aligned with their interests, rather than making soft commitments weeks in advance. After a month of an empty calendar, we shut it down.

There was no post-mortem, no long write-up, and no hand-wringing. We reverted to Slack and moved on. We could have surveyed, formed a committee, and debated tools. Instead, we ran a small experiment and learned how people actually behave rather than how we imagined they would behave.

The same idea works in software engineering.

• Switch one service from REST to GraphQL and see whether your frontend team delivers faster.
• Try GitHub Actions with a single repository before any sweeping migration from Jenkins.
• Add a small Redis cache to the query that customers complain about most and observe whether response times move in a meaningful way.
• Move a pilot Lambda from Node to Python and compare deploy speed, cold starts, and maintainability after two weeks.
• Add Datadog to a single service and decide whether the additional visibility catches issues you would otherwise miss or simply adds noise.

Teams talk about these choices for months. Experiments answer them in days.

How to make more decisions reversible

If you want to build a culture where experiments are the default, a few habits make the loop fast and safe.

• Give every trial an expiration date. Actually put it on the calendar so you are forced to decide whether to stop, keep, or tweak the change rather than letting experiments become quiet, permanent residents.
• Pick one metric that is clearly tied to the outcome you care about. Think of examples like “deploy time improved,” “p95 under two seconds,” or “recruiters scheduled interviews more quickly.”
• Write the rollback plan before you start. Make sure it's boring and easy to execute. If reverting requires a multi-sprint effort you're not running an experiment, you're working with a one-way door.

What actually changes

Teams that practice small, timed, measurable experiments stop rehashing the same questions in every planning meeting. Items that have been stuck in a “considering” state for six months get proven or disproven in two weeks, and the persistent background anxiety fades because people know they can try something without being trapped by it. The most valuable shift is that you learn what your customers truly prefer, which is sometimes not what you assumed they wanted.

Your first experiment starts Monday

Pick one topic your team has discussed in more than two meetings, reframe it as a two-week trial with a single metric and a clear rollback, and start on Monday. Two Fridays from now, review what you learned. Resist the urge to schedule another discussion, draft a sprawling Confluence document, or form a working group.

Try the thing.

The worst case is that you spend two weeks and decide to go back. The best case is that you resolve a topic that has quietly chewed through months of collective attention. Even if it “fails,” you'll have real data and a shared experience, which beats a handful of opinions every time.

Be the person who says, “Let's try it for two weeks,” and then follows through.

Want to ship instead of schedule meetings?

At Source Allies, we help teams escape analysis paralysis and build cultures where reversible experiments are the norm. If you need a partner to run that first small trial or to reshape how your organization makes decisions, we've done it, and we know how to make it stick.

And if you want to join a team that practices what we preach, we would love to hear from you. Fair warning: our interview scheduling is happily ad hoc. We tried the calendar. The calendar lost.