Observability and one pipeline, day one.
Get the small, easy things out of the way early. Stand up the monitoring and logging. Consolidate CI/CD onto one platform everyone ships through. Neither is glamorous, and neither is optional — everything after this lands on real signals instead of guesses.
One platform is an opinion, held on purpose. Two pipeline stacks means every fix lands twice and trust lands nowhere. And the reason both go first is lead time, not urgency: a dashboard is cheap to create and slow to mean anything, because a baseline has to accumulate through it before an anomaly reads as an anomaly. The same is true of a pipeline — it earns trust one real release at a time, and no amount of design work accelerates that. Start them late and the maturity arrives after the moment you needed it.
Understand the business. Then pick the architecture.
A full pass over the infrastructure, and a longer conversation about where the product is going. The technical solution gets worked backwards from that. Never forwards from whatever happens to be installed.
This is the session the rest of the site calls the spek: the estate mapped, the thing your roadmap is blocked on named in writing, the scope fixed before anything is built. Working backwards is what keeps the architecture honest — an estate reviewed forwards from its current install base inherits every accident in it, and an architecture picked before the roadmap conversation is a bet placed before looking at the table. The productized version of the review, and the fixed-scope blocks that can follow it, are on the accelerators page.
$ ls ./accelerators →The first pass is a draft. On purpose.
Write the IaC. Pilot a few services through it. The first pass does not have to be perfect — each service that moves surfaces a pattern, and the next pass hardens it. Maturity comes from cycles, not from a bigger up-front design.
This is also why the blocks on the accelerators page exist: each one is a pattern that has already been through those cycles somewhere. What still has to mature is its fit to your estate — which is exactly why the slow foundational pieces started first. The blocks arrive hardened; the fit arrives through the pilots. Both things are true at once, and the sequence on this page is what makes them compatible instead of contradictory.
The code has to meet the platform halfway.
In between cycles, the codebase gets read for what must change to run on the new infrastructure — configuration, secrets, service discovery, the build itself. We do not write your application code. We do tell you exactly where it will fight the platform, before the weekend where that discovery is expensive.
A migration plan that has never read the code is a plan about infrastructure only, and infrastructure is the half that was already understood. The surprises live in the other half: the connection string built at compile time, the secret checked into a config file, the health check that answers 200 while the app is still warming up. Finding those on a Tuesday costs a pull request. Finding them mid-cutover costs the weekend.
This sequence has run at scale.
At a healthcare-AI company, the founder led a cloud transformation across 45 applications and machine-learning models, with more than a petabyte of data behind them. The estate moved blue/green — a parallel production estate built alongside the live one, so the move was a switch rather than a rebuild — and the first cutover succeeded. That outcome was not the weekend's doing. It was the sequence above, done in this order, before the date: the signals running for months first, the one platform everything shipped through, the drafts that had already been redrafted, the code read before it was moved.
The rest of the record reads the same way — each number fixed to the one prior role it happened in. They are a biography, not Speko engagements; they do not add up to anything, and none of them is a promise about yours.
At a Series B — the Heroku-to-AWS migration, run end to end.
In another role — 40+ ECS microservices, multi-region, zero-downtime migrations.
In another — deployment time cut 60%.
In another — cloud costs cut 30–40%.
You cannot check any of this, and the site knows it. So the next migration is written down instead as conditions you can enforce — five of them, on the cutover page, yours to fire us on.
That is the deal the whole site runs on: an unverifiable past converted into a verifiable present. A track record is a claim about what happened somewhere you were not; the five conditions are claims about what happens in your own accounts, in writing, while you watch. If the record above earns anything, it should earn the thirty minutes it takes to read them.
read: the five conditions →The delivery lead has a name. The founder has a record.
That split is deliberate, and it is the strongest honest version of each. Delivery is a discipline, and a discipline is enforced by someone with a name on it — so it is fronted by the person who holds it. Engineering is a record, and a record kept to the roles it happened in is the one part of a résumé worth interrogating — so it is fronted by nothing else. Neither card is the lesser one.
Martha Tejeda Lopez
Programme delivery across concurrent workstreams: the plan, the sequencing against one date, the executive reporting a steering committee reads without being walked through it, and the cutover discipline — the freeze, the go/no-go, the hypercare exit — held to in writing rather than in intention.
The whole of that discipline is written down on the cutover page, in the open, where a client can hold it against us. It is hers to front because she does not inherit the standard — she sets it.
read: the discipline she fronts →Fintech. Healthcare AI. POS and e-commerce. Telehealth. Game software.
No name on this card, on purpose — the sectors are the identity, and the record above is his. Years inside an AWS Premier Partner consultancy sit in that biography too. The sequence on this page is how he works; it was not designed for this site, it was written down from what already worked.
"Inside an AWS Premier Partner consultancy" is a line in a biography — a place he worked, not a badge this company holds. Speko claims no AWS partner status, here or anywhere on this site.
aws summit toronto 2022 · speaker read: the record above →