Dan Fox
Executive and Agile Coach
Approach
Most of the leaders I work with are not lacking knowledge. They are navigating situations where the right answer is not obvious, the system keeps producing the same outcomes despite repeated interventions, or the people around them are not pulling in the same direction. The problem is rarely what it looks like on the surface.
I work with individuals, teams, and organisations — and the level tends to matter. A team that is stuck is often a symptom of something structural. A leader who feels isolated is often carrying a tension that belongs to the whole system. I try to work at the level where the real leverage is.
My role is to create the conditions for clearer thinking. That might look like holding a mirror up to a pattern, asking the question nobody else is asking, or simply slowing things down enough for something useful to emerge. I bring the background of someone who has built and shipped things — that shapes how I listen, and what I notice. The approach runs the same way: small, survivable steps that surface what's actually true before committing to larger change — barely sufficient to learn what's needed, made at the last responsible moment. Not minimalism for its own sake. Discipline in the face of what isn't yet known.
Engagements often start transactional — a specific situation to think through, a decision to make, a team session to run. That's a legitimate place to begin. Sometimes that's the whole of it. Sometimes working through the presenting problem surfaces something worth going further into. The work doesn't push toward transformation, but it doesn't foreclose it either.
Background
I started working on the web in 1995, as part of an experiment with Hewlett Packard to test whether the web could become a profitable revenue channel. It was essentially a start-up before start-ups were a thing. We worked for luxury travel brands, cobbling together daisy-chained SCSI drives, Macs, a FileMaker Pro database, and an unfeasible amount of AppleScript — generating large static sites piped up an ISDN line to a server under a desk in Bristol. As the web matured, AppleScript gave way to Java Servlets, and we moved on to booking engines, loyalty programmes, and itinerary planners. I spent several years as a combination business analyst and project manager before discovering agile.
My first proper encounter with agile came through an organisation-wide transition: from a traditional waterfall PMO with siloed departments and matrix management, to dedicated cross-functional feature teams working in Scrum. As a freshly minted Scrum Master, I found a whole new way of thinking about work. That thread has run through everything since — including this practice.
The first real lesson
My first Scrum Master role was with a brand-new team, and I was determined to do it properly. I applied the framework exactly as prescribed — ceremonies, artefacts, rules — and watched the team comply without ever quite becoming a team. The numbers looked fine. The actual work was a struggle.
That was the beginning of understanding that coaching isn't the application of a framework. The framework is a starting point, not an answer. What matters is what's happening between people — the real constraints, the unspoken dynamics, the things that aren't in the retrospective notes. I've been trying to get better at reading those ever since.
In the room
A significant stretch of my work was large-scale facilitation — fifty-person innovation events, cross-functional alignment sessions, product organisation design workshops with ten or more product owners at once. I worked with a design consultancy, a major UK recruitment platform, and a healthcare group, among others.
The techniques I used in that period — Constellations, Open Space, visual facilitation — pushed me toward a systemic view of organisations. Dysfunction in a team usually isn't a team problem. It's a structural or cultural condition showing up at team level. That insight has shaped how I work ever since: the presenting issue is rarely where the real work is.
Coaching as a capability
At a fast-growing UK energy technology company, I had the opportunity to design how coaching worked at organisational scale — not as individual engagements, but as a strategic capability. That meant thinking about how to make coaching self-serve, how to run time-boxed focused interventions across multiple teams, and how the coaching function itself needed to be designed if it was going to hold its own in a high-growth environment.
That work shifted my perspective from practitioner to system designer. The question stopped being "how do I coach this team?" and became "what conditions need to exist for good coaching to be possible at all?"
Now
The current edge of my practice is the intersection of coaching and AI. I build custom AI agents, automation systems, and decision-support tools — and I'm interested in what it means for coaches and leaders to work well with AI rather than around it. That includes my own practice: this site, the tools I use with clients, and the way I think about knowledge work.
It is, in some ways, the same question I've been asking since that first Scrum Master role: what does it take to work well in conditions of genuine complexity, where the right answer isn't knowable in advance?
Certifications
I hold a range of certifications across agile, coaching, and leadership disciplines. Most of them are of the knowledge-acquisition type — intensive formats designed to lay out foundational concepts quickly, with fast feedback from expert instructors. They are useful for that. A two-day course does not a Scrum Master make, however.
I treat these as entry qualifications to the continuous learning that self-study and on-the-job experience provide. That is where the real value arrives — in the friction between the frameworks and the reality of a particular team, organisation, or moment.
The name
The name is deliberate. Daedalus is the craftsman — the maker who built the Labyrinth, designed the wings, and understood the conditions of flight before he flew. He survived not because he was more gifted than Icarus, but because he tested incrementally: survivable experiments, smaller recoverable bets that built understanding of the conditions before full commitment.
Icarus doesn't represent hubris or foolishness. He represents what complex conditions produce — emergent forces, unintended consequences, impacts that nobody designed and nobody could fully predict. The wax held at low altitude. The conditions at height were unknown. That gap is where things fall apart, not because people are reckless, but because complexity works like that.
The practice is built on the same principle: helping leaders navigate those forces through work that is deliberate, incremental, and designed to survive contact with what they don't yet know.
Working with me
Across all of the work, a few things stay constant. I don't have an agenda for who you should become. I meet people where they are, not where I think they ought to be. What's said in the room stays in the room. I work within the ICF ethics framework, which governs confidentiality, conflicts of interest, and the boundaries of the coaching relationship.
In one-to-one coaching specifically, my role is not to teach, advise, or mentor. It is to hold the space for you to do the thinking — safely, without judgement, and without me steering toward a predetermined answer. The thinking is yours. I help create the conditions for it to happen clearly.
Facilitation and organisational work operate in a more active register — I'm in the room, shaping the process, sometimes naming what I see. But the same principles apply: your system, your people, your conclusions.