At a recent Leadership Lessons AMA, we sat down with John Hartley, Head of Engineering for Conversational AI at Trellis, former hot sauce company owner, and golden chilli award winner, to talk about what engineering leadership actually looks like once you're in it.
John has spent 16 years in software and about a decade in management. He's scaled teams at startups, writes about leadership at Hartley's Handbook, and has a refreshingly honest take on imposter syndrome, performance management, and where AI does (and doesn't) belong in the decision-making loop.
Below are the highlights, cleaned up but in John's words.
👉 Watch the full session on demand
You didn't start out planning to be a leader. What changed?
I've always been drawn to the people side of work. I started in broadcasting, nearly went into teaching. I wanted to teach math. Then actuarial sciences seemed like the smart move, until I realised it was just sitting in a room looking at numbers all day, and I really missed the community aspect.
When I moved into front-end engineering, I was freelancing, working alone most of the time. It was very, very lonely. As I grew into bigger companies, I realised the interpersonal stuff: the mentoring, helping people figure out what they're best at. That's where I had the most fun. Some people just want to build cool things. That's great. But for me, it was always about building people and building careers.
The defining moment was at an agency called Dynamic. Our front-end lead left. I went to the director and said, "I've never done this before, but I'd be interested in trying it out. Would you give me a shot?" He said yes. And here I am.
The lesson: raise your hand. Worst thing they can say is no.
What was the hardest mindset shift moving from engineer to manager?
Engineering has a lot of ways to solve a problem, but there tends to be a finite set based on best practices. Management is a whole different monster. Every day is a brand-new set of unique problems, and you can't just code your way out of them.
If there's interpersonal conflict between two people on the team, you can't just say "I won't have them work together anymore." That's not an option. You have to understand both sides. That was a big shift.
Radical Candor helped a lot. So did Holding the Calm, a good one for conflict.
The other hard part was the peer group change. I was suddenly managing people I'd been joking around with the day before. I'm also just not naturally serious. I had to learn that just because we do serious work doesn't mean we need to be serious all the time. But you do need to know how to give direct feedback.
One line from the show 911 stuck with me: "The last day to win a popularity contest is the day before you get promoted." When I first became a manager, I tried to make everyone happy. That is one of the worst things you can do. You have to get comfortable making decisions that are best for the team, even when they ruffle feathers.
Read more: 20 Books That Should Be on Every Tech Leader’s TBR List
What was your most defining leadership moment?
The first time I had to fire someone.
Performance management is something a lot of people shy away from because it's genuinely uncomfortable. I withheld feedback. I thought, "they're a nice person, they'll figure it out." Everyone around me could see it wasn't working, and I kept making excuses. By the time we got to a PIP, it was a complete blindside for that person.
That didn't feel good.
Since then, my mindset for any performance issue is: I never want it to be a surprise. If we get to the point of termination, the person should already understand. Not to make them feel bad. It's more: I've done everything I can to support you, and it's just not working out.
Radical Candor talks about this: care personally and challenge directly. You can care about people all day, but if you're not being honest with them, are you really caring about them? They want to do better. You want them to do better. Withholding feedback isn't kind. It just delays the damage.
You have to embrace failure as a natural part of growth.
What leadership decisions should never be outsourced to AI?
Personnel decisions. Full stop.
Hiring, performance management, promotions. That's where humans need to make the call. AI is good at giving you objective information at around 80% accuracy. But ownership is the critical part. You have to make the final determination yourself.
I push my engineers on this too. If something goes wrong, you can't say "sorry, the incident was caused by Claude." That's your code. You own it. However you got to the decision, AI-assisted or not, the decision is yours to stand behind.
For hiring specifically: I use AI note-taking in interviews so I can be fully present in the conversation, and go back through transcripts afterward. It helps with recency bias. The last thing someone said in the interview shouldn't be the only thing you remember. But the actual evaluation? That stays human.
Community pulse check
Before this session we asked the dev community where AI should stay out of leadership decisions. The verdict? Team feedback and 1:1s topped the list (39%), followed by performance reviews (29%).
How are you personally using AI in your day-to-day work?
The biggest workflow change has been a daily digest.
I use Obsidian for notes. It's just a folder of markdown files. I have a Claude script that runs at 6pm every day. It looks back through all my meetings, the transcripts, and the notes I took, and gives me an overview of the day: any commonalities, top action items for tomorrow, industry trends related to what I was actually discussing. If we talked about voice AI all day, it'll pull relevant trends in that space.
I also have a weekly version that groups everything together and suggests moonshot ideas, things we might experiment with based on what's been top of mind.
It's not magic. But it makes the end of the day a lot easier to consume.
What's your advice for leaders who want to integrate AI into their teams right now?
Give people time to actually play with it.
The mistake I see most often is leaders saying "go use AI" without giving any structure for how to explore it. People don't know which tools they have access to, which models do what, or where to even start. It's noise without direction.
What works better: bring a small working group together and figure out as a team how you want to approach it. Give people dedicated time: a one-week hackathon where the first ticket they pick up has to be AI-assisted. See what worked, what didn't. Share the learnings.
Training is also underestimated. You can burn through a lot of tokens fast if you don't know what you're doing. There's real skill in knowing how to break work down so AI can actually help. It comes back to requirements. A vague prompt gets you a vague result.
Start with space to experiment. Build in show-and-tell moments. Don't expect instant results before you've given people room to actually learn.
How has AI changed what you expect from the people you manage?
Mostly: stop saying "we can't do that."
I generally don't tolerate that framing anyway. Don't tell me we can't. Tell me here are the constraints, and here's what we'd need to make it happen.
But especially now, I want people to at least try before they decide something is impossible. Work with Claude, see if there's a path. Maybe there isn't. Maybe it'd take six months and that's a no. But start there. Don't let the first answer be "can't."
John Hartley is Head of Engineering for Conversational AI at Trellis and authors Hartley's Handbook. You can reach him on LinkedIn.
Missed the live session? Watch the recording on demand