Choosing an IT Partner Beyond the Big Firms

What you are actually buying from a big firm

Be clear-eyed about what the large-consultancy purchase delivers, because some of it is genuinely valuable and some of it is value you are paying for but not receiving. The big firms sell three real things: procurement safety (a name your board recognizes and a contract your legal team has seen before), scale (the ability to put a hundred bodies on a problem next quarter), and breadth (someone, somewhere in a firm of hundreds of thousands, has done something adjacent to your problem).

All three are real. If your problem is 'we need 80 developers for an 18-month migration and the primary risk is execution-at-scale and audit defensibility,' the big-firm model is built for exactly that, and a ten-person shop cannot credibly do it. Procurement-driven, low-differentiation, high-headcount work is their home turf. Don't romanticize the boutique alternative for jobs it cannot staff.

But notice what is not on that list: speed, senior attention on your actual code, deep ownership of outcomes, and architectural judgment tuned to your specific business. Those are precisely the things most technology leaders actually need and the things the pyramid model structurally cannot prioritize, because its economics depend on leverage — billing junior time at senior-adjacent rates. The question is never 'are big firms bad.' It is 'does my problem match what their model is optimized to deliver, or am I paying premium rates for a model that fights my goal?'

The pyramid problem, explained

To evaluate any partner you have to understand the engine that drives their behavior, and for large consultancies that engine is leverage. The business model rests on a pyramid: a few senior partners and principals at the top, a wider band of managers in the middle, and a broad base of junior consultants and engineers at the bottom. Profit comes from maximizing the ratio of billable junior hours to senior hours. This is not a criticism of any individual; it is arithmetic, and it predicts the behaviors you will experience.

It explains the bait-and-switch you have probably lived through: the impressive senior people in the sales process are a shared, scarce resource the firm cannot afford to leave on your account, so they rotate off after the sale and your day-to-day is run by people earlier in their careers. It explains why scope changes trigger change orders rather than judgment calls — the contract, not the outcome, is the unit of management. It explains why the team grows when a project is in trouble: more bodies is the lever the model has, even when the real problem is that adding people to a late project makes it later. And it explains the documentation-and-process overhead, which exists partly to make junior, rotating staff interchangeable — necessary for the firm, but a tax you pay.

None of this means the work is bad. It means the incentives point away from the things you care about most. When you evaluate alternatives, you are really asking: does this partner's economic model align their incentives with my outcome, or against it?

What 'senior and outcome-aligned' actually means

The alternative is easy to describe badly. 'Boutique,' 'agile,' and 'senior' are words every small firm uses, including the ones that are just small pyramids with a nicer website. The substance is in the operating model, not the adjectives. Here is what genuinely differentiated looks like.

The people who pitch are the people who build

In a real senior partnership, the person across the table in the sales conversation is someone who will have their hands on your system. There is no scarce-senior-resource to protect because the firm is built from senior people, not around a few of them. This is the single highest-signal difference, and it is easy to test: ask precisely who will do the work, demand to meet them, and write their involvement into the contract. A firm whose model depends on bait-and-switch will get visibly uncomfortable here.

Small teams of high-leverage engineers, not large teams of average ones

A handful of senior engineers — especially AI-native ones who use modern tooling to multiply their output — routinely out-deliver a large team of juniors, and they do it with a fraction of the coordination overhead. Communication cost grows roughly with the square of team size; every person you add to fix a delay adds more lines of coordination than capacity. The right small team ships faster not despite being small but because of it. The signal to look for is output per person and decisions made without escalation, not the size of the org chart they can mobilize.

Incentives tied to outcomes, not hours

The deepest alignment is structural. A partner billing time-and-materials by headcount profits when projects take longer and teams grow — the same incentive as the pyramid, just smaller. A partner willing to price against outcomes, fixed scope at fixed cost, or milestone-based delivery is putting their margin where their promises are. You cannot always get pure outcome-based pricing, and you should be skeptical of anyone who promises it with no shared definition of done — but a partner's reaction to the conversation tells you everything about whether their incentives point at your goal or away from it.

The evaluation framework

Here is the concrete framework we'd hand a technology leader running a selection process. Score every candidate — big firm or boutique — on these five dimensions. The point is not to rig the result toward small firms; it is to evaluate on what predicts delivery success rather than on brand and headcount, which predict almost nothing about whether your software ships.

• Seniority on YOUR account, not in the firm: Not 'how senior is your bench' but 'who specifically touches my system, and how senior are they.' Ask for named individuals, their actual role on your project, and the percentage of their time you get. Write it into the contract with the right to approve replacements.
• Output per person: A small senior team with high per-head output beats a large team of average output at lower total cost and far lower coordination overhead. Probe how much one of their engineers ships and how they use modern tooling to multiply it. Be suspicious of any pitch where the headline is team size.
• Incentive alignment: How does this partner make more money — by your project succeeding quickly, or by it lasting longer and growing? Examine the pricing model, the change-order posture, and their willingness to tie compensation to outcomes or milestones.
• Decision velocity: How many layers sit between a question and a decision? Senior partnerships answer architectural questions in the room; pyramids escalate them up and route them back through a manager. Test it live in evaluation — ask a hard technical question and watch whether you get an answer or a follow-up meeting.
• Skin in the game and continuity: Will the same people be there in month nine? Bait-and-switch, high rotation, and a revolving door of contractors are the dominant failure mode of large engagements. Ask about team stability and structure the contract to penalize unapproved churn.

Questions that surface the truth before you sign

Pitches are polished; the truth is in the answers to specific, uncomfortable questions. These are the ones we'd insist on asking, and more importantly, what the answers reveal. A good partner answers all of them crisply and is glad you asked; evasion on any of them is itself the signal.

Ask each one and listen for whether the answer is specific or generic, comfortable or defensive. Vagueness here predicts vagueness in delivery.

• 'Who exactly will be on my team, what is their seniority, and what percentage of their time do I get?' — Reveals bait-and-switch and bench-padding. Demand names and write them in.
• 'How do you make more money if this project goes well versus badly?' — Reveals whether incentives align with your outcome. Watch for discomfort.
• 'When the scope changes mid-project, what happens?' — Reveals whether they manage to the contract or the outcome. 'Change order' as the reflexive first answer is a flag.
• 'Show me something hard you shipped, and tell me what went wrong and how you handled it.' — Reveals real delivery experience versus rehearsed case studies. Partners who have actually shipped talk fluently about failure.
• 'Can I talk to the engineers, not just the account lead?' — Reveals whether there is senior substance behind the sales gloss, and lets you assess the people who'll actually do the work.
• 'What would make you tell me NOT to build this, or to do less?' — Reveals whether they are an order-taker who bills whatever you ask, or a partner with judgment willing to protect your budget from you.

Contracting for alignment

The relationship you get is largely the relationship you structure. Most of the failure modes above can be designed out of the contract before they happen, and a partner's willingness to accept these terms is itself a strong signal of confidence. These are the structural protections we'd advise building in.

The meta-point: structure the engagement so the partner only wins when you win, and so that the cost of a bad fit is bounded and discoverable early. A confident senior partner welcomes this because it favors them; a firm relying on lock-in and rotation resists it.

• Named-key-personnel clauses: Name the senior people committed to your account and require your approval before they're replaced. This directly neutralizes bait-and-switch.
• Start with a paid pilot: A small, time-boxed first engagement on a real problem tells you more than any reference check. Real senior shops are happy to be judged on a short proof; pyramids prefer to lock in scale before you can assess them.
• Milestone or outcome-linked payment: Tie a meaningful portion of payment to working, accepted deliverables rather than hours logged. It aligns incentives and surfaces delivery problems early.
• Bounded exit and IP ownership: Ensure you own the code and can leave without a hostage situation. Lock-in is a business model for some firms; make portability a contract term, not a hope.
• Right-sized team commitments: Resist the 'we'll add people if needed' framing. Agree on a small senior team and make growth a deliberate decision, not a default lever pulled when things slip.

When the big firm is still the right call

Intellectual honesty matters more than self-promotion, so here is where we'd send a client to a large incumbent rather than to a partner like us. If your dominant constraint is procurement and audit defensibility — a regulated environment where the board needs a globally recognized name on the contract for risk reasons — the big firm buys you something real that a boutique cannot. If you genuinely need to mobilize hundreds of people across many geographies simultaneously, that is the pyramid's home turf and a small senior firm should tell you so honestly. And if the work is truly commodity staff augmentation where the requirement is bodies-with-skills at volume and neither judgment nor speed is the bottleneck, the scale model is a reasonable fit.

For most technology leaders, most of the time, the actual need is the opposite: ship something specific, well, and fast, with senior people who own the outcome. That is the case the big-firm model fights and the senior-partnership model is built for. The framework in this report exists so you can tell which situation you are actually in — and choose on the merits rather than on the reflex of hiring the name nobody gets fired for.