One of my main inspiration these last few years, especially for my consultancy, is Nikhil Suresh, aka Ludic. Last week, I spoke to him to ask him about his experience setting up Hermit Tech, consulting practices and pitfalls, and funny stories. I got permission to share most of my notes (except the parts that might be legally dicey) here.

This reflects my own notes, paraphrasing and moving things around in order to make more sense.

What prominent consulting advice should I take or not take?

Charge for Initial Consultation / No Quick Calls

At Hermit, we don't charge retroactively, don't charge at all for the initial assessment.

Charging up front has a couple effects: it can filter out people who can't afford you at all or have the ability to hire you, which can be good. But you're just starting out, with zero leads or clients, so the value of filtering people out at this stage is very low.

Right now, it's counterproductive, like hitting a paywall when reading an article. You don't want that to happen with cold inbound leads.

Hot leads may provide someone who could be a client for multiple years, you don't want the equivalent of them getting distracted while looking for their wallet and forgetting. This is bad advice in a unique way, I almost can't imagine a situation where it isn't bad.

Don't Call Yourself a Programmer

This is a deep topic, I can't give it a comprehensive treatment here, but the magic word in sales and marketing is positioning. How have you framed yourself to the client? The average salesperson is as bad at this as the average programmer. It's like engineering without a stack trace.

'Programmer' is a bad thing to call yourself because it seems descriptive but actually says nothing.

Even with my industry experience, knowing you're a programmer gives me almost no information about what I could hire you for.

Even knowing more about your actual background (data scientist specializing in Python=Rust integration for high-performance software) that still tells me very little. Imagine how that goes for someone without technical experience!

Second, and more insidious, if you use a name where the client thinks they understnad what that means, you're immediately commodified. They'll think they know the market rate for you, you'll lose status, lose the ability to bill them, and they lose the ability to to use you holistically.

Best approach: don't call yourself anything! Never even let the question come up. At best, you're a consultant, but better, you're someone who solves a certain class of business problem.

No Meetings Without Agendas

Agree to first approximation, but the principle is worth reiterating:

A close friend, Jesse Alford, is super switched-on. The only reason he's not mentioned on the blog more often is that if I mentioned him every time, it would be in every single post.

The most valuable thing I've learned from him is, when you implement any kind of rule in a system it's going to have a set of complex interactions with everything else. There's always an exception.

'Always have agendas' is a good starting point, but think about the pros and cons. And then carry that forward to everything.

In this case, always requiring agendas could put implicit pressure on everyone in the meeting to read them, which can make people feel bad or inadequate going in if the didn't have the time, especially for meetings with long agendas and lots of participants.

General Practices

We use XP (eXtreme Programming) and TDD (Test-Driven Development), but most all of our other distinct practices are taken from improv theater and psychotherapy. I'd have to think how to articulate what they do. It's a lot of checking in and making sure people are fresh. People can clock out at 1pm. If anyone is fatigued that's an issue, go play games until you're fresh again. If someone's rushed or can't follow along, slow down.

It helps to have a team with this kind of thing, solo consulting has a harder time. Having one or two people around to help keep on track is great, you avoid falling down silly rabbit holes.

Other Advice

The best advice I'll give proactively: do not work for any client that asks for a CV.

At that point, they've conceptualized you as a warm body to be slotted into an industrial process. The moment the CV comes out, they're going to approach it as an employment arrangement, not as a consultation.

When that happens, you don't want to end the call rudely, but it's worth wrapping it up at that point, unless you're happy to be an employee with them specifically.

A story about Ash Lally, Infamous Business Jaguar

(On this topic, I mentioned one of Nikhil's most enigmatic co-workers, Ash Lally the Infamous Business Jaguar, and Nikhil recalled a recent story about him)

Nikhil got an inbound email from someone who said they used to work with Ash years earlier, and were interested in getting Ash to consult on a current problem.

Nikhil called Ash, mentioned the guy's name, and got the response "Oh yeah, John Whatever. In 2016 I gave him food poisoning with homemade 4Loko."

Ash then hung up, leaving Nikhil baffled and asking "How do I convert that into a sale, Ash???"

Comments on Pricing and Negotiation

Does Hermit Still Primarily Do Fixed-Price, Fixed-Length Contracts?

Yes, it's still almost entirely FPFL. We did a couple of day rate contracts at the end of last year, hated them, and no longer do them. The moment you charge hourly or daily you become an employee. Moreover, the incentives are terrible, either you do a bad job to milk the contract or you're hurting yourself with bad working hours.

An example of a standard contract: for such-and-such fee we'll give you 20 hours of work a month, make sure your dashboards refresh every day, and you get infinite crisis response from us. The effective rate is roughly $400/hour, and would be much lower if we had a lot of outages. Most clients aren't even that well off, but the rate is still attainable if you're careful with what you sell.

How Has The FPFL Strategy Turned Out

It's turned out good. In the last 4 months, I've sold probably A$80k of fixed-price consultation or dashboard development, for less than 100 hours so in the range of $400-800/hour.

Some caveats on maintenance: you want to work with systems with a relatively low time-sensitivity to outages. The standard story here is Patrick Mackenzie's Appointment Reminder, which appeared not very time-sensitive until it turned out that a hospital was using it to remind sick children to take their medication. All of a sudden, any disruption to that system has a body count.

Hermit mostly does dashboarding and ETL, so if the CEO's finances are out of date by 24hrs, that's not a crisis, nobody's going to die.

This doesn't mean you don't want to work on important things. You always want to work on important things! Just not something that makes you operate in crisis mode. Engineer the business to minimize time spent on call.

What 'knobs' do you leave open for negotiation?

We rarely negotiate hourly rates over a period. Your client shouldn't be thinking about the hours at all. The moment they think about hours instead of outcomes, it's a bad engagement.

It's unfortunately common. A lot of execs just aren't that switched-on, and they treat negotiation as a game they want to win, where winning means getting the most people and the most hours for the least money. You will always lose that game to 50 guys in India (and in the long run the executive loses -Ed)

Clients who are switched on just want results, and don't care about the effective hourly rate. Our effective rate a few months ago was A$1000/hour, that was on a recruiting job. The client was happy, because we successfully placed some good engineers!

But programmers have not solved this pathology. In engineering, someone who has no idea how many hours a thing will take still wants to know the hourly rate.

Some knobs that are open:

Engagement Length

You want to set up some recurring revenue, and engagements with fairly long engagement periods, with lower intensity, are useful for that.

For example, an example engagement with a healthcare facility in Melbourne: they needed an analytics team to help them fix their current system, and Hermit wanted to sign them up for a year-long contract. They didn't need all that much work done, so they cited A$10k/month. It's cheaper than hiring an analyst, gets you roughly 20 hours of work instead of 160, but those 20 hours are split across multiple people with various specialties.

But the client was wary about signing up for a year-long contract, so instead they adjusted to a 2-month contract at $15k/month, and offered 'pick a dashboard and we will gurantee its uptime, regardless of how much work it ends up being, and if we fail you get all the money back'

It wound up taking 30 hours. That dashboard was the single most important one, so they client was happy.

Long story short, make reasonable concessions to fit client needs, with contract length and weekly/monthly rate as standard knobs (though effective hourly rate is not a knob, the client shouldn't be thinking about it!).

Never Discount Your Rate

Semi-agree: never discount without getting something you're happy with in return.

You never want to just give people 20% off.

For a non-profit or other clients that can't afford regular prices, you can see what their needs and finances are, if you like them, etc, and see if their needs can be filled with fewer hours of work/month.

The Two Kinds of Sales Obstacles

First are the people who are scared about spending a lot of money on stuff they don't understand. You need to have lots of patience for these people, most of your clients will start out like this.

Second are the CEOs who just want to win the negotiation game. Never work with them, fire them as clients immediately. If you don't, they'll be rude and pushy for the entire engagement and have a tendency to criticize from a position of ignorance.

If you can manage it, don't get involved with anyone you don't like talking to.

Recently, Hermit turned down a deal with a startup in Queensland because they got nervous every time the CEO talked. It wasn't even that he was deliberately antagonistic, but he'd say things that put everyone on edge and then turned out to be attempts at jokes. Not worth it.

Pricing Trends

All pricing numbers are made up, pick the one you're happy with (cf Secrets of Consulting by Jerry Weinberg).

Pick a number that if the client rejects, you couldn't have gone lower so it's fine, and if they say yes, you're not kicking yourself afterwards.

Don't price based on how much the client has, but rather on how soul-draining the job will be. At a certain fintech startup, they charged out the ass because they hated working there and everyone was miserable.

The size of Hermit's clients has actually gone down over time, as they've accumulated long-term clients and gotten better at closing new deals, so they don't need to charge as much.

Hermit's one-sided cancellation policy

(On earlier versions of their website, Hermit advertised a one-sided cancellation policy, get a full refund on remaining time with a week's notice)

We no longer have this policy!

Not because it was getting misused or we worried about that, but because the goal of the policy was to make people comfortable, and it was making people uncomfortable instead!

Why, because the client started wondering if Hermit was expecting to fail?

No, not even that. Just because people like signing familiar deals, and every unusual clause causes anxiety. Hermit evolved their standard offer to look more and more like what is standard on the market.

To a first approximation, the client wants a dollar value and to not have one more thing to think about. Anything on top of that is additional complexity and gives the client anxiety.

Hermit made their standard deal objectively worse for the client, and it increased close rate by a lot.

That's not to say people don't want good deals, they do, but not in a way that's novel. They don't want to think about it.

Finding and Filtering Clients

Working with Startups

(Nikhil previously stated that Hermit no longer works with startups, despite initially working with them almost exclusively)

We don't work with startups anymore. Not as a matter of principle, but we dislike them as Bayesians.

Long Tangent on the Iniquity of Startup Founders

Most founders are degenerates, very unethical people on average, very willing to lie, dysregulated (which can be even worse), their affairs aren't in order, they can't tell you how much money they have on hand (or will lie about it) their product frequently doesn't work, they ask you to lie to their clients about that, or to build a 'proof of concept' system so they can hand it to their internal engineers (read: React guy) to productionize (badly).

We'd still talk to a startup that reached out to us, but we don't canvas them as part of our sales pipeline.

It's odd that these people get venerated in the tech space, when they're overwhelmingly bad people, and often broke.

Drew McMannis, whose team works with a lot of startups, says they lie all the time just to see if you'll cut your price in half.

Cannot emphasize enough how bad startup founders are on average, barely better than the crypto space.

Their success rate is so low that you're unlikely to form any kind of long-term relationship, the company will explode and then you no longer have a customer.

By contrast government clients have all their own problems, but we never need to wrestle them over payment.

If I work with Deloitte (a company I hate) they're still going to pay me, but a startup? You need to take your payment all up front.

But at the same time, startups are much more likely to need bespoke engineering like the kind you can provide, though they'd generally prefer to hire you as a full-time employee for peanuts and promises instead.

Complexity and Competence

(talking about the business merits of software for high-throughput JSON stream querying)

High-performance software is not a typical market. 99% of businesses do not need it.

A client who needs to query json at high velocity is super niche. Maybe some big orgs or AI companies since chatbots are just firing huge amounts of json.

Most businesses need an application that reasonably non-technical people can type into, and then store the data in clear ways.

None of my clients would use something like that. If they couldn't do it before and their business exists, they don't need it, QED.

One of Hermit's clients manages $50M, with $8M in profit per year, and all of their data procesing is done in hours. All their medical appointments, fairly high-frequency data, their ETL takes like 7 seconds, it's just dumping PostGres to CSV.

Their biggest table is like 600MB uncompressed.

Even if they were a billion-dollar business, that wouldn't really change.

It's very hard for normal businesses to get into the kinds of problems solved by this tool, very niche, specialized parts of industry. Might be of interest to, like Netflix, but even, say, a major bank wouldn't need to read data that quickly.

Recommended talking to Adolgo Ogachavia, who has experience in low-latency Rust programming and has worked with space technologists before.

On Clients

Software complexity is a trap that gets worse as the engineer gets more sophisticated, because you're always tempted to use the most complex thing you can do.

The vast majority of clients absolutely, positively, DO NOT need the most complex thing you specifically can do.

(the most complex thing I specifically can do is probably writing a custom SIMD-accelerated query framework for your boutique data serialization format, a service which approximately nobody needs, so this checks out -Ed)

Most people don't know anything about computers. They don't know what a SLA (service-level agreement) is.

I cannot emphasize enough how many people who pay us struggle with Excel and think Word is a technical skill worth putting on a CV.

Tech-wise, the vast majority of people, including the majority of clients in the market for tech consulting, are effectively your grandparents, so think about what your grandparents can handle and calibrate from there.

They don't need Python-Rust integration. The amount of people in the market for intense, difficult engineering is quite low. Most business value is still low-hanging fruit.

On Other Consultants

Everest Engineering does good work. They read my blog, they're the only good consultancy.

Consultants I didn't meet through the blog are morons. They can't change anything architecturally, they mostly just know how to click buttoms (no engineers need be involved), and they fail at even basic tasks, like provisioning the computing you need for the year and claiming the free 20% discount.

[ REDACTED: Absurd story about a certain very well-known big consulting firm utterly screwing up ]

It's not even that the [REDACTED] team was even that bad! It just makes smart people do stupid things.

When I go into a new engagement where another consultancy was previously working, I have a set of keywords I look for. One of them is 'serverless'. To a first approximation, it means someone fucked up and massive saving are available.

Jordan Anderson

(by way of comparison, Nikhil told some stories about his co-director, Jordan Anderson)

Jordan started out as a physiotherapist, we met at an ML conference in 2019.

He had a family, a second kid on the way, and wanted to make more money.

Nikhil todl him that if he learns SQL, he'll probably be able to make way more money. In three months, he worked through a SQL textbook and switched from his physio job to engineering, going from A$90k/year to 140k.

On his first day he was extremely nervous, worried that the people around him would find out any second he was a fraud, that he's never done any of this before.

Three months after that, he was the best engineer there, was offered and accepted a principal analyst role at A$160k.

Later on, he decided he could probably leave and instead do consulting for A$240k/year. So he went and did that.

The big innovation he brought to his first company was teaching the six-strong engineering team that Git existed. In 2022. Their prior approach was passing around google drive folders with the dates on them. This was at Gold Coast Health, one of the largest hospitals in Australia.

Jordan wasn't aware of this kind of dysfunction when he was studying, it would have seemed too crazy. But even today, there remain plenty of teams that do not know what Git is, and don't use any source control at all. They may not even see themselves as software teams.

By that same token, most engineers don't know what Rust is... at all. Period.

At another contractor, a fintech company that was generally quite good, they were trying to pip install snowflake-connector-python. But the new version of the Python cryptography library it uses builds with Rust, which they didn't have access to on the corporate network, so they were sitting around looking at the build failure wondering 'what the hell is Rust!?'

And this is, on the balance, a good team, not a bad one!

Book Recommendations

• Secrets of Consulting by Jerry Weinberg
• • Then another Weinberg book, Becoming a Technical Leader

• Sales Pitch by April Dunford

• Deep Work by Cal Newport

• Turn The Ship Around! by L. David Marquet

• The Goal by Eliyahu Goldratt

• • It's a narrative about a failing factory. The writer is very smart, but Nikhil didn't like it much on the first read, on the second read with more experience, he concluded this was more like how you should fix most businesses
• • The sequel isn't as good, but also worth reading. There's a good moment in the goal where they need to do something with a machine requiring someone to work lunch, and they have union problems. Nikhil doesn't specify how they solved that problem, but said he used that as an inspiration for a standard party trick he pulls on engagements to get people admin access on their corporate laptops: Just go ask security and they usually shrug and let them do it (???).
• • I asked if the sequel was The Phoenix Project, which I heard Nikhil mention before:
• • • (laughs) No, Phoenix Project is a bad ripoff of The Goal set in a software company, it mostly doesn't make sense. But there is a very funny section in the audio version of both books where, when the protagonist finally fixes his struggling marital relationship (as a consequence of fixing the business problem, fisher-king style -Ed) the audiobook starts playing smooth saxophone. It's the only musical cue in either book, and it makes you feel like you're having a stroke.
• • Nikhil half-facetiously recommends reading the Phoenix Project first, to better appreciate how bad it is compared to The Goal