My First LeadDev LDX3 2025 Experience - Day 2

I finally had some time to reflect and capture my Day 2 highlights. The energy on Day 2 was just as energetic as it was for Day 1, but I decided to take things at a slightly slower pace intentionally.

I kept some time aside from my day to explore the sponsor booths and speak with the vendors. Many of the names were completely new to me, so I was curious to learn about them. Slowing down helped me absorb more. 

Leader or Engineer? Navigating Our Technical Identity Crisis by Marcus Gardiner

The first talk I attended on Day 2 was by Marcus Gardiner Technical Capabitity Head at Softwire, and wow this one really resonated with me. The theme of navigating identity between leadership and technical expertise is something I’ve constantly reflected on in my own journey as a quality engineering leader.

Marcus opened the talk with a series of thought-provoking questions that many of us have asked ourselves at some point:

• Am I a leader or am I an engineer? Am I technical enough? Am I of value?
• The best version of you as a leader means not meeting your full potential as an engineer. And the best version of you as an engineer means not meeting your full potential as a leader.

This really stuck with me. He explained that we often try to be everything at once, be it a technical expert, architect, team lead, business partner, and it does sound good, but it’s a one-way road to imposter syndrome and burnout. He spoke about the danger of drifting instead of deciding. When we don’t actively choose our path, we try to hold on to every identity we’ve ever had. But in doing so, we spread ourselves thin and lose clarity on who we want to become.

Marcus shared four different ways to be technical leaders:

• engineer
• architect
• team lead
• business partner

 

He mentioned that many might want to be all of these at once. It does sound great, but it's a one-way trip to imposter syndrome and burnout if you try to do everything.

One metaphor that Marcus shared was about how farmers in India dealt with monkeys raiding their crops. They’d drill holes in coconuts and place a banana inside. The monkey would reach in, grab the banana, but wouldn’t be able to pull its hand out while holding it. All it had to do was let go to escape—but it didn’t. It held on with a death grip and trapped itself.

“I was holding on to the comfort of my engineering title and knowledge, rather than embracing my new role.”

We all have deep-running insecurity about being “technical enough”. Many of us hold onto old versions of ourselves, whether that’s being ‘technical enough’ or feeling like we need to prove our value when in reality, letting go might be the key to growing into the roles we’re in now.

Marcus reminded us that our job title is just a temporary badge you’re wearing. It’s not who we are. It’s not the position we need to defend. And it's not permanent. It's not YOU.

What idea of your own self are you holding on to a little too tightly? The industry is still going to need expert leaders and expert engineers. Be part of or form a peer coaching group. Don’t hold onto your image of yourself with a death grip. 

View each new role as an experiment that you choose for your own values & reasons. It’s your story. 

And left us with this beautiful closing thought:

“Choose lightly. And then choose again.”

A truly powerful talk that gave me the space to pause and rethink how I see myself and the choices I make.

The million dollar bug: Quality leadership lessons from costly failures by Christine Pinto

This talk was special for many reasons, it was one of the very few testing related sessions at LeadDev, and it was delivered by Christine Pinto, someone I know and respect from the testing community. It felt refreshing to hear a topic that I'm passionate about being discussed on a leadership stage. 

Christine framed the talk as a four‑chapter journey:

• Mythology: How faulty narratives undermine quality strategy
• Mathematics: What quality actually costs and how those costs compound
• Mechanisms: Practical frameworks that turn quality into competitive advantage
• Metamorphosis: Why quality leadership isn’t a checklist, it’s a mindset

She began by challenging common myths that undermines quality efforts especially the belief that teams must choose between speed and quality. Using real-world examples, she showed how this mindset leads to reactive firefighting, where engineers are caught in patching loops instead of innovating. Rather than slowing teams down, quality should be the foundation that enables speed.

Next came the cost of quality and how invisible risks compound over time, draining momentum, trust, and innovation. Christine described how poor quality decisions often lead to a downward spiral, and once that begins, recovery becomes harder. It reinforced the idea that quality failures never stay small but from the chain reaction which can build up to the death spiral. No body wants to bet on a system that is constantly breaking . Now how do you break this loop so she went onto the chapter three

The third chapter focused on practical mechanisms to make quality visible and actionable. She explained how binary thinking like deciding if something is "ready or not" doesn’t work in complex systems. Instead, she introduced approaches like quality confidence matrices and risk-aware discussions that help teams evaluate impact and uncertainty early. Christine emphased on early conversations and reframing technical issues in ways that resonate with business leaders.

Christine emphasised that there is no need of a new process , there is a need to have better conversations earlier. and as quality leaders your role is not to answer all of these but to create the culture where peopple feel safe to ask them. It is about making risk visible because quality discussions die in translation.She gave brilliant examples , if you say oauth callback intermittenly fails for new users, it sounds like a testing ticket for a jira sprint but not for a leadership meeting. But if you say instead we are seeing a customer churn risk in onboarding , now your're on the boardromm , yourre talking about conversion growth. . Its not about exxagerating the situation but making it more relevant. Translate like a strrategist from tech framing to strategic framing. 

She also mentioned that while most companies only realise they are “on fire” after a post-mortem, the best teams run pre-mortems they surface potential risks before they become costly failures.

In the final chapter, Christine shared real transformation stories from companies like Spotify and Amazon. Each took a different path to scale quality whether through automation or team autonomy but the common thread was that they made quality a growth engine, not a bottleneck. These examples highlighted that there’s no single blueprint or playbook, but what matters most is embedding ownership and making quality a shared responsibility across the organisation.

This talk was a strong reminder that quality isn’t just a practice—it’s a mindset and a leadership responsibility. Christine ended the talk with closing statement of quality is speed and quality is your competitive advantage. It was inspiring to see this message land so clearly at a conference like LeadDev.

Theory to action: Architecting and implementing your team operating system by Meg Adams

Another brilliant talk from Day 2. Meg used a really helpful analogy of a team operating system something I hadn’t thought about in this way before.

She started with a problem that I’ve seen too: people often feel disconnected from what’s happening outside their own teams. Especially in cross-functional projects, it’s common to hear things like, “I don’t know what that team is working on.”

Meg had asked people how they might solve this visibility problem. They shared some great ideas:

• More demos
• Celebration forums
• Personal relationships
• Team rotations
• Cross-team mentorship
• Better alignment meetings

All of these ideas worked but not just because they were good on their own. They worked because they fit that team’s specific way of working, their structure, their people, and their culture. What worked for one team wouldn’t automatically work for another as it depends on context. That’s when Meg introduced the idea of the team operating system (OS).

She defined a system as a group of connected parts working toward a shared goal. A team OS is made up of people, structure, setting, and norms all working together, whether we design it or not. If we don’t design our OS, then one just forms on its own by default.

Meg gave us a great framework to document our current OS. She shared a template too (bit.ly/os-template), so we could look at our own teams and reflect honestly.

She walked us through each of the four parts of a team OS:

1. People

Every person brings their own background - communication style, habits, values, past experiences, even power dynamics. All of this shapes the team in different ways.

2. Structure

This is about how we spend our time and how we organise it. Are our calendars showing what we truly value? If we say we value learning or focus time but there’s no time blocked for it then we may not really value it in practice. Structure includes meetings, events, and business rhythms (like planning or reviews).

3. Setting

This includes our environment:

• Physical (remote or office?)
• Digital (Slack, Jira, Zoom, etc.)
• Time zones and working hours
• The energy or tone in the space

4. Norms

These are the rules we follow, both spoken and unspoken.
Some are written in onboarding docs. Others are learned just by watching how the team behaves. Meg encouraged us to observe without assumptions. Do people speak up when there’s a blocker? Is conflict welcomed or avoided? Who talks in meetings? Is it a safe space?

By writing these things down—not what we wish was happening, but what’s actually happening—we get a real snapshot of the team’s current OS. Not a big vision statement, just a clear picture of reality.

Meg then talked about how we can improve our team OS in three steps:

• Act on small wins
• Debug the real issues
• Keep iterating and improving

She closed the talk with a powerful message: every team already has an operating system. The real question is did we design it, or did it just happen? To be true architects of our team culture, we need to start by documenting what exists today, and build from there.

This talk gave me so many practical ideas. More than that, it helped me see team dynamics as something we can shape intentionally not just react to.

That's a wrap on my reflections from Day 2 of LeadDev LDX3 a day filled with amazing talks, inspiring ideas, meaning conversaitons. Until next time, LeadDev!