Approach

How I Operate

A Structured 90-Day Framework

When I come into a new environment, the instinct is to show value fast. I get that. But the fastest way to create more problems is to start changing things before you understand what you’re actually dealing with.

My approach follows three phases: understand, align, execute. The timeline is roughly 90 days but the phases matter more than the calendar.

01

Phase 1 · Days 0–30

Understand

The first 30 days are about building an accurate picture. I'm not here to validate assumptions, including my own.

I focus on:

  • Current architecture and infrastructure
  • Technical debt and operational risk
  • Delivery bottlenecks
  • Documentation gaps
  • Team friction points

At the leadership level, I clarify:

  • Revenue targets
  • Product or service roadmap
  • 6–12 month priorities
  • Where technology is enabling or blocking growth

The goal is simple: establish an accurate picture of reality before making changes.

02

Phase 2 · Days 30–60

Align

Once I know what's real, days 30 to 60 are about getting everyone pointed in the same direction.

I work with the team to:

  • Identify practical quick wins
  • Clarify technical priorities
  • Align engineering work with business outcomes
  • Evaluate automation, AI, or analytics opportunities
  • Surface roadmap trade-offs

This is collaborative, not imposed. Clarity builds confidence. Alignment builds velocity.

03

Phase 3 · Days 60–90

Execute

Structure without flexibility is just bureaucracy. Days 60 to 90 are about putting the right rails in place so the team can move fast without things falling apart.

I establish:

  • A prioritized and visible roadmap
  • Clear ownership across initiatives
  • Delivery cadence and communication standards
  • Practical governance without bureaucracy

By day 90, leadership has:

  • A clear view of technical health
  • A roadmap aligned to business goals
  • Reduced reactive firefighting
  • A team operating with structure

What This Means

Most technical problems are not technical problems. They’re communication problems, prioritization problems, or trust problems that show up as broken systems and missed deadlines.

My job is to fix the actual problem, not just the symptom. That usually means slowing down before speeding up, being honest about what’s working and what isn’t, and making sure leadership has a clear picture of reality rather than what they want to hear.

That’s not always comfortable. But it’s what actually moves things forward.