You Don't Need to Hire Yet

Marcus left Accenture in the spring of 2023. Fifteen years in data engineering, a senior manager title, a client list that included three of the largest banks in Germany. Within four months he had two anchor clients and a third in conversation. By the end of the year he was doing €420,000 in revenue, working by himself out of a home office in Amsterdam, fully booked through Q1 of the following year.

He called me in February.

"I need to hire someone," he said. "I'm turning down work. I've had to push back timelines on two active engagements. I have a prospect who wants to start in April and I have nowhere to put them. The answer is obviously to bring someone in."

I asked him one question: where would his April prospect come from if it fell through?

There was a pause. "From the network, I guess. Same place everyone comes from."

"And if the next two people in the network aren't ready to buy for another six months?"

Another pause. Longer this time.

Marcus's situation is not unusual. It's probably the most common configuration I see among tech boutique founders at early traction: the work is real, the revenue is there, the utilisation is genuine, and the instinct to hire is completely understandable.

But the instinct is pointing at the wrong problem. The constraint isn't capacity. It's architecture.

‍

Why It Feels Like A Capacity Problem

When you're fully booked, the most natural read of your situation is: I need more hands.

It's logical. You're turning down work. Revenue is visible. There's a market for what you do. Hiring feels like the obvious path from here to there - from constrained to unconstrained, from one-person practice to firm. You've earned the right to grow. The clients are there. All you need is someone to help you serve them.

This reading is wrong. Not because growth is the wrong ambition, but because hiring is not the right mechanism for the constraint you actually have.

The constraint isn't that you can't do more work. The constraint is that you don't yet have a system that can generate enough work to keep a second person reliably utilized. Those are different problems. The first feels urgent, since you can see the work you're turning down. The second is structural, slightly abstract, and easy to wave away when you're busy.

But being busy is temporary, while lacking structure is permanent.

Here's what I mean. Marcus's revenue came from three sources: a client from his Accenture network who had followed him into private equity, a former colleague who had started a data team at a mid-market fintech and reached out directly, and a referral from someone he'd helped with a freelance project two years earlier. All three came through existing relationships. None of them came through a system.

That's not a criticism of how he got here. Relationship-led growth (or what I call network activation) is how almost every boutique at his stage gets here. Consulting Success data shows that more than 60% of consultants' revenue comes via referral. That's normal. It's also a ceiling. And the ceiling shows up the moment you hire.

A hire is a fixed cost. Your pipeline is not a fixed income.

When it's just you, a slow quarter means you earn less. Uncomfortable, but manageable. When you have a hire, a slow quarter means you pay a salary you can't cover. That's a different category of problem. For most professional services roles, the total cost of an employee runs 20-30% above base salary once you include taxes, benefits, and overhead. A hire at a $75,000 base salary, for example, is closer to $95,000 all-in (or even higher if you’re based in the UK or most EU countries) - roughly $8,000 per month, every month, regardless of what the pipeline looks like.

Marcus was about to convert an episodic revenue problem into a structural cash obligation.

‍

What The Business Actually Runs On

I want to be careful here because the phrase "commercial engine" gets used so much that it has started to mean everything and nothing. Let me try to be concrete.

Most founders at this stage have something like a pipeline. What they don't have is a system.

The difference is this: a pipeline is what you have when work arrives because of your personal activity - who you know, who they know, how recently you were in touch, whether you happened to mention what you're working on at the right moment. It produces results. But it requires you to be running it. Stop for three months, and it stops too.

A system is what happens when work arrives through something that doesn't depend on your presence. It might be five strategic partners who understand your work specifically enough to refer it when they encounter the right situation. It might be content that surfaces the right founders to you, because something you wrote named their exact problem. It might be a set of trigger signals you monitor (job postings, announcements, company events) that tell you when someone is likely to be in the market, so you can reach them before the conversation starts elsewhere.

These things are hard to build. Most founders don't have them. What they have instead is a lot of personal activity that produces inconsistent results, some of which they've started calling "pipeline." When they hire, the hire walks into that inconsistency and becomes dependent on the founder to generate their work too.

That's not a firm. That's a founder supporting two people instead of one.

Every boutique doing under $400K, $500K/year understands this. They have a positioning that works well enough in a room, because the founder can adapt it in real time (reading the client, adjusting the framing, answering the implicit questions). They have a conversion process that works when they're personally involved. They have a network that generates referrals, sporadically. What they don't have is anything that functions without them.

That's not a commercial engine. That's a commercial dependency. And a commercial dependency is the one thing that cannot be handed off to a hire.

‍

Why The Referral Ceiling Is Real

The data on this is consistent enough that I find it genuinely clarifying.

Consulting Success's recent survey data found that 70% of consultants generate eight client conversations or fewer per month. Over 70% get zero inbound leads from their website. Only 25% market their business daily. The picture this describes is a client acquisition model that depends entirely on the founder being present, visible, and actively maintaining relationships.

That model works at one scale and fails at another. As the survey puts it, "solo consultants often win work through relationships, referrals, and reputation. That works at $200K to $400K. It becomes unreliable above that threshold because those sources are not systematic and not scalable."

Marcus was at €420,000. Right at the ceiling.

The Hinge Research Institute referral study adds a nuance that's worth sitting with. It found that 51.9% of buyers rule out referred firms before they even speak to them. The number-one reason: they couldn't understand how the firm could help them. The firm was visible. It was referred. It cleared the first reputation check. And it still got ruled out because the positioning wasn't specific enough for a buyer to self-qualify.

Referrals get you into the room. Specificity keeps you in the room. And at the moment you hire, the person doing the selling is no longer you. It's your positioning. It's your website. It's the sentence a connector carries when they mention you to someone. If those things can't do the work without you in the room, the hire has nothing to sell from.

This is the specificity problem. It sounds like a marketing issue. It's actually a commercial architecture issue. And it has to be solved before you hire, not after.

‍

The Cost Structure That Nobody Draws Out

Let me be honest about what most growth advice gets wrong here.

The framing you'll encounter most often is: "Hire when you're consistently turning down work." That's not wrong exactly, but it leaves out a variable that matters enormously: the stability of the demand that's creating the overflow.

Marcus was turning down work. But the work he was turning down came from a referral network that produced, in good months, one to two qualified inbound conversations. That's not consistent demand. That's good luck sustained over twelve months.

The correct framing is: hire when you have consistent demand generated by a system that doesn't require your personal presence to function. Not when you're busy. When you have architecture.

Here's why this matters financially.

A consulting firm's margin profile changes dramatically at the point of the first hire. Solo practitioners can run at margins north of 60%. Once you add full-time staff and carry overhead, healthy margins compress to 25-40%, and below 20% is a warning sign that something is wrong. The margin compression is the cost of building a firm. That cost is only rational when the commercial engine can sustain the utilization rate needed to offset it.

In IT consulting, the benchmark utilization target to be profitable is 70–85% of available hours. A single unassigned hire (a consultant who doesn't have a client to bill) costs firms somewhere in the range of $15,000 - $22,000 per month in combined salary and lost revenue, depending on their rate card. For a boutique at Marcus's stage, one month of under-utilization on a hire would wipe out most of the margin from whatever engagement the hire was supposed to support.

Nobody draws this out when they're excited about growth. I'm drawing it out now because it's the arithmetic that makes sequencing matter.

‍

The Inside-Out Trap

There's a deeper pattern underneath the hiring-before-commercial-engine mistake, and it's worth naming explicitly.

Most technically credentialled founders build their business inside-out.

Inside-out means: you start from your credentials and capabilities, define your service lines, build a website, and then go find clients who want what you've built. The commercial work happens after the supply is constructed.

This is the natural sequence for someone who spent fifteen years building expertise inside a large organization. The expertise is real. The service is genuine. The logic of "here's what I can do, now let me find people who need it" feels reasonable.

The problem is that inside-out thinking doesn't stop at the initial offer design. It extends to hiring. When a founder builds inside-out, they hire to scale their supply (to add delivery capacity behind an offer they've already constructed). The implicit assumption is that demand will follow. That if they can do more work, the market will oblige them by providing it.

Demand doesn't follow supply. Demand is generated by systems designed specifically to generate it.

The outside-in sequence, which is what actually works, runs the other direction. You start from a specific demand thesis: a named situation, a type of buyer, a trigger event. You test whether that thesis generates genuine pull from buyers who have the problem right now. Once you have pull, you build or refine your supply to fit it. And you hire when the demand thesis is proven repeatable and the commercial system for generating it is documented and working.

Rob Snyder, who has done as much as anyone to make this thinking legible for practitioners, puts it precisely here: "Demand is what we don't control; it's why someone needs to change. Supply is everything we control. Demand is upstream of supply. It makes supply relevant - or not."

You can build the best supply in the market and have it be irrelevant because the demand isn't there.

Hiring is the largest supply investment a solo founder can make. It deserves the same test that every other supply decision deserves: is the demand there to justify it?

‍

The Chicken-And-Egg Objection

I want to give the counter-argument its due here, because it's a real one.

Devon O'Rourke, who founded Fluvio, a product marketing consultancy, described this tension precisely in an interview: "I can't afford to go out there and hire two people unless I know there's new business for them to work. I also can't afford to say yes to new business and not have consultants sitting on the bench. It's a constant balance."

He's right, the tension is real. The question is how you resolve it.

The wrong resolution is to hire and hope the demand materializes. The right resolution is to use variable capacity - subcontractors, fractional delivery support, project-based collaborators - while you build the commercial engine. Variable capacity lets you serve demand when it arrives without converting revenue uncertainty into a fixed cost obligation.

This isn't a compromise solution. It's the correct sequence. You use variable capacity during the commercial engine building phase. You convert variable capacity to permanent hire when the engine is generating consistent, repeatable, founder-independent demand.

Most founders who have made the premature hiring mistake describe a version of the same experience in hindsight: they brought someone on expecting the pipeline to fill, and spent the next four months under enormous pressure trying to generate enough work to justify the cost. The pipeline pressure forced them into taking work that didn't fit, at prices they wouldn't otherwise have accepted, with clients they wouldn't otherwise have chosen - because they needed the hire utilized.

A hire, in other words, creates pressure that compromises the very decisions that would allow you to build the commercial engine properly.

The sequencing error has a downstream cost that's harder to measure than the direct salary: it corrupts the founder's ability to be selective about what they build toward.

‍

What Maister Understood About Leverage

David Maister's Managing the Professional Service Firm is thirty years old and still the clearest framework for thinking about how consulting firms work economically. One of his central insights is directly relevant here.

Maister distinguishes between three types of consulting work: Brains (novel problems requiring senior judgment - the frontier stuff, expensive, hard to delegate), Grey Hair (complex problems that draw heavily on experience - pattern recognition, refined judgment, still senior-dependent), and Procedure (familiar, well-defined problems that can be executed by more junior professionals following a well-documented process).

Leverage, which is the ability to have someone more junior deliver the work at a margin, only applies to Procedure work. You can't leverage Brains work. The value is in the judgment, and the judgment lives in the founder.

This creates a constraint that most solo boutique founders at early traction haven't thought through. When you hire, who are you hiring to replace? If the work you're doing is primarily Brains or Grey Hair (which it almost certainly is in the first two years of a technical boutique) a junior hire cannot actually substitute for your presence on the work. They can assist. They can handle smaller parts of it. But the value-generating part of the engagement, the translation between deep technical reality and executive-level decision, still requires you.

That means hiring doesn't solve the capacity problem you think it solves. You're still in every conversation that matters. The hire helps at the margins but doesn't change the fundamental constraint.

The commercial engine question and the leverage question are separate but linked. The commercial engine determines whether you can fill a team's calendar. Maister's leverage question determines whether the work you have is structured in a way that a team can actually deliver it. Both have to be answered before hiring is rational. Most founders are answering neither.

‍

The Commercial Engine That Never Got Designed

Here is what I think is the most honest description of what happens between launch and the hiring moment for most boutiques.

The first clients came from your network. You solved a problem well. You got a referral. You solved that problem well too. Your reputation for a particular type of work accumulated organically. Revenue grew. You got busy.

At no point did you sit down and deliberately design a commercial system. You didn't have to - the network was working. Every client led to the next through proximity and reputation. The commercial engine that got you here didn't get built. It accumulated.

An accumulated commercial engine has a fundamental characteristic: it is specific to the founder. Every node in the network knows and trusts you. Every referral is a referral to you, not to your firm. Every sales conversation depends on your presence, your credibility, your particular way of reading a client situation and articulating a path forward.

This engine cannot be handed off. It cannot be delegated. And it cannot feed a hire who is not you.

When I describe BCC's work to founders, sometimes I say: “Most tech boutique founders have a pipeline. Very few have a commercial architecture. The difference shows up when you try to hire.”

A pipeline is what you have when clients and conversations arrive through your personal activity. An architecture is what you have when clients and conversations arrive through a system you designed, and that system runs whether or not you're the one running it that day.

The architecture is what a hire needs in order to have work. Building the architecture is the prerequisite. The hire is the reward for having built it.

‍

What The Correct Sequence Looks Like

I want to be concrete about this, because I've been critical of premature hiring without saying what I think should happen instead.

The sequence that works, based on what I see in the boutiques that make the transition cleanly, looks like this:

First: confirm the demand thesis. Not just that clients will hire you, but that a specific, named trigger situation creates reliable pull. Three or more clients from the same trigger situation - same type of problem, same type of buyer, same forcing event - is the beginning of a pattern. One client plus two others who vaguely fit is not a pattern. It's three data points from three different situations. The demand thesis is confirmed when you can predict, with reasonable accuracy, which companies are likely to be in the market before they tell you. That’s because you recognize the situation that creates the trigger, and you've seen it enough times to know what precedes it.

Second: build at least one founder-independent demand source. This doesn't have to be a full inbound content machine. It might be five connectors who actively carry a specific referral handle — people who regularly encounter your trigger situation and will think of you when they do, because you've given them a sentence they can actually use. It might be signal-based outbound: a monitored set of trigger events that produce conversations without requiring you to cold-reach your entire network every quarter. The criterion is simple: can this mechanism produce qualified conversations when you're heads-down on a 12-week engagement? If the answer is no, you don't have a commercial engine. You have a commercial dependency.

There's a useful test for this. For each of your last five client engagements, ask: if I had been fully occupied on delivery during the three months before this client reached out, would they still have found me? If the honest answer is probably not - because you ran into them at a conference, or you happened to reach out at the right moment, or they called because you'd been in their inbox that week - then your pipeline depends on your personal availability. Which means it will not reliably generate work for a hire who doesn't have your relationships or your visibility.

Third: document delivery to delegation-ready standard. The hire needs to be able to execute without you in every step. That requires written process, defined scope expectations, documented quality standards. Most solo founders at early traction have none of this. The knowledge lives in their head - the judgment about when a client needs reassurance versus challenge, the instinct for what level of rigor a specific engagement requires, the ability to read which direction a discovery conversation should go. Writing that down is uncomfortable and slow and absolutely necessary.

This is harder than it sounds for technically credentialled founders. The value you deliver is often precisely the pattern recognition that comes from fifteen years of exposure to a specific type of problem. That pattern recognition is not easily codified. But the delivery process that surrounds it (scoping, kickoff, workstream management, stakeholder communication, deliverable standards) absolutely can be. Start there. Document the process first. The judgment transfers through working alongside you; the process has to exist on paper for a hire to function independently.

Fourth: validate the finances. Not on a good month. On the last twelve months. After full-cost accounting (salary + taxes + benefits + overhead + the time you'll spend managing rather than billing) does your monthly free cash consistently exceed the all-in cost of the hire? If not, the timing is wrong. A business that's profitable on paper can still not be able to afford a hire if cash comes in unevenly or if the last twelve months include a slow quarter that looks like an outlier but might be a pattern.

Fifth: use variable capacity in the meantime. Subcontractors and fractional collaborators let you serve demand that exists now without betting the firm on demand that might not exist in six months. This is not a compromise solution. It's the correct use of each mechanism. Variable capacity is for demand you have but can't fully serve alone. Permanent hire is for demand you're confident is systematic and repeatable. Using a subcontractor while you build the engine preserves margin, preserves flexibility, and prevents the scenario where you're managing a hire and building a commercial system at the same time - which is too many things to do well simultaneously.

Then hire. With a specific role brief tied to a specific constraint. Not "I need help" but "I need someone who can run the delivery phase of engagements type X without me present, because I have consistent pipeline of type X coming through and I am the bottleneck at the delivery stage."

The hire that comes after this sequence is a different thing entirely from the hire that comes before it. It has work to do on day one. It has a system to plug into. It doesn't require the founder to generate its utilization through heroic personal BD effort. It is, in the truest sense of the word, a leverage decision rather than a hope decision.

‍

The Identity Dimension

I want to add something here that I don't see discussed in the growth literature, but that I've observed consistently enough to mention.

For most ex-corporate founders, the decision to hire carries a significance that goes beyond the operational. There's an identity dimension to it. Hiring your first person is when you become a founder of a firm rather than a very good independent consultant. It's when the thing you've been building starts to feel real - like a company, not a practice.

This is legitimate. The transition is real.

But the identity move and the commercial readiness question are completely independent. You can be ready to think of yourself as a firm-builder without your firm being ready to support a hire. The desire to make the transition is not evidence that the conditions for the transition are in place.

I've talked to founders who hired primarily because they were lonely. Because they wanted the feeling of leading a team. Because being "just a solo consultant" felt like diminishment after years of managing large groups inside a corporation - after years of being the person who built things, developed people, sat in rooms where decisions got made. These are human motivations and I don't dismiss them. But they're not commercial arguments. And the hire that follows from them creates financial pressure on a timeline that human motivations don't resolve.

There's a version of this that's more subtle. Some founders hire because they're uncomfortable with the idea that their firm's growth depends entirely on their own selling, and a hire feels like a solution to that discomfort. If I have a team, they tell themselves, then I'm not just a person. I'm running something. The sales pressure becomes shared rather than personal.

Except it doesn't. A hire who has no commercial system to work from doesn't reduce the founder's BD burden. It increases it. The founder now has to generate enough work for both of them. The discomfort with being the sole source of pipeline doesn't disappear when you hire. It intensifies, because the stakes are higher.

The commercial engine is the actual solution to that problem - not the hire. Build the engine first. The hire then becomes what it should be: an extension of a system that's already working, rather than a bet that the system will start working once the hire is in place.

I sometimes describe this as the difference between a practice and a firm. A practice is what you have when the commercial engine is you. A firm is what you have when the commercial engine runs independently of any one person. The word "firm" implies solidity, structure, permanence. A practice implies the practitioner. You can use the word "firm" before you've built the engine, but you're using it aspirationally rather than descriptively. The transition from practice to firm is not the hire. The transition from practice to firm is the commercial engine. The hire is just the first step in scaling what the engine has made possible.

‍

The Commercial Engine Audit

If you're at the stage Marcus was at (real revenue, genuine utilization pressure, an instinct that hiring is the obvious next move) and you want an honest read of where you actually are before you commit, that's what the Commercial Engine Audit is designed for.

It's a 90-minute working session. We map three things: whether your delivery model can be delegated, whether your pipeline can generate work without you in every conversation, and whether the margins at team scale actually hold. You get a written gap map within 24 hours.

If the gaps are small, you'll leave knowing the hire is the right call. If they're significant, you'll know what to build first - and building it first means the hire you make is one that has somewhere to land.

The session is $600, credited toward a sprint if you go further. If you're at this decision point, it's worth an honest look before you make a move that's hard to reverse.

‍

After The Call

Marcus got the hire wrong once, before he got it right.

About a year before we talked, he'd briefly brought someone on - a junior data analyst, three months into the practice, when Marcus thought the problem was that he needed more hours in the day. The arrangement lasted six weeks. The analyst didn't have enough context on Marcus's clients to work independently, Marcus didn't have time to develop her, and the whole thing quietly dissolved. He doesn't talk about that period much.

The second time, he was slower and the result was different. Not perfect - but different.

I'm not pretending he solved all of this cleanly. The commercial engine he built in is a first version, not a finished product. The hire took longer to onboard than he expected. There are still engagements where Marcus is carrying more delivery weight than he should.

But he made the hire knowing there was consistent work waiting for the person he brought in. He made it with a written process the person could learn from. He made it with a positioning specific enough that the new hire could even help him with a few BD tasks.

He made it in the right order.

That's the difference between a hire that works and a hire that creates the pressure you were trying to relieve.

If you're a tech boutique founder at the solo-to-team transition and you want to run the commercial engine diagnostic before you make the hiring decision, the Commercial Engine Audit gives you a written gap map in one session. Details at here.