At a recent Leadership Lessons, we sat down with Megan Tipps, engineering leader at Parent Sense and author of the blog Leading with Empathy. Drawing on nearly 20 years in software and five years leading multidisciplinary teams, Megan shared the leadership lessons that have shaped the way she leads.
Outside of work, you'll find her gardening, cooking, or baking. At work, she's known for something else entirely: exceptional one-on-ones and an unwavering commitment to her team's psychological safety.
That combination of empathy and candour shaped the entire conversation. If you missed the live session, you can catch it on demand. In the meantime, here are the leadership lessons that stood out most.
Was there a specific moment you realised leadership was something you wanted to pursue, or did it happen more gradually?
"There was definitely this one moment that planted the little seed. I was working on a project where I realised I wasn't going to hit the deadline on my own, so I asked management to get me another developer to help out. I was hoping for someone fairly experienced, but instead they gave me a junior. My first reaction was probably what a lot of developers would have had: this isn't really going to help my deadline. But now I had to deliver the project and mentor someone at the same time, and somehow we got it over the line.
Something unexpected happened then. I realised I genuinely enjoyed helping someone learn, watching things click for them, and seeing their confidence grow. At the same time, it made me think about the decisions leaders make and the impact those decisions have on the people doing the work. That was the moment that planted the seed. The move into leadership happened more gradually after that, but it was the first time I could see myself wanting a wider impact than just the code I was personally writing."
What mindset shift was hardest for you moving from engineering into a leadership role?
"The hardest mindset shift wasn't actually moving away from coding. It was letting go of what I thought a leader was supposed to look like. Early in my career, I had this picture in my head where great leaders always had the answers, always spoke first in meetings, and naturally took charge. That's never really been me. I'm much happier listening first, asking questions, and taking time to think before I speak.
For quite a while, I worried that meant I just wasn't leadership material. Once I accepted that there's not just one way of leading, leadership became a lot more natural for me. I stopped trying to be the loudest voice in the room and started focusing on creating space for everyone else's voices instead."
How did you maintain your technical edge while your responsibilities expanded into leadership?
"I never stepped into leadership because I stopped enjoying engineering. I still love writing code, exploring new technologies, and experimenting with AI tools. That curiosity has never gone away. What's changed is where I get my satisfaction from. Earlier in my career, it came from solving the problem myself. Now I get just as much enjoyment from watching someone else on the team solve a difficult problem, knowing I helped create the environment where they could do that.
Staying technical was never about proving I can still code. It's about staying close enough to the work that I understand what the team is dealing with, so I can have meaningful technical conversations and make better decisions as a leader."
Can you share a moment in your leadership journey where something didn't go as planned, and what it taught you?
"My biggest mistake was around hiring. Early in my leadership journey, I hired someone who turned out not to be the right fit. They weren't doing the work they were supposed to be doing, and when things started going wrong, they blamed everyone around them, including me. I took it incredibly personally. I remember thinking maybe I'm just not cut out for this.
I was lucky to have a really good HR partner who reminded me that every leader makes hiring mistakes, and the important part isn't pretending it hadn't happened, it's learning from it. I reflected on what I'd missed in the interview process and added new questions to catch it next time. One bad hiring decision didn't define me as a leader. It just made me a better one."
What milestone or decision taught you the most as a leader, and why?
"I don't think it was a promotion or a job title. It was the point where I became responsible for the health of an engineering team, rather than just delivering software. Early in my career, I naturally focused on the work itself: building features, solving technical problems, delivering projects. But as my role grew, I realised that even really talented engineers struggle if the environment around them is working against them. If priorities keep changing, if expectations aren't clear, if every release feels stressful, eventually even your strongest people become frustrated.
That completely changed how I thought about leadership. I still care deeply about helping individuals grow, but I spend just as much time thinking about the systems around the team: better planning, clearer communication, calmer releases. Sometimes the best way to help someone isn't coaching them individually, it's fixing the environment."
Some people hear empathy and think it means lowering standards or avoiding difficult conversations. How do you think about empathy and accountability working together?
"I actually think empathy has a branding problem, because for me empathy is really about understanding context. Working on software for parents reminds you very quickly that everyone carries invisible context. You never really know what someone has dealt with before they log into work that morning.
That doesn't mean expectations disappear. If anything, it helps me have a better conversation. If someone misses a deadline, I want to understand why before I react, because maybe they're struggling with something outside of work, or maybe we've changed priorities three times. Empathy doesn't remove the accountability. It just helps you respond to the actual problem instead of the one we've assumed exists."
Empathy doesn't remove the accountability. It just helps you respond to the actual problem instead of the one we've assumed exists.
As a leader, how has AI changed the way you think about building environments where people feel heard, trusted and empowered?
"AI has changed the kinds of conversations we need to have as leaders. Before AI, a lot of my focus was on creating an environment where people felt comfortable asking questions or admitting when they didn't know something. That hasn't changed. But now I also want people to feel comfortable questioning the AI.
One thing I've learned quickly is that AI can be incredibly helpful, but it's also confidently wrong sometimes. I never want someone on the team to feel like they have to accept an answer just because AI generated it. Building trust around AI isn't about everyone using it the same way. It's about creating an environment where people feel safe to experiment, share what they've learned, and just as importantly, share what didn't work."
If you could change one thing about how most leaders are approaching AI adoption right now, what would it be?
"I'd like to see fewer leaders asking how do we get everyone using AI, and more leaders asking what problem are we actually trying to solve. Sometimes it feels like AI adoption has become the goal, and for me, it isn't. The goal is building better products, helping teams work more efficiently, and creating more space for the work that really needs human judgment. If AI helps with that, fantastic. If it doesn't, we should be comfortable saying that too.
I'd much rather have a team thoughtfully using AI where it adds value, than one using it everywhere because it feels like they should. Our job as leaders isn't to chase every new tool. It's to help our team understand which tools genuinely make them better at what they do."
I'd like to see fewer leaders asking how do we get everyone using AI, and more leaders asking what problem are we actually trying to solve.
When tools are faster, there's an implicit expectation that humans should be faster too. How do you help teams set healthy boundaries around AI use?
"The AI burnout is a real thing. We're not just writing code anymore, we need to be the AI's PM, PO and QA all at once, just to make sure it does what it needs to do. Because we can go faster, some people enjoy working on three different projects with their AI at the same time, but that context switching burns you out. I can't do that. My ADHD brain doesn't allow it, it seizes up at some point.
This is where you need to have those conversations with your team members, and you need to have built the trust to have them. Ask them directly: are you burning out, do you need a break? Set boundaries for yourself too. If people push back and say it's unrealistic, ask them why they think that."
How would you recruit for technical competence effectively in this age of AI?
"We can't just go off the same old approach anymore, like asking someone to go write the code and reviewing it, because AI can write it for them. What you need to add is another layer of talking with the person. They need to sit there and tell you why they implemented something a certain way. You need to really drill into that, to understand if they have the knowledge you want for the level you're hiring for."
Want more of Megan's thinking on leading engineering teams? Watch the full session on demand, and keep an eye on her blog, Leading with Empathy, for more.