The first 90 days
When I step into a technology function as an embedded or interim CTO, the first 90 days set the tone for everything after. Here's roughly how I spend them. It flexes to the situation, but the shape holds.
Weeks 1–2 · Listen and map
I start by understanding, not changing. I meet the team one-on-one, sit in on the existing rituals, read the codebase and the docs (and notice where docs should exist but don't), and talk to people outside engineering — sales, support, the founders — about where technology is helping and where it's hurting.
By the end of week two I have a map: how the system actually works, how the team actually works, and where the real pain is — which is often not where people first told me it was.
Weeks 3–4 · Diagnose and prioritize
I turn the map into a short, ranked list of what matters: the few things that, if fixed, unlock the most. I separate the genuine fires from the noise, and I'm explicit about what I'm not going to touch yet. Then I align with the founders or leadership so we're all pointed at the same outcomes.
Weeks 5–8 · Stabilize and ship
This is where momentum returns. I put in the delivery cadence and scope discipline, clear the highest-leverage blockers, and make sure the team ships something visible that proves things are moving. Trust is rebuilt by delivery, not by slides.
Weeks 9–12 · Build the engine
With the immediate pressure off, I focus on the things that compound: the roadmap tied to business goals, the architecture decisions that prevent the next crisis, the hiring plan, and the rituals and ownership that let the team run well without constant intervention.
The thread through all of it
From day one I'm documenting decisions and building the team's independence. Even in a long embedded engagement, I'm working toward the moment the function no longer needs me. That's not a contradiction with being useful — it's the definition of it.
This is how the ENG-EMB engagement begins. If you're scaling fast or between
technical leaders, let's talk.