Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Dev Report mobile

"AI Codes. It Doesn't Program.": Leadership Lessons from Mike Fisher

14 July 2026, by Nicolette

Before Mike Fisher ever shipped a line of production code, he was training as a US Army aviation officer at West Point.

Fast forward thirty years, three CTO and CEO gigs, and more than thirty ultramarathons, and he’s led engineering teams through PayPal’s rocket-ship growth, Etsy’s cloud migration, and now MyFitnessPal as AI shakes up the industry.

We sat down with Mike at our recent Leadership Lessons AMA to dig into what the military really taught him about leading people, the failures that shaped his path, and why coding and programming just aren’t the same thing anymore.

🎥 Watch the full conversation on demand.

What shaped your transition from engineer to leader?

I never planned to go into management. I loved programming since I was a kid, and after seven years in the military I left wanting to be a software engineer, nothing more. A few years in, one of my bosses told me I had so much management experience already, from leading in the military, that I should go into management. I still call myself a reluctant manager, even almost 30 years later.

But one manager, Kathy, was the one who really changed how I saw myself. I thought of myself as an engineer who happened to have led in the military, and she helped me see that all of that leadership experience could be applied directly. That reframing changed the whole trajectory of my career.

What was the hardest mindset shift moving from engineer to manager?

As an engineer, I was expected to come with answers. People asked technical questions, how does this work, what's the best design, and I was the one who was supposed to know. When I became a manager, I wanted to keep being the one with the answers. The hardest shift was realising that isn't the job. You've got a team of people who are probably smarter and more experienced than you in their areas, and your job is to bring the best answers out of them, not supply your own.

How do you keep your technical edge while your influence grows?

That was a real fear of mine. I've kept my hands in by doing side projects throughout my career, nights, weekends, whatever I could find. I remember programming on the train after work, because that was the only 45 minutes I had. Lately, the idea of a player coach has come back, someone who manages the team and still does some of the hands-on work. I love that model, though I'll admit management is genuinely its own discipline. Taking a brilliant engineer and assuming they'll be a brilliant manager is one of the most common mistakes companies make.

Can you share a project that didn't go to plan, and what you learned?

Two come to mind. At PayPal, we were splitting a monolithic database into multiple databases, and the cutover went badly. We were down for several days because we hadn't built the ability to roll back. It taught me two things: how to help a team recover and stay motivated after a real failure, and that leaders need backup plans. There's this idea of burning the boats so you can't retreat, and it sounds romantic, but a good leader still keeps a boat hidden round the cove.

The other was Etsy's cloud migration. Our first attempt failed on a Sunday night. I called my CEO, Josh, expecting a hard conversation. He didn't flinch. He just asked, "When are you trying again?" We cut over successfully that Wednesday. That response taught me more about leadership than almost anything else, get back up quickly, learn from it, and go again.

How do you deal with imposter syndrome?

I still have it. I still wonder, day to day, if I'm doing the best I can. But I've come to think it's healthy, a bit of useful paranoia that keeps me pushing to do better. Almost everyone I know feels this, even people who are clearly right for the job. You don't get rid of it, you just learn to use it.

How is AI changing the way engineering teams are structured and led?

We used to talk about Jeff Bezos's two-pizza rule, a team small enough to feed with two pizzas. Now people are calling it a one-pizza rule. Product and design used to keep six or eight engineers busy. Now it's often one or two, because AI lets people ship so much faster. That's also bringing back the player coach model, because smaller teams are more exposed if someone's out.

The bigger shift is that we used to manage people. Now I think every engineer is going to become a manager of agents. You're not going to career coach an agent, but you are going to need to think about how to break work into chunks for it to do. That is management, and it needs to be taught much earlier in people's careers, not just to managers.

Does AI make the outputs-versus-outcomes trap worse, or help teams get out of it?

It accelerates it. Teams ship something and celebrate because it's out the door, that's an output. What matters is the outcome, whether it actually solves a real problem for the customer and the business. AI means you can ship a lot more, a lot faster, but that can just mean shipping more junk faster if you're not measuring the right thing.

At MyFitnessPal, one of our clearest outcome metrics is simply how often people log their food, because that tells us they're engaged and building a healthier habit. Build something that genuinely helps people, and the financials follow.

What's the most common mistake you see leaders making as they bring AI into engineering?

Underestimating how big this transformation is. I think it's bigger than the cloud, bigger than app stores, maybe bigger than the internet. Part of that is because, for the first time, coding and programming aren't the same thing. AI can code. It doesn't program. Programming is understanding complexity, thinking through systems and architecture, designing how something actually works. That split is harder on engineers than any past migration, because for a lot of us, coding was tied to our identity.

What advice would you give someone taking their first leadership role in a fast-moving AI environment?

Leadership matters in every context, whether you're leading today or in ten years, in a tech company or a non-profit. That means caring about people. Don't let the pace of the technology get in the way of actually leading and caring about the people on your team. That's still the most important thing.

If you want to hear more from Mike Fisher on leadership, failure, and what AI means for engineering teams, watch the full Leadership Lessons AMA video on demand here.

Recent posts

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.