<
>

Engineering Reflections on Rowden's Values

28.11.2025

By Rowden Technologies

Share

Senior Principal Engineer Steve Hall reflects on the values that underpin Rowden’s engineering culture. He shows how they inform every design choice, every collaboration, and every commitment we make to the user.

Alt text

Starting with Why

I want to set out why our values matter in how we deliver our engineering work at Rowden.

It’s easy to see company values as something that simply needs to exist, a few words for the website or printed on posters around the office.

The truth is, the reason behind our values goes back to when the company was small but growing fast. We wanted to capture what we felt made us different, the things that mattered most, and to make sure they guided how we scaled. That doesn’t mean the things we chose are the only things that matter. Rather, they’re the things we wanted to emphasise because they weren’t always common in our industry or in traditional ways of working.

These values are simple to read, but not always simple to live. They matter most when things are difficult - when priorities clash, when timelines tighten, when the engineering problem is unfamiliar, or when a decision needs to be made about what to protect and what to change.

They also matter to the people who join us. Anyone thinking about applying to Rowden, or curious about how we work, should know that these values shape every part of our engineering culture: how we design systems, how we collaborate, and how we hold ourselves accountable to the users we serve.

This piece sets out why these values exist, what they mean in practice, and how they anchor the way we build.

Our Focus is on the End User

People coming from product-led businesses may see this as obvious. In the commercial world, customer focus sits at the heart of product development. But when this company was started, one of our main frustrations with organisations delivering technology into government was the disconnect between what was being delivered under contract - the thing that got the company paid - and what the end user actually wanted or needed.

Much of that disconnect actually stems from how government buys new capabilities. Contracting authorities are often far removed from the people who will use the technology, and procurement cycles are long - sometimes over a decade from requirement to delivery. Most of our early experience was in Defence, but over time we’ve seen similar issues across other government departments.

We believe that while contractual delivery is non-negotiable, meeting our commitments is the baseline; it should never define the limit of what we aim to achieve. Our real goal is to understand what’s actually needed by the end user: what will make their life easier, more effective, and safer. That often means helping customers see where the original contract doesn’t fully reflect the operational reality, and working with them to deliver what truly meets the need.

We also care deeply about usability. The systems we develop are often complex, sometimes more advanced than those our users are familiar with. But complexity in the technology must not translate to complexity for the operator. We aim to make our systems intuitive and efficient: something people want to use, not something they have to tolerate.

We’ve seen too many cases where users reject systems that were delivered to them, even refusing to carry life-saving equipment, because it was so poorly designed or unfit for purpose. That is failure that we never want to experience with the solutions we deliver.

To avoid that, our engineers must understand the context in which their systems will be used: the environment, constraints, and human factors. We challenge requirements that don’t make sense and always view our work through the eyes of the person who will depend on it.

Ultimately, success isn’t just ticking every box on a contract. It’s delivering something that genuinely works for the people who use it.

Pace Matters

In our industry, the idea of delivering at speed can feel almost alien as, outside of urgent operational requirements, government delivery is often painfully slow. One of the things we noticed early on was an obsession with long planning cycles built on very little real information. We differentiated ourselves by moving fast and by balancing risk in a pragmatic way so we could stay genuinely agile and deliver faster.

When we talk about agility, we don’t just mean Agile with a capital A. We mean the ability to react quickly to change; to make progress, to make decisions, and to keep moving forward. That’s what “pace” means for us. Speed for its own sake isn’t the goal, but maintaining a consistent, deliberate pace absolutely is. In complex programmes, there’s always a good excuse to slow down, be that another meeting or another round of analysis, but we take a default stance of ‘bias for action’.

The contrast between the slow pace of capability delivery in government and the rapid evolution of commercial technology is striking. We’ve seen projects where the components we evaluated early in development were obsolete by the time the system reached the user. That’s a failure of process as much as technology.

That doesn’t mean rushing to final delivery. It means getting to something end-to-end as early as possible, even if some parts are immature or stubbed out. A working system, however rough, lets us start learning. It takes ideas off the whiteboard and exposes the real challenges. Sometimes that prototype will be thrown away, but the lessons it teaches are invaluable. We’d rather fail in a week than discover in a year that we’ve been wrong about key assumptions.

Of course, pace isn’t just about speed, it’s also about maintining momentum. In long or complex projects, keeping momentum can feel like dragging a ball and chain. There are headwinds, dependencies, and bureaucracy. But this is where the tenacity of our engineers and delivery teams really shows. Maintaining forward motion, even when progress feels slow, is what separates our teams from our competitors.

Balancing pace and risk is crucial. We deliver systems where safety and security can’t be compromised. Moving fast doesn’t mean being reckless, it means making conscious decisions with an understanding of their consequences. Sometimes the right decision is the one that’s easiest to reverse later. Often, not deciding is the riskiest choice of all.

We are Pragmatists

This value has evolved since the company began. Originally, we talked about practical experience and the belief that real, hands-on understanding of technology was essential for making sound engineering decisions. That hasn’t changed. What’s evolved is our recognition that being pragmatic isn’t just about being technically grounded, it’s about ensuring we can deliver viable solutions in the real world.

Early on, we got frustrated by people working in design and architecture roles for government without ever having dealt with the constraints of the technologies they were specifying or the operational constraints that the system would exist within. Their ideas might have looked good on paper, but fell apart when faced with the realities of implementation. Our approach was, and still is, to get hands-on, to understand the technologies, their trade-offs, and their limits. That makes us more credible, more responsive, and far more effective at building realistic systems.

But our pragmatism needs to go beyond just the technical aspects. It’s about recognising both the technical and non-technical realities that shape what is achievable. This ranges from commercial constraints and contractual boundaries to the operational context in which our systems are used.

Too often, we see well written requirements and architectures that are simply impossible to deliver. We don’t want to be the people who write elegant documents that never translate into working systems. We want to build things that work.

Take “open architectures” as an example. Others often treat openness as an ideology, define the standards and assume the ecosystem will follow. For us, it’s about achieving the outcomes those standards are meant to deliver: interoperability, modularity, and flexibility. We focus on what can actually be implemented to meet those goals, not on ticking conceptual boxes.

Being pragmatic doesn’t mean lacking vision. It means helping bridge the gap between vision and reality. It’s easy to sit in a room and point out why something won’t work, that’s cynicism. Pragmatism is about understanding what our customers want to achieve and working out how to get them closer to it in tangible, achievable steps.

That’s the kind of engineer we value most, the one who doesn’t just highlight the flaws, but can both envision and implement a solution.

Our Diverse Skills and Backgrounds Make Us Better

There are many benefits to diversity, but the one I want to focus on is an aspect that directly strengthens our engineering work. Engineering is a team sport. No good system should ever be the product of a single person’s ideas. The best solutions come from teams that bring different perspectives and experiences to the table.

The book Rebel Ideas explores how teams made up of people who think differently consistently outperform those built from like-minded individuals. That principle sits at the heart of how we want to work. When we bring together people from a range of backgrounds, technical and non-technical, from large companies and small, from defence, industry, or academia, we get a richer set of ideas.

Working in government, there’s always a risk of becoming an echo chamber. It’s easy to slip into the mindset of doing things “the way they’ve always been done” or mirroring our customers’ processes without question. But we don’t believe that’s how progress happens.

Sometimes, the traditional approach is the right way, but not always. We need people who will challenge assumptions, who’ll ask why we do things a certain way, and who’ll bring new methods and contemporary thinking to long-standing problems.

This isn’t about being argumentative for the sake of it. It’s about keeping our thinking fresh and making sure that we don’t let habit dictate design. The best engineering comes from constructive discussion, the friction between different viewpoints that leads to better, more balanced solutions. That’s why we believe diversity is a fundamental ingredient of good engineering.

We Are Radically Honest

Honesty is one of those values that can sound obvious, the kind of thing you see alongside words like trust, integrity, or respect. And, of course, nobody sets out to say they’re dishonest. But what we mean by radical honesty goes far deeper than that.

For us, it’s about telling the truth even when it isn’t easy. It’s about speaking up when silence would be more comfortable. The opposite of radical honesty isn’t dishonesty, it’s avoidance. It’s staying quiet, offering half-truths, or hiding behind excuses. That’s dangerous, because improvement depends on reflection, and reflection depends on honesty.

We can work incredibly hard to deliver something, overcome real challenges, and still be honest enough to say, it could have been better. That level of honesty, with ourselves and with each other, is what drives progress. That is why this value sits so closely alongside our next one: we improve continuously. You can’t have one without the other.

Radical honesty also means challenging assumptions and decisions, not to be adversarial, but to make each other think. One of the most unhelpful things in any meeting is people sitting silently when they disagree. We want a culture where people feel empowered to voice a different view, to question the status quo, or to challenge a decision.

That doesn’t mean everything is decided by consensus. We operate in a world of trade-offs and constraints, and sometimes we have to move forward even when not everyone agrees. What matters is that everyone has had the chance to be heard and that, once a decision is made, we can disagree and commit to delivering it.

Our honesty also extends to how we work with our customers. We’ve earned trust by being willing to tell them difficult truths, but we’ve also learned that how we tell those truths matters. Radical honesty should never come across as arrogance or criticism. It’s about helping customers make better decisions and achieve their goals.

We won’t misrepresent situations to make life easier for ourselves, or let our customers make choices based on incomplete information. Radical honesty means being truthful in a way that helps everyone move forward, even when it’s uncomfortable.

We Improve Continuously

At the risk of stating the obvious, this value means more to us than the standard notion of “continuous improvement” that every company claims to pursue.

For us, it’s about recognising that we’re a growing organisation, not just in size, but in maturity, in the scope of our work, and in the ambition of what we’re building towards: a next-generation engineering powerhouse, headquartered in the UK. We have a strong vision and firm convictions, but we also need the humility to understand where we are today and the discipline to stay focused on how we get to where we want to be.

One of the key lessons we’ve learned is that progress rarely happens overnight. Sometimes, to meet an urgent need, we have to implement new approaches or processes quickly. They may solve the immediate problem, but they’re not always the right answer for the long term. We might need to tear them apart and start again.

Delivery often means building in motion. It can feel uncomfortable for people used to fully defined processes, but it’s also one of our strengths. Starting lean, learning fast, and iterating deliberately means we improve with every cycle. Each loop sharpens our understanding and tightens our delivery. That is how we stay ahead, and that is why pace matters.

As our projects grow in complexity and reach, we’re constantly adapting our processes and ways of working. The fact that we need to change is often a sign that we’ve succeeded, that our impact has outgrown the methods we started with. The key is to reflect on what worked, what didn’t, and what needs to be rebuilt better than what was there before.

Continuous improvement applies on every level. Individually, it’s about developing our skills, deepening our technical understanding, and learning from experience. As teams, it’s about refining how we collaborate, how we communicate, and how we hold each other to account. As a company, it’s about shaping how we operate, so we can continue to deliver increasingly ambitious, meaningful, and effective outcomes for our end users.

We don’t believe in simply copying processes from elsewhere. We study them, understand why they work, and adapt them to fit both how we operate today and how we want to operate in the future. That’s what continuous improvement really means to us, continuous evolution, built on learning, reflection, and belief in what we’re building together.

follow us

contact us

info@rowdentech.com

+44 (0)117 3131236

Unit G3C Bolingbroke Way Bristol England BS34 6FE

ROWDEN TECHNOLOGIES 2025©