Here’s something I’ve learned the hard way scaling an org from a handful of engineers to 25+ across four functions: the CTO job is mostly calendar Tetris, priority triage, and protecting your own focus long enough to actually think. The tech stack decisions everyone romanticizes? Maybe 10% of the role. The other 90% is building the machine that makes decisions when you’re not in the room, and knowing when to zoom in on an implementation detail versus zoom out to where the ecosystem is heading.

I run engineering, product, design, and DevRel at Hiro. Four functions, globally distributed, building developer tools for Bitcoin. When you’re the integration layer across multiple disciplines AND the person on calls with major exchanges figuring out what they need from your stack next quarter, good instincts aren’t enough. You need an operating system.

This is the one I’ve built. It’s not finished. It probably never will be.

The Two Layers

When I talk to CTO peers in the ecosystem, the conversation usually splits into two camps: people who are obsessed with internal execution and people who live in the strategic layer. The ones I admire most run both simultaneously.

The internal layer is the execution engine: how the team ships, how decisions get routed, what rhythms keep a distributed org coherent. The external layer is what I think of as the strategic sensor array: partner conversations, builder needs, protocol governance, and the blind spots forming that nobody on your team can see because they’re heads-down building.

Neglect the internal and your team ships in circles. Neglect the external and you ship beautifully irrelevant software.

💡 Neglect the internal and your team ships in circles. Neglect the external and you ship beautifully irrelevant software.

graph TD
    CTO["CTO Operating System"]
    CTO --> INT["Internal: Execution Engine"]
    CTO --> EXT["External: Strategic Sensor Array"]

    INT --> SHIP["Ship Cadence & Rituals"]
    INT --> DEC["Decision Routing"]
    INT --> PEOPLE["Manager Leverage & Delegation"]

    EXT --> PARTNERS["Exchange & Partner Signal"]
    EXT --> ECO["Ecosystem & Protocol Governance"]
    EXT --> BLIND["Blind Spot Detection"]

    INT <-->|"Feedback Loop"| EXT

    style CTO fill:#2d3748,stroke:#e2e8f0,color:#e2e8f0
    style INT fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style EXT fill:#e53e3e,stroke:#e2e8f0,color:#e2e8f0
    style SHIP fill:#2b6cb0,stroke:#e2e8f0,color:#e2e8f0
    style DEC fill:#2b6cb0,stroke:#e2e8f0,color:#e2e8f0
    style PEOPLE fill:#2b6cb0,stroke:#e2e8f0,color:#e2e8f0
    style PARTNERS fill:#c53030,stroke:#e2e8f0,color:#e2e8f0
    style ECO fill:#c53030,stroke:#e2e8f0,color:#e2e8f0
    style BLIND fill:#c53030,stroke:#e2e8f0,color:#e2e8f0

The Strategic Layer: What’s Coming That Your Team Can’t See

When you’re building infrastructure, your team is necessarily focused inward: the next release, the current sprint, the bug blocking a deployment. That’s correct. That’s their job. My job is to hold a wider aperture.

I spend a significant share of my week in conversations that don’t look like “CTO work” on paper. Calls with exchanges trying to integrate Stacks and discovering pain points in our APIs. Builders spinning up projects on the protocol who need capabilities we haven’t prioritized. Protocol governance discussions where a design choice made today constrains what’s possible in eighteen months.

This is where blind spots get caught. No one on my team is going to tell me that three different exchange partners are all struggling with the same edge case in our transaction format, because no one on my team is talking to all three. I’m often the only person with the cross-cutting context to see patterns that span internal execution and external demand.

The signal from these conversations feeds directly into product prioritization. Partner conversations around Ordinals support reshaped our API roadmap faster than any internal planning cycle would have. The builders told us what mattered before the data did.

💡 The builders told us what mattered before the data did.

The Internal Engine: Rhythms, Not Rules

An org isn’t a machine. It’s an organism. It has rhythms, energy cycles, seasons. The week after a major release has a different metabolic rate than the week before a deadline. The operating system I’ve built tries to respect that instead of flattening it.

Here’s the actual cadence I run:

Monthly is where the org recalibrates. Metric reviews to see if what we shipped is moving the numbers we care about. Reliability reviews, because when your APIs serve billions of requests, you don’t get to treat uptime as someone else’s problem. Infrastructure cost reviews, because cloud spend has a way of compounding silently if nobody’s watching. Goal setting to keep the quarter honest. And a Staff Engineers + EPD Managers sync that’s one of the most valuable meetings on my calendar: the people closest to the architecture and the people closest to the teams, in the same room, comparing notes.

Quarterly is where we step back and pressure-test the bigger picture. Deep product reviews where we look at each product area end to end: what shipped, what didn’t, what the usage data is telling us, and what we’re hearing from partners and builders. This is where prioritization gets real. Not “stack rank your backlog” prioritization. The harder kind: deciding which bets we’re making for the next quarter, which ones we’re explicitly not making, and being honest about why. These sessions are uncomfortable by design. If everyone leaves a quarterly planning session feeling good, you didn’t cut deep enough.

💡 If everyone leaves a quarterly planning session feeling good, you didn’t cut deep enough.

Bi-weekly keeps the cross-functional seams tight. An EPD managers sync to catch misalignment before it becomes a fire. A Product + DevRel sync to make sure what we’re building and what we’re telling developers are the same story.

Weekly is exec strategy: the session where we zoom out from execution and ask whether the direction still makes sense given what we’re learning from partners, the ecosystem, and the market.

As needed is where some of the deepest work happens. Architecture reviews and technical deep dives don’t fit a recurring cadence because they’re driven by what’s in flight. A new API surface, a protocol upgrade, a scaling decision that’s going to be expensive to reverse. These get scheduled when the decision demands it, not when the calendar says so. Same with planning cycles: they happen at the rhythm the work requires, not on an arbitrary quarterly grid.

graph TD
    subgraph QUARTERLY["Quarterly Cadence"]
        QPR["Deep Product Reviews"]
        QPRI["Prioritization & Bets"]
    end

    subgraph MONTHLY["Monthly Cadence"]
        MET["Metric Reviews"]
        REL["Reliability Reviews"]
        COST["Infra Cost Reviews"]
        GOALS["Goal Setting"]
        STAFF["Staff Eng + EPD Mgr Sync"]
    end

    subgraph BIWEEKLY["Bi-Weekly Cadence"]
        EPD["EPD Managers Sync"]
        PDDR["Product + DevRel Sync"]
    end

    subgraph WEEKLY["Weekly Cadence"]
        EXEC["Exec Strategy Session"]
    end

    subgraph ASNEEDED["As Needed"]
        ARCH["Architecture Reviews"]
        DEEP["Technical Deep Dives"]
        PLAN["Planning Cycles"]
    end

    QUARTERLY -->|"set direction"| MONTHLY
    MONTHLY -->|"recalibrate"| BIWEEKLY
    BIWEEKLY -->|"align"| WEEKLY
    WEEKLY -->|"direct"| ASNEEDED

    style QUARTERLY fill:#2d3748,stroke:#a0aec0,color:#e2e8f0
    style MONTHLY fill:#2d3748,stroke:#a0aec0,color:#e2e8f0
    style BIWEEKLY fill:#2d3748,stroke:#a0aec0,color:#e2e8f0
    style WEEKLY fill:#2d3748,stroke:#a0aec0,color:#e2e8f0
    style ASNEEDED fill:#2d3748,stroke:#a0aec0,color:#e2e8f0
    style QPR fill:#805ad5,stroke:#e2e8f0,color:#e2e8f0
    style QPRI fill:#805ad5,stroke:#e2e8f0,color:#e2e8f0
    style MET fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style REL fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style COST fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style GOALS fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style STAFF fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style EPD fill:#38a169,stroke:#e2e8f0,color:#e2e8f0
    style PDDR fill:#38a169,stroke:#e2e8f0,color:#e2e8f0
    style EXEC fill:#d69e2e,stroke:#e2e8f0,color:#e2e8f0
    style ARCH fill:#e53e3e,stroke:#e2e8f0,color:#e2e8f0
    style DEEP fill:#e53e3e,stroke:#e2e8f0,color:#e2e8f0
    style PLAN fill:#e53e3e,stroke:#e2e8f0,color:#e2e8f0

The deep work blocks between these rituals are sacred. Not “try to protect.” Sacred. If I don’t have time to actually read a technical design doc or think through a quarterly roadmap shift, I’m just a meeting router. Focus management isn’t a nice-to-have when you’re spanning four functions; it’s structural integrity. The moment you lose it, you start making reactive decisions instead of intentional ones.

Every Monday I force-rank the three things that matter most that week. Not the three things that are loudest. The three that compound. Everything else gets delegated, deferred, or declined.

💡 Not the three things that are loudest. The three that compound.

The Fabric Underneath

Rituals keep the org running week to week. But there’s a layer underneath that determines whether the org is healthy over years: company values, culture, hiring practices and standards, career ladders. These are CTO decisions that don’t show up on any sprint board.

I set the engineering hiring bar. I define what “senior” means and what the path from mid-level to staff engineer looks like. I shape the culture around how we give feedback, how we handle disagreement, and what “ownership” actually means in practice versus on a slide deck. These aren’t HR tasks that I rubber-stamp. They’re the foundation that every other system sits on. Get the values wrong and no amount of clever meeting cadence will save you. Get the career ladder wrong and your best people leave for companies that take their growth seriously.

Decision Routing: Zoom In, Zoom Out

The hardest discipline I’ve had to develop isn’t making decisions. It’s knowing which altitude to operate at.

Some weeks I’m deep in a technical design review for an API change that will affect every Stacks developer. Other weeks I’m entirely zoomed out, thinking about how a protocol upgrade will reshape our product strategy over the next two years. The failure mode is getting stuck at one altitude. Always zoomed in and you become a senior engineer with a bigger title. Always zoomed out and you lose touch with the system you’re making bets on.

flowchart TD
    D["Decision / Issue Arrives"] --> R{"Reversible in < 1 week?"}
    R -->|Yes| AUTO["Autopilot: Team Decides"]
    R -->|No| CROSS{"Crosses function boundaries\nor affects external partners?"}
    CROSS -->|No| MGR["Manager Decides\n(inform CTO async)"]
    CROSS -->|Yes| SCOPE{"Affects protocol, ecosystem,\nor major partner relationships?"}
    SCOPE -->|No| COLLAB["CTO + Leads\n(30 min sync, then decide)"]
    SCOPE -->|Yes| ZOOM["CTO Zooms In\n(own it until resolved)"]

    AUTO --> LOG["Document decision + rationale"]
    MGR --> LOG
    COLLAB --> LOG
    ZOOM --> LOG

    style D fill:#2d3748,stroke:#e2e8f0,color:#e2e8f0
    style R fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style CROSS fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style SCOPE fill:#3182ce,stroke:#e2e8f0,color:#e2e8f0
    style AUTO fill:#38a169,stroke:#e2e8f0,color:#e2e8f0
    style MGR fill:#38a169,stroke:#e2e8f0,color:#e2e8f0
    style COLLAB fill:#d69e2e,stroke:#e2e8f0,color:#e2e8f0
    style ZOOM fill:#e53e3e,stroke:#e2e8f0,color:#e2e8f0
    style LOG fill:#718096,stroke:#e2e8f0,color:#e2e8f0

The “reversible in under a week” gate is the most powerful one. It pushes an enormous number of decisions onto autopilot, where they belong. The teams that ship fastest aren’t the ones with the smartest leaders. They’re the ones where people aren’t waiting for permission on reversible calls.

💡 The teams that ship fastest aren’t the ones with the smartest leaders. They’re the ones where people aren’t waiting for permission on reversible calls.

The “document decision + rationale” step at the bottom isn’t bureaucracy. It’s the only way a distributed team builds institutional memory. Six months from now, when someone asks “why did we build it this way?”, the answer shouldn’t live in a Slack thread that’s already scrolled into oblivion.

Leaning on Your Managers

The most important thing I’ve learned scaling this org isn’t about systems. It’s about trust.

At 10 people, I could hold everything in my head. Every decision, every context, every nuance. At 25+, that’s impossible, and trying to maintain it is actively destructive. This is where you learn to lean on your managers, and eventually managers of managers.

The shift is emotional, not structural. You have to genuinely believe that your engineering leads will make decisions as good or better than yours in their domain. Not because they think like you. Because they have context you don’t. They’re closer to the code, closer to the team, closer to the daily reality of what’s working and what’s friction.

What I’ve learned to put on autopilot: sprint-level decisions, implementation choices within agreed-upon architecture, routine partner support, most hiring pipeline stages. What I never put on autopilot: anything that touches protocol compatibility, major API surface changes, new ecosystem partnerships, and team health. The first category runs the engine. The second category shapes where the engine goes.

DevRel and Design: The Underrated Subsystems

Two quick notes on functions that often get left out of the CTO operating model.

DevRel at Hiro reports to me, not to marketing. When DevRel sits under marketing, it optimizes for reach. Under the CTO, it optimizes for signal. Our DevRel team is the canary in the developer experience coal mine. They catch the gap between what our docs say and what our tools actually do. That signal feeds directly into product prioritization. If your DevRel function doesn’t change what you build, it’s a content team with a fancier name.

💡 If your DevRel function doesn’t change what you build, it’s a content team with a fancier name.

Design in developer tools is similarly undervalued. Every API, every explorer page, every onboarding flow is a design problem pretending to be an engineering problem. The difference between a tool developers tolerate and one they advocate for is almost never raw capability. It’s cognitive load. Having design in the room when we define the API surface, not after, is a structural choice that compounds.

What Breaks at Scale

At 10: Everyone knows everything. Alignment is ambient. This feels efficient. It’s actually fragile, because it’s built on the assumption that everyone is in every conversation.

At 25: Ambient alignment dies. People start making conflicting decisions in good faith because they don’t share the same context. This is where you either build the operating system or start firefighting full-time.

At 50: The operating system itself needs versioning. The weekly syncs, the flat decision routing, the CTO-as-integration-layer model: it all starts showing cracks. You need layers of management. Not bureaucracy; leverage. The difference is whether those layers accelerate decisions or slow them down.

The hardest transition at each stage is the same: letting go. At 10, letting go of being in every conversation. At 25, letting go of making every decision. At 50, letting go of designing every system. Each step trades direct control for designed leverage.

💡 Each step trades direct control for designed leverage.

The Operating System Is the Strategy

The technology decisions that define a company are downstream of something more fundamental: how fast can your org learn, decide, and ship? And how well can it read the external environment while doing so?

That’s what an operating system is. Not a meeting cadence. Not a decision tree. A living, breathing system for turning ambiguity into shipped product, while keeping one eye on the horizon and the other on the ground.

I’ve been writing about pieces of this for a while now: how we ship releases, how we hire, how we say no, how we build for protocol-level patience, how we navigate an ecosystem that moves on its own timeline. They’re not separate topics. They’re organs in the same organism.

Build yours deliberately. Or it’ll build itself, and you won’t like the defaults.