Why I still lock myself in a box to write code as a CTO

I am a CTO, and on any normal weekday at Buser, where I lead Engineering, Product, and since June 2026 Marketing, I know where my highest return for the business sits. It sits in talking to people. A thirty-minute conversation that aligns two areas before they spend three weeks pulling in opposite directions generates more value for the company than anything I can type into an editor that afternoon. The same is true when I sit with an engineer or a manager to draw more out of them than they thought they could deliver, or when I clear the coordination bugs between areas before anyone opens a pull request.

Even knowing that math by heart, there are days when all I want is to shut the door and live inside my little box, just writing code. No calendar mosaic, no context switching between paid search margins, hiring, and infrastructure, and no waiting weeks to find out whether a piece of feedback actually changed how someone works. Inside the box, the edges of the problem fit on one screen. The compiler answers in two seconds, the test passes or fails on its own merits, and by the end of the night there is a binary on disk that did not exist in the morning.

For years, standard management advice has treated that urge as a relapse that executives are supposed to cure once they take the chair. And sometimes going back to the editor really is an escape hatch. Still, when I look across Buser and the other businesses where I am or was a partner, many of the products and systems that moved the needle started with me locking myself inside that box. Prioritizing what we need to do as managers always comes first, yet making room to build with our own hands does something to an engineering culture that no one-on-one or town hall speech can do: it makes the team run after new knowledge and study on its own.

When the coding box is an escape hatch and where the books get it right

Management literature is hard on technical leaders who refuse to put the keyboard down, and the arithmetic behind that warning is sound. In High Output Management, Andy Grove defined a manager's output as the output of their organization plus the neighboring organizations under their influence. Once you sit in the CTO chair, your own hands stop being the primary unit of production. If you spend a Tuesday afternoon writing a service that a senior engineer on your team could write just as well, while three squads wait for a decision on scope, staffing, or commercial priorities, you are trading the throughput of forty people for the personal satisfaction of one diff.

Camille Fournier describes the psychological side of that trap in The Manager's Path, and Will Larson examines the organizational fallout in An Elegant Puzzle. Both point to the same mechanism: engineers get promoted because they are good at solving deterministic problems, while management is mostly non-deterministic. When two areas disagree on a goal, when a partner contract gets tense, or when you have to tell a direct report that their delivery is below the bar, the feedback loop is slow and uncomfortable. Retreating into your editor during those weeks is procrastination dressed up as work, because nobody can accuse you of slacking off while you are shipping commits.

I paid for that mistake early on at Nuveo, a company I co-founded in 2015 and stepped out of in 2018. As I recounted when writing about why I decided to start a company again, we hit a client delivery at Nuveo with almost no time left on the clock. Instead of splitting the problem across the team and trusting the people sitting next to me, I locked myself in my box to write the core of the delivery myself. The code I produced under that pressure was bad. It worked in production and delivered the result the client needed, so from a distance it looked like a rescue. In practice, I had chosen the worse path. Breaking the architecture into clean boundaries, handing the pieces to the team, and spending my own hours connecting their work would have shipped better software without turning me into a single point of failure.

That memory sets the order of operations for my week today. As managers, we have to prioritize what the role demands before what our habits prefer. Before I earn the right to disappear into a terminal, the human ledger has to be clear: priorities aligned across areas, hard conversations already held, and the team able to ship without waiting for my permission, which is why I have told my teams since 2021 that my goal as a manager is to be fired at the end of the day. Only when the organization is aligned does the coding box stop being a hiding place and become a lever for the business.

What was born inside the box at Buser and in the companies I backed

Where the management books stop too early is in assuming that every worthwhile technical bet inside a company can be discovered in a planning meeting and delegated through a backlog ticket. A roadmap only captures problems the organization already knows how to name. Another class of opportunity only appears when someone who holds the whole business in their head, from unit economics and partner dynamics down to infrastructure cost, sits alone with the raw material and tries to build a working first version. You cannot delegate a hunch that you do not yet know how to specify, and you should not pull a squad off its quarterly goal to chase an intuition that might prove wrong in forty-eight hours.

Several companies where I am or was a partner started or found their footing inside that box. Before Nuveo existed, another business where I was a partner ran into a severe financial crisis. Sitting in more alignment meetings was not going to fix the balance sheet. I took a few weeks isolated in my box to build a technical way out of the hole, and the software that came out of that stretch became the seed of Nuveo. Years later, after nine years acting strictly as a partner and advisor in businesses like Soluevo in recruiting and GoCache in application security, vinellu was born the same way in June 2025. My wife and I wanted a better way to catalog the wines we liked, and she took the CEO chair to build a B2B platform for wine retailers. The day after we talked about it, I went into my box, sketched the screens, wrote the pipeline that organized 118,000 unique wine labels, and pushed version 0.1 to TestFlight in October 2025.

At Buser, where engineering runs as a flat team reporting directly to me without middle management layers, the same dynamic produced two pieces of our current stack in 2026. The first was mcp. As I wrote in I sold my company and became an employee, I went into my box on nights and weekends to implement the Model Context Protocol and JSON-RPC from scratch in Go because I wanted to understand the wire format with my own hands rather than from vendor slides. Halfway through writing mcp serve, I saw the exact governance failure that was about to hit Buser as non-engineering areas connected models to internal systems: every session was burning context on dozens of tool schemas before the first prompt, and live credentials were spreading across personal laptops without an audit log or a clean split between read tools and write tools. That weekend study in my box turned into the MCP gateway and token governance architecture we run across the company today.

The second happened a few months after I took over Marketing in June 2026 and announced internally that Marketing was now MarTech. Most of my work in that transition was human alignment with the team around marginal return curves, attribution models that rewrite past weeks as data matures, and why brand investment cannot be judged by a seven-day click window. Yet when I looked at how paid search campaigns were actually built for our bus routes, there was a mechanical gap that meetings could not close. Early in October, I locked myself in the box on a Thursday night and wrote mads in Rust. You describe the business and routes in a TOML file, a model drafts the Google Ads account structure and copy, and deterministic Rust code checks twenty-four error rules before exporting a paused CSV. No marketer would have opened a ticket asking for a Rust rule engine over ad groups, and no engineer outside the marketing numbers would have known which twenty-four checks mattered. The tool existed because the person sitting at the junction of both areas went into the box and built it.

Why a manager who builds makes the team run after knowledge

Even if none of those prototypes had turned into production tools, going into the box would still pay for itself through its effect on the team's appetite to study. Every CTO says they want an engineering culture where people read papers, learn how their tools work under the hood, and push the technical bar up without waiting for a career development plan. The trouble is that most executives try to build that culture with words. They post links in Slack, approve book budgets, and repeat in all-hands meetings that continuous learning matters, while they themselves have not read a protocol specification or debugged a memory layout in five years.

Teams do not calibrate their effort by what leaders recommend in slides. They calibrate by what leaders visibly pay a personal cost to do. In psychology, Albert Bandura showed in Social Learning Theory that people adopt behaviors and internalize standards primarily by watching role models work through real friction rather than listening to abstract rules. Economists reached the same result through signaling theory: in his 1998 paper Toward an Economic Theory of Leadership: Leading by Example, Benjamin Hermalin demonstrated that when a leader has private conviction about how much a hard problem is worth, verbal encouragement is cheap talk. Followers only raise their own effort when they see the leader spend scarce personal effort on the problem first.

I watch that signal work every time I bring code out of my box. I am direct with my team that I do not treat studying as a romantic pastime. As I argued in Your manager doesn't owe you a career and in AI companies didn't stop shipping, our field moves every quarter, and mediocrity is a choice made in small daily concessions. Still, telling an engineer that they need "blood in their eyes" to study after hours rings hollow until they see the person running Engineering, Product, and Marketing do it first. When I read Martin Kleppmann's paper on move operations in tree CRDTs and implement it in Rust inside outl, as I described in From paper to outliner, or when I wire Clojure to Rust through GraalVM Native Image and C ABI in chrondb, the temperature in the room shifts.

No motivational speech is needed on Monday morning after that. When an engineer on the team sees the CTO fighting the Rust borrow checker, writing property-based tests for tree convergence, or measuring JSON-RPC payload overhead by hand, the comfortable excuse of "I had too many meetings this week to study" dies on its own. People open the repositories out of curiosity. They ask why a specific crate or storage layout was chosen, point out edge cases I missed, and go read the underlying paper so they can argue back on equal terms. A manager who still studies and builds in public creates healthy intellectual discomfort around them, and that discomfort is what pulls a team to go study without anyone taking attendance.

The rules that keep the box from hurting the chair

Keeping one foot in management and the other in the terminal only works if you enforce strict rules on yourself. The first rule is that my coding box can never sit on the critical path of a squad's delivery. If a checkout flow or a partner integration depends on the CTO merging a branch between board prep and one-on-ones, I have stopped multiplying the team and turned myself into the most expensive bottleneck in the building. What enters my box has to be detachable from the daily train: a zero-to-one prototype that proves a technical path exists, an internal CLI like mads or mcp that compresses a workflow, an architectural spike that answers an open question, or an open-source project where I can stretch my own ceiling without holding Tuesday's release hostage.

The second rule is that whatever comes out of my box gets zero immunity from the team's review or from reality. The worst version of the hands-on executive is the CTO who drops an untested prototype into production on Monday morning and disappears into meetings while the team cleans up the fallout. When I build or change a rule in our repositories, I own the regressions in public. Earlier this month in outl, I missed two sibling bugs in my own branch before my pre-PR review caught them. At Buser, when I tightened our repository merge gate in late September to require human approvals from area owners, the rule worked on paper and stalled our merge queue in practice because the pull request authors were already the area owners. When an engineer asked in our tech channel why their pull request suddenly needed a pile of approvals, I replied with two words: it was me. I measured the queue, rolled the gate back three days later to the minimum check that actually caught defects, and left only what worked.

That is the balance I try to keep in the chair. I do not lock myself in my coding box to pretend I am twenty-two again or to hide from the human conversations that move the company. I prioritize alignment and people first, because helping thirty or forty people work in the same direction at their best is how a business wins. And once that duty is paid, I close the door, open the terminal, and build, because the day the person leading technology stops studying and getting their hands dirty is the day the whole team quietly gets permission to stop studying too.

References

1. Grove, A. S. (1983). High Output Management. Random House.

2. Fournier, C. (2017). The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. O'Reilly Media.

3. Larson, W. (2019). An Elegant Puzzle: Systems of Engineering Management. Stripe Press.

4. Bandura, A. (1977). Social Learning Theory. Prentice-Hall.

5. Hermalin, B. E. (1998). Toward an Economic Theory of Leadership: Leading by Example. The American Economic Review, 88(5), 1188 to 1206.