Consultants should be a lot more expensive

If you're not spending at least $1000 per hour on a consultant you just don't want it enough
Consultants should be a lot more expensive

There’s a common misconception in the industry that consultants are expensive. This is, of course, false.

Consultants are not expensive. Not nearly expensive enough.

You see, the goal of a consultant is to be a 10x engineer. Not in the sense of writing ten times more code, or moving ten times as many Jira tickets.

No, the real goal is to make your team feel ten times more productive simply by being around. To dramatically whoosh into a room, say something profound, yet slightly confusing, then disappear into the mist before anyone asks a follow-up question.

This kind of talent isn’t just valuable — it’s transcendent. Who else, 5 minutes into a site visit, is going to look you square in the eye and say, “All of this is stupid.”?


Consultants shouldn’t be hired to do work

Let’s be clear: consultants are not supposed to do work. That’s for employees. The whole point of hiring a consultant is that your team is too busy, too entrenched, or too misaligned to solve their own problems — or worse, they don’t even recognize their own problems.

Consultants are the Schrödinger’s cat of value delivery: they simultaneously do everything and nothing. And the second you try to observe it, the spell breaks.


Consulting should feel sacred

Every delivery from a consultant should be accompanied by a Gregorian chant and at least three ceremonial PowerPoint transitions. You shouldn’t receive a deliverable. You should witness it.

Your team should feel the need to avert their eyes.


Consultants should be trained like spies

Consultants should be trained in evasion, deception, and high-speed exits.

They should be able to:

  • Disappear from meetings whilst “taking things offline” leaving behind only action items
  • Maintain an aura of authority while saying absolutely nothing specific
  • Use phrases like “industry best practice”, “synergies” or “strategic alignment” as smokescreens to commitments

Of course, consultants should be paid like world-class athletes. — because they are elite performers. Their contracts should require biometric checks, retina scans, and at least one ceremonial sacrifice to the business gods before engagement.


You shouldn’t be able to summon a consultant

Access should be restricted. Consultants should be impossible to contact unless you know the correct public payphone to leave the sacrificial whiteboard marker.

You don’t just email a consultant. You summon them. You schedule a consultation via messenger pigeon or whisper it into a conch shell during the new moon.

Once a consultant is engaged, their time should be tracked in 30-second increments and invoiced in carbon credits. Any cancellation within a 48-hour window resulting in a mandatory LinkedIn endorsement.


Everything should feel bespoke

Consultants shouldn’t do slide decks. They should deliver artefacts — hand-stitched, artisanal strategies embedded in mahogany cases, with a proprietary font that costs $800 per vowel.

Your team should look at their work and think: “Wow. We can never afford this again.

Because that’s the point.

Consultants exist not to do what you can do, but to remind you of what you could be — in a vague, abstract way that cannot be implemented without another consultant.

Older post

2025-03-30

Hire More Off-Shore Teams

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.