Guillermo Martinez

The fixed point

I was born on an island that had a name before it had the one on the map. Borikén. Both of us were — Yadira and I — and the story the company is named for is one we heard as children, in the way those stories survive: told rather than written.

Anacacuya is a guide who kept a light where others could find it. That is the whole of why a technology company carries the name. Not heritage as decoration. A bearing.

One of the first serious things I worked on there was public rather than commercial. A police-presence programme, delivered for a telecoms company under government standards, where I came in as the contracted programme manager: a purpose-built data centre, a backbone running to a central command centre, a town-wide wireless mesh, hundreds of cameras. Thirty-six specialists. Seven million dollars in its first stage, and the first deployment of its kind on the island.

What I learned there was not technical. It was that when a system is the thing people call in an emergency, the question is never whether it works in a demonstration. It is whether it works at three in the morning when nobody is watching, and whether anyone would know if it had stopped.

I have been asking that same question ever since, at progressively larger scales, and it turns out to be the only question that matters.

Learning the wire

Routing and TCP/IP were the first domain I mastered, and the qualifications that followed are what made every later jump possible.

It is an unfashionable thing to have spent years on. Packets, addressing, the protocols that decide where something goes and what happens when the path disappears. It is also the closest thing I have to a first principle, because a network is a system where the failure modes are distributed, intermittent, and nobody's fault in particular.

You learn three things there that you cannot learn from a diagram.

That the thing which breaks is almost never the thing that gets blamed.

That intermittent is harder than broken, because broken gets attention and intermittent gets worked around by a person until the person leaves.

And that "it works" is not a state. It is a measurement, taken at a moment, on a definition somebody agreed in advance.

Everything I have done since is that, at a different scale.

Running the shop

I ran a sixteen-person technology company. Not owned — run. I came in to manage IT, and left as general manager with the profit and loss on me, reporting to the owners.

It is the most useful thing on my record for the businesses Anacay serves, and for a long time I undersold it.

Sixteen people. Every problem an owner of ten to a hundred people has, I have had at a smaller scale and with less margin for error. Quoting that ran through one person. A service where the promise was clear and the process behind it was not. Customers who did not care whose fault it was. A month where the number had to work.

I built the company's first program office, because we kept promising dates we could not hold and I could not tell you why. That is not a methodology decision. It is what happens when you have been wrong in front of a customer enough times.

And I put twelve engineers through a certification programme — which made us the first team in Latin America and the Caribbean to meet those requirements. I mention it because of what it cost: it was months of people's time, paid for by a company that did not have spare money, on a bet that capability we could prove would win work that capability we merely claimed would not.

It did.

What changed, in the numbers I was accountable for: revenue up about 70%, margin up about 10 points, hourly rates up about 35%, the account base up about 400%, and the close rate from roughly 60% to roughly 90%.

The one I think about most is smaller and less impressive. We recovered about 12% of revenue that was being lost — not won, recovered — by fixing how time was recorded and how invoices were checked. No new customers. No new product. Just stopping the leak.

That is the direct ancestor of a service Anacay sells today, and it is why I believe most small businesses are closer to a better month than they think.

But the thing I would want judged is not any of those numbers. It is that I have made that bet with my own profit and loss, which is a different kind of knowing than having advised someone else to make it.

Moving what a business depends on

A bank's phone system, moved site by site, with the bank as the client.

Sixteen thousand phones in its headquarters metro. Trader floors, where a dropped call is not an inconvenience. Cutover windows that could not overrun, because the business opened whether or not we were finished.

The result I am proudest of is a small number: after the migration was declared complete, three previously unidentified low-use lines surfaced. Three. On sixteen thousand.

That number is not about care, though there was plenty of that. It is about method. You cannot move sixteen thousand of anything by being careful. You move it by building an inventory you actually trust, by testing the inventory against reality rather than against the last inventory, and by designing the cutover so that being wrong about any one line is survivable.

Every business I work with now has a version of this. It is never sixteen thousand phones. It is one practice-management system, or one phone system, or one move to a new building — and the whole business depends on it, and it has to happen on a weekend.

The scale is not the point. The method is the same, and so is the thing that goes wrong: somebody trusts a list that nobody checked.

Turning around what was failing

A support platform running at about 99.8% availability, rebuilt to about 99.998%.

Those two numbers look similar and they are not. As downtime, 99.8% is about seventeen hours a year. 99.998% is about ten minutes. Same system, same people, a different way of finding out what was actually wrong.

I was the sole program manager on an eight-engineer team, which meant there was nowhere to hide and no one to hand it to.

The thing that made the difference was not a technology decision. It was that we stopped trusting the system that was supposed to be reporting on the problem, and went and tapped the real signal path instead. The monitoring said things were fine. The monitoring was measuring something adjacent to the thing that was failing. That is an extremely common condition and almost nobody checks for it.

The second thing was rebuilding a business's trust in a system, which takes longer than fixing the system and is a separate piece of work. A platform that is now reliable and is still assumed to be unreliable is not yet fixed. You have to show people the number, repeatedly, until the number is what they believe instead of their memory.

Who gets the machines

For several years I ran the yearly capacity and planning cycle for infrastructure inside a business of roughly twenty billion dollars a year.

In practice that meant collecting demand from more than a hundred engineers, one at a time, because a spreadsheet sent to a hundred people returns a hundred wishes and no information. It meant defending that demand through finance, who are paid to disbelieve it. It meant fitting what survived into a budget that was always smaller than the ask. And it meant brokering between teams who all needed the same machines in the same quarter and all had a legitimate case.

I had no authority over any of them. That is not a complaint — it is the whole lesson. What I had was the number, and the commitments teams had made against their own targets. Utilization was surfaced back to the teams. Commitments were taken against what they had said they would deliver. Launches were held for serious offenders. The authority was arithmetic plus a team's own word, and that kind of authority survives you leaving in a way that org-chart authority does not.

Later, in a different organization and on a much broader portfolio — forty-plus products, more than five hundred people — the same discipline recovered the equivalent of roughly 8 to 10% of capacity across constrained resource pools.

Not by cutting what teams asked for. By changing its shape: when they needed it, in what size, and against which commitment.

Two smaller things from that era that I think matter more than the big numbers.

During the pandemic, launches kept going. Not because of a heroic intervention, but because of an unglamorous combination — refreshing an existing site, moving tenants between them, and going team by team to explain what capacity actually existed and when. That last part is the part people skip.

And at the end of that role, I wrote and landed the changes for the first rollout of a new tiered allocation model — one that let a parent pool absorb a service's temporary spikes instead of stranding capacity behind a hard limit.

Then something happened that I did not plan and now consider the best outcome of my career.

The quota-rebalancing work I had been doing by hand became a form, a transformation, and a chain of steps that ran weekly on its own. There was no manual work left in the role. I was moved rather than backfilled, because there was nothing left to backfill.

I did not set out to automate myself out of a job. But when Anacay tells an owner that the goal is a business that runs without them, that is not a slogan I picked up. It is the thing I actually did, to my own role, and it is the outcome I am most confident about recommending.

Making the number mean something

Most organizations cannot tell you where a number came from, and have never been asked to.

I spent years on that problem at the largest scale I have worked at: chargeback and showback reporting for a product area's infrastructure spend, so that the teams consuming it could see what they were consuming and the people funding it could see what it bought.

Alongside that, the case work behind a fifty-million-dollar refresh — measured not in a forecast but in actual equipment orders, which is a much harder and much more honest way to be judged.

And then the one I want to be accurate about, because it is the most important and it is the one I did not finish.

The hard version of this problem is resolving a single request into the services it actually consumes — so that a cost is not merely allocated but traced. I originated that model. It was funded as a priority objective, it was staffed, it stalled, it was sponsored again, and there was a focused pilot deploying when I left.

No formal forecasting was ever delivered from it. There was no ledger.

I say that plainly because the discipline the whole of Anacay rests on is being able to show where a number came from, and it would be a poor start to overstate my own. What I have is the model, the experience of getting it funded twice, and a very specific understanding of why organizations find this so hard — which is not technical. It is that spend lives with finance, outcomes live with the teams, and nobody has the authority to connect them.

Rules into practice

I was the designated product compliance lead for a scoped piece of European regulatory work. I arrived with no regulatory background at all.

That turned out to be less of a handicap than it sounds, because the job was not interpreting law. Lawyers did that. The job was translating an obligation into something an engineer could execute on a Tuesday, and then producing evidence that it had happened.

The boundary matters and I will state it plainly: designated product, engineering and programme leads retained final verification and signoff. I drove the work to readiness. I did not sign it off, and I have never signed off a regulatory position in my life.

The part I would want judged is what happened after.

The commitments moved into the agreements that were negotiated annually. Which meant that in the second year, nobody had to remember. The obligation was inside the thing everyone was already doing, and it enforced itself.

That pattern — build the mechanism, then get out of its way — is the single most repeated thing across my whole record, and it is the answer to the question people always ask about governance: how does it survive without somebody standing over it. It survives by not depending on somebody standing over it. Anything that does is not governance. It is supervision, and supervision leaves when the supervisor does.

The glue

When people ask what I do, the honest answer has always been that I am the glue.

I used to think that was a personality trait and slightly embarrassing. It is not a personality trait. It is a structural role, and it is the one that almost nothing in an organization is designed to fill.

The clearest version I worked on was a many-to-many problem: dozens of systems where every pairing needed its own custom work, which meant the cost of connecting anything grew with the square of how much you had. The answer was not to build more connections faster. It was to build one layer that everything could use, so the problem stopped multiplying.

That work addressed the access patterns it was scoped to and unblocked other teams to do their own remediation. It did not make anything compliant, and I would not claim it did — a layer removes an obstacle; it does not discharge an obligation.

I have also sat on both sides of a platform relationship at the same time — the side providing it and the side consuming it — which is a seam with a person standing in it, and I was the person.

That is the thing I now sell, and it took me twenty-five years to see it as a discipline rather than a habit. Every vendor sees their own product. Every provider sees their own perimeter. Every team sees their own system. The gap between them is where the money goes, and there is no category of company whose job it is to stand there.

Why Anacay exists

Three things I kept running into, at every scale.

Baselines were undersized or absent. Someone would propose a change, implement it, and declare it a success, and no one could say what the thing had been like before. Not through dishonesty — nobody had written it down, and by the time anyone wanted to know, it was too late to find out.

Judgment was the bottleneck, not capacity. The constraint was almost never machines or money. It was the small number of people who could look at a situation and say what mattered, and those people were always the ones with no time.

And the mechanism outlives the mandate. Anything that required me to keep pushing stopped when I stopped. Anything built into how the work already happened kept running.

Anacay is those three things, made into a practice, for businesses of ten to a hundred people.

We write down what is happening now, before anything changes. We fix one thing properly, with a person accountable for every promise it makes. Then we measure the same thing again, on the same definition, and we tell you whether it paid — including when it did not.

That is it. It is not a novel idea. It is just that almost nobody does the first and third parts, and without them the middle is an opinion with an invoice attached.

None of this is a claim that a small business needs planet-scale anything. It is the opposite. Doing this work where a mistake cost millions is what makes it obvious which parts actually matter when the budget is a few thousand — and which parts are theater.