Michael Shreeves

Most people see repetitive tasks or painful processes. I see opportunities for automation, improvement, and more efficient ways of working.

Head of IT, former CTO, and developer with over 18 years of experience. Dad to four, gamer, car enthusiast, and someone who still genuinely enjoys writing code.

My job title might say Head of IT, but most weeks I'm still building projects, experimenting with AI, planning architecture a, or debugging after the kids have finally gone to bed around 9pm.

Michael Shreeves

About

Since 2008 I’ve mostly been the person in the room saying “we could just build that”.

Started my journey at Bedford College in 2006. By 2008, I was building websites after being headhunted into the industry. I spent the first twelve years writing code: front end, back end, infrastructure, security, whatever the job needed. Went from Technology Director, to Chief Technology Officer in the learning industry and now Head of IT across a group supporting 5 organisations, over seventy clinics, where the job is as much about compliance, data governance, and acquisitions as it is technology (Best part, and always will be THE PEOPLE). I still write code most evenings and weekends. Nobody's stopped me yet.

My brain is essentially a never-ending queue of ideas, observations, and moments where I think: “that could be automated,” “we could build a solution for that,” or “why are we paying for this when we could make it ourselves?” Most people call it ADHD. I call it product development. Whether it's a workflow, an integration, a dashboard, or a small tool, most projects start the same way: spotting friction, questioning the status quo, and imagining a better way to do it. The ideas pile up, get rearranged, and occasionally turn into something people actually use.

I like people too, which sounds like CV filler until you see why it matters. The problems worth solving don't turn up in a requirements document. They turn up when somebody walks you through their week and you notice the same task happening three times, or a workaround so old nobody remembers what it's working around. People only tell you that stuff if they're comfortable.

Outside work I'm Dad. Four kids, so the house is rarely quiet and the family calendar is basically a competitive sport. That's how Family Hub started. Whatever time is left goes on football, something with an engine, gaming, or a keyboard.

The tools on this page get built in those gaps. Some fix things I've run into myself. Others exist because somebody described their week to me and I couldn't leave the problem alone. Everything here started life as mush.

Somebody, somewhere, is doing this by hand right now and has stopped noticing.

There's a serious point underneath all that. Budgets are tighter than they used to be, teams are smaller, and the industry's answer has mostly been to increase the per-seat price. I'd rather build the thing that actually fits and price it so cost isn't the reason somebody goes without. Not charity. Just a better deal. A tool built for a real job is the one people are still opening in two years.

Problems I enjoy solving

Not a technology list. The stuff underneath it.

Every tool below started somewhere. Usually it’s one of these, recognised in the wild before it ever became a spec.

Users rarely ask for the thing they actually need.

  • The spreadsheet that became load-bearing

    A tracker that started as one person’s personal list and quietly became the system three teams now depend on, that nobody’s allowed to touch.

    Why I like it — under the conditional formatting is usually a real, decent data model. It just needs a proper home.

  • Systems that won’t talk to each other

    Two platforms that each do their own job well and still can’t agree on a customer record, so someone re-keys it by hand every week.

    Why I like it — the interesting part is never the API. It’s working out which system should actually own the truth.

  • The report that answers the wrong question

    Four hours a month to build, and it answers a question nobody actually asked, twice removed from the decision it was meant to inform.

    Why I like it — half the job is technical. The other half is sitting with someone until they say what they actually meant.

  • The process that lives in one person’s head

    It only works because one person remembers every exception, and everything stops the week they’re on leave.

    Why I like it — that’s not a training problem. That’s an undocumented system wearing a person as its interface.

  • AI without a problem attached

    Being asked to “add AI” to something before anyone’s agreed what it’s actually meant to fix.

    Why I like it — the honest answer is usually a smaller, more boring automation. Less exciting in a meeting. Right anyway.

  • The bottleneck everyone’s routed around

    A step so slow the whole team has quietly built a workaround, and the workaround is now the actual process.

    Why I like it — workarounds are free user research. Someone already told you exactly where it hurts.

What I build

Every one of these started life as somebody’s least favourite Tuesday.

A spreadsheet quietly holding something important together. A subscription costing more than it saves. A job being done three times over because two systems refuse to speak to each other.

Nothing here is shipped. That’s not modesty, it’s the actual status — and it’s why the filter below defaults to showing everything, idea stage included, instead of only the flattering part.

Nothing is called live until it is deployed, backed up, and I have actually restored from one of those backups. A tool with a link has shipped; one without hasn’t, yet. Full list, filterable the same way, also lives on its own shareable projects page.

    The household one isn’t the joke of the set, whatever it looks like next to a clinical imaging viewer. A family tool holds family data — sometimes children’s — belonging to people who’ve never read a data-processing agreement and should not have to. That’s a higher bar than an internal business tool, not a lower one, and it gets held to it.

    Some of it

    Things I’m glad I got to do.
    • Cyber Essentials and Cyber Essentials Took SEEDL through basic myself, and then supported Pure Unity Health from implemetation to documentation.
    • An NHS patient discharge system Scoped it and built it at Phew, working directly with the people who’d use it.
    • Concept to live product Co-founded SEEDL and took its learning platform from an idea to something customers ran their training on.
    • Seventy-plus clinics IT strategy, service delivery and compliance across a group in Primary Care and NHS-affiliated services.

    The software wasn’t the hard part.

    Experience

    Twelve years writing the code, then the jobs that needed somebody who had.

    This process worked because one person remembered everything. That’s not a compliment.

    1. March 2025 – present · Sheffield, remote

      Head of IT

      Pure Unity Health Group

      I own IT strategy, service delivery and IT compliance across the group, supporting more than seventy clinics and staff in Primary Care and NHS-affiliated services. I also support the Medical Legal and Rehab Direct teams working securely with insurers, instructing parties and expert witnesses. Infrastructure, cyber security, applications, data and support — alongside HR, Governance, Finance and Operations.

      • Compliance — NHS Data Security and Protection Toolkit, and PCI DSS.
      • Acquisitions — due diligence, onboarding, and the unglamorous business of merging another organisation’s people, data and systems into yours.
      • Platform, budget and vendor management across the group.
      • Data governance and cyber security, plus the process work that gets IT embedded in how teams actually operate rather than bolted to the side.
      What I learned here
      Key lesson
      Strategy without a working knowledge of the systems underneath it is just a slide deck.
      Skill gained
      Reading a compliance framework as a design constraint, not paperwork.
      Mistake corrected
      Assuming a group of seventy-plus clinics shares one workflow. It doesn’t, and shouldn’t.
      Insight carried forward
      Acquisitions are a systems problem before they’re a legal one.
    2. December 2020 – March 2025

      Co-founder & Chief Technology Officer

      SEEDL Learning

      Co-founded the company and owned the learning platform and the IT infrastructure. Took a concept to a live product: live session booking, on-demand video, learning records, certificates and quizzes, with customers managing their own users, mandating courses and branding their own instance.

      • Achieved Cyber Essentials certification — start to finish, not delegated.
      • Built the IT infrastructure from scratch on Microsoft 365, for a fraction of what the alternative would have cost.
      • Scoped and delivered the platform, and hired the team that shipped it.
      • Automated our own admin — scheduling, reporting and client onboarding tools, because it seemed rude to sell efficiency and then do everything by hand.
      • Held the platform to AA accessibility throughout.
      What I learned here
      Key lesson
      Co-founding teaches you the technical decision and the business decision are usually the same decision wearing different clothes.
      Skill gained
      Building the product and the company around it at the same time, without either one waiting for the other.
      Mistake corrected
      Under-pricing early because charging felt rude for something that used to be free. Cost isn’t the enemy — bad value is.
      Insight carried forward
      Accessibility done from day one is cheaper than accessibility done as a retrofit, always.
    3. March 2018 – November 2020 · Bedford

      Senior Developer

      Phew

      Led projects from first conversation to delivery, working directly with clients to work out what they actually needed as opposed to what they first asked for.

      • Scoped and built an NHS patient discharge system.
      • Wrote the accessibility guidelines the team worked to, and held software to AA.
      • Built a statistics dashboard pulling from several systems that had never been introduced to each other, plus an internal project-tracking and timekeeping tool.
      What I learned here
      Key lesson
      The client rarely asks for what they need first. You get there with better questions, not faster builds.
      Skill gained
      Writing accessibility guidelines a whole team could actually follow, not just quote.
      Mistake corrected
      Treating “the client asked for X” as the end of the conversation instead of the start of it.
      Insight carried forward
      An NHS discharge system taught me the software is the easy 80%. The 20% is understanding exactly what happens when it’s wrong.
    4. September 2016 – March 2018 · Bedford

      Team Lead, Front End

      Xigen

      Supported the team’s work and their growth, ran planning and estimation, and saw projects out to a standard worth putting a name to. Built a timesheet tool to organise and schedule the team’s work — the first of many times the answer turned out to be “write the tool”.

      What I learned here
      Key lesson
      Leading a team is mostly clearing obstacles nobody thanks you for clearing.
      Skill gained
      Estimation that survives contact with reality, more or less.
      Mistake corrected
      Assuming everyone on the team wants to be led the same way.
      Insight carried forward
      The first time “just write the tool” solved a scheduling headache, it became the answer to everything after.
    5. December 2015 – September 2016 · Milton Keynes

      Senior Front End Developer

      Ledger Bennett

      Websites, landing pages and email templates, implemented into WordPress, Umbraco, Eloqua and Marketo, with the gated forms and marketing automation behind them. Making an email look right in the mail client that mangles everything is a skill I have never once stopped needing.

      What I learned here
      Key lesson
      An email that looks perfect in your inbox is a coin flip everywhere else.
      Skill gained
      Marketing automation isn’t marketing. It’s data plumbing with a deadline.
      Mistake corrected
      Trusting a design file over an actual test send.
      Insight carried forward
      If it has to survive the mail client that mangles everything, test it in the mail client that mangles everything. Every time. No exceptions.
    6. August 2013 – December 2015 · Luton

      CTS Front Office Developer

      Lumesse

      Built customised career and recruitment platforms for clients on a SaaS product: a flexible HTML and CSS3 template system, four standard templates, a responsive rebuild that held together at every size, and a refresh of Easycruit’s internal system. Also the first place I worked on the product itself rather than only on what sat on top of it.

      What I learned here
      Key lesson
      Building the product itself, not just what sits on top of it, changes how you think about every project after.
      Skill gained
      Designing a template system flexible enough for several very different clients without becoming several different codebases.
      Mistake corrected
      Under-estimating how much a “small” responsive fix touches when the layout was never built for it.
      Insight carried forward
      Build for the client you don’t have yet, not just the one in front of you.
    7. April 2011 – August 2013 · Milton Keynes

      Web Marketing & Web Developer

      Freestone Creative

      Bespoke websites, search visibility and email marketing campaigns, with the client communication and reporting attached. The job where I learned to explain a technical decision to somebody who did not want a technical answer — useful ever since.

      What I learned here
      Key lesson
      A technically correct answer that loses the room helped nobody.
      Skill gained
      Explaining a technical trade-off to somebody who explicitly doesn’t want a technical answer.
      Mistake corrected
      Leading with how, not why.
      Insight carried forward
      Still the most-used skill in every leadership conversation since.
    8. November 2010 – March 2011 · Milton Keynes · Contract

      SEO & Web Developer

      Burton & Sons Trading

      Five months, one objective: get the key products onto page one. They got there, and the traffic and sales followed them up.

      What I learned here
      Key lesson
      A contract with one clear objective is a masterclass in not scope-creeping yourself.
      Skill gained
      Proving the work with the metric that actually mattered — page one, then sales — not a vanity one.
      Insight carried forward
      Pick the one number that proves it worked, before you start.
    9. February 2010 – October 2010 · Wellingborough

      Website Marketing, Development & First-line IT

      i-Smart Consumer Services

      Improving the company website’s visibility and pitching in on new projects, while helping the IT team keep the servers and machines upright. The start of doing both halves of the job at once, which never really stopped.

      What I learned here
      Key lesson
      Doing both halves of the job — the build and the keep-it-running — teaches you things a pure development role never will.
      Skill gained
      First real infrastructure exposure, alongside the development work.
      Insight carried forward
      The people who only ever build never learn what happens after; the people who only ever run never learn why it was built that way. Do both for a while if you can.
    10. January 2008 – January 2010

      Website Developer, SEO, Email Marketing & IT Support

      THUK Media

      Where it started. Development, SEO, email marketing, client training and IT support — and inside two years, leading a small team. Nobody plans a career that opens with “you do all of it”, but it is a hard grounding to beat.

      What I learned here
      Key lesson
      Nobody plans a career that opens with “you do all of it”, but it is a hard grounding to beat.
      Skill gained
      Being handed a little of everything at twenty and having to get competent, fast.
      Mistake corrected
      Assuming specialism has to come before breadth. For me it was the other way round.
      Insight carried forward
      Everything since has been variations on “a bit of everything”, on purpose.
    11. 2006 – 2008 · Bedford College

      BTEC First Diploma, Information Technology

      Overall grade: Distinction

      Distinctions in website development, networking essentials, and software design and development, plus an Outstanding Achievement award. The networking one has been quietly useful ever since.

      What I learned here
      Key lesson
      A distinction in networking essentials mattered more, later, than it felt like it should at the time.
      Skill gained
      The foundation that “IT” was never going to be one narrow lane.
      Insight carried forward
      Still the reason infrastructure and networking stayed part of the job description, years on.

    Technology beliefs

    Eighteen years of this leaves you with opinions. Here are a few.
    • Every spreadsheet is a system of record nobody signed up to own.
    • Automation should remove the admin, not the accountability.
    • If a process only works because one person remembers it, it isn't a process yet.
    • Most reporting problems start long before anyone opens a spreadsheet.
    • A tool people route around solved the wrong problem, however well it was built.
    • Build vs buy is usually a question of now versus five years from now.
    • Compliance isn't paperwork around the work. It should be part of the work.
    • In healthcare IT, compliance isn't paperwork around the job. It is the job.
    • Nobody asks for fifteen minutes back each week. Everybody notices when they get it.
    • A dashboard nobody checks is an expensive decoration.
    • Most integrations fail because of the data, not the API.
    • Security is a habit, not a certificate on the wall.
    • Most businesses think AI is the solution. It isn't. Knowing how to use it is.
    • AI won't fix a bad process. It just helps you do the wrong thing faster.
    • People think they need AI. More often, they need better data and fewer steps.
    • The best AI projects start with a problem, not a model.
    • AI amplifies good processes and bad ones equally.
    • If the ROI depends on replacing people, you probably asked the wrong question.

    Skills

    Broad on purpose. It’s hard to join things up if you only know one of them.

    Broad on purpose. Most problems sit between departments, systems and people, not inside them.

    Technology

    • Software development
    • Solution architecture
    • Database design & data modelling
    • Cloud platforms (AWS & Azure)
    • Microsoft 365 & Power Platform
    • Infrastructure & networking
    • Cyber security
    • System integration
    • Data migration & governance
    • Reporting & analytics
    • AI implementation & automation
    • Accessibility (WCAG 2.2 AA)

    Product & Delivery

    • Product strategy
    • Product design
    • Requirements discovery
    • Solution architecture
    • Wireframing & prototyping
    • Project delivery
    • Service delivery
    • Incident management
    • Technical documentation
    • Customer support

    Leadership & Governance

    • Technology leadership
    • Digital transformation
    • Strategic planning & technology roadmaps
    • Executive stakeholder & board communication
    • Building, mentoring & leading teams
    • Change management
    • Business process improvement
    • Operational transformation
    • Budget ownership & commercial decision-making
    • Vendor management & contract negotiation
    • Risk management
    • Business continuity & disaster recovery
    • IT governance & information governance
    • NHS compliance, DSPT, PCI DSS & Cyber Essentials
    • Technology due diligence & acquisitions

    Currently exploring

    Nothing here is a product yet. Some of it might not become one.

    Good automation makes itself boring.

    • Early

      AI-assisted first-line IT triage

      Why it interests me

      The repetitive 60% of any support queue is exactly the kind of manual admin I can’t leave alone.

      Potential impact

      Faster first response without adding headcount, in an environment where “wait for IT” already costs clinical time.

      Status

      Testing classification accuracy against a year of anonymised ticket history before it touches a live queue.

    • Exploring

      Process intelligence

      Why it interests me

      Every organisation has an official process and a real one. I want to see the gap, not guess at it.

      Potential impact

      Surfaces the bottlenecks people have quietly worked around, before anyone has to ask about them.

      Status

      Evaluating tooling. No real data run yet.

    • Prototype

      A knowledge system that admits what it doesn’t know

      Why it interests me

      Compliance documentation rots the moment it’s written. I want something that admits that instead of pretending otherwise.

      Potential impact

      Fewer “which version is current” conversations, and a better audit trail for free.

      Status

      Accuracy, and knowing when to say “I don’t know”, matter more than speed here — taking the time.

    • Conversations only

      Clinical workflow automation that respects judgement

      Why it interests me

      The clearest way to get healthcare automation wrong is treating clinical judgement as a workflow step to remove.

      Potential impact

      Time back on the admin around care, without automating the care decision itself.

      Status

      Talking to clinical teams, nothing built — deliberately, until the boundary is right.

    • Design stage

      Acquisition onboarding automation

      Why it interests me

      Every acquisition I’ve supported repeated the same manual data-migration pain. I’d rather solve it once, properly.

      Potential impact

      Weeks off the time to bring a new site’s people, data and systems into the group.

      Status

      Drawing on Estate and the migration pattern from the last two acquisitions.

    Get in touch

    Alright mush.

    Want advice on team efficiency, automation or AI? Or just got a problem that smells automatable — I like those.

    Tell me what’s slow or repetitive and I’ll tell you what I’d try — sometimes that’s a tool, sometimes it’s five minutes with something that already exists.

    Nothing for sale here. I do this because I like solving problems and I like people — reach out and I’m happy to talk and help. Won’t be remotely offended if it drifts onto football or cars.

    Email me LinkedIn 07305 076627