I’ve been seeing Gregor Ojstersek’s work everywhere lately, and last week I finally got him on a live. He went from software engineer to CTO over about thirteen years, and he built Engineering Leadership into a newsletter with over 198,000 subscribers while he was still doing the day job.
His first book with O’Reilly is out now, it’s called The Multiplier Mindset, and what I wanted to ask him about is the idea underneath the title, because he puts a real number on something most of us keep vague. We also got into what happens to your sense of yourself when the thing you were known for becomes the thing the tool does in four seconds.
Below you’ll find the full conversation, a timestamped outline so you can jump to any part of it, and the three things I took away from talking to him.
What You’ll Walk Away With
What senior people actually get paid for now that agents handle the output, with a number attached
Why the fear about AI runs deeper than the tool, and what Gregor says separates the people adapting fastest
His answer to the question he gets most, from someone stuck at team lead and aiming for architect
🎥 Catch all future interviews, subscribe!
🎧 Prefer audio? Listen on Apple Podcasts
Outline
(00:35) – Engineer to CTO in thirteen years
(03:02) – Writing as how he learns
(04:49) – The book I never wrote
(06:10) – Six flat months, then 15,000 subscribers
(10:47) – Delayed gratification, and the promotion trap
(11:38) – Great engineer, bad engineering leader
(12:29) – The identity shift and the near burnout
(14:00) – What multiplier actually means
(18:23) – Was there fear when the agents arrived
(22:16) – Adaptability, innovation, creativity
(23:22) – Speaking business and engineering
(30:49) – Stuck at team lead, aiming for architect
My Takeaways
The promotion trap, and how long he carried both jobs.
So this is the one I recognized immediately from the business side, because it happens to everybody and not just to engineers. Somebody is really good at doing their job, they get promoted, and now they’re supervising the people who do that job, and the skills it takes to be good at the first thing and the skills it takes to be good at the second thing are completely different skills. Gregor said it cleanly:
“What makes you a great engineer doesn’t make you a great engineering leader. As soon as you grow from engineer to managing a team of engineers, your output is no longer just your own output, but it’s the outcomes of the whole team.”
What I didn’t expect was how long he white-knuckled it. He told me the first three or four months were rough, because he was still trying to be the best engineer on the team and lead the team at the same time, he was working weekends, and he got close to burning out before he finally started delegating. The results got better after that, and so did how the team felt about working with him. It’s hard to let go, because those are the exact skills that got you to where you are.
The identity shift.
I asked him whether there was a moment of fear when Codex and Claude Code showed up and started writing real production code, because I hear that fear from CEOs constantly in my coaching work, and he went somewhere more specific than fear:
“A lot of these engineers had an identity connected with a certain programming language, a certain framework. And your whole identity was to be considered a really great Python engineer. So obviously for everyone, you are doubting a bit about your abilities when you see a certain tool coming out and then all of a sudden it has amazing magical abilities.”
Then he said the people who had always pointed themselves at outcomes and business impact, rather than only at the technology, are having a far easier time right now. That’s the same thing I’ve been writing about under the AI Leadership Triad, which is adaptability, innovation, and creativity. He frames it as adapt or get left behind, and I’d say it a little softer, that you take the expertise you already have and point AI at the edges of it instead of handing the whole job over. Same point, two registers.
The multiplier math.
So “multiplier” is a word I’ve seen used about six different ways across six different books, which is why I asked him what it actually means to him. His version is arithmetic:
“When you make, let’s say, 10 people, 20% better around you, that’s a whole lot bigger impact than if you just maybe make your skills like 5% to 10% better.”
And the reason it matters now rather than five years ago is that the measurement moved underneath everybody. He told me companies used to count tasks shipped, some of them literally counted lines of code, and an agent can produce thousands of lines in seconds, so the question stopped being how much you produced and became whether the team built the right thing at all. His line for it was blunt: “You’re not paid to actually write code. You’re paid to solve problems.” I’ve been making a version of that same argument about where AI starts and where it stops in your own workflow, and this is the same move one floor up, applied to a team instead of a task list.
One more thing worth taking from him, whatever you do for a living. He told me he barely has to prepare for a talk now, because his slides come out of newsletters he already wrote, so by the time he’s on stage in London he genuinely understands the material. That’s one of the two reasons he won’t let AI write his drafts, and the other is that he wants the writing to keep sounding like him. It’s also why I spent last week reading research before writing about AI data centers instead of asking a model to summarize the topic for me. Shortcut the writing and you skip the learning.
If you’re the one who has to decide where AI fits across your whole organization, I take three diagnostic calls a month. Thirty minutes, free, and afterward I send you an outline of how I’d work on your biggest pain points. Book one →
The book.
The Multiplier Mindset is out with O’Reilly. The Kindle edition is live and the print edition lands October 31. His subtitle is “how to move from senior engineer to tech leader in the age of AI,” and the leadership half of that travels well outside engineering. I’m not an engineer, I’ve learned plenty from his newsletter, and my copy is on the way. He wrote up the launch himself here: The Multiplier Mindset is officially out.
One Question Before You Go
Somebody on the live asked the question a lot of us have: thirteen years in, stuck between development and team lead, wanting to become an architect and eventually a CTO. Gregor’s answer was credibility, built by taking a genuinely complex project and finishing it with the team, at quality and on time, enough times that the organization starts handing you the next one. I wondered afterward whether that still works when AI compresses how long a complex project takes, and I think it does, because trust is the slowest thing in any organization to build and shipping faster has never made anybody trust you faster.
So here’s mine. If your own output stopped counting tomorrow, and the only thing you were measured on was how much better the people around you got, what would you actually change on Monday?
Watch the full conversation above. And if you’re not already reading him, go subscribe to Engineering Leadership.
Thanks for reading,
Joel
About Gregor Ojstersek
Gregor Ojstersek is a fractional CTO and tech advisor based in Ljubljana, Slovenia, with thirteen years in engineering across the full climb from software engineer to senior engineer, team lead, engineering manager, head of engineering, VP of engineering and CTO. He has coached and mentored more than 200 engineers and leads, and his first book, The Multiplier Mindset, is published by O’Reilly. He writes Engineering Leadership, which now has over 198,000 subscribers, and it’s free to join.
About me
Joel Salinas is an AI Strategy Coach and entrepreneur. AI is everywhere; judgment is scarce. Joel helps founders and leaders adopt AI without outsourcing their judgment to it, and he builds the systems too. Creator of the AI Leadership Triad.
Written by a human, for humans.
