The journey

First: make the system work

My background started in the ordinary, useful work of enterprise software: development, administration, customisation, migration and solution design. SharePoint 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 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 — and authority architectural.

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.