A Year in Review: 2025

What a ride 2025 has been! Just like every year, I have taken some time to pause and reflect to celebrate the wins, acknowledge the challenges, and learning from the struggles. It's one of my way of appreciating the journey and setting the stage for what's next in 2026. 

Work Highlights from 2025

• This was my second year in a leadership role at CFC, and what a journey it’s been. I call it great not because everything was easy, but because I learned so much and can truly see my own growth. Growth isn’t always about promotions, it’s also the quiet progress you feel within yourself.

• Navigating organisational changes while supporting my team wasn’t easy. But these moments taught me that some leadership lessons can only be learned in real situations, no matter how many books you read or courses you take. I focused on clarifying priorities and protecting focus during uncertain times.

• One of my biggest shifts was around conflict. I used to over‑avoid it because I worried it could damage relationships and trust (and yes, in some situations it still can). But this year, I learned to “put the fish on the table” to surface issues early and work through them rather than letting them sit and grow. If you keep a fish under the table, it will start to stink and make the whole place unliveable. On the table, you can cook it, eat it, and move on. This idea, from Sridhar Ganesh’s article shared in a leadership workshop by Lisi and Siva, changed how I see difficult conversations. Inspired by the “put the fish on the table” concept, I practised surfacing issues early and framing them around outcomes. It’s not about saying yes to keep the peace; it’s about respecting differences and engaging with care without losing my authentic style.

• This year as part of internal QE community session I had a privilege to host Debbie O'Brien and she delivered a session on MCP and Playwright. I enjoy organising and hosting these sessions and planning to do many more next year. 

Community Contributions and Conference Learnings

• Last year, I intentionally took a step back from being fully active in the community to focus on my work and settling into my new role. Reflecting back, I realized that stepping away helped me truly appreciate the value of community something I had always known, but experienced more deeply when I was away. This year, I made it a point to re-engage, and it has been incredibly motivating and inspiring to be back. 

• I attended the LeadDev London conference for the first time and what an experience! I captured my reflections in these articles from Day 1 and Day 2.

• I also participated in MoTaCon (formerly TestBash), volunteering alongside Rahul, Natalia, Ben, and Cassandra. We facilitated Lean Coffee conversations on interesting topics, including the ever-relevant topic of AI and testing. 

• At Agile Testing Days, this was my fifth time attending and speaking, and it was another special year. Last year, I set a goal to collaborate on a joint talk or workshop, and this year I achieved it. Naomi and I had been connecting through the Women in Testing community, sharing experiences and challenges that resonated with each of us. We decided to share these insights with the broader community, and after months of preparation across different time zones, we successfully delivered our talk on the topic of  'Quality Leadership Toolkit for the first 90 days'.

• One of the most memorable moments was having my daughter sitting in the front row during our talk, an unforgettable personal experience. It was an honor to have Lisa Crispin, Anne-Marie Charret, and Elizabeth Zagroba in the audience as well. Partnering with Naomi was incredibly amazing, and receiving a speaker gift from ATD a signed copy of "Quality Coach" book by Anne-Marie Charret, featuring my article made the moment even more special.

• This year, I also contributed to the STEC certificate by MoT, participated in a conversation with Rosie Sherry on Leading with Quality (a definite fan-girl moment for me!), and wrote an article on organizing bug bashes published on MoT. It's always great and feels so rewarding contributing on MoT.

• I co-hosted the first few MoT London meetups alongside Gary, creating great community vibes, welcoming amazing speakers, and facilitating discussions. It was a brilliant experience to help build community connections. Alongside co-hosting this meetup I delivered a talk on 'Quality Engineering and Observability' at this meetup.

• For the past two years, I’ve had a goal to launch my own podcast to share my learnings and experiences in quality engineering, software testing, and leadership beyond speaking and writing. This year, I finally co-launched Quality Unfiltered with Suman Bala, and we have already released six episodes. Launching the podcast taught me how much work happens behind the scenes — from planning, organizing, and editing to publishing. Collaborating with Suman has been amazing, and I’m grateful that we could make this happen together.

• Continued mentoring on Mentoring Club and this year I also had the opportunity to mentor someone for six months through the Femme Palette platform. I really enjoyed learning about my mentee’s challenges in leading without a formal title and how she was willing to support developers and QEs with quality related challenges. This experience made me reflect on my own coaching style as well. 

• Finally, I was part of the program committee for Agile Testing Days, reviewing speaker submissions, and also contributed to the program committee for TestMu conference by LambdaTest. These experiences gave me the opportunity to support speakers and contribute to the broader quality community in meaningful ways.

Personal Reflections

• This year, I struggled to keep up with my health and fitness. I love strength training and had been doing it consistently for the last two years, but 2025 tested that rhythm in ways I didn’t expect. Balancing time became much harder, especially with hybrid work and being in the office three days a week. Finding a routine that actually fits my current routine is something I’m still struggling with, and I’m carrying that question with me into 2026.

• What made this hard emotionally was knowing that the issue was not about motivation. It wasn’t that I didn’t want to train but it was that I couldn’t always make it work. In the beginning, I was hard on myself  as I have a habit of setting high expectations for myself. I kept comparing this year to the last two, asking why I couldn’t do “what used to work.” I paused and reflected, instead of forcing the same expectations, I tried to reset by telling myself that even two or three sessions a week was enough.

• Did that work? For a while, yes. For the first month, it helped. And then, slowly, I drifted again. That cycle taught me something uncomfortable but important: adjustment isn’t a one-time decision; it’s something you have to keep renegotiating as life changes. I’m still learning how to do that with more kindness and less self-judgment.

• One thing I did consistently well this year was asking for help. I’ve been on and off coaching since last year, and it continues to be incredibly valuable. In the first half of this year, I was fortunate to access coaching opportunities through work, and I had the privilege of being coached by Katrina Clokie. I had been following her journey for some time, and when she shared she's offering coaching, I grabbed that opportunity and approached her. It defintely turned out to be the right decision at exactly the right time.

• For the first time, I took a full four-week break with complete disconnection. I travelled to India and didn't log into emails, didn't check Teams, and didn't just quickly see what’s happening. Initially, I wasn't sure I should do this. I was worried about staying connected, about things piling up, about whether it was responsible. My coach and my manager were very clear you have to do this. And I did it. What surprised me most was how I felt when I came back. I was not overwhelmed or anxious or behind. I came back with energy, clarity, and a freshness with many new ideas and, more importantly, a different perspective than the one I had before I left. 

• This is a learning I’m taking forward. I no longer want to hold myself back with thoughts like I can't take that long a break or I need to stay connected. This year taught me that true disconnection is not only possible but it's very important to do this. I would recommend anyone to do this.

• I stayed consistent with learning by reading. I regularly read blogs and newsletters, with go-to voices like Alan Page, Pat Kua, Simon Sinek, and Wes Kao apart from software testing related blogs or newsletters. I listened to podcasts such as Lenny’s Podcast, Jefferson Fisher, Rethinking with Adam Grant, and the Engineering Quality Podcast by Ale, Royalee, and Veronika. Every time I read or listened to these podcasts there was so much more that I was able to relate to and learn. Many things resonated while reading or listening. (This gave me an idea of adding all the links to the resources section)

• Finally, I wrapped up the Leadership cohort with Lisi Hocke and Shiva Krishnan. That experience gave me language for things I had been feeling but couldn’t quite articulate.I’m hoping to write more about each topic from that cohort maybe as summaries, and as reflections of how they’re shaping my thinking and leadership. 

It was a good year for me. I'm very grateful for the support and guidance I recieve from people at work and community. Don't want to mention names as I fear I might miss out. 

Looking ahead, there are a few things I want to carry into next year  not as goals, but as areas of focus. I want to continue releasing episodes of Quality Unfiltered in 2026, spend more time enhancing my GitHub profile through small side projects, continue reading newsletters/blogs consistently, continue practicing to write and publish 1 blogpost a month, speak at 2 conferences in 2026 and keep collaborating with community friends. I'm especially excited to start the year with a keynote alongside Suman at PeersCon, I'm so looking forward to this one. This would be my first time attending PeersCon too.

I’m ending the year with gratitude, clarity, and energy with carrying forward what worked, learning from what didn’t, and stepping into 2026 with intention and focus.

Quality Lead – 30/60/90 Day Plan

 In our Agile Testing Days talk, Naomi Fleisher and I shared myths, realities, and the tools that helped us as new quality leaders. Here’s a companion resource with practical tools and frameworks that didn’t fit in the talk - a curated list to guide you through your first 90 days.

Mission (North Star Example)

Lead with a vision of quality that accelerates delivery, improves reliability, and empowers teams to build products that delight customers quickly and with confidence.

First 30 Days – Learn & Connect

Focus: Understand context, culture, and quality ecosystem.

Strategic Onboarding

- Review current QA and automation landscape: frameworks, pipelines, metrics, and challenges.

- Audit test coverage, environments, and release processes.

- Identify stakeholders in engineering, product, and operations.

- Understand company objectives, product priorities, and how quality impacts business success.

- Understand how success is measured in your organisation

Knowledge Building

- Learn how teams collaborate and make release decisions.

- Review product documentation, test strategies, and incident history.

- Familiarize with technical stack and tools supporting testing and CI/CD.

- Understand how AI and automation support productivity and quality.

Relationship Building

- Meet with engineering managers, product leads, and other department heads.

- Listen to pain points around quality, release confidence, and delivery.

- Establish credibility as a collaborator and problem solver.

31–60 Days – Engage & Contribute

Focus: Influence, improve, and implement early wins.

Strategic & Operational Impact

- Identify and implement quick wins (e.g., improved CI stability, automation coverage, or reporting clarity).

- Begin defining a Quality Strategy roadmap — outlining focus areas, goals, and metrics.

- Introduce test coverage awareness in sprint planning and pre-release checklists.

- Partner with DevOps to understand and improve test environment reliability.

Deepen Knowledge

Analyze defect trends, build failures, and release bottlenecks to identify systemic issues.

- Learn what matters most to the business and product teams — reliability, user trust, speed to market.

- Deepend the knowledge and understanding on the business domain and the product offerings.

- Observe how developers and QA collaborate and where enablement is most needed.

Relationships

- Strengthen partnerships with engineering leadership.

- Begin influencing sprint and release processes to better integrate quality.

- Communicate early wins and insights to stakeholders.

61–90 Days – Deliver & Scale

Focus: Establish scalable practices, metrics, and leadership impact.

Strategic Delivery

- Finalize and socialize the Quality & Automation Roadmap aligned with product goals.

- Define key quality metrics (coverage, defect trends, pass rates, etc.) and integrate into reporting dashboards.

- Develop or refine CI/CD and automation strategy for sustainable execution.

- Introduce a framework for developer participation in quality (ex. shared test ownership or quality champions).

Leadership & Culture

- Mentor and guide QA and automation engineers.

- Lead discussions on continuous improvement and retrospective learnings.

- Be recognized as a trusted leader who drives both quality outcomes and team growth.

Guiding Principles

- Lead through collaboration: Quality is everyone’s responsibility.

- Build sustainably: Focus on scalable automation and maintainable frameworks.

- Empower teams: Provide tools, processes, and visibility for quality success.

- Measure what matters: Data-driven insights guide continuous improvement.

- Champion confidence: Every release should strengthen trust internally and externally.

Key Performance Indicators (KPIs)

Focus Area	Example Metrics

Coverage & Automation	% automation coverage, test reliability in CI/CD, stability of nightly runs
Culture & Collaboration	% developers contributing to tests, cross-team quality initiatives launched
Delivery Confidence	Shorter release cycles, fewer post-release incidents, higher stakeholder satisfaction

Thank you to everyone who joined our talk and stopped by to explore this resource we shared. This post is a collaborative effort by Naomi Fleisher and me.

The spiral of overwhelm in leadership

I wanted to write this down because I’ve recently found myself in that familiar place again, the silent spiral that creeps in when I keep saying yes to everything that comes my way, lose sight of my priorities, and suddenly find myself face-to-face with the little monster - imposter syndrome.

This is my way of capturing the moment not to avoid it next time, but to remind myself to pause not to stop, but to reset. To be more self-aware, and to consciously choose how I respond when it happens again because I know it will.

Being in a leadership role often means being in the middle of many moving parts like  initiatives, priorities, actions, conversations and decision making. It can be quite fulfilling, but also extremely overwhelming. And sometimes, it’s not the workload that gets you it’s the way it spirals and creates the loop that you get stuck in.

What does that even mean?

You start with a clear focus and set of priorities. But as requests come in urgent things, people needing support, quick decisions, production incidents, you start saying yes naturally. You become reactive. One yes leads to another, and before you know it, you’re juggling too many things at once. Your WIP (work in progress) limit has long been crossed, but you’re still running without realising it.

This then leads to that all-too-familiar feeling of overwhelm. And when that settles in, it doesn’t stop there it comes in your way of your self-confidence. Suddenly, that quiet voice from that little monster in your head grows louder: “Am I making any real impact? Am I even doing a good job?”

It will create a lot of frustration because none of those doubts are true. But they still show up. And if you don’t catch the spiral early, it feeds itself. The more anxious you feel, the harder it is to think clearly or take a pause or to make the right decision.

So, what do you do when you catch yourself in this spiral?

For me, I’ve found a couple of things that help.

The first is my brag document a space where I regularly record wins, big and small. Sometimes I paste screenshots of kind messages, feedback, or things I’m proud of. When I start to spiral, I go back to it. It’s my gentle reminder: You’ve done great work. You’ve added value. You can do this again.

The second is something Katrina Clokie introduced me to which I'm excited to try: the idea of creating a rule book. I’m just getting started with this, but I love the intention behind it. Your rule book is a set of guiding principles for how you work especially when things get chaotic. So some of the rules that  I'm going to include in my personal rule book to start with are:

• Don’t work on more than 3 things at a time
• Practice saying no or not now regularly
• Pause and reset when overwhelmed
• Focus and revisit on the “why” of the task
• Remember: not everything is urgent

These aren’t the only rules to follow, or the list might be different in some time or the list might grow as I start using it. And I know that it's more of a toolkit that I can use and come back to when I'm back in the sprial stiuation. It's useful to have such rulebook especially because when are you are stuck in those situations it's hard to think so having such pre written list as a rule book helps to refer back to.

I’m still learning how to hold space for myself during the overwhelming days. But I’ve come to believe that leadership isn’t about avoiding those moments — it’s about knowing how to pause, stop and reset.

This blog is for a reminder and a reference for myself.

What about you? What’s in your toolkit when you find yourself in these situations? I’d love to hear.

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!

My First LeadDev LDX3 2025 Experience - Day 1

 I’ve been trying to attend LeadDev for the last three years. I’ve submitted CFPs every time, hoping to be selected as a speaker, but it hasn’t happened yet. I’m not giving up, though; I’ll keep trying. This year, I finally got the chance to attend in person, and it felt special. Big thanks to CFC for making this happen.

As it was my first time attending LeadDev, I wanted to be well-prepared and make the most of the experience. Checked my travel route, laid out my notebook and favourite pen (yes, I still love handwritten notes!). The organisers had an app where I could plan my schedule in advance. That really helped me as it meant I didn’t have to make last-minute decisions during the day and could just focus on being present. I found that really useful. 

I spent some time looking up the talks and the speakers ahead of time and built my schedule based on what I was most interested in. The event had three main stages—Ways of Working, Organisational Leadership, and Technical Strategy. There was also a Solutions Stage with vendor demos, community spaces, office hours, and a chance to meet authors. I didn’t manage to attend everything, but I’ll share what I experienced.

🧡 The day started with a lovely catch-up with Christine Pinto. We’ve met before, but it’s always such a joy to connect in person, especially with someone who’s part of the quality community I deeply value.

Day 1 kicked off with the session I attended first: “How to Keep Everyone Happy (on a Shoestring)?” by Neslihan Şirin Saygılı.

Neslihan shared her journey managing teams without formal management training, facing many real-world constraints: limited budget, limited headcount, limited time, limited life and the added pressure when C-level executives want Friday launches. She described these as “dominoes vs avalanches,” highlighting how small issues can cascade into bigger crises if not managed well.

Her approach starts with taking a wide view. She created a “happiness sparse matrix”. She also talked about “rotating priorities” like pizza trade-offs where each sprint prioritises a different team’s needs, with a “time currency” paid upfront(people respected the fairness)

A bigger perspective came from framing the challenge as a “constraint satisfaction problem,” one without a perfect numerical solution but solvable through heuristics and teamwork. She reminded us it’s okay to have “good enough” plans, It's better to be 70% right today than than 100% right too late. Keep the stakeholders informed all the time.

Her practical advice included focusing on root causes, not blaming individuals, and fixo ne thing fully, not 10 things badly. Keep the big picture, don't let the crisis blind you to the others. She encouraged establishing some principles like casual coffee breaks, sharing credit, listening, being accessible, and supporting personal growth through books and side projects to keep the “emotional bank account” topped up.

Quote from Regina Phalange:

“Our experiences are similar in pattern but unique in detail. I believe we need tailored solutions.”

Managing tech crisis on a shoestring isn’t about being a hero, but being a human.

What resonated most with me was how much this isn’t about having all the answers or being perfect. It’s about understanding the real, messy challenges teams face every day and finding practical, human ways to navigate them and you don't have to do it alone, find help!

The next session I attended was “Better Software, Faster” by Laura Tacho.

Laura opened strong with a clear message: “We need to think about using AI on an organisational level to see the organisational benefits.” She quickly made it clear that AI isn’t about producing more lines of code—because we already know lines of code aren’t a meaningful measure. Instead, it’s about improving the developer experience.

She described how many leaders right now are sitting in a “disappointment gap”—expecting AI to replace engineers or bring instant transformation, but the reality doesn’t match the hype. That contrast was summed up with humour: “The milk is actually shaving cream,” which got a good laugh in the room.

This hype around AI is the biggest barrier for adoption. Engineers might even start seeing it as competition, which only builds more resistance. But as Laura pointed out: data beats hype—every time. Leaders need to set realistic expectations about what AI can and can’t do, and be able to explain those clearly to boards, execs, and development teams alike. While AI can be transformative, that’s not what most companies are seeing in their day-to-day work—yet.

Quote from Brian Houck (SPACE framework co-author):
“The hype around AI is in many ways the biggest barrier for adoption.”

She shared stats showing that advanced organisations in the top quartile have about 60% adoption of AI tools on a daily or weekly basis—but there’s still a huge gap between them and the rest. Laura stressed that if you invest the effort and resources into AI adoption, usage will go up. The average reported time savings is already about 3 hours and 45 minutes per developer per week in the first half of 2025.

Still, she was honest about how hard it is to lead in this space right now. The landscape is evolving rapidly, and many leaders feel like they’re constantly guessing. But we’re not alone in that. Laura wants to equip us to show up with clarity and confidence, especially when it comes to separating hype from what’s actually happening.

She reminded us that we have a hard job to do as organisational leaders. Our role and responsibility is to educate around the hype. It’s easy to get distracted by shiny new tools, but when leadership asks “what are we doing with AI?” — we need to have a clear, honest answer. And when we ask “what does it actually take to build better software?” — the answer isn’t just writing code faster. It’s making sure the code is reliable, maintainable, and valuable.

Laura outlined two things we need to do this well:

1. A common definition of engineering performance
2. Clarity on how AI is influencing that performance

We also need AI-specific measures, not just the usual engineering metrics.

Despite all the newness, she reminded us that the fundamentals of software delivery still hold—collaboration, fast time to market, quality, reliability, and security. AI might help accelerate delivery, but without care, it can also accelerate the wrong things. We need to protect our organisations from delayed damage, like producing more poor-quality code, faster.

One big takeaway for me was around aligning the organisation on a shared definition of excellence. Laura introduced DX Core 4, a framework developed by people like Abi Noda and Dr. Nicole Forsgren (from the DORA team), which has already been used by hundreds of companies. It’s been battle-tested, and it shows that Developer Experience (DX) is one of the biggest levers we have to improve engineering performance.

She shared that around 20% of developer time is lost to friction from inefficient tools and poor internal systems. Since time is such a scarce commodity, mapping DX improvements back to saved time and recovered salary makes a solid business case for investing in better developer experience. Biggest wins for utilisation is going from non-using to using AI. Top metric to track in terms of Impact = time savings per week.  AI Measurement Framework = Utilization + Impact + Cost.

As Azra from Block put it:
“These improvements helped us move faster without sacrificing quality or focus.”

Laura wrapped up by debuting an AI Measurement Framework. This session was a real eye-opener. It helped me see how, as leaders, we need to take ownership not just of tools and tech, but of the narrative around them.