How I work with a company, start to finish

The Problem with Many Consulting Engagements

Many consulting engagements follow a familiar arc:

1. Discovery interviews (2-4 weeks)
2. Analysis and benchmarking (2-3 weeks)
3. Strategy deck
4. Final presentation
5. Consultant leaves

Weeks of work, a polished deck, and often little change.

The failure is rarely the analysis. A recommendation can be right and still not be actionable for that specific team in that specific context.

That gap - between recommendation and reality - is where value gets lost. Closing that gap is what I built my method around.

What an Operator-Consultant Actually Is

I'm a consultant who's been an operator. The distinction matters.

Some consultants train in consulting: they learn frameworks, develop deck-making skills, study case studies, and apply playbooks. Many are brilliant analysts.

Operator-consultants do consulting after spending years doing the work themselves. Their pattern recognition comes from having done the work - not just from theory.

What I bring to engagements isn't framework application. It's:

• Built the onboarding that scaled with an R&D team growing from 30 to 150 developers
• Built systems that processed 500K+ loan requests in regulated environments
• Delivered products serving 100K+ customers
• Hands-on development - full-stack developer, and I write the code for my own apps and websites
• Decision science sharpened through a decade of tech and product roles under real pressure, and at the poker table
• Cross-functional fluency - I've been the developer, the system analyst, the product manager, the technical program manager

This means when I diagnose your organization, I recognize patterns from having lived inside them. When I recommend changes, I know what they'll cost to implement because I've implemented them. When I stay through delivery, I can actually do the work - not just supervise it.

The Four-Phase Method

Phase 1: Diagnose Reality (Not Org Chart)

Many assessments start with the org chart. Mine starts with reality.

The org chart tells you how decisions are supposed to be made. Reality tells you how they actually are. Those are usually different - and the difference is where the dysfunction lives.

What I look for:

• Who really makes which decisions (regardless of titles)
• Where work piles up vs. flows smoothly
• Which "processes" are documentation that nobody follows
• Which informal workarounds are actually keeping things running
• Where culture cracks under pressure (not in good times)
• Which people are quietly load-bearing (and what happens when they leave)

The output isn't a 100-page report. It's a sharp diagnosis of what's actually happening, what will break under growth, and what's hiding in plain sight.

Phase 2: Design Honestly

Best-practice recommendations are a fine starting point. Mine start with what will actually work given your constraints.

I design with three questions:

1. What will the team actually adopt? If your team won't run it, the design doesn't matter.
2. What's the cost in attention? Every new process taxes the team. Is the value worth it?
3. What can be removed? Most organizational improvements come from subtraction, not addition.

The output of this phase is a prioritized action plan - what to do first, what to skip, what to consider later. Each recommendation has:

• The problem it solves
• The expected outcome
• The cost (time, money, attention)
• The risks if poorly executed
• Who owns it

No vague "improve communication" recommendations. Specific, attributable, measurable changes.

Phase 3: Deliver Embedded

This is the phase that sets my method apart.

I don't drop a strategy deck and disappear. I stay through implementation - acting as an embedded product or project manager, coach, or program lead, depending on what the engagement needs.

What "embedded" actually looks like:

• Joining your team's standups, planning meetings, or leadership syncs
• Owning specific workstreams (not just advising on them)
• Coaching managers through hard conversations
• Building documentation, frameworks, and tooling that makes the change stick
• Working alongside engineering, product, and operations as needed

This phase runs from a few weeks for a defined project to a 3-6 month interim for a defined transition. The shape adjusts to what the project needs - not an open-ended retainer.

Phase 4: Transfer Knowledge

The engagement ends when your team doesn't need me anymore.

I am paid per engagement, and the engagement is designed to end.

What I leave behind:

• Documentation of new processes, decisions, and frameworks
• Trained team members who can run the new systems
• Decision criteria so future leaders make consistent calls
• A clear "next chapter" plan - what to monitor, when to revisit

If I've done my job, you'll come back to me for the next challenge - not because you still need me for this one.

Why Cross-Disciplinary Thinking Matters

Many practices specialize narrowly: strategy, HR, tech architecture or finance.

I'm deliberately cross-disciplinary - and I think that's why my work compounds:

Tech leadership

Lets me diagnose architecture, processes, and engineering culture. As a full-stack developer I can read your codebase well enough to tell whether it is a debt problem or a culture problem.

Decision science (sharpened under real pressure)

Lets me see decision quality vs. outcome quality. I look at the decision-making process that produces consistent outcomes over time, not only at the outcomes themselves.

AI (hands-on practitioner)

Lets me give honest AI recommendations. I use AI tools daily in my own work and hold an M.Sc in AI, so I can tell which use cases deliver value and which are demos.

Coaching and communication (NVC, behavioral frameworks)

Lets me handle the human side of change. Strategy often fails not because it is wrong but because people resist it, and I work on that resistance directly.

System analysis

Lets me see organizations as systems with feedback loops, not just charts of people. The best diagnoses come from seeing the system, not just the symptoms.

The combination means I can address the technical, strategic, and human dimensions of change simultaneously. I think organizational problems are always all three at once.

What I Don't Do

Honesty about constraints:

• I don't do enterprise transformation. If you're a 10,000-person org needing a 5-year change program, I'm not your fit. I work best with growing companies and established organizations needing focused transitions.
• I don't do pure strategy. If you want a deck and no implementation help, hire a Big Four firm. I work where strategy meets execution.
• I don't pretend to know everything. If a problem is outside my expertise, I'll tell you and recommend someone better. I'd rather lose an engagement than over-promise.
• I don't do open-ended retainers. Engagements have clear scopes, milestones, and exit points. The goal is to make myself unnecessary.

The Single Question I Ask Every Prospect

Before I take an engagement, I ask one question:

"If we don't fix this, what's it costing you in 12 months?"

If they can answer specifically - lost revenue, lost talent, slower decisions, missed market window - we have a real engagement.

If they can't answer specifically, the problem isn't urgent enough yet, and it is better to come back when the cost becomes clear.

The most successful engagements are the ones where the cost of inaction is concrete and the team is ready to actually change. That readiness is what makes the work stick.

Who This Approach Is For

The operator-consultant approach fits when:

• You need actual change, not just analysis
• You value being told the truth over being told what you want to hear
• You want a consultant who can do the work, not just advise on it
• You want clear scope and exit criteria, not endless retainers
• You're growing, transitioning, or scaling and the stakes are real

It doesn't fit when:

• You need brand validation more than results (hire a name-brand firm)
• You want recommendations you don't have to implement
• You're looking for the cheapest possible option
• Your organization isn't actually ready to change

That clarity helps both sides. Honesty about fit is the first deliverable.

Frequently Asked Questions

How is the operator-consultant approach different from a fractional executive?

Overlap exists, but it's different. A fractional executive owns a function (fractional CTO, fractional CMO). I own a problem or transition. Sometimes that means PM-style ownership, sometimes coaching, sometimes program management - whatever the project needs. More flexible than a fractional role, more embedded than traditional consulting.

How long do typical engagements last?

The Scale Readiness Assessment (diagnosis plus a prioritized action plan) runs 6 weeks. Embedded project work is scoped to a defined deliverable and typically takes a few weeks. A full-time interim covers a defined transition of 3-6 months. I scope each engagement together with the client, by budget and timeline.

Why should we hire you over a name-brand firm?

If you need brand validation for a board, hire a name-brand firm. If you need actual change, hire someone who's done the work. Different problems, different solutions. I'm honest about which you need.

What if you're wrong about the diagnosis?

I document my reasoning so you can challenge it. If a recommendation isn't working in delivery, we adjust - not abandon. The whole point of staying embedded is catching mistakes early. Real-world feedback beats theoretical correctness every time.

About the author: May Mor is a developer, product manager, and organizational consultant with an M.Sc in AI and 10+ years in tech and product roles across fintech, digital banking and adtech. She runs Scale with May: interim and fractional product and program management for tech companies, and operational due diligence for investors.