Cloud as a Story - Vunvulea Radu

 When we started developing our cloud capability, one of the first things I wanted to understand was what experience we already had. People across different locations had worked on cloud projects, solved difficult problems and learned things that could help other teams. Finding this information took effort. It was spread across teams, locations and systems. Each group collected information for its own needs. Sales needed customer references. Delivery teams knew the technical details. Regional leaders looked at people and availability. Communities followed skills and certifications. Everyone had part of the picture. We needed to bring these parts together in one place.One of our working tools was an inventory connecting projects, technologies, locations and the people involved. The important part was agreeing what information we needed and how others would use it. A technology name alone tells you very little. I wanted to know what the team had delivered, the constraints they ...

 When building capabilities (like cloud) across regions, I focused on a core question: what should the organisation deliver as a direct result of this capability? This question helped align decisions about people, projects and business priorities. Training, certifications, communities and reusable assets all play a role, but the focus remains on delivering outcomes we can stand behind for our customers. Initially, we introduced a practical tool: an inventory of our cloud experience. We mapped projects, technologies, locations and the people involved. This gave us clear visibility into our expertise, exposed gaps and identified areas where we depended too heavily on a small group of individuals. With this data, we could make targeted decisions about where to invest next. Developing people required the same clarity. Training access was only the beginning. Teams needed time, hands-on environments and real opportunities to apply new skills. Feedback from our programs highlighted these ...

 Last week, I was working around seven in the evening when I ran out of tokens. I was working on a system built entirely with AI. For a system build with AI, it is impossible to work on this system without AI, so when the tokens were gone, I had to stop. It reminded me of ten or eleven years ago, when the electricity went off at the office. The computers stopped, and everyone went outside because there was not much else to do inside. Back then, our work depended on electricity. Now, more and more, it depends on AI too. Tokens can seem like a small technical detail, just a limit you check from time to time. But when they are gone, you feel what they mean. They can be the difference between continuing your work and having to stop. I wonder if we are starting to depend on AI in the same way. We use it to write, analyse things, find solutions, and move projects forward. Maybe, after some time, working without it will become much harder. Not because we have forgotten how to do the...

 Moving an application to the cloud is not the same as making it ready for AI. AI workloads need data that is available when they need it, systems that can scale, and good automation and governance. If we only move an old application as it is, we may end up with the same limitations in a different place. That’s why I think it helps to separate migration from modernisation. Migration changes where an application runs. Modernisation changes how it is built, operated and improved over time. Before AI agents entered the picture, the modernisation journey already had a familiar shape: discover and analyse the application, decide what to do, migrate it, and decommission what is no longer needed. Those steps still matter. What changes is how much of the repeatable work we can now accelerate. An agent can help explore a codebase, identify dependencies, review configuration and suggest possible modernisation paths. It can also help draft a plan or prepare code changes. That’s useful, ...

  I’ve been using ChatGPT and Codex a lot lately - for research, analysis, writing, and the many small tasks that make up a working day. One thing I’ve started doing is saving the prompt and context behind a document, so I can come back to it later. It began as a practical habit. Then I realised it pointed to something bigger.  I noticed this while working on a proposal for new AI capabilities. When it was time for review, the proposal itself wasn’t the whole story. People also needed to understand how we had got there: what information we’d considered, what assumptions we’d made, and what might happen next. I’ve run into a similar thing with client proposals. Work can start in an early conversation, before there’s a formal project space or an agreed way to share context. Later, I, or someone else, might need to pick it up and carry it forward. The conversation may be hard to find, or the reasoning behind the document may never have been written down. Then the final proposal i...