Your first VP
of Engineering.

The starting brief

We need a VP of Engineering from a great AI company. Someone technical who can scale the team and help us ship faster.

The fictional business context

Aster Workflow is an invented Series A company building AI agents for enterprise support operations. It has 24 employees, including 12 engineers, plus six external design partners. The CTO still reviews most architecture decisions and rescues difficult deployments. The CEO wants more customers; the CTO worries that each deployment creates another bespoke product. These facts are assumptions created for this sample.

What the search is actually solving

The company needs someone who can make delivery less dependent on the founders while preserving technical quality. The first job is to establish ownership, quality standards, and a repeatable path from a customer requirement to a supported release. Hiring a large team is a consequence of that plan, not the starting objective.

The next decision

CEO and CTO must agree that this role owns product engineering, delivery, and engineering management, while the CTO retains model strategy. Resolve that boundary before expanding the search or promising candidates authority.

What you leave with

• A hiring plan tied to business outcomes rather than a company-logo wish list.
• A way to calibrate profiles, approach relevant people, and test the evidence in interviews.
• A next-action plan and exportable decision record your team can continue using.

Role and authority

VP of Engineering, reporting to the CEO and partnering with the CTO. Own product engineering, platform reliability, delivery planning, and engineering management. Make staffing and architecture decisions within an agreed budget and technical principles. The CTO owns model research and long-range technical direction; material disagreements come to the CEO for a documented decision.

Outcomes to hire against

First 30 days

Map deployment bottlenecks, establish delivery and reliability baselines, and name an owner for each critical system.

By 90 days

Agree a delivery operating plan, define release and escalation standards, and assign accountable engineering leads. Set improvement targets from the baseline with the founders.

By six months

Demonstrate the agreed improvement in release predictability and customer deployment effort. Engineering leads own routine decisions; founder escalations and the reasons for them are tracked.

Essential evidence

• Personally led an engineering team through the move from bespoke customer delivery to a repeatable product.
• Made production tradeoffs involving AI quality, latency, cost, evaluation, and fallback behavior.
• Developed engineering leaders and clarified ownership without adding unnecessary process.
• Can explain the outcome, personal contribution, constraints, and evidence behind at least one relevant example.

Preferences and tradeoffs

Prior VP title and famous-company experience are optional. Favor relevant ownership at a smaller company over organizational scale alone. Deep model-research credentials are not required for this scope. An exceptional director may fit if references establish team leadership and cross-functional decision authority.

Unresolved before outreach

CEO: approve budget and compensation range. CEO and CTO: approve decision rights and location expectations. Hiring manager: agree candidate access to technical context. These are unresolved scenario decisions, not hidden assumptions or a market compensation recommendation.

A Applied AI engineering director

Illustrative background: grew an eight-person product team to 25 and introduced model evaluation into release decisions. Why explore: close to the delivery and quality problem. Still to establish: personal ownership of customer deployment outcomes and whether they have developed managers. Calibration decision: use as the lead profile pattern; do not treat the title as disqualifying.

B Large-company platform VP

Illustrative background: managed 120 engineers on shared infrastructure. Why explore: operating discipline and leadership development. Still to establish: willingness and ability to work without mature support functions. Calibration decision: investigate stage fit before investing in prestige.

C Founding engineer turned team lead

Illustrative background: built an AI product from prototype through several enterprise deployments and now leads six engineers. Why explore: direct product and customer context. Still to establish: recruiting, delegation, and leadership through managers. Calibration decision: potentially strong technically; management scope is a genuine question.

D Head of implementation engineering

Illustrative background: standardized complex customer integrations and reduced recurring delivery work. Why explore: directly addresses bespoke deployment burden. Still to establish: ownership of core product engineering and engineering talent development. Calibration decision: clarify whether the business needs this adjacent role before forcing it into a VP specification.

E AI research leader

Illustrative background: led a research group and published influential model work. Why explore: technical depth. Still to establish: accountable ownership of production software, enterprise delivery, and engineering management. Calibration decision: research distinction alone does not answer this hiring problem.

F Enterprise SaaS engineering leader

Illustrative background: built reliable delivery practices and engineering leads at a growth-stage SaaS company; limited stated AI experience. Why explore: organizational fit. Still to establish: hands-on judgment on model evaluation, nondeterministic behavior, and AI operating costs. Calibration decision: keep in scope if the missing AI evidence can be established.

Founder conversation 30 minutes

Ask: Tell me about a product whose enterprise deployments depended too heavily on a founder or a few engineers. What did you change, what did you personally own, and what got measurably better? Probe the starting baseline, tradeoffs, remaining problems, and who can corroborate the account. Listen for a specific operating change, not only a process vocabulary.

Technical discussion CTO 60 minutes

Use a fictional agent that sometimes produces a plausible but wrong support action. Ask the person to design an evaluation, release, and fallback approach while managing latency and cost. Explore ownership, observability, rollback, and customer impact. Strong evidence includes explicit failure modes and reasoned tradeoffs; model-name fluency alone is insufficient.

Leadership discussion CEO and engineering lead 45 minutes

Ask for a situation where a technically strong founder kept overriding team decisions. What authority did the leader negotiate? What did they delegate, and what did they retain? Probe one manager they developed, one decision they got wrong, and what changed afterward.

Bounded working session 45 minutes

Share the same fictional deployment scenario with each participant in advance. Discuss a 90-day plan together; no proprietary customer data and no unpaid production deliverable. Assess prioritization, questions, and judgment rather than presentation polish. Offer an equivalent format when needed.

Evidence standard

Supported

A specific relevant example with clear personal contribution and evidence that can be checked.

Partial

A relevant account with unresolved ownership, results, or context.

Not yet established

The discussion did not establish the requirement. This is a question to resolve, not proof of inability.

Reference and debrief

With the candidate's permission, ask a relevant former colleague: What did this person own when delivery stopped depending on the founder? What changed, and where did they still need support? Debrief by requirement: account, corroboration, open question, next action. The founders own the hiring decision.

Candidate opportunity brief

Aster Workflow helps enterprise support teams use AI agents in day-to-day operations. Our next engineering challenge is making customer deployments repeatable while keeping quality, reliability, and operating costs under control. As VP of Engineering, you would own product engineering and build the leadership system that lets the team deliver without constant founder intervention. You would work directly with the CEO and CTO; the CTO would retain model strategy. The team is small enough for your decisions to shape how the company works. Success means clear ownership, a credible release process, and engineering leaders who can run it.

What to clarify in the first conversation

Decision rights, current team strengths, customer deployment constraints, resources, compensation, location expectations, and why the role exists now. Do not invent settled terms or imply the CTO is surrendering responsibility that has not been agreed.

Founder outreach fictional example unsent

Hi Alex — I’m the founder of Aster Workflow. We’re at the point where customer deployments need to stop depending on our founders. In this illustrative example, your experience taking an applied AI team from custom deployments to a repeatable product is why I’d want to talk. We’re defining a VP of Engineering role with ownership of product engineering and delivery, working with our CTO on technical direction. Would you be open to comparing notes on the problem and whether the role could be interesting?

Turn that into a real message

Replace the illustrative relevance sentence only after verifying a specific source and the person's actual contribution. Explain what caught your attention without asserting unverified impact. Review the message yourself, then send it through your normal channel. No outreach is sent by this sample.

Relationship route

Where a genuine shared relationship exists, ask the mutual contact whether they know the person's work and would be comfortable making an introduction. A shared connection is not evidence of endorsement, willingness, or candidate interest.

First working session

CEO and CTO settle the role boundary, resources, and open terms. Record each decision and its owner. Review the six profile patterns and identify which tradeoff would most change the search. Update the brief before approving candidate-facing materials.

Week one focus the search

The assigned research owner builds a small real calibration set with source links and dates. The founder reviews relevance and evidence gaps. Confirm who can contact each person, check existing relationships and prior outreach, then approve a bounded first outreach group. Research coverage and sourcing volume are agreed separately from the illustrative profiles here.

Week two learn from conversations

The founder leads initial conversations using the evidence questions. The search owner records each person's stated interest, open questions, owner, next action, and due date. Review what the market is telling you. If role scope or terms change, update the hiring plan and affected messages before continuing.

A useful weekly review

• What changed in our understanding of the role or the market?
• What evidence have we actually established?
• Which conversation or decision is stalled, and who owns the next step?
• What should we stop, continue, or change before the next review?

Using your existing AI workspace

Bring the approved hiring plan into your existing Codex or Claude Code workspace if that is how your team works. Ask it to organize supplied research, identify missing evidence, or draft interview preparation. Require source links and distinguish claims from verified facts. Review outputs before use. Connect external systems only with agreed access, costs, and data handling; no integration is required to read or use this sample.

Optional assistance

Jason can review the decisions or take on separately agreed research and execution work. Continuing the process does not require an ongoing advisory retainer. The hiring plan, materials, and decision record stay usable by the founder and team.

Worked decision record fictional

Decision

Prioritize leaders who have made enterprise delivery repeatable; a prior VP title is optional.

Reason

The immediate business constraint is founder-dependent delivery, not management of a large organization.

Open question

Can a strong director own management development as well as technical delivery?

Next action

CEO and CTO compare the applied-AI director and SaaS leader patterns, then approve the initial real-research brief.

Owner and timing

CEO; next joint hiring working session. A real due date is set by the team.

Handoff acceptance

• Find the agreed hiring plan and distinguish settled decisions from open questions.
• Identify the next action and the person responsible.
• Complete an agreed action and save the result.
• Close and reopen the workspace, then resume from the saved record.
• Export the materials and decision record into a format the team can keep.

What this sample demonstrates

A coherent hiring plan, calibration logic, interview structure, candidate story, operating sequence, and local decision-record interaction. It does not demonstrate live people research, candidate availability, outreach delivery, a completed hire, customer tenant isolation, or independent customer usability testing.

What a real engagement adds

Your business context and stakeholders; real researched profiles with sources and gaps; approved company facts and terms; an agreed workspace configured for your team; and handoff checks using your actual workflow. The six fictional profile patterns here illustrate the decisions, rather than substituting for the real research included in an engagement.