Everything else in my life had fallen away and I needed to fill my schedule, so I signed up for a class. By the end of the first day I was hooked.
My teacher stood almost seven feet tall, knew the material completely, and was extremely likeable. His name was Fred. After a single semester I knew what I was going to do with the rest of my life.
Near the end of that semester Fred handed me my first consulting job.
What did Richard Lowe’s first $600 consulting job involve?
Fixing programs on a TRS-80, which at the time was as modern a machine as you could buy. Sixteen kilobytes of memory and two five and a quarter inch floppy drives.
The client offered six hundred dollars. I had my eye on the six hundred dollars.
What I didn’t have was any idea whether I could fix the programs. I found that out later, once I was in too deep to withdraw gracefully. I was overconfident, underprepared and completely naive, and I’d like to be able to say I have since met many consultants who started better, but I haven’t.
What do first-time consultants get wrong?
Looking back, everything it was possible to get wrong.
I didn’t validate my assumptions. I accepted the client’s description of the problem, the state of the code and the amount of work involved, and every one of those turned out to be optimistic.
An hour of questions at the start would have uncovered it. I didn’t ask, because asking felt like admitting I might not be able to do it.
I didn’t write a statement of work. Nothing described what I was delivering, by when, for how much, or what was outside the job. That meant the project was whatever the client believed it was, and their belief could change. And I didn’t know whether I could do the work. That’s the one that matters most, and it’s the one that felt least important at the time, because six hundred dollars was in front of me.
| Mistake | What happened on the TRS-80 job | What to do instead |
|---|---|---|
| Not validating assumptions | Accepted the client’s account of the problem, code and workload; all were optimistic | Ask the awkward questions before you agree on a price |
| No statement of work | Nothing set the deliverable, deadline, price or exclusions | Write down what you’re delivering; two pages is plenty |
| Not knowing if he could do it | No plan for discovering what he didn’t know | Take stretch work only if you can name how you’d learn it |
| Pricing before understanding | Took the job with his eye on the fee | Price only after understanding the work |
Why is validating assumptions the one that catches people?
Because it feels like distrust when it’s protection for both sides.
New consultants avoid asking hard questions at the start because they’re worried about seeming difficult, or slow, or insufficiently confident. So they take the description as given and start work. Then on day three the thing that was supposed to be simple turns out to sit on top of something nobody mentioned, and now the timeline is fiction and somebody has to have an uncomfortable conversation anyway.
The questions were always going to get asked. The only choice is whether you ask them before the price is set or after.
What is a statement of work for?
It gives you something to point at. The value is that when the client asks for something outside the agreement, there’s a document, and the conversation becomes ordinary. That’s a change, yes, here’s what it would take. Without one, the same request is a test of your willingness to be accommodating, and you’ll fail that test repeatedly until the job is unprofitable.
I had no plan for discovering what I didn’t know, and that’s the difference between a stretch and a gamble.
I’ve watched consultants with decades of experience lose money on jobs for exactly this reason. They weren’t bad at the work. There was no boundary, and every reasonable-sounding addition made the project slightly worse until it was a disaster.
Should you take work you cannot do?
There’s a version of this that builds careers and a version that damages them, and they look similar from outside. Stretching into adjacent work is normal and necessary. Nobody’s second job is identical to their first. The test I use now is whether I can describe, concretely, how I’d find out what I don’t know. If I can name the documentation, the person to ask, or the way to work it out, the gap is bridgeable.
On the TRS-80 job I couldn’t have answered that. I had no plan for discovering what I didn’t know, and that’s the difference between a stretch and a gamble. It worked out, more or less, through the sort of effort that’s not repeatable and shouldn’t be a business model.
The book on this: Build a Profitable Consulting Practice is 30 chapters on the commercial half of consulting: statements of work, pricing, the clients to refuse, and forty years of getting it wrong first.
My take
Before you take your first consulting job, write a statement of work. Without one, every reasonable-sounding request becomes a test of how accommodating you are, and you’ll fail it until the job loses money. Validate your assumptions before you agree to anything. Stretch into adjacent work if you can say how you’d learn what you don’t know. If you can’t name the documentation or the person to ask, it’s a gamble. Don’t take it.
What should you ask before taking your first consulting job?
Ask the awkward questions before you agree on a price. They don’t make you look weak, and they’re the only thing standing between you and a job that costs more than it pays.
Write down what you’re delivering. Two pages is plenty. The point is having something to point at.
Know how you’d learn what you don’t know. If you can’t describe that, you’re not stretching, you’re hoping.
Price only after understanding the work. A number agreed in ignorance is a number you’ll regret for the whole project.
Tell them early when it goes wrong. The problem rarely destroys the relationship. Finding out late always does.
I still think about Fred handing me that job. He gave me a start that I was entirely unready for, and I’ve come to think that was the correct thing to do, because there’s no version of readiness that arrives before the first client. What you can control is how much of the damage is avoidable, and forty years on, most of it still is.
Expertise doesn’t pay the bills, contracts do. Build a Profitable Consulting Practice covers the part of consulting nobody teaches, starting with that first six hundred dollar job.
Frequently Asked Questions
- TRS-80, Wikipedia
- Tandy TRS-80 Model I, Carleton University School of Computer Science
