If you draw the org chart of any software company built in the last thirty years and squint, the same shape shows up.
There’s a small group at the top deciding why — why we exist, why this market, why now. Below them, a slightly larger group deciding what — what to build, what to ship, what to cut. And underneath both of those, the broad middle of the company, the part where the headcount actually lives — the how. Engineers, project managers, scrum masters, tech leads, engineering managers, program managers, who took the what and translated it into code, into tickets, into deployments, into release notes, into Slack messages in #releases.
I’ve been part of every layer. I’ve sat in the why room. I’ve run the what meetings. I’ve shipped a lot of how. I’ve also argued, for a long time and in a lot of rooms, that the middle of that pyramid was bigger than it needed to be — that leaders should be co-workers, not reviewers, and that managers who only managed were a tax the team paid for the privilege of having a status meeting. That argument never quite landed either. Same shape as the one I lost about tests — the cost was paid in slow, distributed ways that nobody in the room wanted to add up.
What’s on my mind a year into the agent shift is that the bill is finally getting itemised. And the line that’s getting cut is the one I’ve been pointing at for years.
Most of what we did in the middle was translation.
Business intent translated into product spec. Product spec translated into JIRA ticket. JIRA ticket translated into a branch name and a PR. PR translated into deployment. Deployment translated into a release note. Release note translated into a status update. Status update translated back upward into business language. Each step had its own ceremony, its own job title, its own meeting cadence. A whole industry of frameworks — Agile, SAFe, Spotify model, you name it — grew up around making the translation pipeline more efficient.
We were, mostly, glorified translators. I include myself in that. I include most of the best engineers I’ve worked with. The work was real and hard and required taste, but the shape of it was conversion. Take the thing in this language, output the thing in that language. Repeat.
⸻
The agent conversation keeps getting framed as “AI replaces engineers” or “AI replaces customer service” or “AI replaces analysts.” All of those framings are slightly wrong. AI didn’t come for a job title. AI came for a task type, and the task type it came for was translation.
If your job was mostly converting one well-defined input into a well-defined output — natural language to SQL, requirements to code, ticket to PR, design spec to working component, log line to incident report, customer email to ticket — your task got compressed by an order of magnitude. Doesn’t matter what your title was. The task was translation. The task got cheap.
The two ends of the pipeline didn’t get cheap. Defining why — the business reason, the strategic call, the bet — is harder than ever, because the cost of executing on a bad why just dropped to nearly zero, which means more bad whys are going to ship, faster, with more confidence. Defining what — the product call, the cut decision, the “we will not build that even though we could” — is harder than ever, because the cheaper execution gets, the more options you have, and judgement under abundance is its own discipline.
The middle is what got eaten. And the middle is where most of the org chart lives.
Hold that honestly. Not as a doom story. As a fact about the shape of work.
⸻
Here’s a hard one, because it’s about people I’ve worked with and respected. I’ve also been making this argument, in less direct language, for years — so this isn’t a new position, it’s an old one with sharper teeth.
A lot of engineering managers exist to coordinate translation. They run the standup. They unblock the ticket. They negotiate priority across teams. They write the status update. They translate engineering progress upward into business language and business priorities downward into engineering language.
That work was real. It was load-bearing. The pipeline didn’t run without it.
But if the pipeline itself is shrinking — if the layers between why and shipped code are collapsing because agents can carry more of the conversion themselves — then the manager whose entire job was coordinating the translators has a problem. The work that justified the role is dissolving.
I’ve watched two patterns emerge over the last year. One is denial — managers who quietly defend the rituals (the standup, the status meeting, the JIRA hygiene) because the rituals are what make the role visible. The other is the shift — managers who started writing again, designing again, defining again. Who picked up an agent themselves, not to prove a point, but because the org chart underneath them got smaller and the only way to stay useful was to be in the work.
I don’t think every manager needs to write code. I do think every manager needs to contribute — to the why, to the what, to the design of the harness, to the verification of the output. Coordination on its own is no longer enough. If a manager isn’t contributing to the why, the what, or the trust system that holds the how, it’s hard to say what they’re doing.
This isn’t a vendetta against managers. I’ve been one. I’ve hired dozens. The ones I’m most worried about are the ones who optimised so hard for being good at the translation pipeline that they forgot how to do the work that sat underneath the pipeline. The pipeline is getting smaller. The work underneath is getting bigger.
⸻
I’ve been sketching this on whiteboards with founders for months. Here’s the rough shape that keeps showing up.
A small group of people defining why, mostly unchanged. The why layer was always thin and is going to stay thin, because conviction doesn’t scale linearly with headcount. You don’t need more people to decide why; you need a few people who decide it well.
A larger group than before defining what. Not “product managers” in the old sense — not the ticket-writing, JIRA-grooming, sprint-planning archetype. People who can sit between the why and the agent, hold the context of what’s actually being built, and make the dozens of small calls per day about what “good” looks like. This is taste work. This is judgement work. This is what The Expensive Thing was about. The ratio of what people to how people is going to flip in the next two years, and most teams are not ready for it.
A much smaller group of people doing how — and the how people who remain are doing the hardest how work. Not ticket conversion. Architecture. Trust systems. Performance. The 5% of the codebase the agent shouldn’t touch unsupervised. The harness from The Tests We Skipped — the specs, the eval suites, the golden builds, the agent-of-agent review patterns. Someone has to design that harness. That someone is an engineer with deep judgement, and there are fewer of them on each team than there used to be, but each of them is doing dramatically more.
And then the agents themselves, doing the bulk of the conversion work. Writing the PR. Updating the doc. Filing the ticket. Drafting the release note. Reviewing each other’s outputs.
The team that’s left is smaller in headcount and broader in skill at every level. The middle thinned. The ends thickened. Coordination collapsed. Contribution went up.
⸻
The phrase “hands-on” used to mean writing code. It still does, sometimes. But the deeper meaning is being in the work — close enough to the output that you can see when it’s wrong, opinionated enough about the input that you can define what right looks like.
A founder writing prompts that drive an agent’s product roadmap is hands-on. A CTO designing the eval suite that gates production deploys is hands-on. A staff engineer specifying the contracts an agent must respect when modifying core code is hands-on. None of them are necessarily writing the code anymore. All of them are in the work. This is what I said years ago when I wrote that leaders should be co-workers, not reviewers — that passing down comments was the cheap version of leadership, and the real version was showing what’s possible by doing it. The agent era doesn’t change the principle. It removes the alibi.
What’s not hands-on is approving JIRA tickets in batches. Running a status meeting where everyone reads off their updates. Writing a strategy doc that nobody operates from. Sitting in the layer above the work, translating between what the team did this week and what the business wants next week. That layer is shrinking. The hands-on layer is the layer that survives.
This is uncomfortable for a lot of senior people. It was uncomfortable for me, when I started really sitting with it during the sabbatical. There’s an emotional reflex to defend the role you spent a decade earning. But the role was the org chart — and the org chart is changing.
⸻
Stop hiring for translation. Stop writing job descriptions that read like they were generated from a 2018 engineering ladder. Senior engineers whose pitch is “I can convert tickets to PRs faster than the next person” are going to be very confused, very soon, about what they’re doing every day. You don’t need them. You need engineers who can define a harness, hold the line on quality, and design systems an agent can safely operate inside.
Stop hiring engineering managers whose primary skill is coordination. Hire managers who can contribute — to design, to definition, to the trust system. The standup-runner archetype is over.
Hire more what people. Not product managers as ticket factories. What people who can hold a thesis, define “good” in ambiguous situations, and operate the agent themselves rather than handing intent over a wall to someone else.
Hire fewer people total. This is the hard one to say out loud. The team that does the same amount of work next year is going to have meaningfully fewer people. Not because the people were bad. Because the translation layer collapsed. Pretending otherwise leads to bloated orgs that move slower despite better tools, which is the worst of both worlds.
⸻
Don’t compete with the agent on translation. The agent will win. The agent will keep winning, faster, every quarter.
Pick up the work the agent can’t do. Define what “correct” means. Build the harness. Hold judgement. Take responsibility for outcomes the agent can’t be accountable for. Move toward the what and the why without abandoning the how — because the how people who survive are the ones who can still operate at the deepest layer when something genuinely hard breaks.
The middle is the dangerous place to be right now. Not because middle people are bad. Because the middle is where the translation work was concentrated, and the translation work is the work that’s going.
The good news — and I keep saying this because I believe it — is that this is a paradigm shift, not a job crisis. The work that’s left is more interesting and more valuable than the work that’s leaving. Defining the why and the what is more rewarding than running the standup. Designing the harness is more rewarding than approving the ticket. The shape of the team is changing because the shape of the work is changing, and the work is getting closer to what we always said we wanted it to be — judgement-heavy, hands-on, outcome-owning.
⸻
I started this post with the shape of the old org chart. Why at the top, what in the middle, how in the broad bottom layer, with a manager class running the seams.
The new shape is different. The why layer stays. The what layer grows. The how layer shrinks but gets harder. The manager class either contributes or disappears. The agents do the conversion work, with a harness around them.
That’s not a layoff plan. It’s an evolution of what work is. And every leader I’m talking to is feeling some version of it, even when they can’t quite name it yet.
The work was always the why and the what. We just spent thirty years pretending the how was the work, because the how was where the headcount was, and headcount was where the budget was, and budget was where the org chart was. The headcount is going to move. The org chart is going to follow.
The teams that figure out the new shape first are going to look unrecognisable to their competitors. Smaller. Stranger. More opinionated. Closer to the work. The harness from The Tests We Skipped is what makes this shape safe to operate — without it, the small team plus agents is a faster way to ship the wrong thing. With it, the small team plus agents is what the rest of the org chart used to look like before we built the translation pipeline on top of it.
That’s the shape I’m watching for. That’s the shape I think wins. And — for what it’s worth — that’s the shape I’ve been arguing for in different language for a long time. The agents are the deadline that finally makes the room move.
More to come.
]]>For most of my career I argued for writing tests.
Not quietly. In standups, in team rooms, in conference talks, in 1:1s with engineers I was trying to convince. I pushed for trunk-based development. I pushed for unit tests as the way you knew you hadn’t broken something that worked yesterday. I pushed against the pull request culture as it actually got practiced — not against review, but against the theatre of review we’d built around it.
Most people didn’t listen.
That’s not a complaint. That’s the starting condition. The conversation about AI and engineering has, in the last six months, started circling back to almost every position some of us were holding for twenty years — quietly losing the argument every quarter, watching the bug tracker fill up, getting the half-eye-rolls in standup. The new wrinkle is that the people rediscovering these positions are calling them new things. Spec-driven development. Eval-first engineering. Verifiable execution. New labels. Same practices.
This time, the industry doesn’t have a choice.
⸻
The argument was always simple, and I’ve made it a thousand times.
You write a unit test for two reasons. One: you want to know, today, that the code you just wrote does the thing you think it does. Two: you want to know, six months from now when somebody else changes something nearby, that the thing your code did then still works now. That’s it. Tests are not paperwork. They’re the thing that lets you sleep on Sunday.
The bug that comes back. The regression nobody saw coming. The release that broke a feature nobody was thinking about. Tests are the only protection any team has against those, and the protection is cumulative — every test you write today is a test that catches you next year, next refactor, next migration. Nothing else in software has that property. Documentation rots. Tribal knowledge walks out the door. Tests, if you keep them green, just keep working.
The argument against tests was always the same: tests waste time. I’d rather ship.
What that argument always dropped was the time on the other side of the ledger. Manual QA, run by hand, every release. The same regression test, executed by a human, again and again and again, because the team didn’t trust their automation enough to skip the manual pass. The bug that came back in production six weeks later because nobody wrote the test that would have caught it. The 4am incident. The customer escalation. The Sunday spent rolling back a release.
You weren’t saving time. You were deferring it onto people you weren’t counting in the same column. Often QA. Often support. Often the on-call engineer at 2am. The cost was always paid. The lie was that it wasn’t.
⸻
This is the other position I lost for twenty years. The agent conversation is finally surfacing it.
The argument: pull requests, as practiced in most teams, do not catch bugs. They perform the catching of bugs.
Here’s how it actually works in most places. An engineer writes some code. Opens a PR. The senior engineer assigned to review pulls up the diff in the browser, scrolls through it, leaves a comment about a variable name, suggests a tiny structural tweak, hits approve. They almost never check the branch out. They almost never run the tests against it. They almost never trace a function through the codebase to see what else it touches. The review takes ten or fifteen minutes — for changes that took the author days to write.
That ten-minute review accomplishes something almost worse than nothing. The author of the code, the moment the senior engineer hits “approve,” mentally transfers responsibility for the change. They wrote it. The senior reviewed it. It must be fine. When it breaks two weeks later, nobody quite owns it. Two pairs of eyes were on it. Neither pair did the actual work of verification. And nobody on the team wants to be the one to say so out loud.
I argued for years that this was upside down. That the right model was simpler: the person who writes the code is the person who pushes it to production. Full stop. Review is a conversation, not an absolution. The confidence to push has to come from the author’s own knowledge that nothing is broken — and the only way an author can know nothing is broken is if there are tests, run automatically, in a build they trust, on every commit.
No tests, no confidence. No confidence, no push.
The PR-as-rubber-stamp pattern was a comfortable lie that let everyone feel good about the process without anyone doing the work the process was supposed to be doing. It was a way to look like we cared about quality without paying the cost. I lost that argument too. Most teams kept the ritual. Most teams kept being surprised when production broke.
⸻
Here’s the part that’s funny, in a tired way. Watch the AI safety conversation closely for a minute. Eval suites. Tool-call sandboxes. Approval gates. Agent-of-agent review patterns where one agent writes the code and another reviews it and a third runs the tests. Specs as a first-class artifact. Spec-driven development.
Read those phrases as someone who’s been at this a while, and you’ll notice something. None of them are new.
Spec-driven development is BDD, and ATDD before it, and executable specifications before that. Eval suites are integration tests with a different audience. Agent-of-agent review is what code review was always supposed to be — finally executed by something with the patience to actually check the branch out, run the tests, and trace the change through the codebase. Approval gates are what release management always was, before “shipping fast” turned the gate into a sticker. Specs are specs. Tests are tests.
The conversation isn’t inventing engineering rigour. It’s rediscovering it.
What’s different is the loop. When AI ships your feature in three hours, the bugs ship in three hours too. Your blast radius compressed from a sprint to an afternoon. The instalment plan you were paying on quietly for twenty years just got called in. You can’t dodge the cost anymore by spreading it across enough days that nobody feels it.
The teams that argued against tests for two decades are now standing up eval suites because they have to. The teams that argued against trunk-based development are now adopting it because long-lived branches don’t survive a codebase being modified by agents. The teams that built the PR-rubber-stamp ritual are now watching agents review each other’s code and quietly wondering what their senior engineers were doing in those ten-minute reviews all those years.
The agents didn’t break the system. The agents just ran fast enough that the broken system stopped being invisible.
⸻
You can put a harness on AI. You should. Eval suites, sandboxes, approval gates, dry-run modes, agent-of-agent review — all of it good, all of it necessary.
But here’s the thing nobody is saying out loud. Every harness you build for the agent works for the human too. The eval that catches the agent’s mistake catches the engineer’s. The acceptance criteria that pin down the agent’s task pin down the engineer’s. The golden build that fails when the agent’s PR breaks something fails the same way when a human breaks it. You’re not building infrastructure for AI. You’re building the infrastructure you should have had all along — the infrastructure some of us were asking for in 2008, in 2014, in 2019 — and the agent’s arrival is just the deadline that finally moved the room.
The argument I lost for twenty years is the argument the industry is now winning, by accident, through the back door, because agents made the cost of not having the harness suddenly visible.
I’m not bitter about this. I’m relieved. The work I always wanted teams to do is the work teams are finally doing — not because they were convinced, but because the loop got short enough that they had no choice. I’ll take wins however they come.
⸻
I keep getting sent posts about spec-driven development as if it were a revelation. The first time someone DM’d me a thread on it, I laughed for a minute and then I felt old.
Specs were always the answer. BDD tried to make specs executable. ATDD tried to make them the source of truth. Living documentation was a phrase people used in the 2010s to describe exactly this. None of it caught on widely, because writing the spec felt slow and shipping felt urgent, and the cost of skipping the spec was paid by someone else, later — usually a QA engineer, a support team, or a 2am pager.
Now the spec is the thing the agent reads. It’s also the thing the test suite is generated from. It’s also the thing the eval is built against. Specs aren’t optional anymore because without them the agent is guessing and the team is hoping. So we get spec-driven development. Same idea, sharper teeth, new name.
I’ll take it. I don’t care what we call it. If the rebrand is what it takes for teams to finally take specs seriously, I’ll cheer the rebrand. Some of the best ideas in software take twenty years to get accepted, and they usually need a new name to get there.
⸻
I think about the engineers who argued with me, in standups, ten years ago, about whether we should have a test for this. I think about the teams that picked the PR ritual over actual review. I think about the people who said we don’t have time for tests and meant we don’t have time for the work of being right.
I’m not angry about any of it. Most of those people were doing what the industry was telling them to do. The industry has finally stopped telling them that. The shape of the work is making the case I couldn’t make, and making it more convincingly than I ever could, because the cost of skipping the harness shows up now in three hours instead of three quarters.
The tests we skipped are the tests the industry now has to write. Not because AI demands it. Because the work always demanded it, and the slow blast radius of the old world was the only thing letting us pretend otherwise.
The good news is that the work is finally easy enough to do. The bad news is that the excuse is finally bad enough to call.
More to come.
]]>Three months ago I wrote The Space Between Chapters. That was about the decision to stop. This one is about what happened after.
I’ve been advising founders, having long conversations with people I respect, and — mostly — paying attention to things I was too busy to notice when I was running in overdrive. Some of what I noticed was about them. Most of it, uncomfortably, was about me. Turns out when you’re constantly matching your potential and raising the bar, you build up a nice collection of stories about yourself that don’t hold up once you actually sit still and look at them.
These are six of those stories. I’m calling them comfortable lies because that’s what they are — things we tell ourselves that feel like ambition or discipline or strategy, but are really just habits we never bothered to examine. They’re comfortable because they sound right. They’re lies because they quietly do damage while we nod along.
⸻
Here’s what happens when you suddenly have time: you start perfecting things. That draft you never polished. That product idea you never fully fleshed out. That skill you always meant to sharpen. And because there’s no deadline forcing you to stop, you don’t stop.
I caught myself doing this within the first month. I’d work on something, get it to 90%, and then spend three times as long chasing the remaining 10%. Not because the 10% mattered — but because I could. Time was available, and perfection filled the vacuum.
I see this in founders too. The ones with runway and breathing room sometimes produce less than the ones with six months of cash and a fire under them. That always seemed paradoxical to me, but now I get it. When you have the luxury of perfection, perfection becomes the trap. It disguises itself as ambition. You think you’re being rigorous. You’re actually just avoiding the discomfort of shipping something that isn’t flawless.
“Done” is a decision you make. Perfection never makes it for you.
⸻
People love overdrive. Especially the best ones.
You figure out what you’re good at, you hit that gear, and then you stay there. Every day. Every quarter. You keep matching your potential, and every time you match it, you move the bar higher. Match, raise, match, raise. It feels like growth. It looks like growth. Everyone around you thinks you’re killing it.
But here’s what’s actually happening — you’re chasing your own known potential so hard that you never stop to look sideways. You’re so locked into being as good as you know you can be that you have zero bandwidth left to discover what else you could be. The overdrive becomes the identity. And then you’re not even choosing it anymore, you’re just stuck in it.
I’ve seen this destroy people. Not dramatically — quietly. They burn out not because the work was too hard, but because they never gave themselves permission to operate at anything less than their known max. They kept upping the game, kept raising the bar, kept pushing — and one day they looked up and realised they were exhausted and hadn’t learned anything new in years. All that potential-matching had turned into a treadmill.
What if you deliberately lived a little below your known potential? Not laziness — slack. The kind of slack where you take that random side conversation. Where you notice a problem you wouldn’t have seen because your brain was already maxed out. Where some idea shows up uninvited because there’s actually room for it to land.
The ceiling you know about is not the only ceiling that exists. You just can’t see the other one while you’re pressed flat against this one.
⸻
We’ve been taught to set big goals and reverse-engineer our way to them. Become healthy. Build a great company. Be a better parent.
The problem is, these aren’t goals — they’re identities. And identities are fragile. One bad week and “become healthy” feels like a failed project.
I’ve been experimenting with flipping this. Don’t make health the goal. Make exercising three times a week the thing you do. Eat sugar only on specific days. Stretch on alternate mornings. Eventually, health happens — not because you chased it, but because it was the byproduct of actions you actually controlled.
This changes how I think about strategy too. Strategic thinking doesn’t come from having a strategic goal. That sounds backwards, but stay with me. If you set “be strategic” as your north star, you end up paralysed by abstraction. But if you pick the right micro-actions — the daily, weekly, unglamorous inputs — the strategy emerges on its own. The byproduct is the strategy. The inputs are the work.
I keep telling founders this and watching their faces when it clicks. Stop measuring yourself against the identity. Start measuring yourself against the actions. Did you do the thing today? That’s the only question that matters.
⸻
This one is personal.
When you’re in motion — shipping, advising, building, scaling — everything looks like progress because you’re moving. You develop this optimism bias that’s almost invisible from the inside. The product is getting better. The team is growing. The metrics are trending up. So what’s the problem?
The problem is that motion makes you blind to specific things. The thing that’s quietly breaking. The feedback you’ve been deflecting. The pattern you’re too busy to see because seeing it would mean stopping, and stopping feels like failure.
I watched this in myself at every stage of my career — ThoughtWorks, CodeIgnition, Gojek, PeakXV. I was always in motion. And in the three months since I stopped, I’ve seen things I couldn’t see while running. Not because I’m smarter now. Because I’m still.
The most important realisations I’ve had in three months came from weeks where I did almost nothing. Your receptors open when you stop. You start hearing what was always there. Not because nothing is productive — but because nothing got out of the way.
⸻
There’s a growing anxiety that tech jobs are going away. That AI is making people irrelevant. I talk to people every week who believe this, and I understand why they do — the pace of change is genuinely unsettling.
But I’ve seen this before. Not this exact thing, but the shape of it. The industrial revolution didn’t eliminate work — it created entirely new kinds of work that nobody could have named ten years before it happened. What’s happening now is the same pattern. It’s a cognitive paradigm shift, not a replacement event.
I wrote about this in The Expensive Thing — when execution becomes nearly free, judgment becomes the expensive thing. The work that requires context, taste, human connection, and the ability to define what “correct” means? That’s becoming more valuable, not less.
I see massive opportunity here. I see a need for people to recognise their own importance in this new era. Humans will be required more, not less — but the nature of what they’re required for is shifting. The tools got dramatically better. The need for people who know what to build with those tools got even greater. If you’re paying attention, this is one of the most exciting times to be building anything.
⸻
I’ll be honest about this one — I haven’t figured it out.
What to do is not the problem. There is so much to do. Ideas, projects, people to help, things to build, conversations to have. The problem is that seeing all of it at once creates its own anxiety. Not the anxiety of having nothing — the anxiety of having everything and not enough hours. It makes me less calm than I want to be.
I’m learning — slowly, badly — that I can’t execute everything on my own. That sentence is easy to write and brutal to actually live by. And on the other side of it, I’m also learning that I can’t delegate everything either. Some things need my hands on them. Some things genuinely don’t. Figuring out which is which turns out to be its own full-time job, and I’m not particularly good at it yet.
Patience isn’t waiting. That’s the wrong definition. Patience is choosing what to do next without panicking about everything you’re choosing not to do. Three months of space have at least made me aware that this is the real work — not the tasks, but the calm required to sequence them.
⸻
Three months is not a long time. But it’s long enough to see something clearly: we are extraordinary storytellers — especially to ourselves.
Every one of these six things was a narrative I’d been weaving for years. Perfection is rigour. Running at full potential is discipline. Big goals are strategy. Motion is progress. I believed all of it. It was comfortable to believe, because it sounded like ambition. It sounded like someone who had their act together.
That’s the comfortable lie. It’s not the things we tell others — it’s the story we construct for ourselves and then stop questioning. We repeat it so many times that it stops being a narrative and starts being the truth. And the longer you run, the harder it is to see it for what it is, because examining it would mean stopping, and stopping feels like losing.
But when you do stop — when you put everything out there and just observe — things start surfacing. The narrative loosens. You see the gap between the story and the reality. Reflection becomes easier, not because you’ve become wiser, but because you’ve finally become still enough to look.
I’m still looking. More to come.
]]>In my last post I wrote about the small island of delight — the agent itself — surrounded by a sea of ops work. The note that followed that post was the most common: okay, I feel this. What are the walls, exactly? Name them. Make me a list so I can tell whether I’m about to hit one.
Fair.
This is that list. Ten things I keep seeing people run into when they try to run their own AI agent. I’m going to go through each one directly — what it is, what it feels like when it hits, what it actually costs. No pitches. Just the map.
A small note before we start. Most of these walls look trivial in isolation. Docker, right? TLS, sure. Memory, obviously. None of them is the problem. The accumulation is the problem. When you hit one, you lose an evening. When you hit six in a quarter, you lose the habit of using the agent.
⸻
This is the first and loudest complaint, and it’s not even close. People spend more hours on Docker, YAML, SSH, uptime, VPS sizing, and restart scripts than they spend talking to their agent. The official Docker setup needs at least 2GB of RAM. Cheap $5 hosts get OOM-killed in the middle of the night. You open a DigitalOcean community thread and watch people literally write “gave up.”
What hurts here isn’t that the infrastructure is hard. It’s that you’re doing infrastructure work to get to the interesting part, which is the agent. The ratio is backwards. You should be spending most of your time on what the agent does. Instead you’re spending most of your time keeping the agent alive.
The test: if a power cut or a kernel update would silently take your agent down and you wouldn’t know for a day, you’re on the wrong side of this wall.
⸻
Everyone’s favourite bug. OpenClaw gives you 100-200K tokens of context window, which sounds like a lot until you realise tool calls and file reads eat it in an afternoon. When the window fills, compaction kicks in — summarising older messages to free up space. And anything that wasn’t already written to long-term memory gets smoothed into a summary or disappears.
The pattern looks like this: the agent is brilliant for the first two weeks. Then, almost imperceptibly, it starts re-asking things you already told it. Brand guidelines. Your tone of voice. Your team’s name. You find yourself re-explaining, and you start wondering whether it’s you or the agent. It’s the agent.
People solve this by bolting on Mem0, Cognee, QMD, knowledge graphs — pick your acronym. Each works. None of them is the user’s job.
The test: ask your agent, today, about something you told it three weeks ago. If it stumbles, this is the wall you’re hitting.
⸻
138 CVEs in 63 days. 135,000 exposed OpenClaw instances found on public IPs. 824 malicious skills planted in ClawHub, with around 12% of the registry compromised at some point. None of this is hypothetical. These are numbers from February and March of this year.
The honest truth is that self-hosting an AI agent in 2026 is like running your own mail server. Can you do it? Yes. Should a non-specialist do it? Almost never. The attack surface is enormous, the threat landscape changes weekly, and the consequences of a mistake include someone else operating your agent — with your API keys, your data, your credentials.
Most people I talk to have no idea their gateway is bound to 0.0.0.0. They don’t have a firewall. Their fail2ban is aspirational. And they have no way to tell if something has gone wrong.
The test: if you were breached last Tuesday, how long until you’d know?
⸻
This one bites quietly and then all at once. OpenClaw’s heartbeat feature wakes the agent every thirty minutes by default, and every heartbeat carries the full session context. Add tool calls, long context windows, and a premium model, and you can burn a million tokens in an afternoon without trying.
I’ve seen this pattern several times now. Someone sets up their agent. First week, the bill is tiny — they didn’t use it much. Second week, more use, bill creeps up. Somewhere in week three, they check their provider dashboard for an unrelated reason and see a number that makes them close the laptop. The blog post “burned 1.8 million tokens in a month and got a $3,600 bill” is not a thought experiment. That’s someone’s real Tuesday.
The fix is routing — cheap models for easy tasks, premium for complex ones — plus heartbeat tuning, plus budget caps. All of it is doable. None of it is the user’s job.
The test: can you tell me, within 10%, what your agent cost you yesterday?
⸻
OpenClaw’s skills are MCP servers, which means they’re essentially little programs that run with full access to whatever you give them. The public marketplace — ClawHub — is open to anyone. One security study found 36.82% of community skills contained vulnerabilities. Another found 824 skills that were straight-up malicious, dressed up with professional documentation and innocent names.
The tricky part is that skills are the good thing about OpenClaw. The whole point is extensibility — agents that can actually do useful things in the world. So you need skills. But every skill you install is a supply chain decision, and almost no one is treating it that way. They’re treating it like installing a browser extension. That’s how credentials leak.
The test: name the last three skills you installed, and tell me who maintains them.
⸻
This one surprises people. Once your morning briefing works, it’s natural to think — what if I had one agent for writing, one for research, one for ops? Seems obvious. Seems like the future.
It turns out fewer than 10% of teams who attempt multi-agent setups keep them running. The coordination problems are brutal. Agents on a shared channel talk over each other, duplicate work, hand off in loops, argue. Every handoff burns tokens because every agent summarises before passing the baton. The concurrency caps hit faster than you’d expect. And debugging a multi-agent failure means tracing across multiple context windows that didn’t see the same thing.
Most “multi-agent” stories you read online are really one agent with better prompting. That’s often the right move. But when you genuinely need orchestration, OpenClaw gives you a pile of primitives and a lot of homework.
The test: if two of your agents had to hand work off to each other, could you trace the handoff when it broke?
⸻
OpenClaw added OpenTelemetry support in v2026.2, which is wonderful, and means you can now wire up your own observability stack. Prometheus. Grafana. Tempo or Jaeger for traces. A log aggregator. Dashboards. Alerts.
None of this comes out of the box. It’s all homework. And the people who need observability the most — the ones whose agents are doing real work — are precisely the ones who can least afford the three weekends it takes to build the stack. So they don’t build it. They run blind. Until something breaks and they’re debugging with grep on a log file at 11 PM.
This is the oldest story in ops. The tools are open and free. The time to make them useful is the real cost.
The test: if your agent took an action you didn’t expect last week, could you find out what and why, in under 15 minutes?
⸻
OpenClaw ships fast. v2026.3.22 alone landed 13 breaking changes along with 45+ new features. Old directory structures (.moltbot), old environment variable names (CLAWDBOT_*, MOLTBOT_*) get deprecated without fallback paths. If you’re on a version with known security issues, you have to upgrade. If you upgrade, something in your setup breaks.
I’ve watched people hit this and freeze. They know they shouldn’t stay on a vulnerable version. They also know an upgrade is going to eat a weekend, and possibly break the skill they’ve been building their workflow around. So they delay. The vulnerable window stretches. Eventually something forces their hand, usually the wrong way.
This is the classic unowned-maintenance problem. The agent is core to your workflow, but nobody is on the hook for keeping it current. So it falls to the person with the least time — you.
The test: what version are you on, and when did you last check for updates?
⸻
Solo use is the default assumption. Everything about OpenClaw — auth, config, channels, skills — assumes one person, one agent, one machine. The moment someone on your team says “can I have access too?” you discover that the answer is an hour of manual allowlists, Discord role hacks, and per-channel DM scopes.
There is no native RBAC. There is no team workspace. There is no way for one person to own the infrastructure and another person to own the agent’s behaviour. Community projects like Clawith and Mission Control exist to fill the gap, but they’re separate installs, with their own learning curves and maintenance.
Most real use cases become team use cases eventually. The agent that drafts your newsletter also drafts your cofounder’s newsletter. The agent that watches your CI pipeline also watches your team’s CI pipeline. When that transition happens, people quietly stop using it together and go back to using it alone.
The test: how would you give a colleague access to your agent for one week, then take it back?
⸻
This is the quietest wall, and in some ways the scariest. Agents hallucinate tool calls. They drift from goals in long sessions. They pattern-match on things that look like the user’s intent but aren’t. And you often don’t know it happened until someone downstream points it out.
There’s an emerging benchmark called PinchBench that targets ≥80% task completion and ≤5% tool-call error. Good targets. Also — 5% tool error is one in twenty. If your agent is acting on your behalf twenty times a day, one of those actions is likely wrong, in a way that might not be obvious.
The DIY answer is to build your own evals, approval gates, dry-run modes. Each of those is a small engineering project. Most people just… don’t. They cross their fingers and hope the agent’s next action is a good one.
The test: the last time your agent did something for you, how confident were you that it did the right thing — not the thing that looked like the right thing?
⸻
I don’t list these to be dramatic. I list them because every single person I’ve helped with OpenClaw has hit at least three of these walls, and most have hit six or seven. The failure mode isn’t hitting a wall — it’s hitting several, losing motivation, and quietly giving up on the agent.
That’s the outcome I most want to prevent. The agents themselves are extraordinary. The use cases are real. The value is there. What’s missing is a way to get to the value without the detour through the ops checklist.
Every wall on this list has a solution. Some are small — better defaults. Some are medium — a cost dashboard, an activity log, a curated skill registry. Some are genuinely hard — persistent memory, multi-agent coordination, team RBAC done properly.
None of them are the user’s job.
That’s the bet I’m making with ClawStation. Take the walls down, one by one, in an order that matches the pain. Don’t ask the user to become an infrastructure engineer, a security engineer, a memory architect, and an observability expert just to have an AI assistant that actually assists them.
The island should get bigger. The sea should get smaller. And the interesting work — the thing you wanted when you first got excited about agents — should be most of what you do.
⸻
If you’re hitting one of these walls right now, or you’ve hit one and walked away, I’d love to hear which one. The map gets better every time someone tells me where they got stuck.
More to come.
]]>Few months ago, a friend pinged me late one evening. He’s a founder — not a developer, but deeply tech-first. The kind of person who reads release notes for fun, runs Homebrew updates on a Sunday, tries every new AI tool the week it drops. He’d been playing with OpenClaw for a while. Getting the Gateway up, wiring Telegram, experimenting with skills. He loves this stuff.
His question was simple. Run OpenClaw on a dedicated Mac sitting in his home office, with full access to everything — or set up a VM and wire it up properly with all the bells and whistles?
The Mac was tempting. Low effort. Plug it in, install, done. But it felt fragile — a power cut, a reboot at the wrong time, a macOS update that decides to restart overnight, and the whole thing is down. Not to mention he’s on the road often.
The VM was the “proper” path. Reproducible, backed up, restartable, safe. But then we started listing what “proper” actually meant. Ubuntu image. Firewall. SSH keys. TLS. Bot tokens. A reverse proxy. Some form of monitoring. Log rotation. Restart-on-crash. Backups. A plan for what happens when OpenClaw pushes a breaking change next month.
He could follow all of it. He just didn’t want to own all of it. He’s a founder. He wanted to spend his Saturday playing with the agent and seeing what he could build with it. Not managing Ubuntu.
We spent the afternoon doing the VM path anyway. We got it working. He was happy. And somewhere between the third certbot renewal check and the fourth “wait, why is the gateway returning 502,” we looked at each other and had the same thought.
Why is this so much work? It shouldn’t be.
⸻
That week, I started writing a tiny script to automate what we’d done manually. Provision a server. Install OpenClaw. Wire up Telegram. Give him back a URL and a dashboard. I wasn’t trying to build a company. I was trying to save the next friend who asked.
Then another friend asked. Then another. Most of them were people like him — founders, investors, tech-curious folks who loved to tinker but didn’t want their weekends turning into sysadmin duty. A few had already tried and quietly given up, OpenClaw running on a laptop somewhere, forgotten after the first month.
And somewhere in there, I started thinking about my son. He’s young, he’s curious, he’s the kind of kid who will absolutely want his own AI agent — and he should have one. Not one he rents from a big company. One that’s his. That he can shape, teach, play with, break, and learn from. But I’m not going to hand him a Digital Ocean droplet and a TLS guide. He’d love the agent. He’d hate the setup. And that would be the wrong lesson.
At some point I realised I’d had the same conversation half a dozen times in a month. Each time with someone who was genuinely excited about what AI agents could do, and each time watching that excitement get sanded down by the yak-shaving required to run one.
So I asked myself — why not just let everyone in on this?
Not in a grand startup pitch way. In a small, “this seems useful, let’s make it easy for more people” way. That’s how ClawStation started. One evening, one friend, one decision between a Mac and a VM, and a growing certainty that this shouldn’t be as hard as it was.
No market analysis. No pitch deck. No competitive landscape slide. Just — if I can take the hard part out of this for one friend, I can take it out for a lot of people. Including, eventually, my son.
⸻
Something funny happens when you put a product in front of real people. They tell you things the product teams and the Twitter threads and the hot takes never quite capture.
The people I was helping weren’t developers. But they weren’t non-technical either. They were the people in the middle — the investors who know what a Docker container is but don’t want to debug one, the founders who can read a log file but don’t want to spend Sunday tailing it, the curious tinkerers who love the outcome of tech but not the drudgery of keeping it alive. That’s a huge and mostly unserved group.
The pain wasn’t that they couldn’t understand the infrastructure. The pain was that understanding it didn’t save them from having to run it. You didn’t get to build cool agent workflows. You got to debug why your TLS cert didn’t renew. You didn’t get to explore memory strategies. You got to figure out why the VPS ran out of RAM at 3 AM and took the agent down with it.
People fell in love with their agents. That part I expected. What I didn’t expect was how quickly they hit the next wall, and the one after that.
The morning briefing worked beautifully — until the API bill arrived and they didn’t know why it was $180. The content automation was magical — until the agent “forgot” the brand guidelines halfway through a newsletter. The bot was a lifesaver — until it was down one Tuesday and nobody could tell whether it was OpenClaw, the VPS, the network, or a skill gone rogue.
I started keeping a list. Not because I needed a feature roadmap, but because I kept hearing the same ten or twelve things. Memory that fills up. Token costs that surprise people. Security vulnerabilities arriving faster than anyone can patch them. Skills from the open marketplace that turn out to be malware. Upgrades that break everything. Teams that want to share an agent and can’t.
Each of these, on its own, is a solvable problem. The people I was helping could solve any one of them if they really had to. But none of them signed up to solve solvable problems. They signed up to play with AI. To build something. To see what was possible. The agent was supposed to be the point. Instead, the agent was the small island of delight surrounded by a sea of ops work.
⸻
I’ve been thinking about something for a while — and wrote about it in my last post. When execution gets cheap, judgment becomes the expensive thing. Agents compress execution to nearly zero. The question is what you actually do with that.
And the more I talk to people trying to use agents, the more I think the answer is: not enough yet. Not because they don’t want to. Not because they can’t grasp it. But because the plumbing keeps pulling them back from the interesting work.
88% of firms are using AI. Only 6% see real gains. That gap isn’t because the tools are bad. The tools are remarkable. The gap is because most people — and most organisations — are still stuck at step one. Getting the thing running. Keeping it running. Trusting it enough to let it do real work.
I’ve seen this pattern my whole career. At Gojek we scaled from 300,000 to 120 million monthly orders. At ThoughtWorks, at CodeIgnition, at every company I’ve advised — the hardest problems were never the ones in the spotlight. They were the quiet, boring, unglamorous ones sitting between a great idea and a working system. The plumbing. The wiring. The stuff nobody wants to think about but everyone depends on.
AI agents have the exact same problem. And right now, the plumbing is eating the time of exactly the people who should be out there exploring what these tools can actually do.
⸻
Honestly, I’m still figuring it out. ClawStation today is a simple thing — you sign in with Google, pick a model, connect a messaging channel, and in under a minute you have a personal AI assistant running on dedicated, secured infrastructure. No Docker. No YAML. No TLS renewal at 2 AM. It just works, and you still get SSH, a terminal, file access — the keys to the kingdom, if and when you want them.
That’s the principle. Remove the forced plumbing, not the control. If you want to go deep, we don’t stop you. If you just want the agent running so you can get on with the interesting part, you don’t pay the infrastructure tax to get there.
But that’s the beginning, not the end.
The thing I keep coming back to is the list I’ve been keeping — the walls that real people hit. Cost intelligence so you stop being surprised by the bill. Memory that actually persists across sessions. Security built in, not bolted on. Managed upgrades so you’re not stuck choosing between “vulnerable” and “broken.” Skills you can actually trust. Team workspaces for the inevitable moment when one person’s agent becomes three people’s agent.
None of this is glamorous. None of it is the stuff that makes for viral demos. But it’s the stuff between where we are and where we should be — where the island of delight is big enough that you don’t notice the sea anymore.
That’s the mission I’m slowly growing into. Not “let’s build another AI platform.” More like — how do we get everyone on AI, and what blockers can we solve along the way?
And when I say everyone, I mean it. Founders. Investors. Curious tinkerers. Small teams. My son, eventually. Anyone who wants to find out what they can do with a thinking, tool-using, always-on assistant — without first becoming their own IT department.
⸻
I took a pause this year. Wrote about that too. One of the unexpected things about slowing down is that it makes space for the small ideas — the ones that start with a friend’s question on a random evening, not with a strategy document.
ClawStation is one of those ideas. I don’t know exactly what it will become. I know what it’s solving for right now, and I know who it’s for — the people who love what AI can do and have hit the wall of what it takes to run. The founder, the investor, the tinkerer, the small team, the parent who wants their kid to grow up with this stuff, not watch it from behind a paywall.
And I know the direction. Each wall people hit is a blocker between them and the value AI can actually deliver. If I can take those walls down, one by one, quietly and well, then maybe a few more of the 88% become part of the 6%. Maybe a few more Saturdays get spent playing instead of yak-shaving. Maybe a few more kids get to grow up with an agent that’s genuinely theirs.
That seems worth doing.
⸻
If you’re someone who’s been wrangling with OpenClaw and hit a wall — I’d love to hear where you got stuck. If you’re someone who got it running and is now wrestling with memory or cost or security — I want to hear that too. These are the conversations that have shaped ClawStation so far, and they’ll keep shaping it.
The tool is free. The friction is not. My whole bet is that if we can remove the friction, the island gets bigger on its own.
More to come.
]]>Every conversation I’ve had in the past few months — with founders, board members, investors, government leaders — lands on the same narrative. Agents are here. They write code, handle customer calls, compress drug discovery from months to hours. Move fast or die.
I agree with almost all of it. And yet the conversation keeps missing the hard part.
There’s a heuristic making the rounds: AI agents can replace human execution wherever the output is verifiable. Wherever you can check whether the work is correct, an agent can do it.
This sounds clean. It’s also the most dangerous idea in tech right now — not because it’s wrong, but because it hides the real question. The hardest problem in the age of agents isn’t building them. It’s deciding what “correct” means.
⸻
I spent years scaling a platform from about 300,000 to 120 million monthly orders across Southeast Asia. At peak, we were running ~900 microservices, pushing thousands of deployments a week, with hundreds of engineers making changes every day — sometimes every hour. The engineering was hard. But the hardest part was never writing the code. It was defining what “working correctly” meant across all of that surface area.
What does “correct” mean for an ETA algorithm in Jakarta traffic versus Ho Chi Minh City? What does a “successful” driver allocation look like when you’re balancing earnings fairness, customer wait time, and fleet utilisation simultaneously? When hundreds of engineers are shipping into ~900 microservices around the clock, “correct” isn’t one definition — it’s thousands of definitions, all shifting, all context-dependent. These aren’t edge cases. They’re the entire job.
And they’re precisely the kind of judgment that agents cannot perform for you.
Think about it outside of software. A hiring rubric. A regulatory approval. A financial audit. In each case, someone had to define what “good” looks like before anyone could evaluate the output. The evaluator’s job looks mechanical — check the boxes, verify the criteria. But the person who designed the criteria? That was the real work. That was the judgment call.
Agents are the same. Everyone celebrates the agent that writes the fix, runs the tests, and deploys it without a human touching it. Sounds like magic. But someone designed those tests. Someone defined what “passing” means. Someone built the entire scaffolding that makes autonomous deployment safe. That human work is invisible in the narrative, but it’s the load-bearing wall.
The danger isn’t that agents will fail to execute. They’re getting scary good at execution. The danger is that organisations will deploy agents against poorly defined problems and mistake fast for correct.
⸻
The prevailing narrative frames this as adopters versus laggards. I think the real split is different. It’s between organisations that can change how decisions get made and those that can’t.
Here’s a number that should bother everyone: 88% of firms use AI, but only 6% see real gains. That’s not a technology adoption gap. Tools are easy to buy. That’s an organisational design gap. The 6% have done something much harder than purchasing AI — they’ve reorganised authority, changed decision structures, rebuilt workflows around what agents can and cannot do.
AI adoption is not a procurement decision. It’s a management topology change.
Most organisations aren’t built for this. They have approval chains designed for a world where humans execute every step. Middle management layers whose entire purpose is coordinating human workers. Incentive structures that reward activity over outcome.
Agents don’t fix any of this. They amplify it. Good decisions get executed faster. Bad decisions — or the more common disease, no decisions — also get executed faster. If your organisation struggles to define what success looks like today, agents will just help you fail at speed.
⸻
One more thing, because I keep hearing it — especially in Singapore: agentic coding will finally crack legacy modernisation.
I’ve spent a career in legacy systems. The productivity claims are probably true for the coding part. They’re also probably irrelevant. Legacy migration doesn’t die because of engineering capacity. It dies because nobody documented the business rules, because data quality issues only surface at migration time, and because every legacy system has stakeholders who benefit from it staying exactly as it is.
The bottleneck was never writing code. It was the courage to commit to change and the patience to understand what the existing system actually does. Agents don’t solve courage. They don’t solve consensus.
⸻
If verification is the key insight, then the strategic question isn’t “where can I deploy agents?” It’s “where have I already built the infrastructure that makes agent deployment safe?”
Define “correct” before you automate. The organisations seeing real gains aren’t the ones that moved fastest. They’re the ones that spent time on success criteria, test infrastructure, and feedback loops that catch failures early. Unsexy work. Also the moat.
Reorganise around verification, not execution. If agents handle execution, the human job becomes designing verification systems, defining quality, and handling the ambiguous cases agents can’t resolve. Your org chart should reflect this. Practically, this means your Monday morning standup changes. Instead of “what did we ship?” the question becomes “what did we validate?” Instead of tracking output, you’re tracking whether the output was right. The team that used to have ten engineers building features now has three engineers and seven people defining acceptance criteria, designing test harnesses, and monitoring outcomes. That’s the reorganisation. It’s uncomfortable because it demotes the act of building and promotes the act of judging. Most engineering cultures resist this. The ones that don’t will win.
Build for the judgment layer. The premium doesn’t just shift from executors to problem-framers. It shifts to people who can define what “good” looks like when the answer isn’t obvious. That’s taste. That’s context. That’s knowing how systems behave in the real world because you’ve shipped things that broke and had to figure out why.
Be sceptical of speed. Everyone’s celebrating compression — months to hours, years to days. Speed matters, but only downstream of correctness. Compressing timelines without compressing the validation process is just faster failure.
⸻
Here’s the thing the current conversation gets right, even if nobody says it quite this way: the age of agents rewards builders.
Not builders as in people who write code. Builders as in people who spot problems, construct solutions, iterate, and take responsibility for whether things work. People who’ve shipped things that broke at 3 AM. Who have scar tissue from production incidents and systems that behaved nothing like they did in testing.
Agents are force multipliers for this kind of person. They shrink the cost of trying. They compress the iteration loop. A single person with the right tools can now produce what used to require a large organisation.
But agents don’t replace the instinct for where a system will fail. They don’t replace the discipline to define what success looks like before you start building. They don’t give you taste.
The question I hear most is some version of: if you were building from scratch today, knowing that expertise is approaching free, what would you build?
Good question. But I’d reframe it.
If expertise is approaching free, what becomes expensive?
Judgment. The ability to define “correct” in a world where execution costs nearly nothing. The institutional muscle to verify outcomes, not just produce them. The taste to know what’s worth building in the first place.
That’s the expensive thing.
]]>Sometime ago, I decided to take a pause.
Not because something was wrong. Not because I was unhappy. But because something in me asked for it — quietly, persistently, the way your legs ache after a long run and you just know it’s time to stop. After so many years of running, I needed to catch a breath.
This January, I formally concluded my chapter with PeakXV Partners (formerly Sequoia Capital India & SEA). What a run it’s been.
If you’ve read my earlier post about joining Sequoia, you know I walked in exhausted — physically broken, mentally stretched, searching for a new rhythm after gojek. Sequoia, and then PeakXV, gave me something rare: a front-row seat to an ecosystem bubbling with ideas, energy, and ambition, while also giving me the flexibility to heal.
I have nothing but gratitude. But there comes a time when even gratitude isn’t enough reason to stay. You have to listen to that quieter voice.
I’m extremely grateful to Shailendra for bringing me into this journey. The mandate was clear from day one — help portfolio companies build and scale engineering teams, work closely with founders, be useful. Simple in words, enormous in practice.
Working at Surge with Rajan was one of those experiences that recalibrated how I think about early-stage companies. The energy in those rooms — founders pitching not just ideas but their lives, their conviction, their sleepless months — was electric. You can’t be around that and not be changed by it.
And then there were the conversations. Some of the most candid, unfiltered discussions I’ve had in my career happened in the corridors and coffee shops with people like Ravishankar GV and many other leaders at PeakXV. The kind of conversations where you walk in thinking you know something and walk out realising how much more there is to learn. That’s a rare and unique gift. I don’t take it for granted.
To the founders I’ve had the honour of walking alongside — your curiosity, your grit, your relentless pursuit of what’s possible — you inspire more than you know. I’m cheering for every single one of you.
I’ve been working since I was sixteen. Professionally since twenty-two. That’s decades of building, shipping, fixing, hiring, scaling, advising — decades of waking up with a to-do list that never got shorter. I loved it. Most days, I still love it. But somewhere along the way, the running became the default mode, and I forgot what it felt like to walk.
There’s a difference between choosing to work hard and not knowing how to stop. I was firmly in the second camp.
The truth is, I wasn’t burnt out in the dramatic, collapse-at-your-desk way. It was subtler than that. It was the slow realisation that I’d been so focused on being useful to everyone else that I’d forgotten to be present for the people who matter most — my family, my friends, myself.
Shraddha has been my anchor through every crazy ride. She’s stood alongside me — not behind, alongside — through moves across continents, through late-night calls that bled into early-morning calls, through the times when I was physically home but mentally still in some architecture review. She deserves more than my leftover attention. My kids deserve more than a father who’s always “just finishing one more thing.”
So I decided to stop. Not forever. Just long enough to remember what stillness feels like.
I won’t romanticise it. The first few weeks were uncomfortable. When you’ve spent your entire adult life with a packed calendar, an empty one feels almost threatening. I kept reaching for my phone, checking emails that weren’t urgent, looking for fires that didn’t exist.
I started reading without an agenda — picking up books because they looked interesting, not because someone recommended them for “leadership development.” I went for walks that didn’t end in a call. I cooked meals that took two hours because I wanted to, not because I was optimising for anything.
I spent mornings just sitting with my family. Not planning the day, not mentally drafting a response to someone’s Slack message. Just being there. It sounds simple. It’s embarrassingly hard when you’ve forgotten how.
But then something shifted.
The most surprising thing? Ideas started showing up uninvited. When you stop cramming every minute with productivity, your brain does something wonderful — it wanders. And in that wandering, it finds things you’d never have discovered while sprinting.
I want to be clear: this isn’t retirement. I’m not done. I’m just being more intentional about what I say yes to.
I’m continuing to work with people and teams where I feel I can genuinely help. Most recently, that’s been with Ally — thanks to Mohit — a not-for-profit focused on mental health. Mental health is something deeply personal to me. I’ve seen what happens when high-performing people ignore the signals their body and mind are sending. I was one of those people. If I can help build something that makes even a small difference in how we talk about and support mental health, that matters more to me than any title on a business card.
I’m also advising a few founders, organisations and teams on things I care about — engineering culture, product-market fit, new tech adoption, keeping things simple, the “how not to fail” conversations, and the messy human side of scaling. But I’m doing it at my pace, on my terms. Choosing based on impact, not obligation.
There are so many people I want to thank — colleagues, ex-colleagues, friends who somewhere along the way became all three. I know that even if I try very hard, I’ll miss names. So I won’t try. You know who you are, and you know what you’ve meant to this journey.
To the entire PeakXV family — it’s been a privilege. Genuinely. Not the LinkedIn-post kind of “privilege” that people throw around. The real kind, where you look back and think, “I can’t believe I got to be part of that.”
To the ThoughtWorks family that gave me my foundation. To CodeIgnition, which became a big family that still loves each other, and eventually found its way into Gojek. To the Gojek family that tested every limit I had. To every team that trusted me with their problems and their people.
And to my family — my mother who worked tirelessly on both fronts, my siblings who showered unconditional love, Shraddha who made all of this possible, and my kids who remind me every day what actually matters. They’re also my harshest critics — which sometimes leads to unpleasant conversations, but that’s life. As Sadhguru says, “Isn’t it?” hahaha.
Honestly? I don’t know. And for the first time in a very long time, that feels refreshing rather than unsettling. Right now it’s just daily tinkering…
I haven’t mapped out the professional journey ahead. I’m letting curiosity lead for a bit. Meeting interesting people, exploring ideas that spark something, and staying open to whatever comes next. My calendar is friendlier than it’s been in years.
If you’re building something interesting, thinking through a hard problem, or just want to catch up over coffee — I’d love to hear from you.
More to come. For now, this is me saying — thank you, and see you around.
]]>I need to tell you something that might sting: your CEO doesn’t care about your code.
No one cares whether that button was built with HTML, Flutter, React, React Native, or native iOS/Android—as long as it works, reliably, every single time someone taps it. I know that might be hard to hear, but it’s the truth. Your CEO doesn’t wake up thinking about test coverage, CI/CD pipelines, or whether your architecture is beautifully modular. They wake up worrying about payroll, churn, runway, and whether the sales team has enough momentum to close this quarter.
And this is where we, as CTOs, often fail. We walk into boardrooms armed with diagrams that look like circuit boards, latency charts, and words like “refactor,” “tech debt,” and “observability”—and then we wonder why the CEO’s eyes glaze over. Of course they do. We’re speaking a language that isn’t theirs. We’re explaining the engine when they need to know if the car will get them to the destination—and how much the fuel will cost.
If you want to bring value to your CEO, stop talking in tech. Start talking in money. In business. In outcomes.
⸻
Think of it like this. If your dentist tells you, “We shaved two millimeters off a cavity,” you smile politely and wait for them to finish. But if they say, “We saved your tooth—no $5,000 root canal needed,” suddenly you care deeply. Same truth. Different framing. One is technical. The other is consequential.
When you improve page load time by 200ms, don’t tell your CEO about milliseconds. Tell them about the users who didn’t drop off, about the $1.2M in revenue that stayed in the funnel because conversion went up 3%. When you clean up a tangled subsystem, don’t say “we reduced complexity.” Say, “New engineers can now ship features in a week instead of a month—that’s worth fifty thousand dollars in savings per hire.”
Your CEO doesn’t need to understand how the system works. They need to understand what happens because of the system. And money, growth, and risk are the only language that sticks. If you can’t translate your technical work into one of those three, you’re not speaking their language. You’re just muttering in the corner.
⸻
Here’s another mistake I see you make over and over: waiting for crisis. You push features, debt piles up, the system starts creaking like an old ship, and then one day you announce: “We need to stop everything for six months and rewrite this.”
That’s not leadership. That’s neglect dressed up as a rescue mission.
Engineering is hygiene, not surgery. You brush your teeth every day so you don’t end up in the dentist’s chair begging for an implant. You service your car so the engine doesn’t blow out on the highway at 90mph with your family in the back. You don’t ignore the small stuff until it becomes catastrophic. You handle it quietly, consistently, as part of the routine.
Technical debt is the same. It’s not a credit card bill you clear in one painful, soul-crushing shot. It’s a home loan. You pay it in installments. Predictably. Steadily. Quietly. Bake it into every sprint, every quarter. Twenty percent goes to resilience, to refactoring, to reducing friction. Not as a special event. As hygiene.
Your CEO doesn’t want to hear about open-heart surgery. They want to know you’re brushing your teeth daily and paying the mortgage on time. That’s how you earn trust. That’s how you avoid the emergency.
⸻
But let me remind you of something: empathy goes both ways.
You roll your eyes when your CEO says, “Just ship it faster.” You complain they don’t understand the complexity, the tradeoffs, the reality of building software. But here’s my question for you: do you really understand business?
When your CEO says “faster,” it’s not because they’re naive or careless. It’s because they’re carrying the weight of investors breathing down their neck, employees relying on the next funding round, competitors shipping faster, and customers threatening to leave. Every delay isn’t just about code to them. It’s risk. It’s revenue. It’s survival.
If you can see that—if you can step into that pressure instead of resisting it—you stop sounding defensive. Instead of saying, “You don’t understand how complex this is,” you can say, “I understand why you need speed. Here’s how we’ll give you velocity without blowing up the engine. Here’s the tradeoff, and here’s what it’ll cost us if we skip the brakes.”
When you show empathy, you usually get it back. Your CEO isn’t the enemy. They’re under pressure. Speak their language. Acknowledge their reality. Then show them the path forward.
⸻
Here’s the thing about being a great CTO: your greatest value is often invisible. The deal that didn’t fall apart because the system didn’t crash during the demo. The customer who didn’t churn because performance quietly improved. The engineer who didn’t quit because the environment was sane, not a dumpster fire.
You don’t get headlines for these things. There’s no medal for “disaster that didn’t happen.” But your CEO feels them. They feel the absence of problems. They feel the confidence of not having to worry about engineering while they’re on a call with investors or closing a deal. That quiet trust is the real reward.
Stop waiting for permission to maintain the system. Stop asking if it’s okay to pay down debt. Just do it. Bake it in. Make it routine. And when you do, translate the outcomes: “We reduced onboarding time for engineers by 40%. That saved us six weeks per hire.” “We improved uptime to 99.97%. That protected $800K in annual revenue.” “We refactored the payments flow. That means we can launch in three new markets this quarter instead of one.”
Talk sense. Talk business. Talk money.
⸻
So, dear CTO, here’s what I need you to hear: your CEO gives you freedom, but that freedom comes with responsibility. Don’t squander it by hiding behind jargon, diagrams, and excuses. Stop waiting for permission. Earn trust by making outcomes visible. Pay debt down like a home loan. Keep hygiene daily. Translate every decision—every architecture choice, every refactor, every hire—into revenue, growth, or risk.
Because when you do, you stop being the person who slows things down. You stop being the “no” person. You become the person who makes ambition real. The person who enables velocity. The person who sees around corners and prevents disasters before they happen.
Talk money. Talk business. Talk outcomes. Not tech.
Because when you do, you stop being misunderstood. You become indispensable.
And that’s your true value.
⸻
In summary, here’s what I need you to internalize: Speak impact, not implementation. Translate your technical work into revenue, growth, or risk—the only language that resonates with CEOs and boards. Treat tech debt like a home loan, paying it down steadily and predictably, not in one catastrophic rewrite. Show empathy for business pressure—your CEO isn’t asking for speed because they’re naive; they’re balancing survival, competition, and investor expectations. Make your value visible by connecting engineering wins to business outcomes. And above all, talk sense, talk business, talk money. When you master this, you stop being the person who slows things down and become the partner who makes ambition achievable. That’s the real role of a CTO.
Your’s truly
Scarred/Slapped/Wise CTO
]]>I often get similar theme questions by non-technical founders and CEOs: “How do I really add value for my CTO? I’m not technical, so what role can I play beyond approving budgets or asking for updates?”
It’s a question I’ve heard many times, and it always makes me pause. Because hidden inside it is a mix of insecurity and curiosity — the sense that maybe, as a CEO, you’re missing something essential if you don’t know how to read code or design a system. And yet, the irony is, many of the best CEO–CTO partnerships I’ve seen had nothing to do with shared technical depth. They thrived because of alignment, trust, and a shared understanding of roles.
Too many relationships between CEOs and CTOs collapse into one of two traps. On one side, the CEO becomes completely hands-off, treating the CTO like a mechanic: “Here’s the car, make sure it runs, don’t bother me with the details.” On the other side, the CEO morphs into a backseat driver, nervously second-guessing every turn, every gear shift, every adjustment — without actually knowing how the engine works. Both approaches are doomed. One isolates the CTO, leaving them without context. The other suffocates them with interference. Neither builds trust.
The truth is, as a non-technical CEO, you don’t need to be under the hood with a wrench. Your role is to chart the route and define the destination. You set the “why” — why we’re building, why speed matters, why resilience matters, why costs matter. If your CTO has the clarity of destination, they will figure out the “how.” You don’t need to argue about whether the car should have a hybrid engine or a V8. What you should care about is: does it run reliably, will it get us there fast enough, and will the fuel bill bankrupt us on the way?
This is the first piece of advice I give to non-technical CEOs: your value lies in giving clarity of purpose, not in policing the tools. The CTO who knows where they’re headed will make far better decisions than the one forced to take directions from someone who doesn’t speak the language of engineering.
The second role you play is that of the bridge — or if you prefer, the translator. A CTO is usually fantastic at building systems, designing architectures, and making sure technology works. But translating all that into a language that resonates with investors, board members, or customers? That’s often where they need you. You are the captain on the deck; they are the engineer in the engine room. Without you, the board might never know how much strain the engines are under. Without them, you’d be steering a ship with no power. You’re both essential, but in different ways.
This bridging role can’t be overstated. When a CTO says, “We need to refactor,” most outsiders hear “nerds tinkering.” But when you step in and explain it as, “We’re lowering future costs and ensuring the product doesn’t break under growth,” suddenly it lands. You’re taking their technical music and orchestrating it for the audience. They’re tuning the instruments; you’re making sure the hall hears a symphony, not just noise.
Now let’s talk about growth. Too often, CTOs get stuck as firefighters — the people who are always putting out blazes. A database crashes, a deploy fails, a server misbehaves — and they’re there with a bucket of water. That can’t be their whole career. If you want to add value as a CEO, don’t just thank them for dousing the flames. Encourage them to install sprinklers, fire exits, and a proper safety system. Support them when they say, “We need more people,” or, “We need to pause and build resilience before we add more features.” Let them grow into builders of teams and systems, not just responders to crises.
Recognition matters too. Much of a CTO’s work happens behind the curtain. When sales close a big deal, the world notices. When product launches, the team celebrates. But when the system scales smoothly under a sudden 10x traffic spike? Often silence. As a CEO, you can change that. Shine a light on their contributions. Public recognition goes a long way in reinforcing that their role is more than invisible plumbing; it’s the backbone of your company’s future.
And then comes candor. The strongest CEO–CTO relationships I’ve seen are those built on the ability to tell each other uncomfortable truths. A CTO must feel safe to say, “This won’t scale; we need to slow down and fix it,” even if it disrupts the roadmap. And a CEO must feel free to say, “This is over-engineered; we need something simpler to test the market,” even if it means cutting corners. Neither is right all the time. But both voices are necessary. Without candor, you risk building castles in the sky or, worse, setting fire to the engine mid-voyage.
So, if you’re a non-tech CEO, here’s what I want you to remember: stop worrying about whether you understand enough technology. That’s not your role. Your CTO doesn’t need you to be an engineer. They need you to be a partner. Give them clarity of destination, connect their work to the larger business story, invest in their growth, recognize their wins, and create a culture of candor. They’ll handle the code, the wiring, the systems. Together, you’ll handle the company.
In summary, here are the four key ways non-technical CEOs can truly support their CTOs: Provide clarity about business goals, priorities, and success metrics so they can make aligned technical decisions. Act as a bridge by translating their technical work into business outcomes and protecting their focus from distractions. Invest in their growth by supporting hiring, delegation, and leadership development while recognizing their contributions publicly. Build trust through candid communication where both sides can share hard truths without fear. Remember, your CTO doesn’t need you to understand code—they need you to be a strategic partner who enables them to do their best work.
Your CTO isn’t just there to keep the lights on. They are your co-pilot in building the future. Treat them like a partner on the bridge, not a mechanic in the basement. Do that, and you’ll both win.
]]>Time for self appraisal, the time I dread, because I need to write self appraisal, and I really find myself in a fix, my self-critical attitude tells me that you did what you were supposed to do, and you did not do anything extra ordinary, so why? And what do you write in self appraisal?
Embracing Self-Appraisal with a balanced approach might be daunting task for many of us. It certainly is for me.
Let’s face it: self-appraisal can feel awkward. Boasting about our achievements can seem like bragging, making many of us uncomfortable. But, whether you’re just starting out or you’re a seasoned professional, self-appraisal is a crucial part of professional growth and recognition.
So, how do you balance humility with the need to showcase your accomplishments? Here are some strategies:
Daily Journaling: Start with a simple habit - daily journaling. This isn’t just about listing what you did; it’s about reflecting on your experiences, challenges, and learnings. Tools like Logseq or Roam Research can be incredibly helpful. They allow you to organize your thoughts and achievements in an interconnected web, making it easier to see your growth over time. Documenting Achievements: Use your journal to document your achievements. When you make a habit of recording your successes, no matter how small, you create a reservoir of evidence that you can draw from during your self-appraisal.
Value Every Contribution: Whether your contribution is big or small, acknowledge it. Every piece of work, every effort, every small win contributes to the larger picture. By valuing your own contributions, you’re not bragging; you’re simply stating facts. Concrete Examples: When you talk about your achievements, be specific. Instead of saying, “I contributed significantly to project X,” say, “I developed a specific feature in project X that improved performance by Y%.” This specificity doesn’t just avoid the air of bragging; it clearly demonstrates your impact.
It’s always a team effort whether you have an immediate team or not. Always give credit to your team. Recognize the collective effort. It’s “we” and not “me”. You need to value power of collaboration and understand the importance of teamwork. When working solo it’s gets tought, but acknowledge the support and inspiration you’ve received from others. This could be mentors, peers, or even juniors. This demonstrates humility and gratitude.
Be honest and balanced in how you present your contributions. If there were challenges or failures, mention them along with what you learned. The integrity and a willingness to grow is one of the most important qualities of professional journey.
Self-Appraisal is a story of your own growth, and you need to tell that story to yourself first then to others, and it’s not bragging if it’s based on facts and shared with humility and gratitude. Gratitude towards team, because they made you what you are, graitutde towards organisation because they believe in you. So it’s about telling people how you have grown, and how you have helped others grow, and how you have helped organisation grow and vice versa.
Finally do not think that self-appraisal is adreaded task or feel like boasting. By regularly journaling, acknowledging all contributions, giving credit where it’s due, and clearly stating your achievements, you create a balanced and honest self-appraisal.
And it’s not bragging if it’s based on facts and shared with humility and gratitude. And that’s how your professional growth and recognition will be.
⸻
Self-appraisal isn’t bragging. It’s the annual reminder that you were there, you did the work, and you grew.
Tell the story — with facts, with gratitude, with your team in it. Tell it to yourself first. The rest is just paperwork.
]]>