I've always had the mantra that it's better to ask forgiveness than permission. The original quote is generally attributed to Grace Hopper. She spent her career battling bureaucratic inertia while developing early programming languages like COBOL, and she is often quoted as saying: "If it's a good idea, go ahead and do it. It's much easier to apologise than it is to get permission."
One of the biggest things I'm seeing right now in teams working with AI is how the old ways of asking permission slow down both engineering velocity and, in some cases, innovation.
By the old ways, I mean the tendency to have pipelines and processes full of box-ticking exercises. This applies to life more broadly, but I digress. Those ways of working are dated, bloated and cumbersome to the point that they stall productivity. Even if you set aside the new normal of agentic practices, you still end up following trails left by veteran coders because "that's the way we've always done it".
I'm not saying you should never ask permission, but I've experienced plenty of occasions where a permission-seeking culture erodes the ability to move fast and deliver quickly. You get bogged down trying to win over others, and waste time and energy on things that simply lead to burnout.
Two mindsets
In software engineering, "Easier to Ask Forgiveness than Permission" (EAFP) and "Look Before You Leap" (LBYL) are two contrasting coding styles, both well known in the Python community, and they also work as a metaphor for two mindsets teams can have when building software.
LBYL
LBYL favours preventing every failure before it happens, and generally seeks consensus first. As you can imagine, this is a slow process. The idea of getting many voices in a room to agree on one thing sounds daunting in itself.
You may have worked in, or still work in, an organisation that pushes Requests for Comments (RFCs), architecture reviews and management sign-offs. This is where getting features out really stalls, and innovation is stifled, because you are driving decisions through rigid pipelines to reach consensus before you can continue.
Maybe you work with people who are highly risk averse: a senior engineer who challenges that 1% edge case, or an engineering manager who always asks for timeline estimates or the potential blast radius. All of this leads to analysis paralysis.
Now you need time on the roadmap just to start building the evidence and getting buy-in. This isn't the feature itself; it's just the case for getting the solution onto the roadmap, potentially in the next quarter. Your blockers are now wait times on responses, time zone syncs, and teams with other priorities, so focus shifts. Or you find the one person who worked on something similar previously, who throws in a left-field proposal that you now have to argue against like a game of table tennis.
Finally, you see the light at the end of the tunnel, but it's not over yet. Your solution is on the roadmap, only to be pushed back because it's not considered a high enough priority for the business. Possibly there's political alignment to sort out between teams or platforms, leading to ownership dilution. Maybe you're the issue: you've started work on the feature and found problems you couldn't have foreseen without starting to code the thing. Now you're paralysed over which direction to take, and whether it means updating all the evidence you gathered.
EAFP
EAFP optimises for speed and handles errors gracefully, as if you expect them.
This will obviously sound biased, and it is. It's probably also obvious that this style opposes the former in every way.
I'd be naive to believe that all teams follow the same approach, or that even a whole company follows every step of the satirical process I've detailed above. Some of what I mention now is clearly practised by teams in some form.
Answering risk aversion with recovery mechanisms, such as rollbacks or over-the-air updates, allows you to invest and build forward without constant fear and a lack of faith in your processes. This isn't a silver bullet. Things will slip through, and observability will come in handy there. But it offsets a lot of the risk cost when making proposals.
You can write a proposal or simply create a prototype; a picture is worth a thousand words. A working example gives the naysayers an idea of what it could look like, as well as a realistic timeframe (always an estimate) for development.
This, coupled with feature flagging and canary deployments, really kicks things up a notch. In most cases it's enough to put something into production for a subset of users and A/B test the hell out of it. That gives you live data and metrics to validate your claims easily, and it costs little to nothing when you can simply kill the feature if things go sideways.
The final part of this mindset, which I've touched on, is observability. It lets you evaluate the data and spot issues early through fast feedback loops. Post-mortems and debugging also play a role here, as you have a proof of concept to iterate on. You can take constructive criticism and feedback and use it to develop the idea into a product, gaining buy-in along the way.
Which to choose
When teams operate entirely under a "permission" model, innovation stalls and, in my opinion, burnout follows. Engineers spend more time writing technical specifications, documenting architecture, waiting for Slack approvals and sitting in "could have been an email" meetings than they do writing code.
When you zoom out from the code, EAFP isn't just a programming style; it's a powerful cultural shift for software development.
Balancing deadlines, legacy code and corporate bureaucracy, adopting an "ask for forgiveness" mindset is often the difference between shipping disruptive features and drowning in a sea of admin.
Some of the best tools in tech were built by engineers who didn't want to wait for sign-off. Without them, the performance improvements and internal tools you use every day wouldn't exist. They saw a problem, rolled up their sleeves and built a solution to showcase what could be achieved.
EAFP isn't an excuse for reckless engineering. You cannot simply rewrite the core payment gateway on a whim and say "my bad" when the company starts losing revenue. You still need all the technical safety nets to land on. Bear in mind that forgiveness is only cheap when the cost of recovery is low.
The two-way door rule
Popularised by Jeff Bezos, the two-way door rule says most decisions fall into one of two types: "one-way doors" (irreversible, high-consequence) and "two-way doors" (reversible, low-consequence).
If you're planning to migrate cloud providers or an underpinning architecture, that's a one-way door. Look before you leap and seek permission.
If you're refactoring something benign, like a clunky helper function, or trialling a new open source library, then EAFP applies. Test it out, and if it doesn't pan out, walk away.
Shifting the cultural default
Asking for forgiveness requires management to have high trust that engineers understand the business risks, and it requires engineers to take extreme ownership of their mistakes.
When things inevitably go wrong, the response shouldn't be finger-pointing or introducing new bureaucratic approval gates. Instead, it should be a blameless post-mortem focused on one question: How do we make our systems resilient enough that an engineer can safely try this again tomorrow?
I think agentic processes are starting to upend all this. We're starting to circumvent the permission-seeking nature of our processes so that we can unblock agents to carry out their tasks. When quick, cheap POCs can be built in an afternoon, providing a heap of admin to justify the idea seems pointless.
Overall, stop waiting for permission to build that thing, or to fix a problem that's been bothering you for days or weeks. Follow best practices, add the necessary safeguards, use your expertise, and just do it.
It's not really about permission and apologies; it's about not waiting to have your idea validated by others. Ship it.