Choosing a technology partner is one of the higher-leverage decisions a non-technical executive makes. The work is technical and consequential, the people doing it sit outside the organization, and the cost of choosing badly is not just the project — it is the next two years of dependence on what that project produced. The decision deserves a real evaluation framework, not a beauty contest.
The Pitch Tells You Less Than The Discovery Conversation
Every credible partner can produce a polished pitch. The real signal is in the discovery conversation. Does the partner ask sharp, specific questions about constraints, prior work, integration realities, and the operating model that will inherit the build? Or do they pattern-match the ask onto a generic offering and start scoping? The first shape correlates strongly with shipping. The second correlates with rework.
Hands-On Delivery Beats Polished Sales
The people on the sales call are not always the people on the delivery team, and the variance can be enormous. Harvard Business Review's long-running vendor-management research is unambiguous on this: ask, on the record, who is actually going to do the work. Then ask whether those same people will be available from kickoff to launch and into operations. The answer is the single most predictive signal in vendor selection.
Reference Calls That Are Worth Making
Reference calls are usually theater. They become useful when the questions are sharp. Ask the reference what the partner did when something went wrong. Ask whether the partner stayed engaged after launch. Ask what the reference would do differently. Each of those questions reveals more than "were they good to work with."
Watching For The Operational Tells
Some operational tells correlate strongly with how a partner will behave once the project is live. How they handle scope ambiguity in the proposal — do they flag it or paper over it? How they describe their evaluation and observability practice — with specifics or with adjectives? How they talk about hand-off — as part of the engagement or as an afterthought? Forrester's technology services research consistently identifies these as the durable predictors of partner quality.
The Contract As A Forcing Function
The contract should reflect the operating model, not just the deliverables. Define what done means. Name the hand-off conditions. Specify ownership of code, models, and data. Build in a documented exit ramp, even if you never use it. The MIT Sloan CISR research has decades of data on the difference between contracts that are structured to surface problems early and contracts that paper over them. The structural differences look boring; the outcomes do not.
The Six-Question Pre-Mortem
Before the contract is signed, run a pre-mortem with the partner: assume the project failed; what happened? Six questions that surface the answer. What is the riskiest assumption in the plan? What would cause a six-week delay? What dependency is most likely to slip? What does the team under-staff for? What integration risk is the team under-pricing? What would make us regret this in twelve months? Partners that engage with these questions comfortably are partners that have done this before.
Key Takeaways
- The discovery conversation is more predictive than the pitch — listen for sharp questions
- Ask, on the record, who actually delivers — not who sells
- Sharp reference questions ('what did they do when something went wrong?') beat generic ones
- Operational tells in the proposal predict operational behavior in delivery
- Structure the contract around hand-off, ownership, and exit, not just deliverables
- Run a six-question pre-mortem before signing — partners that engage well have done it before