Ray's Digital World

  At Service NSW, my squads typically serviced five or six projects and clients at once, across licensing, revenue, health and education. Each agency had its own deadline, and each treated its request as the urgent one. Switching between them was only half the problem. When we were ready to engage an agency and asked for what we needed to configure their requirements, such as callback URLs and privacy URLs, they often did not have them. Waits ranged from two weeks to six months, and some engagements were cancelled midway. In my experience, the agency had usually realised it was solving the wrong problem, or lacked the funding or people to support the work. We could not park that work cleanly. We moved to the next agency, and when the first came back, we had to reload the context. The cost The costs were mostly intangible but real: lost focus, demotivation and low morale, all feeding into delays. On the coordination side, we averaged 2.7 hours per incident, with delays of one to ...

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 I...

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...