I came across research covered by Abi Noda showing that removing names from student work reduced bias in how it was graded. It raised a question I couldn't put down: how do organisations understand what people are genuinely experiencing, especially when concerns are hard to raise openly?
That question, combined with years of watching capable people doing good work still get slowed down by slow CI, flaky tests, delayed reviews, and weak feedback loops, led to Team Signal: an anonymous Slack or Microsoft Teams check-in that helps engineering teams identify where delivery friction is being felt. What draws me to this work is the systems that make good work possible or unnecessarily hard, not the tools themselves.
That instinct started earlier. During my Master's degree in Advanced Computer Science, I researched fake news classification using ensemble machine learning models, including sentiment analysis techniques for processing the underlying data. I then moved into front-end development, where I worked across data visualisation, QA, product delivery, APIs, and engineering pipelines, well beyond the role itself. I worked at the seams where friction sits: standardising Storybook so design and front-end stopped diverging, and agreeing the backend contract with frontend before it was used, so changes could not land on one side without the other knowing. Both removed recurring friction. Neither gave me evidence I could point to. The improvement was real. The evidence wasn't. Closing that gap is part of what Team Signal is built to do. It shaped how I think about Developer Experience: not only as the end user's experience, but as the experience of the people building, testing, and delivering the product.
Team Signal shows where the friction might be. DXMethods is what I built to go further, turning what a team learns about its own friction into real, owned change. The goal is not measurement for its own sake. It is to help a team understand its own working environment and act on it.
I am not presenting myself as a former staff engineer from a large technology company. My perspective comes from academic research, practical software-delivery experience, and building products.
That is what I am building through DXMethods.