Operating Principles
These aren't productivity tips or management frameworks. They're positions developed through enterprise software, healthcare technology, robotics and regulated delivery. Each one is grounded in work that forced a decision.
01Operating Principles
Five positions developed through enterprise software, healthcare technology, robotics and regulated delivery.
A solution without a decision is just activity.
Position
Most projects don't fail because people lack ideas.
They fail because nobody is clear about the actual decision being made.
- Teams optimise features.
- Stakeholders optimise opinions.
- Developers optimise implementation.
Meanwhile everyone is solving a different problem.
I prefer to identify one thing first:
What decision are we making?
Once that exists, everything else becomes easier.
- Ownership becomes visible.
- Trade-offs become explicit.
- Success becomes measurable.
Why I think this
Across healthcare simulation projects, nearly every difficult discussion eventually came back to one missing question.
Who owns this decision?
Once ownership disappeared, priorities drifted. Scope expanded. Requirements became negotiations. Delivery slowed.
The biggest improvement I ever made wasn't adding process.
It was making decisions explicit.
What this looked like
At i3 every proposed change entered a decision gate.
Each request had to answer three questions:
- Who owns this?
- What constraint changes?
- What does it cost the agreed baseline?
Anything that failed was parked with a written reason.
Nothing disappeared quietly.
That single habit reduced uncontrolled scope and gave every stakeholder the same source of truth.
What I now believe
Good product managers don't organise work. They organise decisions.
Evidence — i3 Simulations · change control
At i3 every proposed change entered a decision gate. Each request had to answer three questions: who owns this, what constraint changes, and what does it cost the agreed baseline? Anything that failed was parked with a written reason. Nothing disappeared quietly. That single habit reduced uncontrolled scope and gave every stakeholder the same source of truth.
- Decision questions
- 3
- Unowned changes
- Parked
A product is designed from the outside in.
Position
Technology isn't usually the limiting factor.
Reality is.
- Regulation.
- Budget.
- Procurement.
- Risk.
- Organisational behaviour.
- Political incentives.
The best products survive these long before users see them.
Why I think this
Working on autonomous robotics taught me that deployment begins months before engineering.
- Compliance.
- Security.
- Documentation.
- Auditability.
All determine what can actually ship.
When those are added afterwards, engineering becomes expensive.
When they're considered first, engineering becomes simpler.
What this looked like
Before delivery started, ISO 9001 and ISO 27001 shaped documentation, release processes and delivery controls.
Rather than adapting the product later, the product was designed to fit its environment from day one.
What I now believe
Products don't succeed because technology wins. They succeed because reality allows them to exist.
Evidence — Ross Robotics · deployment constraints
Before delivery started, ISO 9001 and ISO 27001 shaped documentation, release processes and delivery controls. Rather than adapting the product later, the product was designed to fit its environment from day one. When compliance, security, documentation and auditability are considered first, engineering becomes simpler.
- Compliance groundwork
- ISO 9001 + 27001
- Design direction
- Outside in
I work across customer needs, commercial priorities, technical teams and operations—turning different perspectives into clear decisions and coordinated delivery.
Evidence — i3 Simulations · cross-functional alignment
At i3, product direction had to work for clinicians, engineering teams, commercial stakeholders and client organisations at the same time. I translated competing needs into shared priorities and executable plans, keeping technical feasibility, clinical integrity and commercial viability connected through delivery.
- Functions aligned
- Clinical + Technical + Commercial
- Client organisations
- 25+
Execution is a system that can be designed, measured and continuously improved. Better planning, feedback loops and visibility reduce friction long before deadlines become problems.
Evidence — i3 Simulations · delivery function
Delivery was treated as an operating system: clear intake, explicit decisions, visible dependencies and feedback loops that returned observed performance to the next planning cycle. The objective was not more Agile, Scrum or Jira. It was an execution architecture that teams could understand, measure and improve.
- On-time delivery
- 90%
- Concurrent programmes
- 4
Frameworks are useful only when they improve outcomes. I keep the practices that create measurable value and discard those that exist for process alone.
Evidence — Ross Robotics · process simplification
Frameworks such as Agile, Scrum, PRINCE2 and PMP are useful only when they improve outcomes. Practices were kept when they clarified ownership, reduced risk or strengthened delivery visibility, and discarded when they added ceremony without measurable value.
- Delivery timeline
- −20%
- Engineering team
- 6