Culture Principles for Innowaring
Creating the Environment Where Innovation can Thrive
This post is part of a series outlining my principles-first approach to AI-Native Product and Systems Innovation.
The first post describes the origin of the Innowaring idea after I published my book, Becoming a Software Company.
The second post describes the Innowaring Concepts, the operating model dimensions for AI-Native innovation — Teaming, Strategy, Flow, and Culture.
The third post describes the principles for the Teaming dimension, the fourth post describes the principles for the Strategy dimension, and the fifth post describes the principles for the Flow dimension of Innowaring.
This post describes the principles for the Culture dimension.
Culture can’t be treated as a passive artifact—something that just exists in posters on walls or HR documents. If the goal is product and systems innovation, culture becomes the operating system. It defines the operational norms for making decisions at every level of the organization.
Culture emerges from what you allow and what you constrain. It is the emergent outcome of thousands of small decisions made by senior leaders, managers, team leads, and individuals. Building a healthy organizational culture takes time, but it can be destroyed quickly through over-control, overemphasis on predictable execution, and micromanagement.
The need for an innovation culture also redefines the role of management control. It must evolve from mechanistic control (common in command-and-control systems) to organic control—the kind seen in decentralized, team-of-teams structures. The role of leadership isn’t to dictate every decision. It is to shape the system by providing context, building trust, and protecting the space where continuous learning and adaptation can thrive.
There is no magic wand to create an optimal culture. However, the following principles can serve as practical levers to continuously evolve a culture fit for software products and systems innovation in the AI era.
Principle: Decentralized Decision-Making
Modern software development isn’t a manufacturing activity, even though it often gets managed like one, with discussions around timelines, budgets, and resource plans. It’s a high-intensity information processing effort that depends on a few big strategic calls and a large volume of quick, informed decisions. For real agility, those decisions must be made by the people closest to the information.
A well-drafted strategy and an optimized development flow can align teams and streamline communication. But that alone isn’t enough. You won't achieve the desired velocity if decisions still have to be shunted up and down the leadership hierarchy for approval.
Ironically, modern communication and documentation tools have made it easier for leaders to retain control over far more decisions than they should. Even when they approve everything, the delays caused by waiting slow the system down. Visibility into work has increased, but so has the ability to impose control over it.
Decentralized decision-making isn’t just letting chaos loose. It’s about identifying which decisions are too costly to delay and giving teams the freedom to act where it matters. Senior leaders should stay focused on the big strategic choices. However, decisions like which feature to prioritize, when to refactor, or whether a prototype is ready to test belong to the teams doing the work.
Principle: More Trust, Less Control
In many organizations, control often masquerades as accountability. Leaders use metrics, OKRs, or review processes not as sense-making tools, but to gatekeep resources or assert power. This pattern is especially common in large enterprises, where senior roles can become bottlenecks—people who are supposed to help resolve ambiguity instead enforce layers of sign-off that slow progress and sap ownership.
For Innowaring, trust must be the default, not as an ideal, but because it works. In practical terms, trust means allowing people to use their judgment in moments that require quick action. It means offering feedback to improve the output, not to control it. The most reliable sign of trust working well is this: your teams consistently surprise you—in a good way. They ship better ideas than expected, faster than expected. And even when the outcome is disappointing, I have found it’s usually due to a lack of context, not a failure of intent.
The leader’s job is to create conditions where good judgment can thrive. You don’t build trust by telling people they’re trusted. You build it by letting them make decisions in their realm of expertise. Sometimes, they may not even want that trust because it’s easier to follow instructions. But in my experience, most people eventually rise to meet it. And when they don’t get it right, that’s usually a cue to offer better context, stronger guidance, and help them grow in skill and confidence—not to take back control.
Principle: First Principles, Then Process
There’s a strong tendency in organizations to treat best practices as sacred. A method works well somewhere, and suddenly it’s adopted en masse—with all of its ceremony, none of its context. That’s how process becomes doctrine and cargo cults form around it. To avoid that, you should start with principles first and use them to define the right-sized process for your situation.
Any accepted process framework—Agile, SAFe, OKRs, or product management methodologies—can be helpful when applied deliberately and in the proper context. But when used blindly, with a lift-and-shift mindset, those same processes become substitutes for clarity and distractions from achieving the best outcomes.
I've seen it firsthand: massive projects where the process was followed to the letter, but the final product missed the mark entirely. The documentation was flawless, and the process governance was perfect. Yet, the output was completely wrong. That’s when I learned that process has to be a means to an end—not the end itself.
When one of my teams needed to reduce sprint cycle time, we didn’t impose an arbitrary goal like “one-week sprints.” We experimented and adjusted gradually. We found that two weeks worked best for a digital health product operating under regulatory constraints. That outcome didn’t come from imposing a best practice. It came from first-principles thinking: We need shorter cycles, so let’s test and find what works.
Principle: Managing Outcomes Over Rigid Plans
It is baffling how sacred formal plans are within organizations, especially large ones. Even though most plans miss their targets, the response is often to double down—to make the next plan more detailed and rigid. This is the Planning Fallacy in action: overestimating what we control and ignoring what we don’t.
At its core, managing through plans is about valuing predictability. But innovation doesn’t come from predictability but from exploring what’s possible. Managing to outcomes is about leaving room for that exploration. It gives teams the space to discover, iterate, and improve based on what they learn while solving real problems.
Rigid plans often exclude that possibility. When deadlines are treated as sacred, teams default to compliance. The pressure to ship “on time” overwhelms the responsibility to ship the right thing. Instead of discovering new value, teams deliver a predetermined scope, even when the context has changed.
Innowaring doesn’t reject planning, but it prioritizes outcomes and impact. The best way to uncover what's possible is to deliver a working product or system in short cycles with a tight customer feedback loop. It reveals right incongruities—problems users care about fixing—in ways heavy upfront planning can’t. It lets teams adapt, course-correct, and learn in motion.
Principle: Continuous Learning
Building an AI-native software product or system isn’t a one-time project in today's environment. It’s an ongoing process of continuous learning. Market dynamics, customer expectations, and technology capabilities are constantly evolving, and organizations and teams must observe, adapt, and evolve their solutions in response.
Most organizations have learning agendas, but learning is often confined to training sessions, workshops, or conferences. Innowaring requires a different stance: learning happens by shipping. It must be embedded in the work and how teams think, work, and build.
The kind of learning that matters the most is the kind that allows an organization or a team to evolve its identity as fast as its environment. For example, Shopify CEO Tobi Lütke recently issued a company directive encouraging the use of AI in everyday work, not just to improve productivity, but to shift how the organization sees itself. That’s what learning at scale looks like.
Continuous learning means institutionalizing feedback loops—not just in product development but also in how the organization understands and evolves itself. It requires space to experiment, safety to fail, and a willingness to adjust operating norms and behaviors.
A culture that supports innovation doesn’t emerge from a single initiative, a reorg, or a leadership offsite. It emerges from how decisions are made, how learning is supported, and how much trust exists between leadership and teams. These are not abstract ideals; they show up in your outcomes—in whether teams can move quickly, pivot when needed, build valuable products and systems, and grow through feedback.
In the AI era, organizations won’t succeed solely on structure, strategy, or flow. They must also cultivate cultures that learn faster, act sooner, and adapt better.
References:
Sidhu, A. (2023). Becoming a Software Company: Accelerating Business Success through Software. Apress.
McChrystal, S., Collins, T., Silverman, D., Fussell, C. (2015). Team of Teams: New Rules of Engagement for a Complex World. Portfolio.
Silicon Valley Product Group (SVPG). (2024). Transformed: Moving to the Product Operating Model. Wiley.
This post is part of a series outlining my principles-first approach to AI-Native Product and Systems innovation. Links to the previous posts (Part 1, Part 2, Part 3, Part 4, Part 5)
The next post will summarize the complete Innowaring Model, an operating model framework for AI-native Product and Systems Innovation.