We recently caught up with Stephan Swart, a fractional CTO and AI adoption coach who’s spent over a decade leading engineering teams. We wanted to talk about what actually holds engineering leadership together once AI enters the picture.
Stephan’s all about helping teams turn AI from a shiny tool into something they can actually use, with the right workflows and skills to back it up. He built the birding app Firefinch, runs a CTO coaching circle, and says he’s learned just as much from his failed startups as from the companies he coaches now.
Below are the highlights, cleaned up but in Stephan's words.
→ Watch the full session on demand
You didn't set out to become a leader. What actually pulled you in that direction?
I don't see myself as a natural leader in the sense that I go looking for leadership opportunities. If there's a good leader already in place, I'll easily stand back and follow.
But in tech leadership specifically, there are a lot of gaps. Early in my career, I gravitated towards those gaps. Every role, I'd start technical and quickly move into something less technical. There wasn't one specific moment. It was more a repeated realisation: this is a gap I could fill.
There's a saying I like: opportunity lurks where responsibility has been abdicated. That's basically been my path into leadership.
What was the hardest mindset shift moving from engineering into leadership?
We all see the world not as it is, but as we are. I used to assume everyone wanted what I wanted. I love taking initiative and pushing boundaries, so I managed people the same way. Some people need that kind of freedom. Others need far more clarity and far more attention than I naturally gave.
I had to learn how to create clarity and set clear boundaries for people, rather than assuming my own way of working would translate.
If you could give every engineering manager one framework for leading their team better, what would it be?
BART. It comes from the psychoanalysis world, not a book, an article. It stands for Boundaries, Authority, Role, Task.
The idea is that these four components are what make up the container within which people can manage themselves. If you're clear on the boundaries, the authority, how decision-making works, the roles, and the task itself, you've created real clarity. Sometimes we assume we're clear on the task and we're not.
If you've studied psychological safety, you'll see how directly this maps onto it. When you create these boundaries and reinforce them seriously, people feel safe enough to actually play out their roles.
You can't manage people. You can only create the container people manage themselves inside.
We're seeing a lot of AI tools rolled out across engineering teams right now. What's the most common mistake leaders make the moment after they've deployed the tools?
The most common mistake is not understanding the tools and not understanding that this isn't just another productivity tool. It's an adoption problem, and it's change management. That has to run all the way through your organisational design and your workflows. Roles are being redefined. You have to actually get into these conversations with your teams and understand their concerns, and to do that properly, you need to understand what the tools are and how they work.
I've seen it play out two ways. One is throwing the tool over the wall: here's the tool, go be productive, then standing back. The other is head in the sand: I don't care what tools you use, just get the job done. Both lead to sporadic adoption, and eventually prohibition dressed up as a security concern.
If there's uneven adoption with a handful of power users and everyone else lagging, it almost always means there's no structure or strategy coming from the top. That's genuinely dangerous. We've seen production databases go down because the underlying discipline wasn't there to begin with.
How do you actually tell, in an interview, whether someone uses AI well rather than just leaning on it?
Watch how they prompt. It becomes obvious fairly quickly. There's the person who's essentially backseat driving, letting the model do whatever it's doing. And there's the person who understands the tool and is making deliberate use of it: they can tell you about a specific skill they built to solve a specific problem, and why managing their own context mattered in a particular case.
If you set up part of the interview to actually watch someone use the tool, and you know what to look for, you'll catch the difference quickly. And you can only know what to look for if you've gone through some training yourself. You have to educate yourself before you can properly evaluate anyone else.
What would you say to a senior engineer who's fulfilled by writing beautiful code and is anxious about spending the rest of their career reviewing markdown instead?
That's one of the biggest fears in software engineering right now, and it's a legitimate one.
What I've experienced is that I'm still building things. I'm just building the system that builds the system, so what I'm building has shifted, not disappeared. In the beginning you have to review everything, because you can't trust the system yet. As it matures, you trust it more, and you stop spending all your time reviewing every line it generates.
If there's someone worth listening to on this, it's DHH. He built his entire career on writing beautiful code, built Ruby on Rails, and even shifted towards this way of working. His take: this AI thing is genuinely worth it, but you have to actually experience it to see why.
If you're that senior engineer, the fear is real. In the wrong organisation, you might end up as exactly the person you're afraid of becoming. But if you put the fear aside long enough to properly engage, there's something new to explore that you wouldn't get otherwise.
Curious to dig in further or hear more of Stephan Swart’s stories? Check out the full Leadership Lessons AMA–available on demand.