The importance of orchestration
I used to write code, then managed delivery, and now I lead AI transformation, the most technically stimulating chapter of my career. Yet, I never stopped coding in my own time, and AI just made those hours count again at work. And that changes how leaders should work.
I spent years writing code. Then I moved into delivery management and stopped writing code for a living.
But I never stopped writing it, though; evenings, weekends, whenever something caught my interest. What I couldn’t do was develop anything serious in the limited hours I had.
Today I lead AI transformation, and something I didn’t expect has happened. The role is becoming hands-on again in a way that counts at work, not just at home. My work never stopped being technical. What has changed is how I can engage with it directly and how far a few free hours go now.
That path, code to delivery to transformation, is why I trust what I’m about to say. The shift that everyone calls new, I watched it arrive from both sides of the fence.
Fair warning: this is a perspective piece, my perspective. It is not a study or benchmarks, nor a case study. It’s a lens. Test it against your own teams.
What delivery management taught me
When you manage delivery for a while, you learn something that sticks. And that is that code was never the whole story.
Projects rarely succeeded because someone typed fast. They succeeded because they had clarity about the requirement, an architecture that held together, a review that caught problems while they were still cheap, and quality that was owned from day one. The best teams I worked with weren’t the fastest typists. They were the clearest thinkers.
So when AI coding tools showed up, and everyone started asking what happens when code becomes cheap to produce, I already had a view. The value moves to everything around the code. It always lived there. AI just makes it obvious.
There’s an obvious objection, so let me make it for you. Of course the delivery guy says the code was never the hard part. Fair enough. Don’t take my word for it, then. Watch the developers getting the most out of AI right now. They start with intent, not an empty editor. Specification first, then agents implementing, reviewing, testing, and a human reading far more code than they write. The craft didn’t vanish from their work. It moved up the stack, to exactly where value was all along.
My side projects grew up
Here’s what I didn’t see coming. The hours I already spent on code started producing things that mattered.
What limits a leader who codes on their own time was never interest, and it wasn’t ability either. It was the setup tax. Scaffolding, boilerplate, configuration, all the plumbing you fight through before you touch the real problem. Your thinking stays sharp. The tooling keeps moving without you. Spend your evenings paying that tax, and you rarely reach the interesting part before the week begins again.
Agents tore it down. An idea that used to cost me weeks of setup and catch-up before I could even test it now takes a fraction of that time to make work.
And the real change isn’t only that the wall got lower. It’s that this kind of exploration finally fits a leadership calendar. Weeks of setup never fit between steering meetings. A few focused hours do. I don’t architect systems or write production code all day. I lead a transformation. But what used to be a hobby and remained a hobby now feeds directly into the job. I can form a technical opinion firsthand rather than relying on slides and summaries, and that shows up in the quality of every decision I make.
One rule I hold myself to, because this is where leaders go wrong. A quick prototype is an argument, not a system. Everything between a demo and production is where engineering actually lives. Forget that, and you become the leader waving a rough build at a team, asking why the real thing takes months. I use prototypes to sharpen my questions. Never to price the work.
The Excel moment
Worth remembering what spreadsheets did to financial work in the 1980s. Before them, a model meant manual calculation or a specialized programmer. After them, almost anyone could run a scenario.
The part people skip: the jobs moved in two directions at once. Roles built on doing the computation, the clerks, declined. Roles built on judgment, the accountants and analysts, grew. Cheap computation turned judgment into the profession.
Software is in the same storyline. Generating code is getting fast and cheap. That doesn’t make building software easier. It moves the valuable work up the stack, toward judgment. Good news, since judgment is what humans are actually for.
The workflow is the leverage
The interesting question in delivery right now isn’t which AI tool to buy. It’s how to work, now that execution is abundant.
Teams are getting real results by building an operating model rather than a license agreement. Specifications before generation. Human judgment at the quality gates. Playbooks that spread good practices instead of leaving it to personal experience. And measures that mean something to the business: cycle time from validated idea to production, defect escape rate, cost per delivered feature; not lines of code generated. That’s the cheapest number in the building now.
None of it comes in a box. Someone designs it, and that someone has to understand how software gets made and how organizations absorb change at the same time. Which is precisely where leadership and technology meet. Transformation isn’t handing out assistants. It’s redesigning how a team turns intent into working software.
Fundamentals got more expensive, not less
I want to be blunt here, because I keep seeing people getting it wrong.
AI doesn’t make engineering fundamentals optional. It raises its price.
An agent will produce a thousand lines per minute. It won’t reliably tell you whether those lines solve the right problem, and it certainly won’t own the trade-off between speed, quality, cost, and maintainability. Someone has to recognize good work, push back on weak output, and design workflows that make sense. That someone needs real depth. I keep investing in mine, deliberately, the same way I always have, because leading this credibly means understanding it firsthand.
It’s also why I’d never tell a student that learning to code is obsolete. Learn how systems work. Learn what good code looks like. Then learn to direct agents that build faster than you ever could alone. The order matters. You can’t orchestrate what you don’t understand, and you can’t review what you could never have built.
Where this leaves us
If you had told me a few years ago that leading transformation would be the most technically stimulating chapter of my career, I’d have been skeptical. But here we are. AI is dissolving the old boundary between the people who decide and the people who build. Leaders can touch the work again. Builders can shape the direction. Everyone ends up closer to the actual problem.
The craft moved from syntax to systems, from producing every line to orchestrating how the whole delivery machine fits together. For those of us who have seen software from both sides, this is where the two views finally meet.
The future of delivery isn’t just faster code. It’s better systems, built by people curious enough to stay close to the technology and experienced enough to know the code was never the hard part.
By Voicu Moldovan
Head of Digital Transformation @ Yonder
STAY TUNED
Subscribe to our newsletter today and get regular updates on customer cases, blog posts, best practices and events.
