Technical
The First Thirty Days of a Consulting Engagement
The first thirty days of a consulting engagement set the trajectory for the rest. Do them well and the client trusts you to ship hard things. Do them poorly and you spend the rest of the engagement fighting for credibility. Here is my playbook for the first month.
Week 1: Listen
I do not write code in week 1. I listen.
- Who are the key stakeholders, and what do they each want?
- What does 'success' mean, measurably?
- What has been tried already, and why did it not work?
- What are the sacred cows I should not touch?
- What is the current tech stack, warts and all?
I schedule one-on-ones with every person whose work my project will affect. Thirty minutes each. Their context saves me weeks.
Week 1 Artifact: The Context Document
At the end of week 1, I write a 2-3 page document capturing what I heard. I share it with the client. 'Here is what I heard. Did I get it right?' This catches misunderstandings while they are still cheap to fix.
Week 2: Assess
I read the codebase, the infrastructure, the documentation (what exists of it). I do not refactor anything. I note everything.
- What works? Keep it.
- What is broken? Understand why.
- What is risky? Flag it in the report.
- What is irrelevant? Ignore it.
The goal is to form a map of the territory. Not to redraw the territory yet.
Week 2 Artifact: The Assessment Report
I deliver a written assessment. Strengths, weaknesses, risks, opportunities. This is not a pitch for more work. It is an honest read on the state of things.
The clients who come from cheap contractors are shocked that I do not try to convince them to tear everything down and rebuild. I tell them which 20% of their system needs attention and which 80% is fine. That honesty buys trust I will need later.
Week 3: Propose
Now I propose a plan. Based on the context and assessment, here is what I think we should do in the next 30, 60, 90 days. Measurable outcomes, not vague intentions.
I keep proposals short. One page, three initiatives, each with a goal and a deadline. Not 20 pages of strategic waffle. The client can decide in ten minutes whether to approve.
Week 4: Deliver Something Small
Before I take on the big initiatives, I ship something small but visible. A broken page fixed, a slow query sped up, a report automated. Something the team will see on Monday and think 'the new person is useful.'
That small win buys me the runway for the larger work. Without it, every week of planning makes the client wonder what they are paying for.
What I Avoid in the First 30 Days
- Criticizing the previous team publicly
- Rewriting more than necessary to fix issues
- Introducing new tools the team does not know
- Making decisions that are hard to reverse
Every one of these is a credibility killer early. I save them for month three when I have earned the trust to push back.
The Pattern
Listen, Assess, Propose, Deliver. Each week has one focus. Each focus produces one artifact. The artifacts accumulate into a clear story: 'here is what we found, here is what we recommend, here is what we already shipped.'
That story is what I email to the client at day 30 as a status update. It is the document that gets the engagement extended, every single time.
RELATED READING
The Consulting Shift I Am Making In Year Two
After a year of writing and building, my consulting practice is changing shape. Shorter engagements. Sharper outcomes.
ReadThe Frontend Shift: Shipping Less JavaScript In Year Two
A year ago I reached for Next.js for everything. This year I often reach for nothing.
ReadThe Serverless Lesson I Would Write On A Sticky Note
After a year of shipping serverless projects, one rule explains most of the wins and all of the losses.
Read