The System Got Bigger
Becoming CTO didn't move me away from engineering. It changed the size of the system I'm responsible for.
I became a CTO recently. I expected the job to make me think less about engineering, but so far the opposite has happened. The system just got bigger. As a platform engineer, I've spent a lot of time thinking about desired state: describe what a system should look like, observe what actually exists, and build mechanisms that continuously reconcile the difference.
I'm starting to think engineering organizations aren't entirely different. There is a desired state: what the company needs to be able to build, operate, secure, and support. There is an observed state: the software, architecture, people, processes, technical debt, incidents, costs, commitments, and constraints that actually exist. Somewhere between those two is the job.
The systems around people can be engineered
There's an obvious danger in taking the analogy too far. People aren't pods. Organizations aren't deterministic systems. You can't write a controller that reconciles an engineer into behaving the way you want, nor should you try. But the systems around people can absolutely be engineered, and that's the distinction I'm becoming increasingly interested in.
Testing shouldn't depend on someone remembering to run the right suite. Production standards shouldn't depend on someone remembering what the platform team decided six months ago. Compliance evidence shouldn't require an archaeological expedition every time someone asks for it. Deployment safety shouldn't depend entirely on tribal knowledge. AI agents shouldn't receive enormous amounts of authority simply because nobody designed better boundaries for them. Those are all engineering problems.
The boundary around those problems is much larger for me now. The code and infrastructure are still there, but so are questions about what we should build, what we should buy, which technical debt actually matters, where engineers should spend their time, what should be automated, what requires human judgment, what authority an AI agent should have, and how much complexity the organization can afford to operate.
Those decisions eventually become architecture, even if they never appear on an architecture diagram. They become cost, reliability, developer experience, product velocity, security, and organizational behavior.
Organizations accumulate manual reconciliation
Kubernetes has spoiled me in one particular way: it made continuous reconciliation feel normal. If I declare that three replicas should exist and one disappears, I don't want a human checking the cluster every fifteen minutes and creating another one. The system knows the desired state, observes reality, and acts when the two diverge.
Engineering organizations contain an astonishing number of processes that work nothing like this. Instead, we build human reconciliation loops.
Sometimes that's appropriate because judgment is required. But sometimes we've put a person in the loop simply because nobody ever engineered the loop. That's a very different thing, and it is changing how I think about automation.
Making an individual task faster is useful, but I'm increasingly more interested in removing entire coordination problems. A faster test suite is good. A system that understands when tests should run, runs them, evaluates the evidence, prevents an unsafe change from progressing, and records what happened is something different. The first automates a task. The second starts encoding an engineering responsibility.
AI makes the boundary more important
AI agents make it possible to automate engineering work that previously required judgment rather than simple scripting. That creates a temptation to solve every problem by giving the agent more context, more tools, and more authority. I don't think that's enough. If an agent can write code, something still has to determine whether that code is safe to merge. If it can create infrastructure, something has to define which infrastructure it is allowed to create. If it detects a production problem, there needs to be an explicit answer to whether it can change production.
Those aren't primarily prompting problems. They're systems design problems. The interesting work increasingly happens around the agent: authority boundaries, policy, evidence, observability, rollback, escalation, and interfaces. The engineering system matters as much as the intelligence operating inside it.
This is where my Engineering OS experiment is getting more interesting. The original question was how much of an engineering organization one engineer could encode into software, agents, policy, automation, and platform infrastructure. BusyNow gives me a real production environment in which to test that. If the automation is bad, I have to deal with it. If the platform is too complicated, I have to operate it. If an abstraction doesn't work, production eventually exposes it.
Becoming CTO has given me another version of the same question: how much organizational friction exists because responsibilities that should have been encoded into systems still depend on humans remembering to perform them?
The answer isn't to turn everything into software. Some decisions are ambiguous. Some require context, empathy, negotiation, creativity, or judgment. Some are important enough that a human should remain responsible even if software could technically make the decision. The challenge is identifying where humans add judgment and where we're simply using them as unreliable cron jobs.
The system got bigger
My job didn't stop being engineering when I became CTO. The boundary of what I'm engineering changed. I'm still interested in reliable systems, good abstractions, constrained interfaces, feedback loops, observability, and making complicated things easier to operate.
It's just that now some of those systems contain software, infrastructure, AI, processes, budgets, customers, and people. That's a much larger system, and I think I'm going to learn a lot from trying to understand it.