About Marcus.

People rarely explain an IT problem in technical language. They explain what they were trying to do. What changed. What they saw. What they’re worried about. What they think they might have broken. Sometimes the most useful detail is also the one they’re embarrassed to mention.

Counselling made a habit of listening before trying to fix anything, and it has carried into my technical work. The same principle applies to larger projects.

Understanding that first can change the technical solution quite a bit. It also helps to remember that technical expertise has limits. I might understand the technology very well, but I don’t understand someone else’s business or circumstances better than they do.

1. A small MSP

   My first IT business was a small MSP around Mandurah. Running an MSP means becoming familiar with quite a lot of things whether you intended to or not: servers, networks, applications, security, vendors, backups, users, and whatever strange problem appeared that morning.

   There often wasn’t another technical team to escalate something to, so problems tended to get followed all the way through. That was a useful way to learn.

2. Global IT Operations

   Later I moved into larger environments, including responsibility for IT operations across Australia, South Africa, North America and Europe. Working across several time zones makes weak systems fairly obvious.

   One team is finishing while another is starting. If an environment depends on one person remembering how something works, eventually that person is asleep, unavailable or has moved on. Monitoring has to be useful. Documentation has to survive staff changes. Handovers have to make sense to someone who wasn’t part of the original conversation. A lot of how I approach operations and architecture now came from working in that environment.

3. Infrastructure, products and automation

   Over time, I became more interested in eliminating recurring operational problems than repeatedly fixing them by hand. That has led to internal tools, integrations between systems that were never designed to work together, browser automation when no useful API existed, and more recently AI-assisted operational systems.

   One project turned roughly 18 years of accumulated operational knowledge into a system that could help diagnose recurring application and infrastructure faults, work through likely causes and, where appropriate, carry out remediation. Previously, much of that depended on an experienced person recognising the symptoms and remembering what had happened the last time.

   Making that knowledge available more consistently is the kind of automation I find interesting: not technology for its own sake, but removing dependence on somebody having exactly the right thing in their head at exactly the right moment.

   Some recurring problems have also turned into products. Sahelay and Emailmetry both started because something appeared often enough that building a proper solution made more sense than continuing to solve it manually.

Most of my work still sits somewhere between infrastructure, operations, architecture and development, especially when a problem crosses several of those boundaries at once.

Experienced technical help is expensive.

That is understandable: infrastructure, security, architecture and automation take years to learn. But it also means the people and organisations with the least room in their budget can end up dealing with some of the hardest technology problems with the least support. I wanted the business I built to make room for that.

Future Fit IT uses revenue from commercial work to help fund at-cost, discounted and pro bono technical support. That includes work with people affected by stalking, harassment and family violence, First Nations peoples and communities, LGBTQIA+ communities, refugees and people seeking asylum, remote communities, neurodivergent people, and organisations working alongside them. The detailed explanation of who we support, why, and how it works is on the Future Fit IT About page.

For me, though, the reason is fairly simple: good technical help should not only be available to whoever has the largest IT budget.

The communities Future Fit IT supports weren’t chosen from a marketing exercise. Some came from work I’ve done in regional and remote Western Australia. Some came through counselling. Some come from my own life.

I’m queer and neurodivergent. I’ve also lived through violent situations, and I know how quickly safety can become entangled with technology: who can find you, which accounts they can access, what information a business has to publish, and whether ordinary tools still feel safe to use. Experiences like those have affected the way I think about privacy, security and technical support.

Sometimes a technology problem really is just a technology problem. Sometimes somebody’s ability to work, stay independent or feel safe is sitting on the other side of it. It helps to know the difference.

Working in regional and remote Western Australia also changes some assumptions about what “good IT” looks like.

• An onsite visit might take days to arrange.
• Internet access can be slow, expensive or unreliable.
• A cloud product may assume connectivity that simply isn’t available.
• The person who originally installed something might now be hundreds of kilometres away.

In those environments, resilience matters. So do documentation and knowledge transfer.

Where practical, I want the people who actually use a system to understand enough of it to handle common problems themselves, and to know when they genuinely need outside help. A solution that only works while its original engineer is standing beside it isn’t much of a solution.