The person in
the pocket.
I'm Nigel Holder, founder of PocketDev. I help teams bring clarity to complex technical and operational systems, with a background spanning enterprise engineering, healthcare integrations, Azure automation, reporting platforms, and process improvement.
Background
From psychology to systems.
A winding career path turned out to be the most useful credential of all.
"The most useful credential I have isn't on paper — it's a decade of seeing the same failure patterns across completely different industries."
Over a decade of working across enterprise engineering, healthcare technology, education technology, reporting systems, and internal business platforms, I kept noticing the same pattern: intelligent, capable teams held back by the systems around them rather than by any lack of skill. Ambitious work outpacing the infrastructure it needed to actually hold.
I trained in psychology before I trained in technology. That sequence matters. It means I approach process and systems design with an understanding of how humans actually make decisions, carry cognitive load, and respond to ambiguity — not just how systems work on paper.
The name PocketDev comes from a simple idea: the most important person for a team's technical and operational clarity isn't necessarily a specialist buried in one silo. It's someone who understands the whole enough to design it for scale — and who feels accessible, like they're always in your pocket.
I write, advise, and build at the intersection of engineering, process, and psychology. The blog is where I think out loud about what I'm seeing. The case studies show what happens when theory meets practice.
Philosophy
How I think about this work.
These aren't taglines. They're the operating principles that shape every engagement.
Clarity is leverage.
Every hour spent clarifying a process, decision framework, or ownership structure pays dividends for months. Ambiguity is expensive. Most businesses just don't see the invoice.
Systems should be designed for humans.
Most process failures aren't human failures — they're design failures. I build systems that account for how people actually work, not how we wish they would.
Complexity is often a symptom.
What looks complex from the outside usually has a small number of underlying failure modes. My job is to find them, name them clearly, and design them out.
Cross-industry experience is a thinking tool.
Every industry has blind spots — things everyone accepts as given that aren't. Fresh eyes from a different context often see the solution that specialists miss.
Approach
The way I work with clients.
Every engagement follows the same three-phase discipline — regardless of industry or problem size.
Diagnose
Before any solution is proposed, I map what's actually happening — not what the org chart says is happening. I look for misaligned incentives, unclear ownership, and the invisible processes that no one has named.
Design
I build the system that should exist: decision frameworks, process maps, ownership structures, and the tooling that supports them. Everything is designed for humans — accounting for real workloads and real behaviour.
Deliver
I don't disappear after a slide deck. I work alongside teams through implementation, adjust as realities emerge, and make sure the system actually gets used. The goal is operational change, not documentation.
Start with the work.
The ideas are in the blog. The proof is in the case studies.