← all writing

Finding the Craft Again

Staying close to the craft is not the same as doing it. What it took to close that gap as a founding CTO.

At Snapdocs, I was deeply technical but hands-off on code. I did architecture reviews. I participated in technical design. I could hold my own in any systems conversation. But I wasn't writing code. I wasn't in the implementation. I hired strong architects and engineers who'd been building systems and infrastructure for years. My job was to shape direction, not build the thing myself.

At Preset I was running architecture reviews, still in the room for technical decisions. But I'd also moved further into strategic product thinking, the layer above the systems, where you're shaping what gets built, not how. The altitude increased. The distance from the code grew.

I got good at that altitude. Zoom out. Prioritize. Delegate. Trust. Step in at design reviews, not pull requests. It worked. Both companies scaled. I scaled with them. So when I started building something new as a founding CTO, I brought the playbook that had made me successful. And for a while, I struggled with why it wasn't working.

Early-stage startups have a specific kind of silence. Not the silence of things running smoothly, but the silence of things not existing yet. There's no "how we do things here." No inherited architecture. No institutional memory. Every decision you make, or don't make, is foundational, whether you treat it that way or not.

I didn't treat it that way. I treated it like Snapdocs. Like Preset. I'd say things like: "Let's not over-engineer this early." Or: "We can clean this up later." Or: "I trust you to figure out the right approach."

These sound reasonable. They are reasonable in a context where "the right approach" has a default, where someone has pattern-matched this problem before, where there's enough structure for ambiguity to resolve itself. We didn't have that. We had three people and a very hard problem and no one to inherit clarity from.

The thing no one tells you about being hands-off is that it feels like wisdom. You're not in the weeds. You're not micromanaging. You're "letting the team own it." You get to stay at the level of strategy and architecture and vision while others handle implementation. It feels like leverage. It feels like maturity. Which is why it was so disorienting when I started to realize I was the problem.

I don't remember a single moment. It was more like a series of small frictions that didn't add up. Why does this system work this way? "It just evolved that way." Why did we make this tradeoff? "We had to ship." What happens when this breaks? Silence. I kept asking questions that no one had good answers to, and not because the team was weak, but because the questions had never been asked. The decisions had been made in the cracks. There was an abstract void, and nobody could step up to fill it.

I had delegated clarity that didn't exist yet.

Here's the thing that was hard to admit: I used to do this.

Years ago, before the titles and the scaling playbooks and the "operating at altitude," I wrote code. I built systems. I made architectural decisions with my hands, not just my opinions in a review. But I'd been away from it for a long time. And the distance had grown in ways I hadn't fully reckoned with.

The industry had moved. The tools had changed. The patterns I half-remembered were outdated. I wasn't just stepping back into building, I was starting over. Relearning things I once knew, except now I was slower, rustier, and surrounded by people who'd never stopped.

There's a specific kind of humility in that. Not the humility of doing work that feels beneath your title, but the humility of realizing how far you've drifted from the craft. That you stayed close enough to speak the language, but not close enough to do the work. And now you have to earn that back.

I remember sitting with a system design problem and feeling the gap between what I knew I used to be able to do and what I could actually do now. It's a quiet kind of vertigo.

So I went back to the beginning.

Not performatively. Actually. I relearned the fundamentals and how the new patterns worked, how the infrastructure had evolved, what "good" looked like now instead of five years ago. I built things badly and then rebuilt them. I asked questions I was embarrassed to ask. And slowly, I started to find it again. Not the old version, because that was gone. But a new version. Slower in some ways, more deliberate in others. Less clever, more careful. I stopped asking "what's the best practice?" and started asking "what breaks?" I stopped optimizing for speed and started optimizing for traceability. For systems that could explain themselves. For decisions that future-me would be able to reason about.

There's a small irony I think about sometimes. Starting with 0 commits and reaching 1,266 contributions in 2025. The graph gets denser as the year goes on: sparse in the early months, then building through summer, then dark green clusters in Q4 as the new patterns finally start to stick, and 151 commits in the first few weeks of 2026. The hardest work of the last two years hasn't been the kind that shows up cleanly. It's been internal: unlearning patterns, rebuilding intuition, sitting with the discomfort of being a beginner again at something I used to be adjacent to but never fully owned. The green squares are proof it happened. But even without them, I'd know.

I don't think "operator vs. builder" is the right frame. It's more like: different stages need different versions of you. And sometimes the version you need is one you left behind, except when you go looking for it, it's not there anymore. You have to rebuild it.

At Snapdocs, at Preset, staying hands-off on code was leverage. At an early-stage startup, it was abdication dressed up as wisdom.

The role didn't change because I wanted it to. It changed because the company needed something I wasn't giving it. And the hardest part wasn't the work itself, but accepting that staying close to the craft isn't the same as doing it, and that I'd have to close that gap myself.

I'm still in that process. There are days it feels like I'm back. Days it still feels like I'm catching up. But I don't think you get to build something new from altitude alone.

You have to go closer. Even when it costs you the story you had about yourself.

Anupreet Walia is CTO & Co-Founder of Brevian. Originally published on LinkedIn.