01
Customer outcomes
Equip engineers to shape experiences and technical solutions from customer context, then act when a release passes acceptance checks but the customer’s problem persists.
Internal hiring brief
Head of Engineering
Build the leaders. Accelerate delivery.
Make enterprise agents dependable.
Role overview
The mission and scope of the hire.
Build an engineering organization that turns Beam’s product ambition into reliable customer outcomes through autonomous pods and agentic engineering.
Location
Pakistan · in person
City and office to be agreed
Leadership model
Lead through pod leads
Own strategy, staffing, standards and delivery
Key partners
Product + founders
GTM, Solutions and the AI-native initiative
Reporting and terms
To be agreed
Reporting line, package and employment terms
Mandate at Beam
Six challenges shape the role and its decision rights.
Beam is building an enterprise agent platform across Discover, Build and Optimise: understand valuable opportunities, create agents that execute business processes, and improve them through production evidence and feedback. The ambition is a reinforcing loop: production experience improves understanding of the business and informs what agents should do next. The Head turns this direction into engineering priorities and an organization of autonomous pods.
02
Agentic engineering
Set the operating model and investment priorities for agent-enabled development; build adoption through leads and improve the organization’s ability to deliver valuable work reliably.
03
Pod leadership
Develop leads, choose team boundaries and staffing priorities, and establish tested secondary ownership of critical systems.
04
Credible delivery
Make scope, capacity and dependencies explicit; improve release cadence and recovery while sustaining current commitments.
05
Coherent architecture
Align API, event, data and infrastructure decisions across pods; make reuse, build/buy and migration choices against actual constraints.
06
Enterprise reliability
Protect tenant and approval boundaries, handle uncertain external actions, and recover safely from customer-facing failures.
Decision ownership · target operating model
Founders
Company-level decisions and final hiring decision
Product
Problem, feature intent
and acceptance criteria
and acceptance criteria
Head of Engineering
Commitments, staffing
and engineering standards
and engineering standards
Delegated authority + coaching
↓
Pod leads + engineers
Pod leads: planning, delivery, engineer development and production ownership.
Engineers: experience and implementation decisions.
Engineers: experience and implementation decisions.
Working model: combine customer, GTM and Solutions input with technical evidence; represent Beam in customer technical discussions, explaining architecture and deployment trade-offs and bringing requirements into engineering priorities. Partner with the existing AI-native initiative on adoption. Build capability through leads while delivery continues; additional headcount, a fully staffed PM layer and a fixed budget are not assumed.
Candidate profile
Essential experience, leadership scope and Pakistan fit.
12+ years overall
Across engineering and engineering leadership, with the most recent 3+ years in people management. Previously a hands-on software engineer; still able to review code and diagnose failures.
3+ pods · 15+ engineers
Previously held concurrent responsibility through leads and built or materially reorganized a multi-team organization. Verify dates, reporting lines and delegated decisions; peak scope need not cover the full three years.
Owned-product experience
Owned a software product through roadmap, release and production improvement. Exclude services-only, outsourcing and staff-augmentation management.
Backend and distributed systems
Deep judgment across backend and distributed systems. Can personally ship a feature end to end across frontend, API, data, tests and deployment.
Firsthand coding-agent practice
Personally uses coding agents and has helped a team adopt them. Can show how generated work was tested, reviewed and safely released.
Pakistan · in person
Search Lahore, Karachi and Islamabad/Rawalpindi; consider overseas candidates with a credible relocation path. City, office and package remain open.
Recruiter search brief
Search owned-product leaders with the required career-wide scope.
Start with owned-product companies with Pakistan engineering teams. The three examples below show the experience we want to find; use the full search list to identify current and former engineering leaders.
Three companies that illustrate the search
Each offers a different connection to the work this leader will own at Beam.
Metric
Accounting and financial intelligence software with Max AI.
Pakistan connection: its team page lists a Rawalpindi office.
Why it matters for Beam
Look for leaders who turn business problems into dependable workflows and useful AI features, with ownership beyond the initial launch.
Rewaa
Retail SaaS connecting inventory, point of sale, accounting and integrations.
Pakistan connection: its engineering board lists a Karachi Technical Lead role.
Why it matters for Beam
Look for leaders who coordinate product areas and integrations, making complete customer workflows reliable across team and system boundaries.
SadaPay
Digital wallet; its product-engineer brief calls for daily coding-agent use, review and end-to-end delivery.
Pakistan connection: the role prefers Karachi.
Why it matters for Beam
Look for leaders who can extend firsthand agentic practice across pods while maintaining production quality. Check earlier leadership scope: the advertised team is small.
Full search list · 28 company pools
Work through the first wave, then use the other pools to close gaps in the shortlist.
| Priority | Companies | Relevant experience |
|---|---|---|
| First wave | Metric, Paismo, ImagineArt / Vyro, Metal, Rewaa, QLU.ai, Social Champ | Owned SaaS workflows, integrations and AI products. Verify enterprise fit for creator-product backgrounds. |
| AI talent and referrals | Uplift AI, Nectar Social, SOCByte, SimpliEd | Production AI, APIs and coding-agent practices. Pakistan-based multi-pod leadership remains unverified. |
| Adjacent products | Neem, Safepay, SadaPay, CreditBook, Bazaar | Financial and commerce workflows: transaction reliability, integrations and end-to-end product delivery. |
| Backups | Securiti AI / Veeam, DigitalOcean / Cloudways, Motive, Educative | Broader platform and management scope; seek startup-style ownership. |
| Second wave · if needed | CureMD, TCP Software, i2c, Careem, Afiniti | Expand here if the first pass leaves gaps in multi-pod leadership or production depth. Verify current Pakistan product-engineering scope and personal agentic practice. |
Additional product pools: PureSquare / PureWL (cybersecurity SaaS) and CareAxiom / Icon (senior-care software). Maiden Century builds investment-data software; confirm its current Pakistan engineering footprint. Sample leaders appear below.
Parallel route: leaders who worked abroad at Amazon/AWS, Google, Microsoft, Meta or comparable product companies and returned to Pakistan. Verify overseas employment, current location and subsequent multi-pod leadership.
Search: use Pakistan location and current/past employer filters. Titles: Head/VP/Director of Engineering, Senior Engineering Manager or product-company CTO. Search each employer and the returnee pool separately. Try site:linkedin.com/in/ "Head of Engineering" "Pakistan", then vary the title and employer.
Pitch: build the leadership system behind Beam’s enterprise agent platform, with ownership of engineering delivery and the transition to agentic development.
Sample profiles · employee engineering leaders
Start with Muhammad Umair Khan: his public profile contains the clearest evidence of leadership across teams and through leads. The others are relevant product-company leads with larger evidence gaps. Keep the company map as the primary search direction.
Public sources checked 11 September 2026. No founder or cofounder role was found in the reviewed career histories below; confirm unlisted ventures in screening. Titles, dates and scope are profile claims unless an additional source is linked. These are sourcing examples, not a cleared shortlist: personal coding-agent practice, current interest and in-person availability remain unverified for all three.
| Company / sample profile | Evidence relevant to this role | What HR still needs to establish |
|---|---|---|
| Rewaa Muhammad Umair Khan Director of Engineering Karachi | First screen. Engineering since 2012; people-management roles since 2021. At Rewaa, describes three teams plus oversight of a fourth, with an engineering manager in his reporting line. Earlier led 20+ engineers, architects and managers at Airlift. Owns POS and omnichannel roadmaps, API/data/code reviews and production delivery. His technical writing covers Rewaa performance work and his move into management. | Confirm concurrent pod/headcount structure and delegated authority; separate engineers from other roles in the 20+ claim. Test recent backend depth and the reported release-cadence improvement. Request a real coding-agent workflow and evidence of team adoption. |
| CareAxiom / Icon Muneeb Ahmad Director of Engineering Pakistan / Lahore career history | Product-leadership follow-up. Engineering since 2011; principal engineer → architect → Engineering Manager from March 2022 → Director from March 2025. Rails/Node/React, deployments and people-leadership recommendations. CareAxiom's official site describes an owned cloud care-coordination platform and Lahore engineering team. | Establish personal product area, roadmap ownership, headcount, pods and leadership through leads; none is numerically evidenced. Resolve overlapping CareAxiom/Go Icon entries and a Chicago-labelled prior role; confirm current physical location. Check coding-agent practice directly. |
| Maiden Century Ajmal Ismail Head of Engineering | Retained architecture lead. Its official leadership page names Ajmal. Profile shows engineering since 2012, Head of Engineering since January 2024, and prior principal-engineer/solutions-architect roles. Java/Python, React and SQL support the full-stack architecture signal. | Profile lists Lahore, current job New York: confirm residence. Head tenure alone is under three years at this check date; establish earlier actual people management. Verify concurrent pods/headcount through leads and personal coding-agent practice. |
Apply the same exclusion in further sourcing: inspect the full career and side ventures for founder/cofounder roles. An employee “founding engineer” title alone does not mean business founder. Keep service-only companies out of the target pool; prior services employment does not erase subsequent owned-product leadership.
Evaluation criteria
Seven capabilities, with observable evidence for management and technical judgment.
Management and leadership
Assess how the candidate sets direction, develops pod leads, staffs teams, delivers customer outcomes and leads change. The green/red criteria below define the leadership bar, including technical judgment. Require their own decisions and results at multi-pod scope; calibrate before use. Missing evidence is a follow-up, not a demonstrated failure.
Independent ownership
Evidence: One initiative from ambiguous goal to result; dated before/after evidence and a stakeholder reference.
Green flags · meets bar
- Sets direction. Turns a business goal into a scoped plan with success measures, owners, dependencies and explicit trade-offs. Explains which decision was theirs and where shared agreement was needed.
- Runs the operating cadence. Reviews working milestones and delivery risks with leads; intervenes early with an owned recovery plan and next checkpoint. Resolves dependencies and agrees scope, date or capacity changes while leads retain execution ownership.
- Closes the loop. Shows an outcome that held after launch or an enterprise escalation resolved with a clear recovery plan, customer updates and verified prevention.
Red flags · below bar
- Requires executives to supply the plan or repeatedly resolve routine dependencies; offers status reporting as the main contribution.
- Claims success from activity or an aggregate dashboard, but cannot explain a missed commitment, corrective decision or resulting change.
Agentic engineering practices
Evidence: An adoption initiative they led: direction, investment choices, lead ownership, resistance and results. Establish its scale and their contribution; test the proposed operating model live.
Green flags · meets bar
- Sets the engineering operating model. Defines how agents change roles, pod responsibilities and the path from customer problems to shipped outcomes. Establishes maintained customer and technical context, source ownership and a way to resolve conflicting information. Decides what to standardize and where leads retain discretion, including autonomy limits and quality accountability.
- Leads the transition. Prioritizes workflow and infrastructure investment against business value. When code output outpaces review or integration, addresses waiting, work in progress and rework before expanding automation. Develops leads to own adoption, preserves engineers’ ability to explain and maintain the system, and adjusts skills and capacity while maintaining commitments.
- Owns organization-wide results. Evaluates whether teams deliver more valuable work with credible commitments, sustained quality and acceptable cost. Uses evidence to resolve constraints, reallocate investment and stop or expand practices. Shows that improvements continue through leads without depending on their personal intervention.
Red flags · below bar
- Offers personal prompting skill, a tool rollout or an adoption target as strategy; cannot explain changes to responsibilities, investment or delivery capability. Treats unverified context as authority or adds automation despite an unresolved review bottleneck.
- Leaves the transition to an AI champion without owning its outcomes, or becomes the indispensable workflow expert. Claims productivity gains without evidence of team adoption, customer value, quality and cost.
Developing leaders
Evidence: A lead’s before/after scope, one coaching or performance example, and a former-report reference.
Green flags · meets bar
- Delegates real authority. Names leads who gained ownership of planning, design, delivery and people development. Explains decision boundaries and how oversight changed as their capability grew.
- Coaches and holds the bar. Uses specific feedback, development goals and follow-up. Describes a difficult performance decision, support provided, the outcome and what they learned.
- Builds durable capability. Shows leads handling trade-offs and setbacks independently, with credible succession or backup coverage. Former reports can corroborate increased scope and autonomy.
Red flags · below bar
- Keeps all meaningful approvals or bypasses leads to manage individual tasks; treats delegation as withdrawal of support.
- Avoids performance conversations or substitutes pressure for coaching; cites promotions or retention without evidence of improved leadership capability.
Team design & hiring
Evidence: An organization change and hiring decision, including constraints, ramp expectations and subsequent results.
Green flags · meets bar
- Designs around the work. Explains pod missions, service boundaries and cross-pod dependencies. Distinguishes a capability gap from insufficient capacity before changing reporting lines.
- Makes resourcing choices. Compares developing, reassigning and hiring against priorities, budget and ramp time. Can justify a role they chose not to hire and the delivery trade-off.
- Owns hiring quality. Defines the job bar, contributes to sourcing and structured selection, then checks onboarding and on-the-job outcomes. Shows how hiring evidence changed the process.
Red flags · below bar
- Uses headcount growth or an inherited org chart as the achievement; cannot connect staffing decisions to customer or delivery outcomes.
- Copies a larger company’s structure, hires for pedigree or assumes new hires remove dependencies without onboarding and ownership changes.
Product & delivery judgment
Evidence: A release that missed its customer outcome: scope choices, evidence, partner decision rights and the subsequent engineering action.
Green flags · meets bar
- Connects customer and platform value. Uses customer, Product, GTM and Solutions input to prioritize engineering investment. Explains architecture choices to customers and distinguishes reusable capability from a justified exception. Establishes support, upgrade and ownership costs before customer-specific commitments are promised.
- Makes credible commitments. Scopes a useful first release, exposes uncertain dependencies and agrees scope/date choices with Product. Explains how sequencing, technical debt and build/reuse/buy decisions affect the commitment.
- Owns release outcomes. Demonstrates improved delivery cadence with quality and recovery measures. Checks customer adoption after launch and adjusts when acceptance checks pass but the problem persists.
Red flags · below bar
- Treats tickets as sufficient customer context, dictates Product priorities unilaterally or routinely hands unresolved outcome problems back to Product.
- Promises dates before testing assumptions; relies on overtime, bespoke forks or additional features without a maintenance plan or success measure.
Leading change
Evidence: One change: baseline, pilot, knowledge transferred and effects on delivery and team trust; corroborate with an affected lead.
Green flags · meets bar
- Diagnoses before rollout. Identifies the constraint with affected leads and teams; distinguishes skill, incentives, tooling and capacity. Explains why the selected intervention addresses the cause.
- Tests a staged transition. Pilots with named owners, a baseline and stop/expand criteria. Plans coexistence, migration, rollback and capacity for learning while current commitments continue.
- Makes improvement stick. Coaches adoption, uses dissent as evidence, revises an ineffective process and transfers ownership. Verifies that a second person can operate a critical system independently.
Red flags · below bar
- Starts with a wholesale reorganization, rewrite or tool mandate; cannot explain sequencing or the cost to delivery.
- Counts training, documents or rollout completion as success without changed behavior, measured effects or sustained ownership after they step back.
Technical judgment
Evidence: A system/design decision and production failure; practical review plus the technical decisions below.
Green flags · meets bar
- Reasons across the system. Traces a customer action through UI, APIs, asynchronous workers, data and deployment. Compares service boundaries and communication patterns; can inspect code or telemetry to test an explanation.
- Protects correctness. Handles tenant authorization, stale approvals, duplicate messages and uncertain external-action results. Explains consistency, reconciliation and compatible schema/service releases with concrete verification.
- Balances operations and economics. Justifies capacity, latency, reliability and cloud-cost choices. Can challenge infrastructure recommendations and plan recovery around customer consequences.
Red flags · below bar
- Chooses microservices, a rewrite or scaling by preference; cannot describe failure behavior, the relevant state transition or a rollout path.
- Delegates all technical reasoning away or promises exactly-once effects without supporting guarantees.
Decision standard: use comparable past work, a live decision and corroboration together. Require evidence across all seven capabilities; do not average away an essential failure. A well-reasoned alternative can meet the bar. Assessors record decisions, personal contribution, results and ratings independently before debrief. Distinguish not assessed, insufficient evidence and demonstrated failure; assign an owner to each material gap.
How to test decision-making: establish what they personally owned, the support available, the strongest alternative, accepted downside, reversibility and evidence that would change their decision. Vary one consequential constraint and assess whether they revise the plan coherently. Probe when they intervened, how that strengthened a lead’s judgment, what worsened alongside an improvement, and what a failed hire or release changed.
Five core technical capabilities
Depth required: deep backend and distributed-systems ownership, with the current ability to personally deliver a feature across frontend, API, data, tests and cloud deployment. Require production experience designing or evolving independently deployed services and broker-based event processing. Establish this through shipped work and a few consequential decisions.
Beam context: inspected checkouts show a TypeScript/NestJS API, React/Next.js Studio, PostgreSQL, Redis, pg-boss and NATS JetStream, separate agent runtimes and document processing, plus container and GitOps deployment paths. Accepting work, executing it and confirming the customer outcome cross separate failure boundaries. Confirm active runtime versions, data ownership and production configuration before proposing architectural changes.
One customer outcome crosses several failure boundaries
- Experience Studio Submit work
- Control Beam API Authorize + persist
- Schedule pg-boss Initialize + dispatch
- Transport NATS Deliver execution message
- Execute Agent runtime Steps, tools + approvals
↩
Return path: versioned patches via NATS → API persists status → Studio updates and refetches
Accepted ≠ completed
Delivery ≠ business success
Retry ≠ safe repetition
Five technical capabilities: use one past shipped feature to establish experience, then a focused design discussion and code review to test current judgment. Credible end-to-end delivery establishes routine development and release competence. Probe supporting mechanics only when the evidence raises a concrete concern.
End-to-end feature delivery
Evidence: A feature they personally took from product intent to production; clarify their own code, key decisions and the customer result.
Green flags · meets bar
Can still ship independently. Explains a coherent solution across UI, API and data, shows what they implemented and can reason through a change to it. Their shipped work establishes routine testing and release competence.
Red flags · below bar
Only coordinated the work or built an isolated piece; cannot explain how the full feature works or make a concrete implementation change.
Microservices and event-driven architecture
Evidence: A production workflow spanning services and a queue or broker, with one consequential architecture decision.
Green flags · meets bar
Chooses and connects sensible boundaries. Explains why services are separate and when to use synchronous calls or events. Handles the consequences of delayed, duplicate or failed work without promising guarantees the system cannot provide.
Red flags · below bar
Names patterns without explaining their trade-offs; assumes message delivery means the action completed or that retrying is always safe.
API design and access control
Evidence: An API they designed for a real client or integration; examine one permission boundary and an ambiguous result.
Green flags · meets bar
Designs clear, secure contracts. Makes inputs, results and failure behavior understandable to callers. Checks what the acting user may do to the specific tenant’s data, including work executed in the background.
Red flags · below bar
Leaves clients guessing whether work succeeded, or treats login and UI restrictions as sufficient protection for every tenant, object and action.
Data design and consistency
Evidence: A data model they designed and a concurrent update or partial failure they had to handle.
Green flags · meets bar
Protects the business state. Explains where authoritative data lives, the transaction boundary and how conflicting or incomplete updates are resolved. Chooses a practical consistency approach for the customer consequence.
Red flags · below bar
Assumes separate database writes, messages and external actions succeed together; cannot explain which state to trust or how to prevent duplicate effects.
Coding-agent use and verification
Evidence: Their own agent-assisted change and a short live review of generated code.
Green flags · meets bar
Uses agents with technical control. Supplies relevant context, inspects the diff, explains the behavior and uses a meaningful check to establish correctness. Can debug and correct the result themselves.
Red flags · below bar
Accepts plausible code or green tests without understanding what they prove; cannot explain or repair the generated behavior.
Interview and assessment plan
Four interviews and three connected cases, supported by references.
The hiring journey4½ h interviews + up to 1½ h preparation
-
01 · Screen
HR30 min
Scope & fit
Career scope, Pakistan availability and expectations.
Entry requirements -
02 · Product & leadership
Saqib90 min
Product strategy & agentic practices
Prepared SDLC discussion and live pod-leadership case.
Cases 1 + 2 -
03 · Technical
Adeel120 min
Technical judgment
Past feature, focused design case and practical code review.
Case 3 + code review -
04 · Alignment
Founders30 min
Mandate & decision
Aqib & Jonas align on scope, authority and the first 90 days.
Final hiring decision
Before SaqibPrepare the agentic SDLC
Up to 90 minutes · two pages or five slides, including the lifecycle diagram.
Before the final decisionCorroborate with references
Check material leadership and delivery claims against the interview evidence.
HR · scope and fit
Verify the candidate profile, in-person availability and package expectations. Advance with established career and management scope, concrete examples and documented questions for later stages.
Saqib · product strategy and agentic engineering practices
Assess customer-outcome judgment, engineering priorities and leadership through pods. Discuss the prepared agentic SDLC and live pod case; advance when the candidate defends a workable approach and supports it with comparable past decisions.
Adeel · technical judgment
Start with a feature the candidate personally shipped to establish end-to-end experience. Use one connected case to probe two consequential decisions across service communication, API access or data consistency, then a short code review to test current coding-agent use. Use existing evidence across the five capabilities and follow up only on material gaps. Adeel provides the technical recommendation.
Founders · mandate and decision
Reconcile interview and reference evidence; align on the first 90 days, resources, decision rights and mutual expectations. The founders make the final hiring decision after resolving material evidence gaps.
Assessment coverage · proposed for calibration
| Capability | Saqib | Adeel | Founders |
|---|---|---|---|
| Independent ownership | ● | ○ | ○ |
| Agentic engineering practices | ● | ● | ○ |
| Developing leaders | ● | — | ○ |
| Team design and hiring | ● | — | ○ |
| Product and delivery judgment | ● | ● | ○ |
| Leading change | ● | ○ | ○ |
| Technical judgment | ○ | ● | ○ |
● Primary assessment ○ Follow-up or corroboration — No planned assessment
Case studies · design mandate for the interview owners
Purpose: test whether the candidate can solve the leadership and technical challenges above. Use three connected challenges at an engaging fictional B2B software company, with realistic customer stakes and constraints. This defines what the assessment must establish; Saqib and Adeel own the scenario, inputs, prompts and detailed scoring for their challenges.
1 · Engineering with coding agents
Saqib
Saqib
Goal and scope
Judge the end-state engineering organization: roles, pod responsibilities, shared capabilities, investment priorities and adoption through leads. The SDLC diagram should show how engineers obtain and verify customer context, make experience/design decisions within Product intent, use agents, verify outputs and learn after release. At each stage, make decision ownership and the evidence needed to proceed visible.
Structure and assessment
Prepared beforehand, then defended in person. Proposed cap: 90 minutes of preparation, two pages or five slides including an SDLC diagram; 25 minutes live. Look for clear ownership, justified investments, a staged transition and credible organization-level outcomes. Test how they choose autonomy boundaries and respond when skills, review capacity or incentives constrain adoption. Reward a non-obvious improvement in customer understanding or delivery when its benefit and downside can be tested.
2 · Leadership through pods
Saqib
Saqib
Goal and scope
Judge how they create independent ownership while delivery continues: pod boundaries, delegated decisions, coaching and performance, capability versus capacity, and knowledge transfer. Require choices about what to sequence, staff or defer within existing constraints.
Structure and assessment
Live discussion, proposed 20 minutes. Introduce a realistic tension between delivery commitments and leadership or coverage gaps. Look for a sequence of actions, accountable leads, an explicit trade-off and evidence that ownership has transferred. An org chart or hiring wish list is insufficient.
3 · Reliable cross-service delivery
Adeel
Adeel
Goal and scope
Judge how the candidate designs a feature across services and protects the customer’s data and actions. Focus on two consequential technical decisions and their ability to understand and correct agent-generated implementation.
Structure and assessment
Within Adeel’s 120-minute stage, use the first 90 minutes for the past-feature walkthrough and focused case, followed by 30 minutes of practical review. Vary one constraint to test how they revise a decision. Reuse evidence across the five capabilities; routine release, CI/CD, infrastructure and incident-process drills are unnecessary unless a material gap emerges.
Design standard: owners supply enough context to make the task answerable, define consistent assumptions and clarifications, and calibrate strong/weak evidence against the assessment bar before the first candidate. Separate candidate instructions from internal answer guidance when administering the exercise. Map case and past-work evidence to the seven capabilities; the technical areas elaborate technical judgment rather than create a second scorecard. Require a chosen course of action; permit different solutions when assumptions and trade-offs are sound.
Candidate experience: AI assistance is allowed; the candidate explains their contribution and how they checked the work. Prepared work is a bounded simulation, not production work for Beam. Send finalized preparation instructions at least three working days before the interview. Keep all three challenges within the stated time budget, with no additional homework. Accept sanitized examples or a detailed reconstruction of past work; confidential employer material is unnecessary.
Reference checks and hiring decision
With candidate consent, corroborate material claims with a former manager or Product partner and a lead they managed. Verify actual scope, delegated authority, a difficult performance or delivery decision, and whether improvements persisted after they stepped back. Use references to resolve specific gaps or contradictions in interview evidence. The founders review independent assessments and reference findings before deciding; enthusiasm for the proposed plan does not establish capability.
Recruiting execution
Calibrate the search and settle the terms needed to make commitments.
HR checkpoint, proposed
six researched prospects within five working days, including the returnee route. Record career dates, pod/headcount scope, product ownership, agentic examples, Pakistan fit and package expectations as verified, candidate claim or unknown. Calibrate with Saqib and the founders; Rabia is the proposed coordinator.
Before candidate commitments
settle city/office, compensation and relocation support, reporting line, employment terms, overlap/on-call expectations, budget, hiring/performance authority and architecture escalation; calibrate interview timings and criteria. Saqib and Adeel finalize their exercises from the case-study mandate; agree the first-three-month plan with the finalist. Keep sourcing confidential through outbound LinkedIn and a confidential Workable role. If the pool is thin, bring evidence to the founders before changing the bar.
First 90 days
Proposed outcomes to agree with the finalist and use in onboarding.
By day 90, the Head should have built and enabled accountable pods, helped shape the product roadmap, and increased delivery velocity through agentic engineering. The Head owns making this model work across priority product areas.
What we expect the Head to achieve
-
By day 30
Own the direction and transition
- Define pod missions, accountable leads and delegated decisions; agree staffing, coaching and the tools each pod needs.
- Review customer priorities with Product; propose roadmap opportunities, technical investments and trade-offs, with initial capacity and dependency estimates.
- Baseline delivery speed and quality; agree the agentic development workflow with leads and put initial improvements into use.
-
By day 60
Make the model work in delivery
- Staff priority pods and coach leads to run planning, delivery and engineer development; ship customer-facing work with clear service ownership.
- Co-create a prioritized six-month roadmap with Product, including engineering proposals, capacity, dependencies and credible near-term commitments.
- Use agentic workflows across priority pods; remove review and integration bottlenecks and measure early velocity gains alongside quality.
-
By day 90
Deliver sustained organization-wide results
- Pods have capable leads, clear ownership and the resources to operate independently through at least two delivery cycles.
- Help create and maintain the roadmap with Product; show how engineering input improved priorities, sequencing and commitments, informed by delivery and customer feedback.
- Increase velocity through team-wide agentic engineering, targeting 50% less scope-to-production time for comparable work with verified customer value and sustained quality.
01
Build, enable and empower pods
Each priority area has a clear mission, accountable lead, capable team and delegated decisions. Equip pods with customer context, tools, coaching and staffing. Leads independently own planning, delivery, quality and engineer development through at least two delivery cycles. Critical services have primary and secondary owners, tested recovery and clear escalation; routine execution no longer depends on founders or the Head.
02
Help create and improve the roadmap
Jointly shape a prioritized six-month roadmap with Product. Bring customer and production insights, technical opportunities and investment proposals into prioritization. Make capacity, dependencies and trade-offs explicit; agree credible near-term pod plans. Show which roadmap decisions engineering input changed, and keep the roadmap current using delivery evidence and customer feedback.
03
Increase velocity through agentic engineering
Every pod uses an agreed agentic lifecycle on suitable work, from understanding the problem through verified release. Enable adoption through training, shared tooling and review practices; remove recurring bottlenecks.
Proposed stretch target: reduce median time from agreed scope to production by 50% for comparable changes across priority pods. Demonstrate sustained gains and customer improvement within agreed quality and cost guardrails, tracking failed releases, defects and rework.
Agree the milestones, numerical stretch target, resources and decision rights with the finalist before joining. Establish the delivery baseline in the first two weeks. Improvements should reflect comparable work and customer outcomes across pods; smaller tickets or shifted work do not count as gains.