The journey

Before the career: understand the system

The professional story starts with enterprise software, but the technical one starts much earlier. As a kid I loved electronics kits, breadboards and figuring out how things worked. I copied BASIC programs from Commodore 64 magazines, then patched them when the next issue printed the corrections. One of my first original programs was an inelegant but functioning rule engine for predicting budgie colours for my dad.

By my teens I was building small systems for other people. Two Microsoft Access applications I wrote for my dad were used operationally at the prison where he was Head of Security. At school, when I was not allowed to choose Computing at GCSE because I already had too many technical subjects, I asked for the material and worked through it anyway. I later took Computing at A-Level, became fascinated by subjects including PGP encryption, and got an A.

At the University of Reading, Applied Computer Science gave those interests more formal language. I gravitated toward Cybernetics: AI, robotics, feedback, classification and machine understanding. Professor Kevin Warwick was a major influence, but the lecture I still remember is built around a much smaller question: what is a chair?

My first choice for a final-year project was to build an ELIZA-style conversational program from scratch in Pascal. I read books on natural-language processing and tokenisation, discovered that the problem was much larger than the available time, and changed direction. The project I actually completed was a home automation system using sensors and lights, with a robot arm under software control.

My year in industry at BT in Martlesham Heath added another recurring theme: failure and recovery. I worked on integration testing for Directory Services and wrote the rollback guides for Directory Services Y2K incidents. Long before cloud resilience or autonomous agents, the question was already there: what happens when interconnected systems fail?

Read the personal origin story →

I turned down the obvious graduate path and started a company

My BT placement had made telecoms feel like the obvious destination for a computing graduate. But during my final year at Reading, another route appeared. Alongside Bez Baker, an experienced permanent Microsoft employee, and my fellow student Kevin Bluer, I started delivering paid software projects for Microsoft UK.

We worked on internal systems including UKWeb, Microsoft UK’s intranet, Exchange Digital Dashboards and projects using Microsoft CMS Server. I was barely out of university and already building software for Microsoft, interacting with senior people there and even teaching Flash and ActionScript to some of their staff.

So when graduation arrived, I turned down the BT graduate route I had once regarded as the dream and co-founded Precision Web with Bez and Kevin instead.

It was my first serious entrepreneurial lesson as well as my first company. Microsoft was effectively our only significant customer. When the work was brought in-house, that concentration became fatal to the business model. Precision Web closed cleanly, everyone was paid, and I moved into contracting.

Looking back, two lessons survived: do not confuse one excellent customer with a resilient business, and when the evidence says the business no longer works, closing cleanly can be a better outcome than waiting indefinitely for rescue.

Then: make the system work

Contracting and enterprise development gave me the ordinary, useful education of production software: development, administration, customisation, migration and solution design. SharePoint later became a large part of that world because organisations had a very human problem: information was everywhere, collaboration was messy, and software had to fit how people actually worked.

The useful lesson was not “SharePoint is important.” It was that enterprise technology is mostly an exercise in trade-offs. The feature is rarely the hard part. Adoption, information architecture, permissions, maintainability, integration and change are where the real system lives.

Then I walked away from technology

By my late twenties I had spent years contracting as a developer in London and was becoming disillusioned with the industry. The frustration was not really technology itself. It was project delivery: budgets, deadlines and compromises that meant I rarely felt able to develop things to the level of quality I wanted.

At 28 I took a year out. I spent a snowboarding season in Whistler, including instructor training, then travelled solo through Southeast Asia and Australia. By the end I did not intend to return to a conventional technology career at all. The plan I wanted was much simpler: snowboard instructor in winter, Divemaster in summer.

Reality intervened in the form of an empty bank account. I knew London contractor rates could fund the next step, so I returned to technology intending it to be temporary.

The surviving 2007 travel posts are still in the archive →

I came back for the money. I stayed because there was no manual.

SharePoint 2007 had just arrived and was a huge change from SharePoint 2003. The platform was interesting, but the thing that really caught me was how little good documentation existed. There were unanswered questions everywhere.

I found the SharePoint User Group in London, run by Nick Swan, and started attending the events. I began blogging what I learned and documenting the things I had struggled to find elsewhere. When I later moved to Manchester, I asked Nick if I could replicate the group there and started organising the North West meetings.

That local group became something much larger. I started speaking as well as organising, brought influential specialists including Spence Harbar and Neil Hodgkinson to the community, and began presenting at conferences including the events organised by Steve Smith. As other regional groups formed, I helped new leaders get started, mentored organisers, built the website that advertised the groups and eventually became the national SUGUK overseer.

The Microsoft MVP award came later. The more important change had already happened: I had gone from building software mostly inside projects to learning, documenting, teaching and building infrastructure around a technical community.

Then the cloud moved the boundary

Office 365 changed the architecture conversation. Organisations were being asked to hand more operational responsibility to a vendor in exchange for speed and scale. That was exciting, but it also made trust, privacy, service continuity, control, limits and exit strategy more important, not less.

That is why my 2014 talks spent so much time on what the marketing did not tell you. The cloud was clearly the direction of travel. The job was still to understand what you were giving up, what you gained, and what still needed designing.

Geneva Office 365 deck ↗ · Cloud decision deck ↗

Community became part of the work

The Microsoft community gave me a place to learn in public. I led the North West SharePoint User Group UK community, travelled to user groups and conferences, and received Microsoft MVP recognition four times.

Speaking was never really separate from engineering; explaining a system forces you to understand which parts matter and which parts are just product noise.

Microsoft’s Reconnect profile ↗

Low-code made building easier, and architecture more important

PowerApps and Flow lowered the cost of turning an idea into working software. That was brilliant. It also made it much easier to produce systems nobody wanted to maintain.

So the interesting questions shifted again: where should processing live? How do you handle failure? How do you make interfaces consistent? How do you keep configuration reusable? How do you give people speed without pretending engineering discipline is obsolete?

Read the Power Platform notes →

I kept poking at new interfaces

Virtual reality was one of those detours. I used AltspaceVR, Virtual Desktop and other early tools, wrote about mixed reality at work, and in 2017 delivered a PowerApps/Flow session from inside VR while building the application through the headset.

It was hard. That was partly the point. You learn more about a technology by trying to do real work with it than by watching a launch video.

Now software can act

AI agents make the old questions sharper because the software is no longer only presenting information or waiting for a user to click a button. It can plan, call tools, alter systems and delegate work.

That makes capability exciting. It also makes authority an architectural concern.

My current work around DaemonCore, Semantic Publishing Protocol and agentic software engineering is therefore not a rejection of the older Microsoft/enterprise career. It is the same instinct applied to a new level of autonomy: understand the boundary, make the capability useful, and do not confuse convenience with control.