Ray's Digital World

Early in my career at HSBC, I supported FIERCE, an internally built execution and routing engine that let traders in London and New York execute fixed-income trades on live Bloomberg and Reuters feeds. When something went wrong, nobody needed a dashboard to tell you. The trading floor told you. I have since moved through delivery and product roles, but that early work shaped how I judge products. A launch is a date. Reliability, recovery and support are what customers actually live with. Lesson one: recurring incidents are product feedback At HSBC I provided L1 and L2 support, led root cause analysis on recurring incidents and automated process and system health checks. Automating checks was useful, but the bigger shift was in how I thought about repeat problems. An incident that returns is not bad luck. It is the system telling you the same thing twice. Later, at Infosys, I led a 10-member offshore team managing integration and production environments for Bank of America applicati...

Time zones get blamed for a lot. They make meetings awkward and handovers slower, but in my experience they are rarely what actually sinks distributed delivery. The real damage happens when nobody can see the same risks, the same capacity and the same dependencies. I have worked across this problem in several forms: leading offshore teams, coordinating vendors in different countries, and travelling to regional teams in Australia. The setting changes. The failure pattern is remarkably consistent. Make capacity visible At Capgemini, I was offshore delivery lead across three Agile squads on the Co-operative Bank's core banking redesign, with multiple vendors across time zones and competing priorities. One of the things senior management and clients appreciated most was simple: presenting team utilisation and capacity visually. That improved resource planning and decisions because leaders on the other side of the world could see the constraint instead of being told about it. When ...

Most advice on cross-functional collaboration comes down to asking people to communicate more and respect each other. Both are good ideas, and neither tells you what to do on Monday morning when three groups hold three different understandings of the same product. What has worked for me is more practical. I try to give everybody the same picture of the problem, the same reasons for a decision and a clear line to who owns what. Turn complexity into something people can question In my current work with several organisations and a wide range of stakeholders, the research, workflows and dependencies are complex enough that a written document would never have aligned everyone. So I turn them into visual maps, explain them in plain English, and keep changing them as people ask questions. That last part is what makes it collaboration. A map people can challenge becomes shared. A polished artefact presented at them stays yours. Put the strategy on one page I also like a strategy on a pag...

Ask a stakeholder what they need from a product's data and there is a good chance they will say "a dashboard". It sounds concrete and it can be delivered in a sprint or two. It can also be a very efficient way of producing charts that change nothing. The data work that has helped me most started with a specific operational question, and only then moved on to how to display the answer. Measure the pain before you fix it At my previous Government role, onboarding a government agency involved a partnerships team, product teams such as Proof of Identity and Profile Connect, and my squad. Roles were unclear, and it felt chaotic, but feeling chaotic is not an argument. The useful number was this: we were averaging 2.7 hours per incident on coordination, causing delays of one to two days and sometimes a week. That turned a vague frustration into a problem with a size. I founded an onboarding squad as a buffer, with defined roles, a single ServiceNow process aligned to the IT...

There are two popular stories about AI and content. In one, it replaces human expertise. In the other, everything it touches turns to mush. Building a content automation system for a client through my business, Rays Digital, left me believing neither. The client was a seasoned product leader with strong professional expertise and almost no visibility on LinkedIn, averaging 131 impressions a day, even though the people he wanted to reach were active there. Expertise was not the gap. The gap was consistency, focus and format. What we built I built a content automation system in n8n with three jobs: Identify high-performing topics, so effort went towards subjects the audience had shown it cared about. Optimise posting cadence, so visibility did not depend on when someone found the time. Structure each post around hook, insight and call to action, so ideas arrived in a form people would read. We used no paid promotion. What happened Average daily impressions grew from 131 to...

The first time I suggested a retrospective to a team that had never run one, I learned something no Agile course had taught me. The objection was not to me, and it was not really to retros. It was a whole way of working telling me, politely, that this looked like ceremony for its own sake. That happened on one of the high-visibility priority projects, where I was Senior Product Owner. The aim was to give NSW real-time visibility of housing development, tracking residential construction from planning approval through to occupation. Data was fragmented across departments, and councils, utilities and emergency services were working from incomplete information. The delivery setting was about as far from a startup as you can get: three organisations (2- government departments and one overseas digitisation private partner), legacy systems, heavy regulation and a team based in Bathurst with a long history of waterfall delivery. Why the textbook version failed I started by introducing Agil...