Skip to main content
A lone leader stands above a dense network of technical infrastructure, looking toward a clear teal horizon.

Does the Role of CTO Still Mean Something in the Agentic Age?

Written by Matt Merryfull on . Posted in Articles.

Neon Light / Perspectives / Agentic Age

Does the Role of CTO Still Mean Something in the Agentic Age?

Technology leadership was built around scarcity. What happens when the scarcity begins to disappear?

Matt Merryfull · 7 September 2026 · 15 minute read

A lone leader stands above a dense network of technical infrastructure, looking toward a clear teal horizon.

I’ve been thinking a lot lately about what it actually means to be a CTO. Not theoretically, but personally. For most of my career, my pathway was reasonably clear: I was a technologist. I built things, wrote software, designed systems and solved technical problems. I founded a technology company and, perhaps inevitably, became its CTO. Technology was the scarce capability I possessed.

Increasingly, however, I find myself doing something different. I’m spending less time thinking about how something should be built and considerably more time deciding what should exist in the first place. What problem are we solving? What outcome are we trying to create? What constraints matter, and what does good look like? Once I’ve worked through those questions, another increasingly follows: can I instruct an agentic system to work out the rest?

That’s a very different relationship with technology. The more capable those systems become, the more I find myself moving away from the traditional role of CTO and toward something that looks much more like the role of CEO. That transition has forced me to confront an uncomfortable question: if someone who has spent most of his career building technology is deliberately moving away from its production at precisely the moment it is becoming more powerful, what exactly is changing?

Perhaps the question isn’t simply how AI will change the CTO. Perhaps it’s more fundamental: does the traditional role of CTO still mean something in the Agentic Age?

It’s easy to forget how unusual the ability to build technology has historically been. There are more than eight billion people in the world, yet SlashData estimated approximately 48.4 million active software developers globally by late 2025. That’s around six developers for every thousand people on the planet, and its estimate for professional developers is smaller again. [1]

Even across advanced OECD economies, where technical capability is much more concentrated, ICT professionals represented only around 3.1% of employment in 2024. Historically, those populations were considerably smaller. [2]

Within that already scarce group, capability was never evenly distributed. There is an enormous difference between being able to write some code and being able to understand a complex organisation, design an appropriate architecture, build reliable systems, operate them, evolve them and make sound technical decisions under uncertainty. Good technical operators were scarce. Good architects were scarcer, and people capable of connecting technology to commercial strategy were scarcer again.

That scarcity shaped the organisations we built around technology. We created engineering departments because technical capability needed to be concentrated, and engineering management because that expensive capability needed to be coordinated. Architecture functions emerged because complex systems exceeded the ability of individual developers to reason about the whole. Eventually, we placed someone above those structures: the CTO.

Seen through that lens, the CTO wasn’t created simply because organisations inherently require a Chief Technology Officer. The role emerged because technological capability was scarce, specialised and difficult to coordinate. That distinction matters, because agentic systems are beginning to attack the underlying scarcity.

We’ve been making software development easier for decades. Assembly gave way to higher-level programming languages, languages gained frameworks, and infrastructure moved into the cloud before becoming managed services. Entire technology functions became SaaS products, while low-code and no-code platforms lowered the barrier further. Each abstraction allowed fewer people to accomplish more.

But throughout almost all of those transitions, one thing remained remarkably persistent: somebody technical still had to translate intent into execution. The business could explain what it wanted, but somewhere downstream a technical operator had to convert that requirement into a system.

Agentic computing changes that relationship. Increasingly, we can describe a desired outcome in natural language and have a system investigate the problem, formulate a plan, interact with tools, write software, inspect existing systems, test its work, respond to failures and iterate toward the outcome.

None of this means autonomous agents can reliably build and maintain every production system today. They can’t. Long-running software development remains particularly difficult, and the current version of Zhenfeng Cao’s 2026 paper Agentic Software points to benchmark evidence showing a substantial performance drop when agents move from isolated tasks into sustained software evolution. [3]

But arguing about whether agents can currently replace an entire engineering organisation risks missing the bigger change. I’m less interested in whether an agent can do everything a software engineer can do than in how much of the machinery that historically existed between human intent and technical execution still needs to exist. How quickly is that machinery being compressed?

A recent paper helped crystallise this for me. In June 2026, Zhenfeng Cao published an arXiv preprint under a deliberately provocative title: The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm. Within days, the title and conclusion had been revised, and the paper became Agentic Software: How AI Agents Are Restructuring the Software Paradigm.

That change is important. The argument became more nuanced: software engineering isn’t simply disappearing. Instead, Cao argues that the definition of software itself is changing. In traditional systems, humans write the decision logic in advance and encode it into software. In an agentic system, the reasoning engine increasingly determines what actions to take at runtime, generating code and using tools as necessary to achieve an outcome. [3]

Cao describes the transition as:

AI-assisted productionAI → Software → Result
becoming: agentic executionAgent → Result

It’s a deceptively simple distinction. Under the first model, AI helps humans produce the software that produces the outcome. Under the second, the human describes intent and constraints; the agent plans, executes, validates and returns the outcome.

The code may still exist — sometimes a great deal of it — but it becomes an instrument used by the system rather than necessarily the product around which the entire process is organised. That begins to explain what I’m seeing in my own work. [3]

Think about the organisational chain historically required to turn a business idea into functioning technology. It might have looked something like this:

Business intent → CTO → Architect → Engineering Manager → Developer → Infrastructure → QA → Deployment → Outcome

Every layer existed for a reason. Complexity needed to be translated, technical decisions made and work decomposed so that specialists could execute it. Quality needed to be checked and infrastructure operated. Agentic systems don’t need to eliminate every one of those activities to fundamentally change the economics; they merely need to compress enough of them.

A CEO might increasingly be able to say:

Here is the problem. Here is the desired outcome. Here are the constraints. Investigate the options and determine how we should solve it.

From there, an agentic system can begin decomposing the problem itself. Other agents can research, architect and execute, while others test the work and challenge the output. The human moves progressively upward.

Cao describes that emerging human role as moving from code author toward intent architect, coordinator and auditor. In his proposed progression of agentic engineering, the role continues moving upward again: architect, orchestrator, and eventually goal setter and governor. [3]

That progression caught my attention because, if you follow it far enough, it stops sounding very much like software development and starts sounding remarkably like executive leadership.

The shift in value

Knowing how to build something becomes less differentiating than knowing what should be built, why it should exist and whether what has been produced is actually right.

Perhaps the biggest change I’ve noticed isn’t what the agents can do, but what I increasingly don’t need to do. Historically, I would approach a technology problem through implementation. Increasingly, I can begin much further upstream.

How should we architect this? What infrastructure should we use? What should the data model look like, what framework should we build it in, and how should we deploy it?

What problem actually matters? What outcome would create the greatest leverage? What information and constraints does the system need? What should remain human, where should autonomy stop, and how do we know whether the result is good?

Then I can instruct systems to investigate and execute increasingly significant parts of everything underneath those questions. My role becomes judgement: challenging assumptions, examining the architecture, interrogating the commercial rationale and recognising unintended consequences. I’m connecting decisions to the broader organisation, allocating resources, determining risk and deciding whether we’re solving the right problem in the first place.

That’s not really the job of a software developer. Increasingly, I’m not convinced it’s even the traditional job of a CTO. It looks much more like the job of a CEO, which creates an interesting paradox: technology has never been more central to what I do, yet I’m becoming less involved in directly producing it.

My technical experience hasn’t become irrelevant. Quite the opposite: it gives me the judgement necessary to recognise good technical decisions, bad ones and dangerous ones. But the economic value of that experience is shifting away from my ability to personally execute.

Knowing how to build something becomes less differentiating than knowing what should be built, why it should exist and whether what has been produced is actually right.

This is where the argument becomes uncomfortable for companies like Neon Light. Historically, software development was something we sold, and that made complete sense. Clients had problems they couldn’t solve because they lacked the technical capability required to solve them. We possessed that capability, and the scarcity created value.

I’m increasingly unconvinced that software development itself should remain a primary part of our offering. Not because software is becoming less important — there will almost certainly be vastly more of it in the world — but because the production of software is becoming progressively less scarce.

That’s a very different proposition, and we can see the economic moat around software production eroding before our eyes. A capability that historically required specialists, substantial capital, large teams and significant time can increasingly be accessed through natural language and relatively inexpensive compute. The output isn’t uniformly good, safe or maintainable, but the direction is clear enough that ignoring it feels more dangerous than acknowledging it.

When the cost of producing something falls substantially, the market eventually reprices its production. Software development doesn’t have to disappear for software development as a differentiated service offering to come under enormous pressure. It simply has to become sufficiently accessible.

At that point, software becomes increasingly analogous to infrastructure: still essential, still technically complicated underneath, and still capable of catastrophic failure when handled badly, but progressively less likely to be the thing a customer considers their source of competitive advantage. It becomes an implementation detail.

This is where the transition becomes particularly relevant to Neon Light. We’ve already been moving the business upstream, with our own process framed around four stages:

01

Discover

What actually matters?

02

Diagnose

Are we solving the right problem?

03

Design

What should the system become?

04

Deliver

Execute decisions made well.

When we originally formalised that process, those stages represented a way of approaching complicated technology engagements properly. Viewed through the Agentic Age, however, something else becomes apparent: agentic systems disproportionately attack Deliver. They make production cheaper, increase implementation capacity, reduce the number of people required to execute and shorten iteration cycles. They allow technical work to happen in parallel and increasingly convert implementation knowledge into something accessible on demand.

But making Deliver cheaper doesn’t automatically make the other three stages easier. In fact, it may make them more important. If an organisation can build almost anything, discovering what actually matters becomes more valuable. If implementation is cheap, diagnosing the correct problem becomes more important than rapidly solving the wrong one. And if technical capacity becomes abundant, designing the right system, organisation and operating model becomes the differentiator.

Then Deliver becomes what it arguably should always have been: the execution of decisions already made well. That is a significant validation of where Neon Light has been heading. Our value doesn’t need to be our ability to supply more implementation capacity; it can sit in helping organisations make better decisions about technology.

That means understanding the problem, diagnosing the organisation, designing the architecture, defining the operating model and establishing governance. It means identifying where humans should remain accountable, determining where agentic capability creates genuine leverage and where it simply introduces more complexity, and then orchestrating the capability required to deliver the outcome.

Removing software development from the centre of our offering therefore isn’t retreating from technology. It may be recognising that technology production itself is moving downstream in the value chain. The scarce capability is moving upstream.

I don’t think the answer is simply that the CTO disappears, but I suspect the role splits.

In smaller organisations, the dedicated CTO may become increasingly difficult to justify in its traditional form. A technically literate founder, CEO or product leader supported by sophisticated agentic systems may soon command technical capacity that previously required an engineering leadership hierarchy beneath them.

They won’t suddenly acquire twenty years of engineering knowledge, but they may no longer require twenty people merely to translate intent into execution.

For larger organisations, something different happens. The CTO could become more important, just not as the senior manager of the people who produce technology.

Someone still needs to decide which decisions agents can make and which require humans, what information they can access and what authority they can exercise. How do agents identify themselves, how is their activity audited, and how do autonomous systems interact?

There are also decisions about which models and platforms an organisation should own and which it should rent, where organisational knowledge lives and how agent performance is measured. And someone has to answer the most uncomfortable question: who is accountable when an autonomous system produces exactly what was requested, but the request itself was wrong?

Those aren’t simply software engineering questions. They’re questions about organisational architecture, authority, risk and strategy. The future CTO may therefore be less responsible for running a technology department and more responsible for architecting the relationship between people, information, technology and autonomous systems.

That is a substantially different role, and potentially a far more important one. But it also implies something uncomfortable: a significant amount of the work currently performed under the title CTO may not survive the transition.

For much of the technology era, one of the most consequential questions in business was: can we build this? That question created enormous industries — software companies, technology consultancies, system integrators, engineering organisations, outsourcing markets and cloud providers. Entire careers existed because turning an idea into functioning technology was difficult.

Agentic systems increasingly answer: probably. And when can we build it? becomes easier to answer, the harder questions move elsewhere. Should we build it, and why? What problem are we actually solving? What does success look like, and what should remain human?

Those questions extend well beyond the system itself. What happens to the organisation if this works, or if it fails? Where does our advantage come from when our competitors have access to the same models? And perhaps the biggest question of all: what should we do when our ability to execute is no longer our primary constraint?

Those are questions of judgement, direction, context and accountability. Ultimately, they’re questions of leadership.

Yes, but perhaps not in the way it once did. If the CTO is primarily the organisation’s most senior technical operator — the person who controls the machinery required to translate business intent into software — then I think that role is facing genuine disruption. The scarcity upon which it was built is eroding.

If the CTO instead becomes responsible for designing how people, agents, information and technology operate together, then the role may become considerably more important. But that’s an evolution, not simply a new collection of tools added to an old job description.

For those of us who have built careers around technical capability, there is an uncomfortable question worth asking now: how much of what I do has value because technical execution is genuinely valuable — and how much has value because technical execution used to be scarce?

I’ve started asking myself that question. The answer is changing my own role, it’s changing Neon Light, and increasingly I think it’s changing how we should define technology leadership itself.

Perhaps the ultimate consequence of the Agentic Age isn’t that everyone becomes a developer. It’s that fewer people need to be one. Technology doesn’t disappear, software doesn’t disappear and engineering doesn’t disappear, but the implementation layer becomes thinner.

The people who historically built their value around operating that layer face a choice: compete with increasingly abundant execution, or move upstream toward the things that remain scarce:

judgement, intent, architecture, direction and ownership of outcomes.

Continue reading

Cross-sectional illustration of a corporate boardroom above a hidden operational technology infrastructure representing workflow complexity and value creation.

Due Diligence Finds the Deal. But there’s more to it.

Written by Matt Merryfull on . Posted in Articles.

Traditional due diligence is designed to validate risk, not uncover operational potential.

TL;DR

As PE and VC firms hold assets longer, “fine performance” is no longer enough. Increasingly, value creation is being driven by operational redesign, workflow optimisation, technology alignment and AI readiness.

The challenge is that most organisations were never intentionally designed as cohesive operating systems. They evolved over time through fragmented workflows, disconnected systems, tribal knowledge and process accumulation.

This article explores:

  • why “full potential” diligence is becoming critical;
  • why technology is still commonly viewed through the wrong lens;
  • how AI amplifies operational maturity (or lack thereof);
  • and why operational discovery must happen before meaningful transformation can occur.

The real leverage is rarely found in replacing software.

It’s found in uncovering and redesigning the operational behaviours the software currently reinforces.

Recently, I came across a quote in an article discussing longer private equity hold periods and the growing importance of post-deal value creation.

One line in particular stood out:

“There is always a comprehensive diligence conducted pre-acquisition, but that diligence doesn’t always include a view of what we’d call the ‘full potential’ of the company across all commercial and operational levers.”

That observation is more important than it first appears.

Because in my experience, most due diligence processes are still heavily geared toward validating risk, not uncovering potential – especially in the realm of technology and tech-enabled organisations.

That being said, there’s absolutely nothing wrong with that. Risk matters. Financial quality matters. Legal exposure matters. Cybersecurity matters. [over] Analysis Paralysis matters. But those activities largely answer one question:

“Is this business safe enough to buy?”

They do not necessarily answer the more important question:

“What could this business become?”

And that gap is where enormous amounts of unrealised value continue to sit dormant inside organisations and is perhaps getting a new light shined on it in the wake of AI emergence and delayed exits.

The Challenge With Traditional Due Diligence

Traditional diligence is usually constrained by time, access and incentives.

Pre-acquisition, you rarely have unrestricted access to operational staff, internal politics, undocumented workflows, fragmented systems or the ugly reality of how decisions actually get made inside the organisation – In my experience, there is a slight veil of “honeymoon behaviour” when conducting pre-acquisition due diligence – completely normal mind you.

This polished operating narrative often looks like:

  • The org chart.
  • The approved process.
  • The architecture diagram.
  • The reporting pack.
  • The “single source of truth”.

Then post-acquisition reality arrives.

  • You discover five disconnected systems doing the same job.
  • You discover the business runs on spreadsheets nobody wants to admit exist.
  • You discover customer data is fragmented across departments, tools, vendors and legacy systems.
  • You discover approvals are bottlenecked through tribal knowledge.
  • You discover operational reporting is manually assembled by exhausted middle management every Friday night.
  • You discover technology teams maintaining workflows the business no longer even understands.
  • Lots of sticky-tape and bubble-gum.

And perhaps most importantly:

You discover the business has never actually been designed intentionally as an operating system.

It has simply accumulated over time…and to be quite honest, that’s actually completely normal. Systems and processes are built around the value-proposition, not the other way around.

Technology Is Still Commonly Viewed Through the Wrong Lens

One of the biggest mistakes I continue to see in both traditional due diligence and post-deal operations is that technology is treated primarily as infrastructure.

  • A cost centre.
  • A cyber risk.
  • An integration challenge.
  • A platform rationalisation exercise.
  • A migration roadmap.

But technology is none of those things in isolation.

Technology is the enabler through which an organisation executes decisions.

It is the engine room between commercial ambition and day-to-day operations.

The real issue is not whether a company is running outdated legacy systems.

The real issue is whether the organisation’s workflows, decision-making structures, data flows and operational behaviours are aligned to the outcomes the business claims it wants to achieve.

That’s a very different conversation.

Because often the greatest value opportunities are not found in replacing software.

It’s found in redesigning the operating model the software currently reinforces.

“Full Potential” Is Operational, Not Abstract

The phrase “full potential” sounds abstract until you put it to work.

To me, full potential is:

The measurable value left on the table because the organisation’s workflows, systems, data structures and decision-making processes are not aligned to its commercial ambition.

That value leakage appears everywhere:

  • Revenue leakage.
  • Approval latency.
  • Manual handling overhead.
  • Poor customer visibility.
  • Duplicated effort.
  • Delayed reporting.
  • Broken feedback loops.
  • Slow decision cycles.
  • Inability to scale.

Oftentimes regressing back into the “Business vs IT” tug-of-war.

Most organisations don’t lack ambition.

They lack operational coherence.

And the longer a business is held, the more those inefficiencies compound, impacting uplift, exits and ultimately value.

Which is why sustained “full potential” diligence makes complete sense in a modern PE environment. Its part strategy and operational opportunity combined.

This Is Where AI Changes the Equation

The article also referenced the increasing use of generative and agentic AI across portfolio companies.

That trend is real.

But most organisations are still approaching AI in a very traditional sense.

They are asking:

“How do we apply AI to the business?”

Instead of asking:

“What operational friction exists inside this business that AI could help eliminate, accelerate or augment?”

Those are radically different starting points.

AI is not magic.

AI amplifies operational maturity, brutally punishes those that are not (a tale for another day).

If the organisation’s workflows are fragmented, undocumented or politically inconsistent, AI often magnifies the chaos rather than resolving it, creating some bizarre frankenstein monster commonly referred to as “AI Slop.”

Which is why workflow discovery and operational mapping are becoming increasingly important before large-scale AI adoption.

You cannot coherently automate what you fundamentally do not understand.

The 4D Gap

This is one of the reasons I’ve increasingly framed transformation work through the lens of Neon Light’s 4D framework:

Discover → Diagnose → Design → Deliver

Not as a consulting slogan.*

As an operational discipline.

Because most organisations skip directly to delivery.

They implement platforms before understanding workflows.

Attempt to deploy AI before understanding the impacts.

Buy tooling and or engage MSPs before identifying operational constraints.

Scale process before validating whether the process is even correct.

The result is predictable:

More technology.

More complexity.

More operational drag and cost.

Not more value.

The “Discover” and “Diagnose” phases are where full potential actually becomes visible.

Not just through interviews and workshops, but through understanding how the organisation truly operates beneath the surface – usually where the value has either been operationalised or quietly trapped.

That process is rarely linear.

It involves operational friction, competing priorities, legacy behaviours, technical debt, organisational fatigue and often a fair amount of uncertainty. But there’s also a certain level of shared understanding that emerges when teams begin unpacking those challenges together.

In many respects, that’s where meaningful transformation actually starts.

Not from a vendor pitch deck or a migration roadmap, but from aligning technology enablement with the operational realities and ambitions of the business itself.

That is where the hidden leverage exists.

(* kind of a consulting slogan 😹)

The Shift That’s Coming

Longer hold periods are forcing a shift in mindset.

“Fine performance” is no longer enough.

And increasingly, PE and VC firms are realising that value creation is not simply financial engineering or aggressive cost reduction.

  • It is operational redesign.
  • It is workflow optimisation.
  • It is information clarity.
  • It is decision acceleration.
  • It is technology alignment.

And increasingly so, it is AI readiness – not jumping into bed with AI on day one.

The firms that understand this will likely outperform over the next decade, keep exit schedules tight and enjoy the benefits of increased organisational value.

Moving forward, the leverage will not come from simply buying good businesses.

It will come from systematically uncovering the unrealised potential already trapped inside them.

Source Article: https://www.pehub.com/value-creation-and-post-deal-due-diligence-more-important-with-longer-hold-periods-blackstone-injects-5-billion-into-jv-with-google/

Continue reading

2025 – the year AI stole my dopamine

Written by Matt Merryfull on . Posted in Articles.

A reflection on automation, responsibility and the evolving definition of purpose in the AI era.

TL;DR

Early software development delivered purpose through struggle, mastery, and ownership. AI collapsed that loop.

As AI evolved from a gimmick into a capable reasoning partner, productivity exploded…but satisfaction quietly evaporated. The dopamine wasn’t being stolen outright, it was slowly (sort of) displaced. When effort disappears, so does the sense of authorship and responsibility that once gave our work meaning.

This isn’t just a engineer problem. As AI becomes universal across industries, we’re now entering an “Agency Age” where tools increasingly act on our behalf. When understanding becomes optional and outcomes are generated rather than earned, responsibility blurs and systems become brittle.

The real risk isn’t job loss – it’s loss of agency. Progress without responsible ownership becomes momentum without direction.

The next frontier isn’t faster output or smarter tools. It’s intentional agency: deciding what to automate, what to retain, and where responsibility must remain human. Fulfilment in the AI era won’t come from competing with machines, but from reclaiming authorship over direction, intent, and consequence.

AI didn’t just change how work gets done – it forces us to redefine purpose itself.

Setting a relatable scene

Its the year 2002 and we’re deep in the weeds developing OptusTV on the iPhone2 and the soon to be released iPhone3G; phones that were never meant to stream video – that was me building a way to stream (ahem, progressively download) video playback for a product launch. No documentation, no guidance, no outside help – just one impossible task after another, one tiny addictive victory at a time. Young, ambitious, out there to solve all problems with technology – go get ’em tiger.

It was an incredible time to be a software engineer, there were coding books everywhere, limited web resources to lean on, the internet was painfully slow in Australia, CPUs still had “Pentium” at the start and AI was something that only existed in movies and SciFi novels. Developing software back then felt very much like opening up the digital frontier and the notion of developing a piece of software for the very first time was a real possibility.

I suspect this period of early expansion is the same in most exploits across industries; the thrill of doing something “first” – feeling like you’ve conquered the mountain before all others and living to tell the tale. It’s an exhilarating feeling and being part of a group of like-minded individuals sharing similar goals made that period in my life truly special.

Fast-forward to 2025 and unbeknownst to me, it would prove to be the pivotal moment that AI would assume the heavy lifting of the software development and with it, quietly take my dopamine as well.

I’ll be honest, I was particularly late to the AI game. Sure, I read about it, tinkered with the tools, made a video of Will Smith gobbling pasta, read the philosophical and societal issues concerning our jobs and livelihood, but using it in my day to day – nope. It was only when I was invited by Github to beta test Copilot in 2021-22 that I actually decided to give it a try.

My initial assessment of AI was that it was conflated and clumsy. Sure it worked, but it felt like someone speaking broken english giving a lecture on Shakespeare, sure it got over the line, but it did so in a very round-about kind of way. Hallucinations happened often, context was limited and the ongoing result would wander off into oblivion very quickly. In all honesty, it felt like autocomplete on steroids – and not in a good way.

I wrestled with the technology a lot, fought it even when it wanted to do one thing and I another. Differences of opinion, latest versions and features clashing, solving problems and dealing with issues that it created and would then apologise profusely for drove me round the twist to the point where I turned it off to get some sanity and focus back. I consulted my peers who signalled the same experiences and frustrations with the technology, some going as far as requesting refunds given the technology did not meet expectations in terms of productivity and quality.

That was the way it was for a while – AI was still very gimmicky. I didn’t use it in my primary role and it didn’t have a significant impact on what I did. I continued to experiment with AI, but not from an engineering point of view. Research, ideation, analysis were commonplace usages for AI and indeed it helped. Combing the internet and research documents for specific pieces of information is incredibly time consuming and AI breezed through that better and better with each iteration to the point where the “flow” state was beginning to emanate in my work. This felt like cheating in some ways and in other ways, like laziness. I knew what I wanted and now I had the all-seeing oracle to consult whenever I chose. It was intoxicating, and unsettling – a small taste of what might happen if AI became capable of carrying more than just the menial load.

Then something shifted…

When OpenAI’s o1 model came out in 2024 with the ability to “reason”, I rebooted coding with AI. This was significant as the AI tools had clearly been on a supercharged journey of evolution to address the needs of software engineers. Once I started using it and it understood my work, could resolve its suggestions with what I was trying to achieve, reduced hallucinations, removed the need for prompt engineering structures and sequencing and started working with me, I made a dedicated effort to incorporate it everywhere and anywhere I could.

The productivity gains were dramatic and very, very noticeable. Analysis became trivial, identifying bottlenecks and issues with my work became a matter of minutes instead of hours, roughing in patches became days instead of weeks. The tool had shifted into the realm of conversational and cooperative. Adding the ability to read, understand and compile emails, designs, flowcharts, image creation and develop and iterate – the productivity really began to accelerate. AI wasn’t assisting me anymore, it was taking the load off my shoulders.

That’s when the discomfort set in.

The problem that slowly began to surface in my everyday interaction with AI was a lack of satisfaction in my work. Sure I was motoring through work that would have otherwise taken days, weeks or in some cases months to do pre-AI, but I was left on the other side with an ever growing feeling of hollowness. My first reaction was to do more work, improve the systems I’d put in place, make them better, faster, more resilient, give it access to more information, but the unrelenting efficiency by which the AI was performing tasks I gave it, only fuelled the underlying problem. I came to realise that massive increases in personal productivity didn’t equate to satisfaction.

Up until this point in time, solving digital problems was my thing. People came to me from all over to solve unsolvable problems, confident in my ability to solve them. That responsibility gave me incredible purpose. Throwing yourself into problems no one else could comprehend, let alone fix is quite a privilege. The dopamine wasn’t just from success, it was from the cycle of struggle, anticipation and resolution. AI collapsed that entire loop.

Sure, my initial reaction to AI solving problems for me was akin to the first time you see a magic trick, it’s truly a wondrous thing to behold. AI is relatively instant, understands every subject, every language, is mostly right (given the right context and information) and endlessly helpful. But once I realised it was doing my thing, I realised my joy wasn’t being stolen outright – it was being displaced.

This isn’t just a technology problem.

With AI now permeated into Finance, Healthcare, Law, Marketing & Media (Canva anyone?), Manufacturing, Logistics, Insurance, Education, Resourcing, Retail & FMCG, its on the way to being as universal as electricity and the internet. Most people and industries are encountering AI through tools, not as a core capability, but the overall direction is clear.

What productivity, satisfaction, creativity, fulfilment and purpose means to each of us, especially considering we’ve moved away the ages of “distribution” (e.g. digital age, information age, social media) and into something that more closely resembles the “agency age”; where our agency is shifting away from us in a constantly, but ever so subtle, productivity-boosting, dopamine-sapping way, will be something different and unique to every one of us. Yes it has an element of fear, but an equal amount of thrill and excitement.

That shift has consequences.

Responsibility used to be tangibly connected to the effort. You built something because you understood how. If it broke, you fixed it because you owned it. AI challenges that relationship. When you no longer fully understand what’s happening under the hood, responsibility becomes abstract, and systems by consequence become brittle.

This is where I get a little uncomfortable in my chair. It’s not a fear of AI itself, but more so about where responsibility lives in an AI-enabled world. When the thinking, designing and deciding are increasingly outsourced, what does it mean to truly own an outcome?

…I don’t have clean answers yet – and I suspect the answer will change over time.

For me and for right now, the transition is well underway. Building things using software is always going to be a thing I do – I’ve come across too many upside down systems to know that AI doesn’t have imperfect answers to incompatible realities, messy constraints and compromises that are fundamentally human in nature. Those gaps still matter…for now.

But, I’m certain of a few things, firstly, redefining purpose and fulfilment is no longer optional. The things that historically gave us meaning; struggle, mastery, publication, are being reshaped. Preserving first-principle thinking, craft, artistry and responsibility isn’t nostalgic though – it’s resilience.

AI did steal my dopamine in 2025. It flipped the switch on who was solving the everyday puzzles and for the first time in my career, I had to confront the difference between progress and fulfilment. Looking back, that shift was inevitable. In 2002, if there had been a faster or better way to solve those streaming problems, I would have taken it without hesitation. I’ve always used the best tools available. AI isn’t different in principle: it’s different in proximity.

It’s closer to the bone now. That’s why it feels unsettling.

What’s changed isn’t productivity, or even creativity, it’s agency. When effort collapses, responsibility becomes harder to see or assign. When understanding becomes optional, ownership blurs. And when systems become powerful enough to act on our behalf, the question stops being can we build this and becomes who is responsible (read: accountable) when it works, and what happens when it doesn’t?

This is the heart of the age we’re entering.

The next frontier isn’t faster code, smarter tools, or even higher output. It’s intentional agency. It’s deciding where automation ends and responsibility begins. It’s preserving first-principle thinking not as nostalgia, but as a safeguard against brittle systems that no one truly understands or owns – a very real danger I’m seeing unfold.

AI will continue to accelerate…everything, including our capacity to build things we don’t fully comprehend or understand. That makes design, diagnosis, and decision-making more important, not less. The value is no longer in doing the work faster; it’s in asking better questions, defining the right problems, and choosing deliberately what should, and should not be delegated.

In the Agency Age, fulfilment won’t come from outpacing machines – let’s be honest, that’s not possible anymore. It will come from reclaiming authorship over direction, intent, and consequence. That’s a tougher challenge than writing code ever was, and requires a different mental approach we can’t outsource.

AI may have stolen my dopamine, but it showed me something far more important – progress without agency is just momentum. And momentum, without responsibility, is how systems and people, quietly lose their way. The challenge isn’t about keeping pace with AI – its about redefining what purpose means in a world where agency is no longer guaranteed.

Continue reading

AI Isn’t the Future, It’s the Filter

Written by Matt Merryfull on . Posted in Articles.

Temporary Concern, or the New Normal?

TL;DR

Businesses are no longer deciding whether to adopt AI — they’re deciding how quickly they can do it before someone else does. Traditional digital modernisation often failed due to high upfront cost and complexity. AI flips that — reducing resource overhead, accelerating delivery, and changing how software and strategy are approached.

But…

From due diligence to product design, AI-readiness is now a permanent evaluation lens. Companies ignoring it risk being outpaced or devalued. But moving fast without architectural discipline — a la vibe coding — introduces its own fragility.

To help teams move with confidence, I’ve developed the Blacklight 4D Framework:

Discover → Diagnose → Design → Deliver — a structured path to uncover, validate, and execute on AI-native opportunities.

📩 I work with investors, founders, and teams to navigate innovation, M&A, and strategic tech delivery. Let’s talk if you’re building, buying, or betting on the next wave.

Across industries, businesses are facing a clear fork in the road: evolve with AI, or be overtaken by those who already have. In every due diligence engagement I’ve run over the past 12 months — from payments to policy to platform ventures — AI is no longer a speculative layer. It’s a strategic constant.

What was once an exploration — “Could we use AI here?” — is now a gating condition: “Are you AI-ready enough to move forward?”

If you’re not embedding AI into your architectural thinking, operational model, and commercial roadmap, you’re preparing to compete against businesses that already have — and they’re doing it faster, leaner, and smarter.

they’re doing it faster, leaner, and smarter.

From Paper-Tiger Modernisation to AI-Native Execution

Traditional business modernisation promised leverage: digitise your systems, connect your data, unlock new markets. But it often fell flat. Expensive COTS systems, bloated middleware layers, and months of onboarding for abstract outcomes. Most companies balked at the cost, because the resource overhead and risk outweighed the perceived opportunity.

Now? AI-native strategies have flipped that dynamic.

  • Prototyping timelines have collapsed.

  • Small teams can outbuild entire departments.

  • LLM-powered workflows remove the need for excessive headcount to scale.

  • Training, automation, and deployment can be embedded with near-zero marginal cost.

The high-friction modernisation of the last decade has been replaced by modular, intent-driven, low-lift innovation — and the gap between adopters and followers is growing…really, really fast.

AI as a Due Diligence Standard, Not a Side Topic

In technical due diligence, we’ve reached a tipping point: AI-readiness isn’t just part of the review — it’s foundational.

Key questions now include:

  • Can this company scale without exploding OPEX?

  • Is the product team fluent in AI-first design and automation?

  • How resilient is the architecture under real-world LLM use?

  • Can the company defend its IP in an AI-assisted competitive field?

We’re not just looking at code or capability anymore — we’re looking at velocity, adaptability, and execution logic. We’re also applying this lens internally: our own skunkworks innovation tracks are AI-native from day zero, because anything else is slower, costlier, and harder to pivot.

The Software Shift: From Code to Cognition

This shift has deep implications for software engineering and IT leadership.

AI is not just a tool for speed — it’s transforming the structure and economics of delivery:

  • System design trumps individual code quality

  • Prompting replaces boilerplate

  • Testing and deployment are increasingly self-managed

  • Toolchains are flattening, generalist builders are accelerating

  • Cost-to-deploy is approaching zero

This isn’t just a change in toolkits — it’s a redefinition of what it means to build.

Vibe Coding and the Cognitive Gap

But here’s where the nuance creeps in — and where strategic leaders need to tread carefully.

The rise of vibe coding — where users describe what they want and AI writes the code — introduces a new kind of fragility. Yes, anyone can now generate software. But most don’t know how it works, what breaks it, or how to fix it. It’s like handing the keys to a supercar to someone who’s never driven manual.

While this lowers the barrier to entry, it also raises the floor for required system literacy. We’re heading into a world where more people can “drive” the system — but fewer understand how it’s wired underneath.

In the near future, this may be abstracted away entirely — with specialist LLMs handling fault tolerance, debugging, triage, and observability. Developers will become orchestrators, not operators. But for now? It’s a risk. One that must be assessed in any serious technical review or innovation planning cycle.

Blacklight 4D as Strategy: Build What the Business Can’t Yet Buy

We’ve formalised this into what we call Blacklight 4D (find what you cannot yet see) — a short-cycle innovation program built around AI-native tooling, modular architecture, and due diligence-grade engineering and creative disciplines.

It’s designed for companies that:

  • Need to prototype fast without overcommitting headcount

  • Want to validate innovation without legacy drag

  • Are preparing for M&A, internal restructuring, or investor scrutiny

  • Have leadership buy-in, but need execution clarity

It’s not about shiny proofs of concept. It’s about building real capability, fast, with the structural foresight needed to scale or integrate post-sprint (look to our recent hackathon for more).

Who We Help

I partner with decision-makers who see the writing on the wall and want to get ahead of it. Whether you’re preparing for a capital raise, exploring a tech acquisition, building internal capability, or modernising your stack — I help map risk, accelerate opportunity, and engineer with intent.

📩 If you’re navigating AI-readiness, due diligence, or innovation bottlenecks — let’s talk. I’m currently supporting engagements across multiple sectors.

Continue reading

Building Bridges

Written by Matt Merryfull on . Posted in Articles.

with Real-Time Data and Unreal Engine

TL;DR – A Hackathon Recap

We set out to prove that Unreal Engine can be more than a rendering tool—it can be a live, integrated node in a real-time digital ecosystem.

In just a few days, we:

  • Prototyped a WebSocket-based sync layer connecting UE with a web UI (Google Maps) and .NET backend using MassTransit + AWS SQS.

  • Used Cesium for UE to build a 3D twin of the real world.

  • Demonstrated two-way communication, not just visualisation—allowing interactions from and to UE.

  • Skipped auth (for now) to focus on real-time viability and cross-system collaboration.

  • Explored how SpacetimeDB’s timewarp unlocks “experiential analytics”—revisiting moments in time spatially.

We also leaned into a cross-disciplinary team model, where engineering and technical artistry collaborated closely—proof that diverse perspectives create richer solutions.

This wasn’t about shipping production code. It was about momentum toward something bigger – BRAID-like 🤓, if you will.

Foundations are everything…

At Neon Light HQ here in Sydney, we recently ran a focused internal hackathon aimed at solving a deceptively simple but expansive problem: how do you synchronise Unreal Engine (UE) with other platforms in real-time – and in a way that’s extensible, scalable, and meaningful beyond the confines of game development?

The goal was to prototype a WebSocket service that could shuttle data back and forth between UE and external interfaces, making UE not just a rendering endpoint, but a participant in a broader digital ecosystem.

We landed on a three-tiered architecture:

  • A .NET Core backend acting as an intermediary layer, built using MassTransit for message orchestration and AWS SQS for queueing and fan-out

  • A React web interface that displayed contextual overlays via Google Maps.

  • A Cesium for UE setup rendering a rich 3D digital twin of the real world (this is almost trivial these days – so big thank you to the team over at Cesium).

The intent? If a user clicks something in the web interface, a WebSocket event fires to UE. UE responds with spatial context or 3D metadata. And just as crucially, if UE detects a spatial interaction (e.g. an object selected in-world), that event fans out to web dashboards, logs, and notification systems.

This may sound modest, but the core principle flips a common pattern on its head. Most integrations (Bentley Systems, for instance) are read-only. Data flows into the visual system but not out. We’re proving that the loop can – and should – close.

It’s not that these systems don’t have the capability, the desire just hasn’t been there, until now.

Why It Matters

Most of today’s visual-based workloads – spreadsheets, reports, PDFs – exist in ecosystems that sit around spatial engines, not within them. And while tools like UE Datasmith help ingest content into Unreal, they don’t help facilitate collaboration or insight generation from inside the experience – realistically, that’s not what Datasmith or UE was designed to do.

We believe that real value comes when spatial platforms become expressive interfaces—not just canvases.

Think: stakeholder walkthroughs that generate insights, not just impressions. Engineers observing user focus patterns. Designers iterating based on behaviour, not assumptions. Expand this use case through to future governance and the digital twin interface and you’ll see where our team’s collective minds are travelling toward.

This is why one of our next moves is incorporating SpacetimeDB, a time-aware database that unlocks ‘timewarp’ capabilities. Users and systems will be able to query what was happening, who was there, and what was seen at any point in the spatial timeline. It’s experiential analytics without the friction—impressions captured passively, insight drawn actively.

In the video, we see the world coordinate data (Latitude and Longitude) being synchronised from UE through to Google Maps. Towards the end, the ability to “warp” to different locations is captured as well – enabling new interaction paradigms not possible in previous experiential delivery.

On Security, Teamwork, and Realities

In the interest of velocity, we excluded an authentication layer. Not because it’s not important – it is, especially for security and multi-tenant setups – but because the goal of this hackathon wasn’t polish, it was potential. We know auth is a critical next step for any real-world deployment.

Equally critical to the hackathon’s success was our interdisciplinary team. Neon Light’s DNA isn’t just code; it’s artistry, engineering, experience, and storytelling. In this sprint, we saw technical artists collaborate with engineers, ops folks challenge assumptions, and designers stretch the boundaries of what the toolset was originally built for. That shared intent – the idea that collaboration is the actual outcome – was more valuable than any single feature we shipped.

Looking Ahead

As we step back from this experiment, it’s clear we’ve only scratched the surface. The addition of pub/sub queues – using MassTransit via C# and .NET with AWS SQS – enables a fan-out approach to event handling, allowing decoupled services like notifications, AI processes, reporting, and data-lakes to react asynchronously to system activity. This de-centralised approach offers scalable pathways to expand workloads and capabilities without overloading the core systems.

Equally compelling is the opportunity presented by SpacetimeDB’s timewarp feature. It introduces a novel concept in experiential analytics: the ability to revisit specific moments in a shared 3D environment and extract insights without interrupting or distorting the original user experience. Imagine stakeholders being able to explore what was viewed, when, why, and for how long – without intrusive data capture or forced interactions. It’s a subtle but powerful shift: analytics that respect the flow of experience while enabling deep reflection later.

a powerful shift: analytics that respect the flow of experience while enabling deep reflection later.

This prototype, while small in scope, is a key step toward a broader connected ecosystem. While we held off implementing authentication for now – given the short hackathon window – we fully recognise its role in enabling secure and scalable infrastructure for real-world deployment. Similarly, the discussions and cross-domain collaboration that fuelled this build are just as important as the technical outputs. The blending of software engineering and technical artistry created a feedback loop of ideas that shaped not only what we built, but why we built it.

We’re treating this not as a standalone exercise, but as a foundational thread in a broader tapestry – one that will weave into larger platform ambitions. This includes improved interoperability, new collaborative workflows, and real-time digital experiences that extend across disciplines and industries. As we refine these concepts and begin incorporating persistent state layers, we’re opening the door to meaningful partnerships, scalable implementations, and new ways of engaging with the digital world.

Continue reading

Bridging the Gap

Written by mmerryfull on . Posted in Articles. No Comments on Bridging the Gap

Ella Eberhardt – Internship 2024-25

How Mentoring Interns Today Shapes the Leaders of Tomorrow

In an age where technology evolves at lightning speed, the gap between classroom theory and workplace application grows wider by the day. As someone who’s spent over two decades in the technology and digital innovation space, I’ve witnessed firsthand how crucial it is to bridge this divide. My recent experience mentoring Ella Eberhardt, a bright Bachelor of Creative Intelligence student from UTS, reinforced my belief that meaningful internships are perhaps more vital now than ever before.

Beyond Coffee Runs: Reimagining the Modern Internship

When I decided to bring an intern into our technology and creative design consultancy last quarter, I was determined to avoid the clichéd internship experience. You know the one—fetching coffee, making copies, and being relegated to busy work that provides little value to either party.

Instead, I structured Ella’s experience around what I consider the three vital environments of modern work: the client’s experience for direct stakeholder engagement, our company headquarters for collaborative learning, and remote work for developing self-discipline and focus.

This approach wasn’t without its challenges. The confidential nature of our projects (many under NDAs) initially gave me pause as I didn’t want to relegate Ella to a mundane workplace experience. The complexity of the projects that we often deliver also made me question the ability for an intern to provide meaningful contributions and conversely what can be learnt from the organisation in a relatively short space of time.

Plus, I strongly believe interns deserve compensation—the era of unpaid “experience” should be behind us; something I believe we haven’t gotten right yet. Paying our interns should be simple and legislated accordingly for business owners not to get caught up in the administration of it all. I had to wrestle with this and I understand why many small businesses shy away from the undertaking.

But these concerns paled in comparison to the potential benefits of providing a genuinely educational and enriching experience (both ways I might add).

The Reality Check Generation

What struck me most about working with Ella was something I’ve observed across her generation: an impressive confidence bolstered by their digital nativity. They’ve grown up online, navigating complex digital landscapes with ease. Yet this same confidence can sometimes create a blindspot when it comes to receiving critique or understanding the methodical, sometimes mundane steps required to reach ambitious goals. 

One of the most valuable skills Ella developed during her time with us beyond being simply assigned tasks was to seek out what I call “defining done”— the ability to clarify and agree expectations and deliverables rather than assuming parameters. Ella herself commented that knowing when to consider a piece of work finalised was tricky. This speaks to something I’ve held closely throughout my career, which is the notion of Getting S*** Done. This statement bookends nicely to defining done – there is a real art to defining completeness, too much deliberation and investigation leads to “analysis paralysis” and introduces bloat to projects, too little and assumptions and misalignment creep into a project and blow out costs and timelines with re-work and re-calibration. Failure is an excellent teacher but we have to nurture and support what comes next; the courage to ask questions in spite of this and the willingness to persist. Having the support of your manager/organisation rather than punitive measures is critical and it builds trust and confidence across the board. Once you have this, you can really GSD.

“Equally important was learning to “manage up,” recognising that her supervisors (both myself and at the client) were often time-poor and that successful delegation requires proactive clarification.

Oftentimes I find myself context switching between multiple projects and priorities—a reality for most people in supervisory roles. Decision-making in these environments hinges on two critical components: available information and background knowledge. The time-poor component creates a situation where supervisors rely on team members to perform requisite research, fact-finding, and validation to supply that “available information.”

What impressed me about Ella was that she arrived with a solid framework for analytical thinking from her Creative Intelligence program. However, adapting this academic approach to the workplace required refinement. Where university assignments offer structured rubrics and clear parameters, professional tasks often come with implicit expectations and unspoken requirements.

I observed her growth when she began anticipating informational gaps in client deliverables before I needed to point them out. Rather than simply completing the assigned analysis, she started contextualising her findings within the client’s specific business challenges—something her academic training had prepared her for conceptually, but that required practical calibration in a fast-paced professional environment. This refinement process—taking strong academic foundations and recalibrating them to serve time-constrained decision-makers—represents a crucial transition that even the most well-educated graduates must navigate.

 Learning how to clarify expectations at the time of being given a task was a skill that Ella developed over the course of her time with us. This goes hand in hand with my earlier point of work definitions and GSD – having elevating levels of empathy enable others to do the same within an organisational structure and breeds a culture of common support and camaraderie.

Our client noticed this shift too. They commented that Ella showed stronger interest in strategic tasks than routine ones—a common trait I’ve observed in ambitious young talents who sometimes overlook the foundational building blocks in favor of the big vision and attributing themselves to it. Through mentorship, we worked to balance these tendencies and build competency and understanding of the importance of operational routine as the building blocks to meaningful contribution, personal growth and purpose.

The Apprenticeship Model Still Matters

In an era increasingly dominated by AI and automation, the soft skills that define successful careers can’t be downloaded or programmed—they must be observed, practiced, and refined through real-world experience. As a technologist and probably the industry most at-risk of disruption I’ve come to appreciate that AI is a very well-informed companion and co-pilot in a very different future to the one I’ve made a career out of and hopefully can pass along to the next generation.

When Ella found herself facing the occasional situation where responsibilities became blurry (a common challenge in multi-vendor environments), she had to navigate complex stakeholder dynamics that no classroom could adequately simulate or AI create a facsimile of to respond to. These moments, though occasionally uncomfortable, provided invaluable learning opportunities that will serve her throughout her career.

What surprised me most was her feedback. Ella mentioned she expected to be “ferrying assistant mundane tasks in an office setting” and instead found herself applying her academic knowledge in meaningful ways while gaining direct client exposure. She discovered that the principles taught in her creative intelligence program actually translate to the workplace—when given the opportunity to apply them. It’s really awesome to bear witness to other people’s “A-Ha” lightning strike moments.

It’s really awesome to bear witness to other people’s “A-Ha” lightning strike moments.

Why Every Business Should Consider Mentoring Interns

If there’s one thing I’d urge my fellow business leaders to consider, it’s this: internships benefit both parties in ways that extend far beyond temporary help or resume building.

Technology remains just as misunderstood today as when I entered the field decades ago. We desperately need practitioners who can not only master technical concepts but effectively communicate them to build understanding and confidence among stakeholders. A worrying reliance on technology is emerging and the silver bullet of Artificial Intelligence can and has compounded this even further.

Through mentoring, I found myself reflecting on my own skills and approaches. Your body of work has a way of dictating the tide and this can mean that some areas simply get overlooked or neglected. There’s nothing quite like fresh perspectives to make you reassess and refocus your own assumptions and practices – for that I’m continually grateful for having this experience once again.

In my time I’ve witnessed workplace cultures transform from autocratic management to collaborative environments, but this shift brings its own challenges. Autonomy requires responsibility, and that responsibility needs conscious development. Internships provide the perfect testing ground for this growth. Many of us have worked in collaborative environments for years now, but it’s only through the bumps, bruises and growing pains that we’ve evolved. We should be well placed to highlight the way for future generations.

Looking Forward, Not Back

The reality is that in our rapidly evolving digital landscape, we need creative, confident thinkers who can navigate complexity while maintaining the discipline to execute methodically. These skills aren’t developed overnight or in isolation—they’re cultivated through meaningful professional relationships and real-world challenges.

At Neon Light, we’re building a roadmap to making meaningful mentorship a cornerstone of both our business philosophy and our approach to technology consultation. This commitment reflects my own professional journey—having navigated the evolution from technical practitioner to strategic advisor over two decades. The same principles that guide our client relationships—demystifying complex technology concepts, building bridges between technical capabilities and business outcomes, and fostering genuine human connections in an increasingly digital world—inform our approach to developing talent. By investing in the next generation of technology thinkers, we’re not just fulfilling a corporate responsibility; we’re cultivating the kind of multidimensional problem-solvers who will advance our industry in ways we can’t yet imagine.

So, to those reading this, I encourage you to consider how you might incorporate internship opportunities into your organisations. Not as a source of cheap labor or a corporate social responsibility checkbox, but as a genuine investment in our collective future and an opportunity for mutual growth. As I’ve stayed in touch with previous interns and watched their careers flourish, I’ve realised that perhaps the most rewarding aspect of mentorship isn’t what we teach them, but what they go on to achieve. 

After all, in a world increasingly shaped by artificial intelligence, the uniquely human skills of creative problem-solving, effective communication, and collaborative innovation have never been more valuable. And those are precisely the skills we have the privilege to help develop when we mentor the next generation.

Continue reading