_edited.png){kind=small}
About
I simplify complexity in programmes where ambiguity is constant and change is certain. Not by removing things — most of the complexity is real and has to stay — but by working out which parts carry weight, and making those unmistakable.
Carol Mota, Founder and Director. Nine years inside Google's data centre programme, leading global cross-functional programmes.
WHAT SIMPLIFYING ACTUALLY MEANS
Simplification is not compression.
The same material, shorter, is not simpler — it is just shorter. The hard part was never length. It is judgement about what matters.
A programme carrying genuine complexity has hundreds of true things in it. Only a handful change what anyone does next. The work is separating those from the rest, holding the line on what has to survive, and then making it clear enough that a room of people with different priorities can act on the same understanding.
Often the thinking has already been done. It was decided in a meeting and never written down, or written down somewhere nobody looks, or written in a form that takes twenty minutes to interpret. From inside the programme that is indistinguishable from never having decided at all.
Done by someone who doesn't understand the domain, that isn't simplification. It's deletion, and it costs more than the complexity did.
HOW WE WORK
Clear enough that the real conversation can happen.
Clarity isn't a presentation quality. It's what makes a decision possible — and it usually means putting the difficult thing on the page rather than around it.
Most programmes already know what their real problem is. It gets discussed in ones and twos, by people who have concluded that raising it formally costs more than it's worth. I put it in the work, stated plainly and without blame, so it stops being something to route around.
No hedging. No padding. Nothing in the pack that exists to look thorough. The test isn't whether people agreed with me — it's whether the decision got made, on time, and whether the room came out of it more together than it went in.
WHERE THIS COMES FROM
Nine years where nothing stayed settled.
Delivery inside Google's data centre programme is a permanent state of change. Sites move. Scopes shift. Regulation arrives mid-build. Work runs across time zones and functions that each hold their own definition of done. Nothing stays still long enough to be written down properly, so the documentation ends up describing a programme that no longer exists.
I spent those years building the systems that held underneath it — process and compliance, executive reporting, business process standardisation across a global portfolio, and a communications programme that trained more than nine hundred people in how to make a message land.
Most recently, an end-to-end delivery operating model for the EMEA region: fragmented, siloed tracking replaced with a single governed view of scope, ownership and schedule, taken from discovery through live pilot to regional scale. Delivery teams asked for the extension themselves, which is the only test of an operating model that means anything.
Programmes rarely lose control for lack of talent. They lose it because the system underneath the work was built for a smaller, slower version of the same business, and nobody has the remit to rebuild it while it's still running. That remit is what Studio Claro is.
How we work with clients.
A small number of clients at a time, in data centres, infrastructure and energy. Engagements are delivered by a small senior team rather than a large one, and where a programme needs sustained capacity, that capacity is permanent Studio Claro staff rather than contractors brought in for the job.