Submarines DevCon 2025 Keynote Speech

Introduction

I was recently asked to give a keynote speech at the Rolls-Royce Submarines Developer Conference in February 2025 which took place in Derby, UK. The talk was titled: Unlocking Innovation: Enterprise Software and Culture. The post below contains some sanitized details of the talk for both attendees to reference and others to learn from.

The talk was broken down into five main sections outlined below. Each section had an image / icon associated with the topic and was displayed on the slides and which were handed out as stickers after the conference.

01 - Psychological Safety

Psychological Safety was the first topic because it is, in my mind, the single most important aspect of a high-performing team. Without it, you can't have trust, and without trust, you can't have a high-performing team. It's the foundation of everything else we'll talk about today. I discussed this topic by referencing three books as I often do. These books are:

1. Culture Code by Daniel Coyle: This book really taught and convinced me of the importance of psychological safety and how it's the foundation of a high-performing team.
2. The Fearless Organization by Amy Edmondson: This book is a deep dive into how to implement psychological safety in your team or organization. I've implemented many of the practices in this book and have seen great results.
3. The Right Kind of Wrong by Amy Edmondson: This book acts as a manual for teams and leaders to understand the key role of failure in an organization and how to do it in the right way to learn, grow, and deliver at pace.

02 - Bureaucracy

Bureaucracy was the second topic because it's the single biggest killer of innovation in an organization. It's the enemy of agility and speed. I discussed similar things here as I did in my podcast and in my Calvium interview. I referenced the book The Delicate Art of Bureaucracy by Mark Schwartz which is seminal on this topic. We talked about methods to work through the bureaucracy, why it exists, and some outside-the-box ways to deal with it.

03 - Special Unicorn

The third topic was all about how it is common in a company to feel like our problems are special and unique. This leads to people trying to invent totally new ways to do things when there are already proven methods out there. I mentioned that we should be using technologies that are neither unique, nor cutting edge.

Projects and technologies which are well established within organizations like the Cloud Native Computing Foundation and The Linux Foundation are solid candidates. It would also be a good idea to pick topics that someone can learn by watching YouTube videos, attending bootcamps, or with health communities and documentation. If we are heading in a special company specific direction, it's likely the wrong choice.

I referenced the book The Phoenix Project and The Unicorn Project by Gene Kim which are great books on this topic. I also referenced the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim which really set a strong direction on DevOps as a process for achieving higher software delivery performance.

04 - Sacred Cows

The fourth topic was a chance to take out a few sacred cows of the industry around the difference of both Agile vs. Waterfall and moreso agile vs. Agile. I discussed this through three main points:

1. agile should be an adjective, not a noun: I discussed how agile is an adjective about the way you work, not something to do. It shouldn't be the task, it should be a way to achieve your tasks. Formal Agile methods like Scrum can be useful, but they contain very specific solutions to solve very specific (and difficult) problems. If you aren't in charge of keeping 8-10 highly paid engineers busy on an ongoing basis, you probably don't need Scrum.
2. Let the Problem Drive the Solution: I talked about how the problem you are trying to solve should drive the solution. There are plenty of problems around our business where a waterfall process is completely appropriate. I would argue we have very few places where formal Agile methods are appropriate. Our company just isn't organized that way. That said, there are plenty of places where we can take some of the good learning and ideas from agile methods and apply them to our work.
3. Use Your Brain: This may sound obvious, but we have an enormous number of talented colleagues and friends in this company. If we take a little time to think about a solution without formal methodologies getting in the way, we'll often come up with something far more simple and elegant. Use agile as a tool towards better, faster, and cheaper solutions. Don't get stuck trying to shoehorn a formal methodology into a problem that doesn't need it.

05 - Partnership

This last topic was all about working with our external partners and vendors. Big companies like ours can rarely handle everything we need without outside help. In the Software Factory team we pioneered a newer approach to working with our partners. We don't purchase software or even deliverables in our contracts, we simply purchase time. During that time, the vendor employees assigned to this project will join our team and we'll work together side-by-side to deliver on our goals. This model has been incredibly successful for us and I would encourage you to consider it in your own teams.

This model requires a mutual trust and respect between the organizations that rarely exists in the older contractor / control model.

• We must trust the vendor to deliver on their promises of focus, effort, and time. If something takes longer than they initially think, we have to trust that they were working hard to deliver and the delay is a normal delay that could happen to anyone.
• The partner must trust that we will be fair with our expectations, timelines, and work projects. We need to account for onboarding, ramp-up time, and the inevitable learning curve that comes with any new project.

We call this our Burst Model where we can quickly burst one or more people onto our team to help deliver something in as short as a week or two.

I wish I could say I learned this in a book, but I didn't. This was a model which seemed obvious to me and from the first time we brought someone in to help with a project we used this model. Eventually, it became a standard working practice and it was only later I realized how strange this was across the rest of our business and other industries.