Somewhere around the 30-person mark, I realized I hadn’t reviewed a pull request in weeks and the team was shipping faster without me in the code. No one really prepares you for that shift. But once the org crosses 50 people across four functions, the tech stack calls everyone romanticizes become the smallest slice of the week. The actual job is building a machine that routes decisions well without me in the loop.
I run engineering, product, design, and DevRel at Hiro: four functions, globally distributed, building developer tools for Bitcoin. Good instincts aren’t enough for that, so I built an operating system, and this is how it works.
The Two Layers
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 the strategic sensor array: partner conversations, builder needs, protocol governance, and the blind spots forming that the rest of the team can’t see because they’re heads-down building. Neglect the internal and the team ships in circles; neglect the external and we ship beautifully irrelevant software.
Neglect the internal and the team ships in circles; neglect the external and we ship beautifully irrelevant software.
The Strategic Layer
When we’re building infrastructure, the team is necessarily focused inward: the next release, the current sprint, the bug blocking a deployment. My job is to hold a wider aperture.
A significant share of my week goes to conversations that wouldn’t appear on any CTO job description: calls with exchanges discovering pain points in our APIs, builders who need capabilities we haven’t prioritized, protocol governance discussions where a design choice made today constrains what’s possible in eighteen months. My team isn’t going to flag that three different exchange partners are struggling with the same edge case in our transaction format, because no single person on the team is talking to all three. Partner conversations around Ordinals support reshaped our API roadmap faster than any internal planning cycle would have, and the builders told us what mattered before the data did.
The Internal Engine: Rhythms, Not Rules
An org is an organism with rhythms and energy cycles, not a machine. The operating system I’ve built tries to respect that instead of flattening it.
Monthly is where the org recalibrates: metric reviews, reliability reviews, infrastructure cost reviews, goal setting, and a Staff Engineers + EPD Managers sync that’s one of the most valuable meetings on my calendar.
Quarterly is where we pressure-test the bigger picture: deep product reviews, hard prioritization, honest accounting of which bets we’re making and which ones we’re explicitly not. These sessions are uncomfortable by design; if everyone leaves feeling good, we didn’t cut deep enough.
If everyone leaves quarterly reviews feeling good, we didn’t cut deep enough.
Bi-weekly keeps the cross-functional seams tight: an EPD managers sync to catch misalignment early, and 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. As needed is where architecture reviews, technical deep dives, and planning cycles live, scheduled when the decision demands it, not when the calendar says so.
The deep work blocks between these rituals are sacred. If I don’t have time to read a technical design doc or think through a roadmap shift, I’m just a meeting router. Every Monday I force-rank the three things that matter most that week: the three that compound, regardless of how loud everything else is.
Decision Routing: Zoom In, Zoom Out
The hardest discipline is knowing which altitude to operate at, not whether to make decisions.
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 two years. The failure mode is getting stuck at one altitude: always zoomed in and I become a senior engineer with a bigger title; always zoomed out and I lose touch with the system I’m making bets on.
The failure mode is getting stuck at one altitude: always zoomed in and I become a senior engineer with a bigger title; always zoomed out and I lose touch with the system I’m making bets on.
The reversible-in-under-a-week gate pushes an enormous number of decisions onto autopilot, where they belong. The teams that ship fastest are the ones where people stop waiting for permission on reversible calls.
The document-decision-and-rationale step serves as institutional memory. Six months from now, the reasoning behind a design choice shouldn’t live in a Slack thread that’s already scrolled into oblivion.
Leaning on Managers
At 10 people, I could hold everything in my head. At 25+, that’s impossible, and trying to maintain it is actively destructive. I had to believe that my engineering leads would make decisions as good or better than mine in their domain, precisely because they carry context I don’t have.
What I’ve put on autopilot: sprint-level decisions, implementation choices within agreed-upon architecture, routine partner support. What I never put on autopilot: protocol compatibility, major API surface changes, ecosystem partnerships, and team health.
DevRel and Design
DevRel reports to me, not to marketing. Under marketing it optimizes for reach, whilst under the CTO it optimizes for signal. Our DevRel team is the canary in the developer experience coal mine, catching the gap between what our docs say and what our tools actually do. That signal feeds directly into product prioritization, since a DevRel function that doesn’t change what gets built is just a content team with a fancier name.
If a DevRel function doesn’t change what gets built, it’s a content team with a fancier name.
Design in developer tools is similarly undervalued. APIs, explorer pages, and onboarding flows are all design problems pretending to be engineering problems. Having design in the room whilst we define the API surface has caught more usability problems than any amount of post-launch feedback ever did.
What Breaks at Scale
At 10, everyone knows everything and alignment is ambient, which feels efficient but is fragile. Once the team hits 25, though, people start making conflicting decisions in good faith because they no longer share the same context, and that’s the inflection point: either build the operating system or start firefighting full-time. By 50, the operating system itself needs versioning. The answer at each stage is the same: letting go of direct control in exchange for designed leverage.
The answer at each stage is the same: letting go of direct control in exchange for designed leverage.
The technology decisions that define a company are downstream of something more fundamental: how fast can the org learn, decide, and ship, and how well can it read the external environment whilst doing so? I’ve been writing about pieces of this for some time, from how we ship and hire to how we say no and build for protocol-level patience. They’re all organs in the same organism, and the operating system is what keeps them synchronized.