Three weeks before close, a buyer asked a simple question: "If your principal engineer is out for a month, what slows down?" The CTO shrugged and said: "only he knows the data plane and the deployment system end-to-end." Two days later, the investor requested a different model: not burn-down charts, rather bench depth. The code looked fine, the organization did not. The deal still closed, but with a holdback tied to succession, on-call health, and predictable delivery.

People risk is not soft. It shows up as missed roadmaps, fragile releases, and incident drag. This edition is about how diligence converts org charts and practices into execution forecasts.

Why this matters

Technology is a snapshot, but teams are the future. Investors don't buy the last release, but rather the next 8 quarters of predictable shipping under stress. The fastest way to de-risk that future is to look through the following angles and answer related questions:

  • Leadership & succession: Can the company survive vacations, attrition, or a sudden scale-up without changing its risk profile?
  • Org design & interfaces: Does the structure mirror the architecture and product boundaries with clear ownership and healthy surfaces to Product, Security, and QA? Where the company develops multiple products, the system should be shaped so each team truly owns a small, coherent slice, shipping without constant cross-team handoffs.
  • Execution health: Are delivery metrics reliable and used for improvement, not theater?
  • Culture behind the numbers: Do incidents create learning or blame? Are people burning out? Is knowledge durable and well organized?

Get these right and velocity compounds. Get them wrong and the cleanest codebase develops a limp.

What investors look for - beyond resumes

  • Leadership that operates, not just presents: Weekly decisions documented, architectural guardrails enforced, leaders who can explain trade-offs without deflecting. A named #2 for each critical area is nominated and explicit succession maps exist. If the CTO is still the de facto SRE lead, the risk goes up.
  • Org topology that mirrors the system and products: Service owners exist for every revenue-critical domain, with a platform team providing "paved roads" (CI/CD, observability, golden paths). Healthy IC/manager ratios and spans of control (managers with 5–8 directs is typical, 12+ hints at neglect, 3 or fewer signals micromanagement). If the company works with outcome-aligned product teams, boundaries should match that reality: "team = API boundary" where sensible, 1–3 services per team, and SLOs the team owns.
  • Execution that is measured and humane: Cycle time, deployment frequency, change failure rate, and MTTR matter, but only if coupled with on-call load and post-incident learning. A team shipping daily but paging people at 2 a.m. three nights a week is trading today's velocity for tomorrow's attrition. Investors might sample a quarter's worth of incident reviews and look for the words "we missed," "we changed," not "root cause: human error."
  • Talent engine, not heroics: A written Skill Level Reference Framework (SLRF), structured hiring loops, time-to-fill and time-to-productivity metrics in range, and an intentional contractor/agency mix. Upskilling ahead of the curve in areas like AI guardrails and core security shows the organization learns faster than the threat landscape evolves.

Outcome-first teams

Outcome teams as the default, not a dogma. There isn't a single "correct" org model, and early on a one-team mission can be the smartest move. That said, the pattern we most often see succeed at scale in software startups is empowered, outcome-aligned product teams: a PM–Design–Tech triad that owns a customer outcome and the small system slice needed to ship independently. Treat that as the default starting point in growth phases, then deviate deliberately when the context demands it.

  • Outcome first. Make the above-mentioned product team your atomic unit: a cross-functional squad that owns a customer outcome end-to-end and is accountable for impact, not a feature backlog.
  • System follows. Shape the architecture so that outcome is actually ownable: clear service/API boundaries, explicit data contracts, and runbooks so the team can ship independently. Aim for a small, coherent slice (often 1–3 services) with SLOs the team truly owns.
  • Platform as leverage. Keep a small platform group to build paved roads: CI/CD, observability and an Internal Developer Platform. Their job is to remove friction and cognitive load so product teams self-serve 90% of the time and approvals remain the exception.
  • Guilds for influence. Use lightweight chapters/guilds (design, data, security) to set standards and coach across teams, so autonomy doesn't decay into inconsistency.
  • The diligence question. Choose one customer journey and ask: How many teams must say "yes" for a small change to ship? If the answer is regularly more than two, you have an org/architecture mismatch. Fix it by moving ownership to the outcome team or reshaping boundaries until the system fits the team.

Stage and stake: how the lens sharpens

  • Seed/early A. Investors accept potential key-person risk if the team shows clarity: explicit owners, a realistic hiring roadmap, basic on-call rotation, and evidence of learning.
  • Series B/Growth. Expect real bench depth in platform and product, target IC/manager ratios, measurable delivery and incident health, and a working hiring machine that can add teams without collapsing the culture.
  • Control buy-outs. Buyers probe succession and knowledge transfer hard, might sample on-call calendars, review a quarter of incidents, and test whether the org can absorb a 2× customer load without a 3× increase in headcount.

Some patterns that work (and why)

  • Owner–operator maps with succession: a list of the top 8-12 domains (payments, auth, data platform, release train, AI pipeline, etc.). For each: owner, deputy, and "two things that break if both are out". Make the deputy a real shadow participating in rotation for design reviews and incident calls. This collapses key-person risk before it is priced into the deal.
  • Team topology mirrors architecture: small, cross-functional product teams own customer-facing domains and a platform group owns the paved roads (CI/CD, observability, developer portal, etc.). Security champions are embedded in teams. Clear service ownership means dependencies are known, incident paths are short. Where teams are outcome-aligned, keep "team = API boundary" a guiding rule and cap ownership at 1–3 services to manage cognitive load.
  • On-call health with SLOs and error budgets: rotation coverage is fair, out-of-hours pages are rare, and there's comp time/money for hard nights. Service SLOs feed error budgets; when they're blown, pause feature work and focus on reliability until you're back within budget.
  • Talent scorecards and predictable hiring: a skills matrix tied to the roadmap (what we need, by when), structured interviews with rubrics, and a standard onboarding path. Track time-to-productivity. Contractor reliance should be documented and tapered with knowledge transfer milestones.
  • Decision hygiene via lightweight documentation: ADRs capture why a choice was made, what alternatives were rejected, and the rollback plan. Postmortems are blameless and produce two classes of action: quick wins and systemic fixes. Decisions survive staff turnover.

Red flags that lengthen negotiations

  • A bus factor of one on anything revenue-critical is a major risk. For example, if "only Priya understands the data pipeline", the business is exposed.
  • There is a manager/IC imbalance when managers carry 12–15 direct reports with no time to coach, or conversely spend 80% of the week coding instead of leading.
  • A hero culture emerges when after-hours paging is chronic, there are no compensating policies, and "we pulled an all-nighter" is celebrated in Slack.
  • Metrics theater is evident when DORA charts exist but no decisions come from them and incidents routinely conclude with "human error" instead of systemic fixes.
  • Silo friction shows up when Security acts as a last-minute gatekeeper, QA remains isolated, and the Platform team is treated merely as a ticket queue.
  • Outsourcing as a crutch occurs when agencies run core operations without knowledge transfer and a single contractor effectively "owns" release automation.

One or two of these can be mitigated post-close, but 3 or more usually trigger a price adjustment, earn-out conditions, or a pause.

Habits worth adopting before the next round

  • Maintain a People-Risk Register: key domains × owner × deputy × risk notes × mitigation due date. Review monthly.
  • Publish an Engineering Operating Manual: how we plan, ship, staff, escalate, and learn. Make it part of the onboarding material.
  • Track delivery and well-being together: cycle time, deployment frequency, change failure, MTTR and weekly pager minutes per person. Act on both.
  • Institutionalize learning: postmortems with owners, deadlines, and follow-up audits, and quarterly "delete a process" reviews to keep governance lean.
  • Make onboarding a product: day-1 dev environment, golden paths, shadow rotations. Measure metrics like time-to-first-MR and time-to-on-call.

Mini-Glossary

  • IC: Individual Contributor (non-manager engineer).
  • Span of control: Number of direct reports per manager; extremes signal risk.
  • Bus factor: How many people can leave before a function stops; 1 is dangerous.
  • ADRs: Architectural Decision Records: lightweight docs of key technical choices.
  • SLO / Error budget: Service Level Objective and the allowed "unreliability" that guides when to pause feature work.
  • DORA (DevOps) metrics: Deployment frequency, lead/cycle time, change failure rate, MTTR (not the EU regulation).
  • Bench Depth Model: A talent management approach that measures how many capable successors are available for critical roles, assessing both readiness (ready now, soon, later) and coverage depth to ensure organizational resilience.

Your turn

What People-Lens surprise have you hit in a deal? A single-point-of-failure staff engineer, pager fatigue, or metrics theater? Share the scar; it helps the next team.

Next in the Playbook

I'll write about API Strategy & Integration Readiness in Edition 12. Stay tuned!

Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.