How I lead

My principles.

The thinking behind how I build products and lead the people who build them, the way I actually work, and what I took from the work that didn't ship.

Building the product

How I approach product.

How I decide what gets built. Some of these I apply before a screen exists, some while it takes shape, some long after it ships. Together they decide whether a product earns trust and holds up over years.

Contextual Research

Users rarely complain about what frustrates them most. They adapt, normalise, and carry on.

So I don't ask people what they want. I watch what they actually do: the workarounds, the habits, the friction they've stopped noticing. That adapted behaviour is where the real product problems live, and where the gap worth building for usually hides.

In practice For MonitoringHub I spent weekends in shops, schools, and stalls, watching how people actually used their CCTV, sensors, and the apps tied to that hardware. The sharpest finding was that what people said they'd do was the least reliable signal of all.

Root Cause Thinking

A stated problem is almost never the real one. I treat every complaint as a symptom and trace it to the structure underneath.

Users report what's in front of them; very few can name the actual cause. In my experience, repeatedly, talking it through confirms the deeper issue, and the fix for the root is always different from the fix for what was asked.

In practice On a diagnosis call for a critical-infrastructure client, "I don't like this dashboard" turned out to be an information-architecture problem, which I reframed live on the call. The diagnosis was the work; the redesign was the easy part.

Decision Architecture

What I build has to do four things before a person acts: earn trust through transparency, surface only what's critical, keep cognitive load low enough that the right decision is the natural one, reached fast, and make the wrong move easy to undo.

That isn't interface design, it's decision architecture. The screen is the surface; the structural commitments that decide what it can and cannot show are the work, and they exist to serve one thing: the person under pressure making the right call quickly. Decision architecture is what holds when the screen changes, and the screen always changes.

In practice I set one colour language across every product, red for critical, amber for warning, green for healthy, so an operator under pressure could read system state at a glance and act without stopping to think.

Behavioural Design

Most designers apply psychology as context for their decisions. I apply it as the input that shapes the decisions themselves.

Cognitive load, mental models, habit loops, operant conditioning, social comparison: these aren't post-hoc justifications. They decide what gets built and what the product asks of its user before a single screen exists. My study of psychology is a working instrument, not a credential.

In practice At one client I built an operator-performance system on operant conditioning and social comparison, with an anonymous layer so the scores changed behaviour without turning into office politics.

Constraint-Led Design

Resource limits, technical boundaries, and organisational realities are design inputs, not obstacles.

I plan for the real constraints up front, the developers, the delivery and licensing terms, the client, management, and the people who'll actually use it, and I ask each of them the edge-case questions early. Working within actual limits forces precision and prevents over-engineering, and accounting for them up front is what keeps rework and late failure to a minimum. The solutions that hold for years are built for what was true, not for an ideal version of the conditions.

In practice A fully configurable Dashboard is the kind of system that takes a large team, designers, developers, data engineers, to build and maintain. I had two developers, and even they were pulled onto live work whenever it came in. So I deliberately scoped it semi-configurable: enough flexibility to stand up dozens of client deployments without running a full development cycle every time. The constraint chose the architecture, and it's still running years later.

Design Advocacy

Resistance to an unfamiliar idea disappears the moment the idea becomes something people can react to.

Every significant proposal becomes a wireframe, a prototype, or a working reference before I ask anyone to evaluate it, and I bring stakeholders in early through walkthroughs, cross-team workshops, and plain explanations, with a shared checklist so nothing is missed. People commit to what they can see and test, and to decisions they helped make, not to abstract proposals.

In practice The configurable Dashboard, MonitoringHub, the rebuilt TouchConfig, none were approved or sold off a slide deck. People approved or bought them after reacting to something that already worked.

Leading the team

How I lead teams.

How I build and lead. Not just a design function, but the people, how they grow, the way they work together, and a practice that keeps running after I leave.

Influence Without Authority

Title gives you permission. Impact gives you authority.

I started at Intellve under the development team manager. About two years in, my track record on the products was strong enough that the company moved me to report directly to the CTO, that layer bypassed, not by request, but because structure follows impact. The influence reached well past my own team: into engineering's technology decisions and into deals I held no authority over.

In practice By my fourth or fifth year the CTO often approved my proposals without detailed review, and I was shaping calls that sat with engineering, not design, the charting libraries, the move to web, the configurator's architecture.

Behavioural Hiring

I listen for what candidates do after the literal question is answered. Those who stop gave you their prepared answer; those who keep going showed you how they think.

Every role eventually goes past its formal boundaries, so I hire for trajectory, not the checklist. The ceiling for how far a person will go is set in the interview.

In practice I hired most of my team as freshers, chosen for how they reasoned, not what they already knew, and grew them into independent contributors who shipped production work without me.

T-Shaped Teams

A team built entirely on narrow specialisation breaks the moment one person is unavailable.

I build teams where every member works across at least one adjacent discipline. Not because every role demands it, but because resilience at the team level requires it. It is a deliberate decision, not a by-product of good hiring.

In practice My graphic designer learned HTML and CSS; my front-end developers learned design thinking and Figma. On a team of four, no one could afford to be a single point of failure, so I made sure no one was.

Structural Accountability

When a person's behaviour creates friction, the problem is almost never the person. It is the system that lets the friction continue unchallenged.

I fix the environment first: clear ownership, agreed timelines, documented decisions, and continuous review, the structures that make the right behaviour the default. I would rather build the system that prevents the problem than manage it after it appears, and I stay the first to step in when something unexpected blocks the work.

In practice When handovers to engineering and QA kept causing friction, I didn't escalate people; I built the cross-team workshop and the pre-delivery checklist that removed the friction at its source. When the company later went for CMMI Level 3, much of what the certification required was already in place, because I had built it.

Radical Transparency

Difficult conversations happen directly, with the person they concern, at the moment they are needed.

Not through management layers, not softened into ambiguity. The same holds for delivery: if a timeline is going to slip or a dependency is blocked, the people affected hear it from me early, while there is still room to act, never at the deadline. Relationships and projects both survive an honest conversation; what neither survives is the surprise.

In practice In a creative standoff between two of my people, I didn't broker a comfortable compromise that would have weakened the work. I heard both out fully, decided on the merits, and told each the reasoning to their face.

Scalable Leadership

The only real test of a team system is whether it runs without the person who built it. I design for that test from day one.

Cross-skilling, documentation standards, and self-service frameworks are not overhead. They are the difference between a team and a dependency.

In practice When I was let go, one front-end developer kept all six products running, on the design system and documentation I had built. I had, by design, made my own role removable. I would do it the same way again.

Working method

How I use AI.

AI is how I move faster and check myself; it is not how I decide. Once a requirement is frozen, I use it to compress the parts that used to be slow: research and synthesis, high-fidelity wireframes, and turning those into working pages and prototypes, while I review, correct, and decide at every step. It also does the quieter work, cross-checking, recall, and finding patterns across more material than I can hold in my head. The judgement stays mine.

From a frozen requirement to a reviewed prototype

Once requirements are locked, I use AI to produce high-fidelity wireframes and turn them into working pages and prototypes, reviewing and correcting at each step. Stakeholders get something real to react to in days, not weeks, while every decision stays mine, not the tool's.

Pressure-testing a decision before it commits the team

Before I commit a team to an approach, I have AI surface the failure modes I might be underweighting: the edge cases, the single points of failure. It does not make the decision. It makes sure I am not deciding with a blind spot.

A private second brain I built myself

Seventeen years of notes, briefs, research, and project documents sat scattered and unsearchable, so I built a local RAG system over all of it, through the same AI collaboration I am describing here and with no prior coding background. It ran entirely on my own machine, no cloud, no keys, because client and proprietary work cannot leave it. A drive failure took the build before I hardened it into production; rebuilding it properly is on my list.

The distinction that matters

AI accelerates research, prototyping, recall, and pattern-finding. It does not replace the field visit, the stakeholder conversation, the architectural decision, or the design judgement.

The systems on this site came from seventeen years of operational work. AI helps me do that work faster and communicate it more precisely. It does not do it for me.

What I got wrong

A failure I own.

My biggest professional failure never shipped. I keep it here because the lessons it taught me, about planning, about stakeholders, and about where organisations actually invest, changed how I run anything that cuts across teams.

A modernisation that died at the merge

What it was. TouchControl was the oldest product in the portfolio, and its interface showed its age while everything else had moved on. Nobody asked me to fix it. I initiated a full visual modernisation, a dark but modern theme and one consistent icon system across every screen, because the one product that still looked a decade old was quietly undercutting the company's brand.

How I led it. The CTO approved the direction. Engineering was at capacity and could only help where database, API, or integration work was involved, so the rest sat with my team. I reviewed every screen with them, planned where developer time would be needed, and set up a separate branch for the work while the main product kept shipping, running it in parallel without delaying a single regular delivery and bargaining for developer time week by week. The build itself was the team's: the graphic designer reworked every screen and icon in about a month, and my two front-end developers carried it alongside their live delivery. In about three months it was done, and it landed well at a company town hall: only the theme had changed, so there was nothing in the flow or the logic to argue with.

How it failed. The main branch had moved several versions ahead during those three months, with new features and screens added for clients along the way. When we merged, many screens needed major rework against code that had kept changing underneath us, and the new client additions weren't themed at all. The merge was reverted. The replan I kept asking for was postponed for revenue work, again and again, until the gap was too wide to close. By the time I had a daily-merge plan ready, the graphic designer who owned the icons had resigned and left the organisation for a better opportunity, and a front-end developer followed. With no one willing to prioritise it, it halted, and it never shipped.

What I changed Three lessons, and I operate by them now. First, execution quality is worthless without the integration path secured up front: for anything cross-cutting I lock the merge cadence, the edge cases, and a real commitment from every dependent team before the first screen, never a long-running branch left to drift. Second, I drive that kind of work to a decision on my own timeline, instead of letting evidence and goodwill quietly expire while a discussion gets postponed. Third, the hard one: organisations invest in new revenue, not in polishing what already sells, so work like this has to carry its own commercial case from day one, or it loses every time it competes with revenue work.