Louisa Denly

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

  • 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?

  • Creating Sustainable Strategy for Open Source Projects

    When I first started leading Galasa over two years ago, there was only one question that I kept asking myself – how do I make this project sustainable for the long-term?

    Open source is a unique way to develop software, predominantly because it is through the passion of developers, documentation writers, designers, architects, and leaders that volunteer their time to spend creating something they believe in. This can create something extraordinary and industry-changing like Kubernetes, Zowe, Linux, and the vast array of projects that are used across the IT industry to keep the world running. However, the downside is that unless you have a continuous stream of volunteers, these open source projects can suffer and find it difficult to continue. 

    There is often a passion and driving force behind those that maintain open source projects that keep the community alive, and that can be seen through webinars, blogs, conference presentations, awards, YouTube videos, and more. However, if this isn’t curated and thought through, especially when the project is small, it can be hard to gain the publicity and the extra support that you might need. For example, if someone new picked up the project to use it for the first time and they had nobody to contact for help when they got stuck, it’s unlikely they’ll continue using it.

    When I took on Galasa with the rest of the brilliant maintainers and committers, it was clear we needed some guiding principles with the activities we were going after as a group. What would help the project survive for the long term? What can the maintainers do to continue attracting new users and developers? What is the strategy?

    Firstly, strategy is a concept that has been poured over and written about over centuries. However, for this, I’ve used the definition that strategy is a plan of action designed to achieve a long-term or overall aim. So, the first thing for us to do was define the mission and vision – what was Galasa here to achieve?

    The mission was defined as the following: to allow customers to deliver software with confidence by simplifying and encouraging automated integration testing to help Mainframe modernisation within Hybrid Cloud environments and increase the reliability of repeatable software releases. Yes, it was long and wordy, but it best fit what the project was about, to make deploying software on the Mainframe easier and more reliable.

    Then, once we’d defined the overall aim of the project, it was time to consider what were the long-term goals that we were trying to achieve. The guiding principles by which when we are choosing to do something to benefit the project, did it fit into the following aims?

    1. Grow the number of users and companies utilising Galasa.
    2. Grow the number of individual contributors on GitHub.
    3. Deliver version 1, user requirements, and features for Galasa.

    These may seem far reaching and not very SMART (specific, measurable, achievable, realistic, and timebound), well, that was the point. If we created goals that were too difficult to obtain, everyone may lose interest and find it demotivating. On the other hand, if the goals were too specific, and everyone was volunteering time, then they may find the pressure of holding to those goals too much and they would not continue.

    In reality, it has been difficult to continue all three of these goals at the same time – sometimes it’s more important to prioritise the build pipeline and creation of a better documentation experience, than it is to blog and make videos about the project. However, they have provided a good steering guide for the maintainers to consider what they are focusing on.

    The most important thing about creating a good strategy is the ability to remain consistent and reliable in delivering in small steps towards the overall aim. The journey for Galasa remains bumpy as we enter our third year in the open, however it’s the love and passion for creating something that will be used to make software engineers and enterprise level applications more resilient for the long term keeps us motivated.

    How have you created strategy for open source projects? Do you agree with what I’ve laid out, or have you done things differently? I’d love to hear your experiences.

  • Galasa Updates

    On the 11th February, the Technical Steering Committee got together to talk about the progress on the project, the roadmap, what’s next, and to share experiences of the contributors and committers of the project. It’s been a couple of months since we all got together and looked at the technical deliveries of the project and the roadmap for the next few months.

    Mike Cobbett, the project’s lead technical architect, lead the discussion below on the latest releases of 0.38, 0.39, and the upcoming planning for the 0.40 release later in February. Recent releases have introduced encrypted secrets management, a consolidated mono-repo for easier contributions, and role-based access control (RBAC) to improve security and governance. Looking ahead, the team is focusing on enhancing parallel test execution, improving security with HTTPS support inside clusters, and expanding Web UI capabilities for better visibility into test cases and results. Additionally, upcoming work will enable integration with password-protected Maven repositories and upgrade etcd for improved authentication and performance. As the contributors continue to enhance the project, the key aims are to ensure Galasa remains scalable, secure, and adaptable to your enterprise testing needs.

    The team release regularly, with all the issues being tracked in GitHub with a long backlog of items that the team want to achieve.

    The Galasa contributors and committers have an ambitious roadmap focused on enhancing scalability, security, and usability. In the near term, efforts are centred on secure access control, including role-based authentication enhancements and expiring access tokens to improve governance. Test execution is also being streamlined with support for password-protected Maven repositories and better HTTPS certificate handling. As the project progresses, expect major advancements in the Web UI, including expanded test visualization, log analysis, and real-time status tracking. Further down the line, the team is exploring infrastructure optimizations for better scalability, continued security enhancements, and ongoing refinements to make contributing to Galasa more accessible for the open-source community.

    The contributors and TSC are looking ahead into 2025 with excitement about the increase of use of Galasa and the continued technical development in Galasa. You can also find content about all the technical updates have happened over the last quarter on the Galasa website. If you’d like to contribute, come and join us for our daily scrum meetings, fortnightly iteration planning meetings, monthly TSC meetings (calendar link), and the Github repo.