Want to Innovate? Start Breaking Rules

The best teams in software don’t follow every rule. They know exactly which ones to break, and why.

The most significant technology innovations, from agile to open source to serverless, came from teams that deliberately broke existing constraints. Bear in mind, breaking the rules in software development doesn’t mean ignoring standards. It means questioning why a standard exists and whether it still applies to your context. The most dangerous rule-breaking is doing it without understanding the rule first.

What Does It Actually Mean to Break the Rules in Software Development?

“Learn the rules like a pro, so you can break them like an artist”

Attributed to Pablo Picasso

The Fast Company Pattern

Back in May 2019, Fast Company revealed its list of the 50 best workplaces for innovators. The list has run every year since, with the applications for the 2026 edition marking its eighth. It acknowledges the businesses that cultivate big ideas and encourage experimentation.

That 2019 list was a mix of obvious choices (like Amazon and Mozilla) and true surprises (who would’ve expected to see an Australian-based digital marketing agency?). But ultimately, every included company deserved to be in it.

Why? Because all of those companies truly honored what people imagine when thinking about an innovative workplace. These companies pursued unusual projects driven by their own employees, embraced failures as part of the learning process, and facilitated collaboration between teams so ideas could thrive.

The Agile Question

Being innovative means staying flexible enough to change course quickly. But is this kind of rule-breaking innovation possible when standardized processes deliver peak operational performance? Aren’t those things mutually exclusive? This is where agile development earns its place, not as a rulebook to follow blindly, but as a way to keep experimentation and delivery moving at the same time.

The Fast Company list backs that up. Companies like Amazon didn’t get there by picking rigor or flexibility. They built room for both.

Innovation in software development often requires challenging established practices. That includes development methodologies, architectural patterns, team structures, and technology choices. The teams that have created the most durable innovations, Amazon’s microservices architecture and Netflix’s chaos engineering, did so by first understanding existing practices deeply, then deliberately breaking specific constraints when evidence supported it.

Which Famous Rule-Breaks Held Up, and Which Ones Quietly Failed?

Why Startups Have the Edge

The digital age is forcing businesses of all sizes and across industries to keep pace with rapid technological changes. That context is ripe for startups to blossom. That’s because they don’t have to fight a company history that hangs over their innovative ideas. Since they come out of the blue, they can define themselves however they want, becoming disruptors.

Why Incumbents Struggle

Of course, there’s also the other side of the story: incumbent businesses struggling to stay in the game. In this struggle, the need for a new approach is most visible. Because technological development demands fast adaptation, larger companies that are digitizing themselves often don’t respond quickly enough to new challenges.

The problem is clear. Companies need to adopt a digital mindset that puts digital tools to use, but they need to do so in an organized way that ensures successful implementation. So how do they transform digitally while allowing flexibility and innovation, but still maintaining accountability and responsibility? Many organizations address this by relying on software development services.

As contradictory as it sounds, it’s possible to have processes, plans, and strategies that secure a business’s long-term future while also allowing employees to innovate and thrive. For that to happen, company execs need to foster a new approach to doing business. Doing so allows a new set of rules to emerge, ones that don’t come from the top-down but are created horizontally. They need to break the rules that made them successful in the first place.

A note on another well-known example: Spotify’s squad and tribe model, introduced in 2012, was, for years, one of the most cited organizational innovations in tech, widely copied as a template for structuring engineering teams. Despite its popularity, the model is now considered more of a cautionary case than a best practice to follow. That’s because Spotify quietly abandoned it around 2020, and one of its original authors, Henrik Kniberg, has said the company wasn’t fully practicing it even when the model was first documented.

When Should You Challenge an Established Engineering Practice, and When Should You Leave It Alone?

Challenge it when: you have evidence they’re causing harm in your context, your team understands why the rule exists, you can run a bounded experiment, and you can revert if the experiment fails.

Leave it alone when: you’d be breaking security practices without understanding the threat model, breaking performance standards without measuring, or discarding process practices simply because they’re inconvenient. The distinction that matters is between rules causing genuine harm and rules that are just unfamiliar.

What Does Productive Rule-Breaking Look Like in Practice?

• Migrating from a monolith to microservices when team coordination cost is measurably slowing releases.
• Replacing blame-based incident response with blameless postmortems to improve honest reporting.
• Adopting chaos engineering with modern tooling (Gremlin or AWS Fault Injection Service) to test resilience instead of relying on planned downtime.

How Do You Actually Run a Rule-Breaking Experiment?

1. Name the rule explicitly and document why it exists and what it protects.
2. Gather evidence that the rule is causing measurable harm in your specific context.
3. Confirm your team understands the original constraint before touching it.
4. Design a bounded experiment with a clear success metric and a defined time box.
5. Build a clean revert path so a failed bet costs a sprint, not the system.
6. Run the experiment, measure against the baseline using your project management tools, and keep, adjust, or roll back based on the data.

How Do You Build a Culture Where Productive Rule-Breaking Is Safe?

In a very interesting article about this topic, Jeanne Ross, a research scientist for MIT’s Center for Information Systems Research, says that companies can do three things to get started:

1. Distinguish digitization from digital initiatives.
2. Give digital business leaders space to invent new rules and metrics.
3. Identify and train new leaders.

Distinguish Digitization From Digital Initiatives

The first item is crucial to successfully adopting an innovative atmosphere in the workplace. It means that businesses need to understand the difference between the technologies driving the current landscape (everything from data science to artificial intelligence) and the initiatives in place to make those technologies work for business purposes (reliability, predictability, security, visibility).

The important thing, according to Ross, is “not to let digitization efforts be the sole application of digital technologies.” In other words, the possibilities brought by new emerging technologies (the innovation that can come out of them) shouldn’t be bound by the tight performance metrics of traditional initiatives (such as cost savings and customer happiness). Though companies can certainly measure those technologies against those metrics, they shouldn’t always define their success or failure.

Instead, it’s important to understand that emerging technologies can bring new data-rich and innovation-driven propositions, from new business opportunities to improved insights. For that to happen, a company has to set those metrics aside and forget about the traditional rules for a while. In their place, businesses have to make experimentation a core value. Since it’s impossible to guarantee that customers will love a new product, service, or feature, it’s important to leave room for testing and for failure.

Give Digital Leaders Space

Sounds hard to pull off? It is. It’s important to provide a safe and clear space for people to experiment and innovate. That’s why Ross’s second point is to “give digital leaders space.” In other words, people within a company have to have permission to fail, to try and try again to understand what might work as the context changes, historical business rules be damned.

By doing that, businesses can start figuring out what works and what doesn’t, generating new revenues along the way while also paving the way for the business model of the future.

Identify and Train New Leaders

Of course, that can only take place with the right people leading the way. That brings us to Ross’s final point: having leaders with a fresh mentality who understand the new way of doing things is a must for the approach to work at all.

Traditional leaders are often limited by fear of breaking the rules or by bias toward methods that contradict their experience. That’s why companies looking to innovate should also break the rules when choosing new leaders: set aside traditional skills for a moment and focus on other important abilities, such as creativity, communication, focus, and a lack of fear.

How Engineering Leaders Enable Innovation

Among the companies listed by Fast Company, there’s one that many would have guessed as an innovative business: Amazon. After being included in the list, the tech giant shared a blog post revealing some of its “secrets” for being considered one of the best workplaces for innovators. Those secrets align closely with the points above:

• Empower people
• Embrace failure
• Foster creativity
• Cultivate innovators

For traditionalists, this might seem strange, since many businesses grew big by letting execs make all the decisions. But those times are gone, and the rules have changed. That’s why anyone trying to innovate should start breaking them. That’s not to say companies should become anarchists, but that innovation initiatives need new rules for new times, rules that feel more like frames of reference rather than established laws.

By allowing flexibility and experimentation, and by fostering a culture that embraces failure, modern companies can finally start innovating and move with the current tides.

How Can a Development Partner Help You Experiment Without Losing Accountability?

The hard part of rule-breaking innovation is keeping accountability intact across the entire innovation process, from spotting the constraint to running the experiment to deciding what sticks. That’s why many organizations lean on engineering partners who balance experimentation with delivery discipline. A capable partner provides the scaffolding, often including innovation management software to track experiments, metrics, and revert points, that lets a team try, fail, and revert safely. That structure turns a risky idea into a bounded, recoverable experiment.

BairesDev has seen the scaling side of this firsthand. In the Pinterest case study, the team grew from 5 developers in 2019 to 233 by 2023, while keeping delivery on track as scope expanded. Growth like that only holds up when structure keeps pace with headcount, which is the same discipline this article has been describing.

Key Takeaways

• Most software development practices were invented to solve specific problems in specific contexts. When context changes, mindlessly following those practices can create inefficiencies. High-performing teams question assumptions and adapt accordingly.
• Amazon’s microservices architecture violated the monolith-first principle. Netflix’s chaos engineering violated “don’t break production.” These innovations came from deeply understanding existing rules and deliberately breaking them when they no longer applied.
• Create time and space for experimentation (dedicated innovation time, hackathons, or focused sprints), make failure safe through small, reversible experiments, and ensure teams understand the reasoning behind rules before deciding to change them.