CTO Handbook

1.1Team Configuration

• Do: Establish small cross-functional teams who own outcomes end-to-end. Hold these teams responsible for measuring these outcomes. In the age of GenAI, a “one pizza team” is perfectly sized for agility: 1 PM, 1 designer, 1 data scientist (if needed) and a few engineers. If individuals are embracing hybrid roles, such as a PM doing design or engineering work, the team can be even smaller.
• Do: Let teams set their own norms: core hours, when to hold retrospectives, and whether to run sprints or kanban. Teams have the autonomy to decide for themselves.
• Do: Standardize what must be common across teams: bug severities, feature prioritization, product vernacular, customer support and customer implementation processes, logging, user analytics, the systems for documentation and issue tracking, and career ladders (see and ).
• Do: Add platform teams where there is genuine leverage. Platform teams provide the stable core, but they are not centralized gatekeepers nor are they the only teams that can contribute to this core. Good candidates for a cross-product platform group: user authentication, reporting and analytics, an LLM gateway or proxy, a data bus across products, shared components, and third-party integrations. Good candidates for intra-product platform group: authorization, data pipeline, standards around APIs + data access, and shared components.
• Do: Embed technical leadership within each team, but provide cross-team channels for peer review and best practice sharing, such as an Architecture Review Board (ARB). draws the line between a tech lead and a manager.
• Do: Every six months, rebalance teams around evolving business needs. Avoid permanent boundaries that become more important than outcomes, such as finding work to keep a team busy while higher priorities languish in backlogs of other products’ teams. Offer rotations to cross-pollinate (see for the cadence).
• Avoid: Never reallocate someone without extreme care; an allocation matrix is not just a numbers game but has profound effects on morale. Teams are “home base” for their members and reassignments can be disruptive. Where possible, ensure 1) the person affected is excited by the change, 2) any specific responsibilities held by that person for quality or operation of a feature are handed off cleanly, 3) the rest of the team feels good about the move too.
• Avoid: Avoid relegating quality assurance to a dedicated QA role. Quality is owned by the entire team: designers validate experiences, product validates outcomes, engineers automate tests (see ), and team collectively owns production issues.
• Avoid: Avoid creating an “us vs. them” culture that pits teams against each other. Teams should never compete on performance or battle over who gets to implement a feature.

1.3Span of Control

• Do: Keep management layers to a minimum. A hybrid manager can oversee up to 4 directs. An exclusive manager can oversee up to 8. Avoid overloading managers; beyond these limits they will not be as effective, and studies show manager quality is the key driver of employee retention. shows what the limits mean at scale.
• Do: Codify IC, technical leadership, and people management responsibilities in a career ladder (see and ), and offer rewarding career paths for any combination.
• Avoid: Don’t create manager-only roles unless the organization genuinely needs them. At scale, some management is inevitable; management as a status hierarchy is not.
• Avoid: Don’t pigeon-hole or force breadth. Offer opportunities where someone can flourish in areas where they have expertise or interest. Do not force “engineering” or “PM” or “management” silos. Do not force someone to manage.
• Avoid: Believing that GenAI innovations mean ICs no longer need as much management support as before is misguided. While ICs indeed need less support for routine unblocking and status reporting, they actually need more help with quality oversight, strategic alignment, and career mentorship than ever. It works out to a wash.

1.7Global Scaling

• Do: Hire globally for capability, not just arbitrage. Nearshore and offshore personnel should be treated identically as much as possible, for example access to the same training materials, meetings.
• Do: Operate with a remote-first mindset: design for asynchronous work from the beginning. Use written decisions (see ), accessible documentation, recorded demos, and explicit ownership to reduce dependence on meetings.
• Do: Use time zones as an advantage where possible. Handoffs should move work forward, not simply create queues between teams.
• Do: Preserve meaningful overlap. Distributed teams still need deliberate periods for collaboration, pairing, design, and relationship building.
• Do: Invest disproportionately in communication infrastructure: wikis, comments, bots.
• Do: Give every team the means to meet in person at least twice a year, but never require someone to travel.
• Do: Ensure proper guardrails for anyone working internationally, not just offshore personnel but travelling employees. Restrict access to customer data, production systems, and other sensitive information where required by company security policy and customer contracts. Enforce with firewalls/VPNs, not just words (see ).
• Avoid: Avoid scheduling meetings at difficult times for distributed members to meet, especially for standing meetings. For example, a 4 pm PT meeting in LA would be 1 am for a teammate in Poland.

1.8Offshoring

• Do: Work with the executive leadership team and the board to set a target for R&D cost as a percentage of revenue, and monitor it as a KPI (see ). Decide deliberately what offshore ratio the organization is aiming for rather than letting it drift with each requisition.
• Do: Concentrate the work with one or two key partners that have a footprint in several geographies. A short list buys a real relationship and consistent practices; multiple geographies spread regional risk and keep the sourcing options open.
• Do: Interview offshore candidates as if they were referred employees — the same loop, the same bar, the same rigor described in . Validate communication skills explicitly, because distributed work is written and asynchronous first (see ).
• Avoid: Don’t let the offshore bar drift below the onshore one. Offshore talent is expected to contribute at the same level as everyone else; when it does not, the problem is the partner or the loop that let them through, and it is fixed there rather than absorbed by the teams.

2.1Hiring

• Do: Hire highly motivated generalists who can operate in ambiguity. Especially at the leadership levels, optimize for judgment, curiosity, ownership, and learning velocity rather than narrow résumé credentials. Value intrinsic motivation over on-paper experience.
• Do: Hire for the organization you want to become, not the one you currently are. As the company scales, selectively add people who bring rigor without importing bureaucracy.
• Do: Expect everyone to contribute to the product. Engineers should understand customers; designers should understand technology; product should understand technical constraints.
• Do: Make “people who make other people better” a core hiring criterion. Hire for culture add, not culture fit. The test is whether someone raises the standard and widens the range of opinion in the room, not whether they resemble the people already here.
• Do: Let candidates see behind the curtain: sit in on a team meeting, and talk with anyone in the company they choose. Hiring is a two-way fit.
• Do: Find “hooks” to entice top talent (which is, effectively, just following this handbook): unlimited PTO, a focus on career development and DevEx, mission-driven work, above-average comp where possible, work/life balance, contributions back to open source projects, top-notch tooling and hardware, a culture where people help each other, and flexibility on where and when to work (limited core hours, or the ability to travel, even outside the country). Most of these are policies, and and cover how to set them.
• Avoid: Don’t turn hiring into a hazing ritual. Use realistic work based on “problems from the trenches,” structured evaluation, and multiple perspectives rather than clever interview puzzles. Run one standard plan: defined phases, assigned questions, and grading criteria for each interviewer to blunt bias, and a panel debrief where the interviewers decide together (see ).

2.3Onboarding

• Do: Every team maintains an onboarding document, and the newest member of the team owns it. They work through it, and they revise and improve it as they go — the person best placed to see what is missing is the person who just hit the gap.
• Do: Give every new hire an onboarding buddy: someone on their own team, and never their manager. The buddy is who they ask the questions they would not raise with a manager yet.
• Do: Give every new hire a checklist for their first day, week, month, and quarter. It is an amalgamation of company, department, and team tasks, maintained by HR, the department head, and the team’s tech lead respectively, so each layer owns the part it actually knows.
• Do: Pre-provision access to core infrastructure — SSO, GitHub, AWS or GCP, the password manager, the communication tools — before the start date. Day one is for setting up a local environment, not for waiting on administrative IT tickets. For anything that cannot be auto-provisioned, provide one unified, single-click place to request it, ideally inside a tool the new hire is already in, such as Slack.
• Do: Set the expectation of contribution in the checklist itself: a working development environment on day one, and a change in production within the first week. The size of the change does not matter; the fact that the paved road carried them there does (see ).
• Do: Hand over current product tutorials, walkthrough videos, and architecture documents, and ask for a review rather than a read. A new hire has the only fresh pair of eyes the team will get, and stale documentation is never more visible than it is in that first month.
• Do: See the mandatory training through to completion — security, compliance, and whatever else the company and its customers require. Track it rather than assume it (see ).
• Do: Include an explicit guide to how we build software here: the RFC and ADR (architectural decision record) process, pull request etiquette, code review expectations, testing norms, and what a blameless post-mortem actually looks like (see and ).
• Do: Outline incident management basics early. Every engineer should know how on-call escalation works, where the status pages live, and what makes an incident a Sev-1 — long before their first on-call shift (see ).

2.4Career Growth & Comp

• Do: Build parallel IC and management ladders with genuinely equivalent status and compensation potential (see ). Nobody should have to become a manager to advance.
• Do: Make expectations explicit at every level. Career ladders should describe scope, judgment, technical and product impact, collaboration, and leadership — not just years of experience.
• Do: Offer many methods of enrichment: monthly professional development days, annual multi-day hackathons, technical conference opportunities, biweekly tech talks, and perhaps even a formalized coaching program.
• Do: Reward increasing leverage, not increasing headcount. A Staff engineer who makes 30 engineers more effective can be more valuable than a manager with 10 reports.
• Do: Pay competitively and transparently enough that compensation isn’t a constant source of anxiety. Use market data, consistent leveling, and meaningful equity refreshes (see and ).
• Do: Be flexible wherever the work allows — part-time arrangements, shifted hours, a change of assignment. Offer it evenly to everyone, not just to whoever asks loudest.
• Do: Make career development an active responsibility of leadership. Regular conversations should focus on where someone wants to go, what they need to learn, and what opportunities will stretch them.
• Do: Promote on demonstrated performance against the career ladder (see ) — never for tenure, and never as a retention lever.

2.6Performance Management

• Do: High standards and high care are not opposites. Be explicit about what excellent performance looks like and equally explicit that people will be treated with dignity.
• Do: Feedback should be continuous, specific, and unsurprising — frequent, lightweight conversations beat the annual review every time. Partner with HR to move the formal process as close to a continuous model as the company allows (see and ); whatever annual review remains should summarize a year of conversations, never reveal previously undisclosed problems.
• Do: Be as candid as the situation allows and trust the team with the information. Share the worries alongside the hopes; rose-colored glasses are their own kind of disrespect.
• Do: Address performance issues early. Coaching, clarity, and support come before formal performance processes; prolonged ambiguity helps nobody.
• Do: Separate performance from potential (see ). Someone can be excellent at their current level without needing to become a manager or pursue ever-broader scope.
• Do: Build a culture of praise, celebration, and appreciation — including for the learning that comes out of a failure.
• Do: When someone must leave, do it decisively and humanely. Don’t keep people in limbo because leadership is uncomfortable making a difficult decision. Fail fast: once it is clear someone is unable or unwilling to perform, take the loss early rather than late.

2.8One-on-One Conversations

• Do: Make them own the agenda. Require them to populate a shared document before the meeting. This forces them to prioritize what they need from you: blocking issues, strategic alignment, or coaching.
• Do: Dedicate one session a month to the Individual Development Plan (IDP). Zoom out from the sprint cycle and actively map out growth opportunities (see ): who needs a customer site visit? Who is ready to lead a spike on a new technology? Who needs coaching to prep for an upcoming tech talk or all-hands presentation?
• Do: Normalize continuous feedback. Offer constructive, highly specific feedback on recent work, and explicitly solicit feedback on your own management: “What is one thing I could do this week to make your job easier?”
• Do: Track and review action items. Open the meeting by quickly reviewing action items from the last session. If you promised to unblock them with another team, confirm it happened. This builds deep trust.
• Do: Coach, don’t just solve. When they bring you a problem, resist the urge to immediately dictate the technical solution. Ask, “What approaches have you considered so far?” or “What’s your gut telling you?”
• Avoid: Don’t use the time for status updates. If you can read the update in Jira, Slack, or an email, it does not belong in the 1:1. Pivot status updates to asynchronous channels.
• Avoid: Don’t cancel. If a conflict arises, always reschedule within the same week. Canceling sends the message that they are your lowest priority.
• Avoid: Don’t do all the talking. A successful 1:1 should feature the employee talking 70% of the time and the leader talking 30% of the time, mostly asking probing questions. If your jaw is tired at the end of the meeting, you did it wrong.

2.9Skip-Level One-on-Ones

• Do: Focus on the macro environment. Ask questions about team culture, tooling, and processes: “What process is slowing you down the most?” or “Is the strategy we announced at the all-hands translating to your day-to-day work?”
• Do: Ask for feedback on their manager (your direct). Frame it constructively: “What does [Manager’s Name] do that you find really helpful?” and “Where do you think [Manager] could lean in more?”
• Do: Help them connect the dots. Skip-levels are a great time to explain the “why” behind high-level business decisions that might seem confusing on the ground floor.
• Avoid: Don’t override their manager. If a skip-level asks you for a decision (like a vacation approval, a promotion, or a tech stack change), do not make the call in the room. Say, “That’s an interesting point, let’s discuss it with your manager.” Overriding destroys your engineering managers’ authority.
• Avoid: Don’t turn it into a venting session without action. If they bring up a valid systemic issue, own it. But don’t let the meeting devolve into unproductive complaining.
• Avoid: Don’t keep your managers in the dark. Tell your direct reports you are doing skip-levels, explain the purpose (gathering systemic feedback, not spying), and share high-level themes with them afterward without breaking confidentiality.

3.1Product Development Lifecycle (PDLC)

• Do: Expect product, data science, design, and engineering to operate together throughout the lifecycle, even though PMs will contribute more at the bookends and engineers in the middle with the SDLC.
• Do: Embed GenAI throughout the entire lifecycle. AI assists with research synthesis, product thinking, UX exploration, specifications, architecture, implementation, testing, documentation, and analysis — not merely code completion (see ).
• Do: Hold retrospectives at least monthly (see ). They exist to celebrate what worked as much as to fix what did not.
• Do: Evaluate every roadmap item against the same criteria (see ). Prioritize actively and cull what fails.
• Do: Be explicit about whether a deadline is hard (a customer commitment that cannot budge) or soft (an internal objective). Ask the team to commit to a date; never impose one without their buy-in. Prefer ETAs to deadlines, and prefer ticket prioritization to ETAs.

3.4Software Development Lifecycle (SDLC)

• Do: Code is cheap; good ideas are scarce. Once AI can produce most of the code, the team’s bottleneck is no longer typing speed — it is the supply of well-formed ideas ready to build.
• Do: AI is a fundamental change to how the company builds software, not another developer tool rollout.
• Do: Use AI throughout the PDLC: customer research, competitive analysis, product requirements, UX concepts, prototypes, architecture, coding, testing, code review, documentation, analytics, support, and operations.
• Do: A good idea arrives with full context and works out ambiguity up front: product intent, acceptance criteria, architecture decisions, domain models, invariants, UX principles, non-functional requirements, examples, and edge cases. Often the best spec is not a PRD but a workable prototype.
• Do: Compress the feedback loop (see ). Go straight from idea to prototype to evaluation, rather than marching requirements through mockups, tickets, implementation, and QA before learning anything.
• Do: Use small batches and continuous delivery rather than large release trains. The organization should be optimized to safely change the product every day.
• Do: AI should be capable of producing most of the code, while humans own the engineering judgment. Engineers increasingly become architects, reviewers, validators, system thinkers, and owners rather than typists, and the scarce skills become problem decomposition, verification, taste, and understanding the business.
• Do: Build an AI-native engineering platform: approved models and tools (see ), secure context access, evaluation, observability, automated testing, and policy enforcement.
• Do: Treat AI fluency as an organizational capability. Teach people how to use it well rather than prescribing a single tool.
• Do: Evaluation follows a testing pyramid (see ), with most tests generated by AI from both the specification and the implementation.
• Do: Code review always begins with a GenAI first pass — correctness, consistency, DRY (don’t repeat yourself), architectural integrity, security — that tells human reviewers where to focus their judgment.
• Do: The quality bar rises as code generation gets cheaper. Automated tests, static analysis, security scanning, observability, review, and production feedback become more — not less — important.

3.7Developer Experience

• Do: Optimize relentlessly for developer flow. The best developer experience is one where the path from idea to production is frictionless.
• Do: Build a paved road: local development, CI, testing, deployment, observability, security, dependency management, and AI tooling should work by default.
• Do: Make organizational knowledge AI-accessible. Architecture, product context, APIs, incidents, decisions, and code should be discoverable by both humans and agents.
• Do: Keep organizational knowledge up to date by putting the documentation where the work happens. Tech Leads own the ADRs (see ) stored in version control; the on-call engineers own the incident runbooks attached to their services; and Product Managers own the design docs in the central wiki. Stale documentation is a liability. If a system changes, don’t count the pull request as complete until the documentation is updated as well.
• Do: Automate toil rather than adding process. Establish a strict toil budget: if a team spends more than 20% of their capacity on repetitive, non-creative manual work as quantified by tickets (see ; e.g., deployments, data backfills, ticket triage), pause feature work until the bleeding has stopped.
• Do: Defend the calendar as fiercely as the toolchain, such as no-meeting days.
• Avoid: Do not burn out your team. Set clear expectations that work/life balance is prized. For individuals who work overtime for some pressing need (push to deliver a feature on time, fix for a production issue, on-call incident, etc.), pay them back in some way, such as by offering additional time off.

3.8Automated Agents

• Do: Invest in the infrastructure that lets agents run unattended: a checked-out codebase, sandboxed runtime environments, realistic test data, and credentials scoped to only what the work requires.
• Do: Schedule agents to work autonomously through the backlog, starting with lower-priority bug reports. An agent can write the code, verify the fix, and code review its own work before a person ever looks at it.
• Do: Balance cost against capability by running open-weight models in the company’s private cloud alongside enterprise-licensed frontier models. Open-weight models are often less than a year behind the frontier, which is more than sufficient for many agentic tasks.
• Do: Schedule agents to diligently hunt for security vulnerabilities in the codebase and in a production-like environment, logging every finding with an assessed severity so it can be triaged like any other defect (see ).
• Do: Deploy self-serve agents where people already work — Slack and the other communication tools — connected to logs, databases, codebases, wikis, and every other source of institutional knowledge. Make them available under appropriate access restrictions across the entire business: learning, troubleshooting, ideation, customer support, and innovation. High-quality internal platforms are a prerequisite for turning AI’s individual productivity gains into organizational gains.
• Avoid: Don’t take the human out of the loop. Autonomous work earns a pull request and a final human approval, never a merge of its own.

3.10Operating Rhythm

• Do: Run the organization on a predictable rhythm. People can plan around a calendar they can see, and every ritual on it should have an owner and a reason to exist.
• Do: The rhythm is shared; the mechanics are not. Teams decide how a standup or a retrospective runs (see ), while the cadences below keep the whole organization in step.
• Do: Reserve the slowest cadences for the heaviest, most time-consuming decisions. Portfolio review each quarter, and resource reallocation and promotions every six months, so teams are not reshuffled or re-leveled on a whim (see and ).

4.1Measurement Principles

• Do: Measure outcomes and system health, not individual busyness. DORA metrics, product outcomes, reliability, customer impact, and developer experience should tell a coherent story.
• Do: Use SPACE-style thinking to understand productivity. Satisfaction, performance, activity, collaboration, and efficiency/flow provide a much healthier picture than commits, story points, or lines of code. Combine system telemetry (PR turnaround, build times) with developer sentiment (quarterly surveys on workflow friction).
• Do: Measure AI adoption by outcomes, not token consumption or generated lines of code (see ).
• Do: Standardize the definitions behind the numbers — ticket priorities, incident severities, what counts as done — so a metric means the same thing on every team.
• Do: All technical work should be accompanied by a ticket, even non-coding tasks. This makes it possible to track metrics like toil and unplanned work with minimal overhead (see ).
• Avoid: Never use productivity metrics as an individual performance weapon. Metrics should identify systemic constraints and opportunities for improvement.
• Avoid: Avoid OKRs (objectives and key results). They involve high overhead, yet ultimately provide competing north stars with other measures. Instead, use the roadmap as the objective and KPIs as the key results (see and ).

4.2The Scorecard

• Do: Nine metrics across four pillars: trust and reliability, execution and flow, business health and economics, and customer impact. Few enough to fit on one page; broad enough that no single number can look good while the organization gets worse.
• Do: Mindful of Goodhart’s Law, pair every metric with a guardrail that catches the obvious way to game it. Deployment frequency without change failure rate rewards reckless shipping; a falling cost ratio without outcome attainment rewards starving the roadmap.
• Do: Define each metric from the customer’s point of view wherever possible: incidents customers felt, latency customers experienced, outcomes customers received.
• Avoid: Deliberately leave SPACE and other developer-experience metrics off the scorecard. They are diagnostic tools for the engineering organization to improve itself, not a story the rest of the business needs to follow.

4.3Visibility & Review

• Do: Make metrics visible to the people doing the work. Teams should be able to see whether their changes are actually making the system and product better (see ).
• Do: One scorecard at every altitude (see ). The board, the executive team, and the delivery teams read the same numbers, so nobody is reconciling two versions of the truth.
• Do: Read trends, not points. A single quarter is a sample; the direction over several quarters is the signal, and a miss with a credible trend is not a crisis.
• Do: Status comes from the gap to target, never from a hand-picked color. Set targets explicitly and let the scorecard report against them mechanically.
• Do: See also : eNPS and other measures of team health, trended over time and reviewed with the team, sit alongside the scorecard rather than on it.

4.4Sample KPI Dashboard

5.1Tech Consolidation & Efficiency

• Do: Prefer boring infrastructure and differentiated features. Complexity should exist because it creates customer value, not because engineers enjoy operating it.
• Do: Continuously delete things. Old services, vendors, abstractions, feature flags, data pipelines, and code should have an expiration mechanism.
• Do: Standardize the platform; preserve freedom at the product edge. Tech leads can leverage their peers in architecture review board discussions when there are tough calls.
• Do: Use AI aggressively for modernization (see ). AI can map legacy systems, explain unfamiliar code, generate migration plans, write tests, update documentation, and accelerate large-scale refactoring.
• Avoid: Don’t consider architecture an annual review exercise. As it constantly evolves, keep documentation up to date (see ). Train up the team on all aspects with ongoing tech talks, including those that do not involve their day-to-day work.
• Avoid: Resist the call to chase the latest language, framework, or fad when the current choices are doing the job well.

5.2Strategic Tech Debt

• Do: Tech debt is a portfolio decision, not a moral failure. Some debt is absolutely rational.
• Do: Prioritize debt according to business impact: reliability, security, developer velocity, scalability, cost, and strategic flexibility. Use production evidence where possible (see and ).
• Do: Prefer incremental modernization over heroic rewrites, though a rewrite can be justified with a sound staged, funded plan.
• Do: Encourage teams to find an appropriate time allocation for tech debt reduction. For a typical maturing feature team, they should be addressing tech debt 20% of their time as noted in .
• Do: Ignore sunk costs. However much sweat equity or political capital went in, decide on what is best from here. Retire features, tools, or systems that are no longer the right choice for the next phase, however entrenched or expensive they were.
• Avoid: Don’t let “we’ll fix it later” become permanent architecture. Every intentional shortcut should be justified, then logged as tech debt for a future remediation with an assigned owner.

5.5Decision-Making

• Do: Classify a decision by impact and reversibility before choosing how to make it. Most decisions are two-way doors: they belong with the team closest to the work, and the ceremony is reserved for the ones you cannot walk back.
• Do: Match the method to the stakes. Analysis and consensus for the irreversible and high-impact; small hypothesis tests for anything easy to undo; consultation when specialized knowledge is needed but the owner keeps the call.
• Do: Write down the decisions that are hard to reverse — the context, the options considered, the owner, and the date — so they are never re-litigated from memory (see ).
• Do: Try to weakly hold strong opinions, that is, be open to changing your opinion. Disagree and commit. Rallying behind a final decision is more important than protracted debate or second-guessing. For especially tough decisions, try to build in optionality with checkpoints.

5.6Core Architectural Principles

• Do: Build vs. Buy: Buy commodity; build your differentiators. If a system does not provide a unique competitive advantage (e.g., authentication, generic CRM, standard monitoring), buy it. Reserve engineering capacity strictly for the core product.
• Do: Service Boundaries: Enforce domain-driven design. Defer breaking systems into microservices until the organization’s communication structure requires it; avoid creating a distributed monolith where independent deployments are impossible.
• Do: Multi-Tenancy: Architect for strict tenant isolation from day one. Define clear boundaries for logical separation (shared database, separate schemas) versus physical separation (dedicated infrastructure) based on the compliance needs of your enterprise customers.
• Do: The Data Platform: Treat data as a first-class product, not a byproduct of application state. Establish clear contracts for how data is published to the analytical ecosystem to prevent operational database migrations from breaking downstream pipelines (see ).
• Do: ADR & RFC Process: Require Architectural Decision Records (ADRs) or Requests for Comments (RFCs) for all irreversible design choices. Document the context, alternatives considered, and the final decision so future teams understand the “why” behind the code.

6.1Data Integrations

• Do: Treat integrations as products, not one-off projects. Clear contracts, observability, retries, versioning, and ownership are essential.
• Do: Prefer event-driven and API-based integration patterns where appropriate.
• Do: Design explicitly for imperfect external systems. Rate limits, schema changes, duplicates, outages, and partial failure are normal.
• Do: Make integration health visible to customers and internal teams.
• Do: Use AI to accelerate connector development while maintaining automated contract and integration testing (see ).
• Do: Continually experiment with ways to further streamline integrations. High-effort integrations do not scale.

6.2API Strategy

• Do: Design APIs for developers, not merely for internal architecture.
• Do: Consistency beats cleverness: predictable authentication, pagination, errors, versioning, idempotency, and documentation.
• Do: Treat API quality as part of the product and potentially part of the company’s strategic value.
• Do: Provide excellent documentation and examples — and make them AI-readable (see ).
• Do: Measure API adoption, reliability, and developer experience, not merely endpoint count.

6.3Strategic Partnerships

• Do: Partner when the relationship creates distribution, capability, or defensibility — not because “strategic partnership” sounds good.
• Do: Design integrations so the company retains control of the customer relationship and critical IP.
• Do: Make partner engineering accountable to product outcomes.
• Do: Build repeatable patterns for marketplace listings, co-selling, certification, and technical enablement.
• Avoid: Avoid partnerships that create permanent bespoke engineering obligations without strategic return (see ).

7.1Security & Compliance

• Do: Security is everyone’s responsibility, with specialized expertise where necessary. Mandate training to everyone technical at least annually. Ensure the OWASP Top 10 and threat modeling are part of all design discussions.
• Do: Governance: Set up proper security and compliance governance with documented policies, including a Security & Compliance team, Security Committee consisting of the security officer and technical leaders, and an AI governance committee to approve all LLM integrations (see ).
• Do: Data protection: Protect all data at rest and in transit with strong cyphers and disable weaker ones. Be mindful of data residency; for PHI and PII this may mean US-only storage and firewall rules to prevent international access.
• Do: Resilience: Ensure there are proper cross-region encrypted backups available. Set and test RPO (recovery point objective) and RTO (recovery time objective) at least annually. Use bar-raising RPOs and RTOs internally while advertising looser ones to customers.
• Do: Automate compliance evidence collection wherever possible. SOC 2 and ISO should be properties of the development system, not annual paperwork exercises. It is also what keeps the company diligence-ready (see ).
• Do: Use automated dependency, secret, vulnerability, and AI-generated-code scanning. Add monitoring and kill switches so failures demand attention.
• Do: Provision all systems with role-based access controls (RBAC) and multi-factor single-sign on (MFA SSO) under a principle of least privilege. Automate the review of permissions, especially when someone’s role changes.
• Do: Use a third party to perform penentration tests at least annually. Rotate vendors. Add a bug bountry program as budget permits.
• Do: Hold vendors to your own internal standard. Establish a formalized vendor risk management process to evaluate third-party tools, sub-processors, and APIs before they touch the production ecosystem or handle customer data. Ensure vendors sign BAA agreements if handling unencrypted PHI.
• Avoid: Don’t rely on security theater. Avoid creating complex, bureaucratic security policies that slow down development if you are not actively monitoring, testing, and enforcing those same policies in production.

7.2Reliability & Incident Management

• Do: Define SLOs around customer experience, not infrastructure vanity metrics (see ).
• Do: Teams own the services they build. You build it, you operate it.
• Do: Automate detection, diagnosis, rollback, and recovery wherever possible.
• Do: Incidents should produce learning and systemic improvement rather than scapegoats. Each incident should have a documented write-up spearheaded by the responsible tech lead and shared in a cross-product ARB setting for knowledge sharing within 1 week of incident closure. The document should include incident metadata, quantified customer impact, timeline of events, root cause analysis (RCA / “the five whys”), a reflection of what went well and what went wrong, and action items with logged tickets, assigned owners, and ETA.
• Do: Use reliability work to inform product and architectural priorities (see ).
• Avoid: Avoid names where possible in incident reports to promote a blameless culture.

7.4IP & Open Source Hygiene

• Do: Prohibit the use of strictly copyleft-licensed software (e.g., AGPL, GPL) in proprietary production code without explicit legal approval. Stick to permissive licenses (MIT, Apache 2.0, BSD) as the default. Inquire about licenses when discussing designs in architecture review meetings.
• Do: Establish a clear “path to open source” policy where the CTO + legal approves contributions, safeguarding internal infrastructure patterns, proprietary business logic, and engineers’ time.
• Do: For any company-sponsored open source projects, establish Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO). If an external developer submits a PR to your repo, you must ensure you have the legal right to use their code.
• Do: Standardize on enterprise-tier AI assistants where vendor agreements explicitly state your code and prompts will not be used to train their models.
• Do: Ensure every employee and contractor signs a Proprietary Information and Inventions Agreement (PIIA) before their first commit.
• Do: Define a clear policy on moonlighting and side projects. If prohibited by company employment agreement, allow an “escape catch” with CTO + Legal permission. Side projects are acceptable and even beneficial as long as they are built on the employee’s own time, using their own equipment, and do not compete with the company’s business.
• Avoid: Do not allow developers to paste proprietary source code, internal architecture diagrams, or customer data into public, consumer-grade AI models.
• Avoid: Avoid wasting effort on formalizing patents/inventions. Don’t pursue IP formalization as a knee-jerk reaction; make the decision based on defensibility, strategic importance, and the economics of protection.

8.1FinOps & Tech Budgeting

• Do: Position engineering leaders to own economic outcomes, not just technical outcomes, aligned with KPIs (see ).
• Do: Make infrastructure and SaaS costs visible at the product and service level.
• Do: Partner with the finance team to prudently capitalize engineering time in a manner that avoids manual bookkeeping or timesheets (see ).
• Do: Treat cloud efficiency as an engineering problem before treating it as a procurement problem.
• Do: Measure AI economics explicitly: model cost, infrastructure cost, engineering time, and resulting business value.
• Do: Optimize for gross margin and strategic leverage, not simply the lowest technology bill.

8.2GTM Partnership

• Do: Technology is a partner to Sales and Customer Success, not a fulfillment organization.
• Do: Make customer feedback directly visible to product and engineering teams.
• Do: Give team members standing opportunities to meet users and watch them work, and to sit in on prospect calls (see ).
• Do: Say yes quickly when the opportunity is strategic; say no clearly when it creates an unsustainable product.
• Do: Measure the opportunity cost of bespoke work. Create explicit rules for when it can be accepted that involve feedback from the technical team.
• Do: For customer support, define a strict tiering system to protect engineering flow. L1 is for frontline support to triage, L2 for the customer success team, and L3 is an escalation to engineering. Use a centralized issue tracker to capture categorization and reproduction steps.
• Do: Establish clear SLAs on customer issue resolution based on severity, e.g. severity 1 requiring an immediate interrupt vs. lower severity work that can go into the backlog (see ).

8.3Collaborating with C-suite peers

• Do: Make sure everyone can state the strategy and ensure the roadmap aligns to it. Focus on the mission and the customer; do not fixate on competitors or copy them.
• Do: Translate engineering details into customer and business outcomes.
• Do: Frame technical trade-offs as business risks. When advocating for platform investments or tech debt paydown, speak in the language of the C-suite: margins, onboarding speed, customer retention, and security liability (see ).
• Do: Help business peers understand technical concepts that are likely relevant to their role, such as how key features work (at a high level).
• Do: Provide a strong technical voice to ensure business decisions are made with full clarity on technical repercussions, such as unit costs, IP ownership, team morale, tech debt, and other factors.
• Avoid: Don’t expect a peer to care about the elegance of a data pipeline refactor. They care that if the bottleneck isn’t fixed, the platform cannot onboard upcoming enterprise clients without doubling cloud compute costs.
• Avoid: Don’t “go rogue” and build a technical strategy in an isolated vacuum. If your technical bets do not map directly to the CRO’s revenue targets or the CPO’s product roadmap, the organization is fundamentally misaligned. If you build something the business is not prepared to market, sell, and implement (all 3) don’t be surprised if it never gets used.
• Avoid: Don’t offer false certainty on greenfield R&D timelines. Avoid giving the executive team precise delivery dates on highly ambiguous projects; present ranges and confidence intervals, and communicate variance the moment it appears (see ).

8.5Executive & Board Visibility

• Do: Tell a simple story: what are we building, why does it matter, what did we learn, and what is getting in the way?
• Do: Expose risks early. Bad news should travel faster than good news.
• Do: Show technical investment as a portfolio: growth, reliability, efficiency, security, and strategic differentiation (see ).
• Do: Give the board confidence without drowning it in architecture diagrams. Good slides include 1) KPIs (see ), 2) strategic delivery & outcomes, 3) security & risk posture, and 4) financial efficiency.

8.6HR Partnership

• Do: Prefer unlimited PTO. Monitor usage, and encourage anyone under-using it to take at least three weeks.
• Do: Nix annual reviews, or at least work towards that (see ). Institute a comprehensive program of continuous feedback that encourages recorded peer and manager feedback. The goal is to share actionable feedback early and often, as opposed to waiting for a review period.
• Do: Ensure fair and equitable compensation with salary bands that are tied to each rung of the career ladder (see ), with separate bands per specialty (Engineering, Data Science, Design, Product Management). Benchmark with public and private sources and set bands at a fixed percentile above the mean, such as the 60th. Adjust comp internationally by a fixed percentage per region (EU, India, South America), and keep it equitable within each region.
• Do: Partner on measuring employee net promoter score (eNPS) and other measures of team health. Trend these over time. Meet with the team to discuss the results and push forward improvement initiatives to drive the scores higher (see ).
• Do: Set raises by formula, not by negotiation. Score everyone on the team the same way, keeping compensation equitable and removing as much subjectivity as the process allows. The manager’s judgment goes into the 9-box placement (see ), not into the number (see ).
• Do: Work to align the company bonus program to the calibration matrix, so there is a consistent methodology for rewarding high performers across salary and bonus.
• Do: If inheriting a team that has not had strict equity guidelines around salaries, make adjustments at each opportunity to even out.
• Avoid: Do not adjust pay across regions of the country. People move and it gets messy, since comp cannot be adjusted downward.

9.1Tech Diligence Preparation

• Do: Make the company diligence-ready continuously, not in the final 12 months.
• Do: Maintain an authoritative inventory of system architecture, networking architecture, data flows, public APIs, third-party integrations, security controls, IP, licenses (see ), and technical debts/risks. Automate as much of this as possible.
• Do: Eliminate tribal knowledge around critical systems. Ensure all infrastructure configuration and deployment is automated (IaC).

9.2Telling the Tech Narrative

• Do: Explain how the platform supports scale, margins, reliability, product velocity, defensibility, integrations, and future AI capabilities.
• Do: Be candid about technical debt. Buyers generally care more about whether you understand it and have a credible plan (see ) than whether the codebase is pristine.
• Do: Demonstrate the strength of the technical organization, not just the technology.
• Do: Show that the system can evolve without requiring the original founders or a few heroic engineers.
• Avoid: Don’t sell the architecture; sell the technical advantage.

9.3Post-M&A Assimilation

• Do: Protect the people who created the value, whichever side of the deal they sit on. Retention is not simply a compensation problem; autonomy, identity, and meaningful work matter.
• Do: When acquiring, finish the technical diligence the deal timeline cut short: who owns which system, the architecture as built, the tech debt and licensing obligations that came with it, and what the roadmap has already promised customers.
• Do: Score what that diligence turns up with the frameworks the rest of the organization already uses — the tech-debt portfolio in and the initiative scorer in — so inherited work competes for capacity on its merits.
• Do: Integrate deliberately rather than immediately standardizing everything. Identify which capabilities should be absorbed, preserved, replaced, or retired (see ).
• Do: Keep the acquired feature teams together and pointed at their own product. Ask what they need that they did not have before, and align their incentives with the scorecard everyone else is measured against (see ) rather than leaving them on the metrics of a company that no longer exists.
• Do: Give teams clarity about their future as quickly as possible.
• Avoid: Don’t let the acquisition destroy the operating model that made the company valuable in the first place, yet be rigid in thinking the operating model shouldn’t adapt to the new environment.