We don't come in with the answer
How we approach tech consulting: problem-first, not solution-first
The first thing clients notice (sometimes with mild surprise, occasionally with relief) is that we don't turn up with a solution. Most consultancies have one in their back pocket before the first meeting is over; the discovery phase is just the courtesy call before the proposal lands. But we genuinely don't work that way.
What we do instead is spend real time on the problem. Rather than a perfunctory scoping session, we’ll have an actual conversation about what's not working, what you're trying to achieve, and whether technology is even the right lever to pull. A lot of clients come to us with a tool in mind – that might be a platform they've read about, a system their competitor uses or even something they’ve started building themselves. But our starting point is always the same: let's understand the problem you’re trying to solve first and work backwards from there.
And yes, that includes being honest about whether we're the right people for the job. If we can see that a project isn't suited to us, or that the direction a client is set on doesn't make sense, we'll say so. We believe this is how you build actual partnerships - relationships that last longer than a single statement of work.
The route in depends on where you're starting
End-to-end software delivery vs. standalone development: which engagement is right for you?
One of the questions we get from clients who haven't worked with us before is: what does the process look like? The honest (and sometimes mildly frustrating) answer is that it depends. Because the engagement is shaped around what you actually need, and what we're not going to do is sell you a fixed package and retrofit your situation into it.
If you're coming to us with a design and customer experience challenge - working out what you want to build, who it's for, and what it needs to do at a human level - that's one kind of engagement. It's broader, more exploratory, involves more stakeholders, and takes longer to converge. If you're coming to us with a defined problem and a clear implementation need, that's a different starting point. And if you want the whole thing end-to-end, from initial design through to working software, that's a third route - and arguably the most powerful one, because the two sides of that process talking to each other ultimately results in a better experience for customers, users and employees.
And the final option is this: let’s start small. For clients who are new to working with us, our honest recommendation is to start with a defined problem rather than a full programme. Bring us something real (a specific challenge, a process that isn't working, a capability you want to test) and let's see what we can do with it. A proof of concept or a focused first sprint tells you far more about how we work than any credentials document. It also protects you. You get to see how we think, how we communicate, how we handle the moments when something's harder than expected, and we get to understand how you work: your decision-making process, your appetite for iteration, what good looks like for you.
What to expect from an agile development engagement
Or rather, what exceptional delivery looks like from the inside
Once an engineering project moves into development, a few things need to be true for it to run well - and two of them are on you as much as us.
The first is a shared understanding of what we're solving. That sounds obvious, but it's more specific than it sounds. Before any code gets written, we'll do product discovery - not a lengthy requirements document, but a focused piece of work that surfaces the key stakeholders, the systems involved, how things interact, and what the build backlog actually looks like. It's the difference between starting a project and starting the right project.
The second is a tolerance for iteration over perfection. Software projects that try to plan everything upfront in exhaustive detail tend to deliver something that was accurate six months ago. The agile methodology exists precisely because the alternative - long planning cycles, long build cycles, a reveal at the end - is a reliable way to build the wrong thing with great precision. We make adjustments in small intervals, which means the drift between what's being built and what's actually needed stays manageable.
The last is your ongoing engagement. As we’ve said above, the way we work is iterative, which means you'll see working software regularly, sometimes weekly, sometimes more often. That frequency is how we close the gap between what you asked for and what you actually want (which, in our experience, are rarely identical until you're looking at something real!). But we’re realistic about the constraints on your time, and we know not every client wants to join a daily standup - that’s fine too – so our delivery managers will act as a proxy for you, enabling the teams to make sensible judgements on your behalf. That said, if we’re being transparent, there's no substitute for the client in the room when a decision matters.
The delivery manager as quality gate
What does a delivery manager actually do?
A word on the delivery manager role, because it's genuinely important and often underestimated.
As we’ve alluded to above, our delivery managers aren't project administrators. They're the primary point of continuity on a project - the person who holds the client's context, understands the use case, and can stand in the room (or on the call) and make a credible judgement about whether what's been built is actually right. When the daily standup surfaces a decision and you're not there to make it, your delivery manager is.
That role sits at the intersection of functional (does it do what it's supposed to?), emotional (does it feel right to use?), and social (does it reflect well on the people presenting it?).
From design to build: end-to-end digital delivery with one team
We’ve always been known for design, customer experience, and strategic consulting, but being part of a wider global technology group means we’re able to take that work all the way through to implementation - not as a hand-off to a separate team, but as a continuous, connected process under one roof. You're working with one team that can take you from problem to product, which we’ve found is a rarer thing than it should be in the consulting industry.
If you're trying to work out whether we're the right fit, the best thing to do is talk to us. We'll tell you honestly what we think we can do, and equally honestly if we think someone else would serve you better. Not a pitch – just how we work.
