Louisa Denly

product manager, degree apprentice graduate, open source advocate, bookworm, flautist, heavy-metal fan | views are my own

  • Organising the Agenda

    What happens when you get a group of people together to organise a conference? Well, it turns out it’s mostly a mix of Diet Coke, pastries, and long table with keyboard tapping being heard faintly in the background.

    The GS UK conference committee got together this week to organise the conference for their flagship event in November 2026. I’ve been part of the committee since 2023, and it’s been a blast. The conference is unlike anything else – a group of highly diverse individuals that are passionate about all things IT – observability, security like ACF2 and RACF, operating systems like TPF and z/OS, databases from DB2 to Adabas, and AI covering MCP, agents, and LLMs. The platform is growing rapidly, and the conference is having to adapt at a rapid rate to accomodate.

    When I joined, the process for submitting papers was to email each individual track with your submissions, meaning it felt like an underground network of submissions with a small subset of people submitting that knew. After a couple of years of testing the waters, we have finally moved to Sessionize, a way to view all the conference submissions in the same place – the same is used for conferences such as the Linux Foundation. Bringing change to an organisation that has been working in a particular way for many years has been difficult – we have been through education sessions, video walkthroughs, and emails to make sure that we were all rowing in the right direction.

    There was something oddly satisfying about seeing all the submissions in one place. For years, conference planning had felt a little bit like everyone disappearing into separate rooms, emerging months later with a finished agenda and hoping it all fitted together. Suddenly we could see everything. The good ideas, the accidental duplication, the emerging themes, and occasionally two track chairs realising they had both accepted almost exactly the same session. It turns out visibility is a wonderful thing, even if it occasionally means discovering you’ve all had the same idea at the same time.

    This year, we decided to get together as a group and go through the agenda together – going through each stream and discussing the agenda as a whole, looking at the clashes, and working as a whole event to ensure that we are doing the same thing together. What I found particularly interesting, was that as a group, we have slowly exposed how each stream thinks about how their stream is being put together. Looking around the room, it struck me that everyone had arrived with the best intentions for their own area. Nobody was deliberately creating clashes between sessions or gaps in the agenda. Yet when you put twenty passionate people together, each optimising for their own audience, somebody has to step back and optimise for the whole conference.

    A stream chair cares about the depth and technical credibility, but the attendee cares about a coherent experience, enough variety, and breadth covering beginners through to experts.

    There is a hidden depth to conference organisation. On the surface it’s about ensuring that the lunch is served, keynote sessions are delivered, the slide content, there are no hiccups with the sessions. Below the surface, it’s balancing the agenda across all tracks and days, difficult decisions between one speaker and another, and a trade off between streams. Like many organisational changes, the tooling change from email to Sessionize wasn’t about the technology, it was about helping people understand why we were changing, and how to bring them along for the journey. This took significantly longer than first anticipated.

    The day was brilliant, and I felt like we were more like a team than I’ve ever seen. As I drove home, I found myself talking to Joe, less about the tooling and more about the people. A conference agenda is ultimately just a reflection of the community behind it. The technology helps, the process helps, but neither replaces a room full of people who care deeply about creating something worthwhile. Looking around the room, listening to debates about session clashes, audience levels, and emerging topics, I was reminded why I’ve stayed involved. The best conferences aren’t built by software or committees. They’re built by communities willing to spend a day eating pastries, drinking Diet Coke, and arguing passionately about what their peers need to learn next.

    I’ll look forward to the conference in November!

  • Mentors, Networks, and the Space Between

    My role is broad. I’ve spanned over seven projects around the mainframe in the last four years, from enterprise integration, transaction processing, and acquisitions. This has required a growth mindset, bouncing between teams, executives, and context. The trend has followed me through my entire career – different roles and accounts in Consulting, different acquisitions in my technical lead role – a strength of mine being the breadth and variety of the projects I’m involved in.

    This level of volatility in my career has meant that the people I surround myself with become incredibly important. Reminders like my long-term career strategy, settling my emotional volatility, and listening to help me problem solve issues that crop up. I vividly remember being in my early twenties and listening to an executive all hands making an off-handed comment about having mentors in and out of work to talk to, and I was confused. How does someone get a mentor outside of the company I’m employed by? Where do I find one?

    This was reinforced by the book Lean In by Sheryl Sandberg, which I’m aware is a controversial book, whereby she tells a story about a woman that repeatedly asks her for advice over a series of months, and then one day turned around and asked Sheryl how to find a mentor. Sheryl reminded her that mentoring isn’t always about a formal relationship between two people every month with strict boundaries, it can be asking for help and learning from each other over time.

    Networking, to me, is a dirty word. Overused, underexplained, and setting younger people up with the daunting task of working out how to game the system. How can I meet as many people as possible? How can I collect as many people and mentors as possible? What does it even mean to have a network? 

    When I first joined IBM, within a few months I became incredibly curious. In my lunch, I would scour the intranet for information – what companies did we work with? What jobs did people do? What sectors do we work with? I stumbled upon Richard, who at the time worked in media and television, we met over the phone as I was a keen apprentice he replied to my note quickly. I had no understanding for how senior he was, and we began talking about all sorts – what I spent my time doing, how I was enjoying working in IBM, and learning about IBM’s strategy at the time. Richard remained a mentor of mine throughout the next decade, until he retired a few years ago and we try to keep in touch when we can.

    Another example is around 2 years later, my third role in IBM and I had a personal development plan review with my second line manager, I had a list of 15 people I wanted to speak to about areas of the business I was interested in, articles to read, books to read. I remember his quote “you’re overboiling the ocean here, Louisa, you could scale it down slightly,” and I scoffed, confused as to why he thought that was too many. I was ambitious, and not afraid to cast my net wide.

    Mentoring isn’t built through structure, it’s built through repeated moments of curiosity and connection.

    At the time, I was an apprentice and I had no idea how many doors that would open, and that what I was building was a personal brand and a network. I was building a rolodex of people to call when I needed help choosing my next role, deciding on how to approach a problem, understanding the business strategy. Although I never felt like I had enough. Looking back, I now believe that feeling was due to the hype around a network and nobody truly describing what it meant. 

    To me, there is a difference between networking and mentoring. For example, I have mentors that have been by my side for over a decade, seeing me through management changes, house moves, marriage, and in turn, I help them navigate their own challenges, even if they are generally much senior than I am. I have also had mentors that come and go, I see them once in a blue moon when we work on a project together, it’s like working with an old friend, and then they go back to their day job. Some mentors which I meet monthly, quarterly, we text when there’s a problem or we want to get a coffee, or some mentors, I see in the corridor or when they get a coffee from the coffee shop near my office. It’s a flexible relationship and one that for me, has turned into genuine friendships.

    Networking however, is the ability to meet people and build knowledge, understanding, or context.

    For example, now I’ve been to GS UK for a while, I have a network within the conference. I know many speakers by sight or name, I build a friendship with those I see regularly, like the committee, and I seem to have an amazing capacity to meet one person, and for them to introduce me to twenty other people. Networking is about knowing how an organisation or group of people operate, having the interest to understand who is friends with who, how decisions are made, and often, networks aren’t always useful, they are people that you meet and maintain relationships with. It doesn’t mean that you would have every person in your network as a mentor, that would be crazy, but it means you have a group of people that you know and that provide you a range of opinions, thoughts, and perspectives.

    Coming back to my original note, even though my role is broad, and my network has morphed and changed, my mentors have come and gone, I see it as a privilege to have spent time with those that have guided me in one way or another. I’ve been through a lot of loss from mentors leaving roles or companies, and I’ve found that relationships and friendships morph to fit the circumstances. A mentor that I would never text, we now send each other articles and exchange opinions regularly, however, others have drifted away.

    I spend time and energy keeping those relationships that mean something, and often, I don’t want anything from them because that isn’t my main goal. Go into mentoring with curiosity, interest, and the desire to find out more. Don’t let the ‘we haven’t got a monthly calendar invite’ or ‘I don’t know when I’ll next see them’ stop you from having a crew around you to help when you’ve broken down. 

  • Women in Tech Hampshire, July 2026

    Yesterday, I went to the Women in Tech Hampshire summer BBQ, hosted just outside Southampton at a local business park. I had watched the team at Spectrum IT deliver the event multiple times on LinkedIn, but hadn’t had the courage to go along, even though I’m outgoing and love being around new people, something about branching out of my usual comfort zone of big tech scared me. My way to get around the anxiety of going to the event was to tell people at work that I was going, almost as a commitment to myself that I was going to put myself out there with a new group of people.

    The event is hosted every other month, and features a panel of women that talk about a particular subject – in the past they’ve had topics like female founded companies and neurodiverse leadership. This time, it was about general female leadership in tech. I turned up, not sure what to expect, and immediately found another woman on her own so we started talking and gradually we both felt a lot more comfortable. We invited a few more people to sit with us as they were also on their own and we had formed a group of five within the first fifteen minutes.

    I’ve spoken on podcasts before about community being a particularly important part of belonging as humans, and that in my experience as a flautist, the community is great because you can turn up, know nothing else about the person but their love of the flute or love of music. I had the same feeling at this event. Once we’d got our food we found a table, and immediately started finding common ground in our use of AI, and our opinions of using LLMs to help us with our day to day work, the ways into work that didn’t involve a degree, and the sorts of technology that we all worked on. We had something in common which immediately made everyone feel like they belonged.

    Once we’d eaten, we were ushered into the conference room with over 50 women crowded around tables and perched on tables around the edges. The panel included three leaders – Andrea, Anita, and Tiffany. The questions were fascinating, ranging from whether they had any female mentors as they progressed through their careers, how they found being the only female in a boardroom, and their advice for women contemplating leadership. I particularly found it interesting when a member of the audience asked what to do when as a technical developer, she was told that she needed to move into management to progress – the answer was to negotiate with her work or leave the job and find somewhere that celebrated you as an individual contributor.

    Often, I find that female-led tech panels are cringe, or they regurgitate the same advice. However, in this panel I felt a level of comfort between the panellists and the audience. We didn’t pretend that a woman could have it all, there had to be sacrifice, the panellists acknowledged how privileged they were to be in the position of authority that they held, and the discussion about handling family and the demands of a career were interesting. I felt a level of candidness from the women that I hadn’t seen before.

    As a product manager, part of my role is to lead without authority. Bring teams together to achieve something they didn’t think possible, deliver a business case for a new product to gain approval, negotiate and deliver across the business with teams that don’t work together. I was intrigued that, given all three panellists were in people leadership roles, the discussion naturally gravitated towards management responsibility.

    It made me realise that I’d come to see leadership differently. Most of my career has been spent in roles where I haven’t needed formal authority to get things done. As a product manager, I’ve had to learn how to influence people, bring teams together, and create momentum without ever being their manager. Having panels like this in big tech are few and far between, and so hearing their experience gave me pause for thought about what I could aspire to, rather than be afraid of.

    I’ll definitely be coming back, what a warm, lovely, diverse, and welcoming community of women (and the odd man). I felt like I could have something in common with anyone there, and I really appreciate having my eyes opened to businesses outside of my usual comfort zone. It’s important to be reminded that smaller companies operate outside of big tech.

    I spent the drive there worrying about whether I’d fit in outside of my usual world of big tech, and within fifteen minutes I was sat with four strangers talking about AI and career journeys as though we’d known each other for ages. Communities often feel intimidating from the outside, but once you’re in the room, most people are just looking for someone to sit with.

  • Open Source is a People Problem

    It’s been six months since I stood down as Chairperson of Galasa, an open-source project under the Linux Foundation. Galasa took me around the world, from Las Vegas, Orlando to Milton Keynes, and gave me the opportunity to work alongside some incredibly talented engineers. Yet six months on, the lesson that stays with me isn’t about technology. It’s about people, ownership, and what it takes for an open-source project to outlive its founders. Looking back, I spent a lot of time thinking about architecture, roadmaps, testing frameworks, and adoption metrics, trying to demonstrate that the project was healthy through numbers alone.

    The hardest part was building a community.

    There were a number of difficulties in running a project like Galasa – I didn’t have regular code contributions coming from another vendor, the conversation around testing z/OS applications was as advanced as it needed to be to adopt the technology, and despite my best efforts, I found it hard to bring new people into the project that wanted to take leadership roles to compliment or succeed my own. The adoption metrics were promising, I had the team pull download data, interaction data on Slack, the likes on LinkedIn. However, with any open-source project, you need the momentum of a community to continue going, you need the debate around whether to remove the Eclipse plug-in, or whether we are ready for a version 1.

    I believe that open-source communities don’t succeed by a group of people agreeing on an architectural change, they are defined by people who are engaged enough to disagree. 

    The role was fantastic at putting me in the forefront of the customer problem. For example, when I was pulled into a conversation from a distributed developer attempting to write Galasa tests for their mobile banking app, and he had a complex Galasa set-up on his system, digging around through complex 3270 screen tests and CICS interactions. Another example, where I was called over to a table at a conference to analyze a hybrid-cloud CI/CD pipeline and how Galasa was going to be the central test framework for their z/OS Connect tests. I enjoyed encouraging new presenters at their first conference, watching external companies talk about Galasa and how they’re using it to make their day-to-day work easier. I believe that we don’t do enough testing on Mainframe applications, and as a culture, we’re incentivized towards test-driven development and shift-left testing, which is difficult when your test scripts are written in dog-eared, coffee-stained test scripts in the drawer of a colleague that you bring out only when testing something into pre-production. Additionally, I found the creation of strategy fascinating – how do you rally people around a common goal, set out what you want to achieve, and create the processes to do that. It’s the small things, like bringing development updates to YouTube to encourage wider viewing, documenting all meeting notes for future reference in GitHub, stepping back to watch others’ present when you could have easily done it yourself. 

    The reality of running an open-source project is tough. I spent hours looking for contributors, through the Open Mainframe Project’s Summer Mentee program, LinkedIn, talking to potential contributors online, understanding how other open-source projects succeeded, presenting at customer sites to get them interested. It needs a diverse group of companies to thrive. Looking at successful projects such as Kubernetes, it became clear that technology alone wasn’t enough. Kubernetes wasn’t successful because Google built it. It succeeded because companies such as Microsoft, Red Hat, and IBM brought different perspectives, competing priorities, and healthy tension to the project. The competing companies forked the code for their own use, spent time sending engineers to conferences, evangelising the project online. I spent time balancing the roadmap and engineering effort that the team wanted to dig into, with blogging, articles, videos, and ensuring that we weren’t just building great tech, but talking about it too.

    If nobody knew we existed, then they wouldn’t consider joining us.

    Ultimately, metrics can tell you that people are watching. The number of views on a blog or video, the reactions to a LinkedIn post, the number of people in a room at a conference. Metrics helped when we wanted to pull features because we knew who was using it, or how many people were downloading code or viewing the website documentation. What metrics can’t tell you, is whether people are willing to invest their time, evenings, weekends, or careers to help build something. That, is something I massively underestimated.

    If I could go back, there are a few things I’d do differently.

    Firstly, I’d invest earlier in creating smaller contribution opportunities. Joining an established codebase can be intimidating, and it wasn’t always easy for new contributors to find a meaningful starting point.

    Secondly, I’d spend more time developing future leaders. Open-source projects need succession planning just as much as commercial organizations do. Ownership must be distributed if a project is going to survive beyond its founding team.

    Finally, I’d continue pushing beyond the traditional mainframe audience. Going to DevOpsPro and the Linux Foundation conferences started that, but I didn’t do enough. Some of the most interesting conversations I had, came from developers who weren’t part of the established community but were trying to solve similar testing and automation challenges. 

    Looking back, I don’t regret a moment of my time with Galasa. I love working with talented engineers, travelling the world, and helping continue to shape conversations about the future of testing on the mainframe. If there’s one lesson I’ve taken away, it’s that open source is ultimately a people problem, not a technology problem. Code can be written by a handful of developers, but communities require shared ownership, healthy debate, and a constant influx of new voices. Building Galasa taught me about software, but it taught me even more about leadership, community, and what it takes to create something that can outlive its founders.

  • Where is the line between collaborative and assertive?

    Yesterday was a breezy day, sun was poking through the trees, and the fish swimming around the pond. I was having a coffee with a colleague, and we were discussing how to be more assertive as a woman in the workplace without coming across as angry and aggressive. A few years ago, I was told that my leadership style was too collaborative, and not assertive enough. I found this feedback confusing at the time. I had always had pride in my ability to bring a group together and collaboratively make decisions, give constructive feedback to one another, and to move forward. However, in the eyes of this colleague that was not seen as a positive trait. 

    In previous roles, I would employ all sorts of tactics to bring a group of people together. Having concrete meeting agendas and outcomes to encourage attendance and make each person feel needed, going ahead of time to collect content, sending feedback forms regularly, individually making connections with all of those that you need on board to get to know them. It could be said that my approach is laborious, long-winded, overly focused on others’ feelings, and at times, slow. However, I didn’t see this as part of the job, I saw it as a way to connect with others and make interesting technology together. 

    In the project the colleague and I were working on, I found myself bending to be more assertive, which worked in part. My goal was to create an outcome-based roadmap for the product, which spanned many workstreams, which made collaboration hard. My initial approach had been as I described, to go around all the individual teams, gather data for what they were doing, create the customer outcomes, and encourage them to put together the master epics, the work they were going to deliver for the project. Given I was one person, and the collaborative effort was slow because of other mitigating factors, I found myself getting into endless discussions around development delivery, exposure of the roadmap to the wider team, how can we speed up. My response was to get into a room with my peer product manager and write the product scope and strategy together, a three-hour session that involved a lot of whiteboarding. The outcome was that I could write the entire list of product outcomes without the input of the technical team and present them to the wider audience – I felt I was being more aggressive in my approach – if my previous approach meant I was too slow, this would be a clear fix.

    The reaction to the work was mixed. The development team were impressed, I had taken all the previous input and distilled it into the top priorities for the entire team to focus on. Like my previous blog about creating a strategy, 90% of the work we’re doing should fall into one of the product outcomes.  The colleague was confused, had a lot of questions, and I sensed I had gone rogue, not taken all the advice. Feeling like I had crossed an invisible line from collaborative to assertive, I went back to my old ways. The colleague I was recalling this to made a sigh to suggest she had received the same, going from being incredibly nice to a summer intern in the team, to overly aggressive when for the fifth time that week he had gone to an over-extended coffee break she had to firmly say no, he needed to finish the work that he had started.

    Here are three things that I have done to help combat the collaborative versus aggressive narrative:

    • Being explicit about decisions versus discussions,
    • Setting boundaries earlier with those around you,
    • Separating ‘listening’ from ‘agreeing’.

    The irony is that when uploading this blog through AI, the feedback I got was that I was too narrative-driven, flowing, and I needed to tighten the structure… Perhaps even AI is trying to tell me I’m too collaborative and not aggressive enough. What’s the age-old advice we always tell women? What would a man do?