Why Making Technology Accessible Is Personal to Me

The Work Before the Work

I had some trouble at Queen’s University and ended up working at the aluminum factory through the local union. The union gave me the opportunity to go back to school while I worked.

I studied computer programming. But for most of my career, I found myself working in networks and infrastructure.

I ran the network at Empire Life, a Canadian insurance company, for about five years. Then I had the opportunity to become the senior network architect for the Canadian Parliament, where I spent about a decade.

That is quite a distance from where I started.

I still keep in touch with some of the people from the factory. They knew me before any of the books, the talks, the videos, or the AI agents. They’re proud of where I ended up.

And I remember what that work required. Three twelve-hour shifts over a weekend, doing physically demanding work, takes something out of you.

Technology opened another path for me. That experience is behind the seriousness I bring to teaching and sharing what I learn.

There Is a Person on the Other Side of the Video

When I publish something, I think about who might be watching.

Maybe it’s somebody working at a gas station who listens to my YouTube videos and wants to move into IT. Maybe it’s a woman who wants to get back into the workforce and needs somewhere to start.

I mentioned both of those possibilities during my conversation with Alan Shimel on Techstrong TV because they matter to me.

They can watch somebody work through it. See the tools. Hear the vocabulary. Follow the steps. Start asking their own questions.

That’s why I’ve laid so much of my journey out publicly through websites, blogs, videos, and code. People can see how I got somewhere, including the learning that happened along the way.

I want them to have a starting point.

I’ve Experienced What Happens When Skills Come Together

Around 2016, while I was at Parliament, operating the infrastructure we had built was becoming increasingly difficult. The scale and complexity were creating a problem.

That pushed us toward network automation.

For me, something clicked. The programming education I had received years earlier and the network experience I had accumulated were coming together.

I could use Python to communicate with the network. I could describe an operation programmatically instead of logging into devices and doing everything by hand.

That changed how I worked.

It also helps explain my enthusiasm for what is happening now.

Today, I can describe an agent in network engineering terms. Test the interfaces on these devices. Produce a report. Notify me if you find a serious problem.

The network knowledge still shapes the request. You have to understand which devices matter, what constitutes a problem, and what information belongs in the report.

But you have another way to turn that knowledge into something useful.

Let People Start With What They Know

There is a lot of operational expertise sitting inside infrastructure teams.

People know which checks they run before a change. They know what they look for when an interface is behaving badly. They know which information another team needs before it can make a decision.

Giving them a way to express that knowledge in their own technical language is significant.

At Itential, I work with tools that let me describe what I need and build toward it. During the interview, I gave the example of an agent that tests interfaces, sends a report, and escalates serious findings.

That is a recognizable job to a network engineer. It has an outcome they understand.

The interesting questions then become very practical. What should it test? What counts as serious? What should happen when the data is incomplete? Who needs the result?

Those are good questions. They bring the engineer’s experience into the work.

Making something easier to build creates an opportunity to spend more time understanding what it should do.

The First Build Needs Somewhere to Go

The ability to create an agent is exciting. I build them, so I understand that excitement very well.

But accessibility has to extend beyond the first successful demonstration.

In an enterprise, somebody needs to understand what the agent can access, who can run it, what it did, and how its work fits into the operation.

If all of that becomes a separate engineering project after the agent is built, we have introduced another barrier between an idea and useful work.

This is one of the reasons I joined Itential.

The building experience sits alongside an operational platform. Agents use scoped tools, access controls govern their use, and their actions run through governed execution. Those controls are described in Itential’s security and governance overview and Trust Center.

That foundation matters to the person building. It also matters to the people who have to operate, review, and support what gets built.

A useful path into this technology should help people participate in the whole process: describing the work, inspecting it, testing it, and understanding how it runs.

Access Includes Knowing How to Judge the Result

When we make building easier, we also need to make the learning around it visible.

• An agent returns a report. How do you know the report answers the question you asked?
• It identifies a problem. What evidence supports the finding?
• It proposes a change. What else could that change affect?

These are the kinds of questions infrastructure engineers already work through. They belong in the learning experience alongside the tools and the prompts.

That gives experienced engineers an important role. The knowledge they have accumulated can help somebody else understand what good looks like.

It gives newer practitioners something useful to study, too. They can inspect the request, the tools, the findings, and the reasoning behind the next step.