Why I stay 20–30% in the editor as a principal engineer
Twenty-five years in, I still spend a fifth to a third of every week writing production code. Here is why, and what it actually looks like in a calendar.
I am a Principal AI Engineer at AVEVA. I have led delivery for organisations of up to 200 engineers, sat in architecture reviews where the smallest decision shaped a roadmap for a year, and written more strategy documents than I would like to count. I have also, every week of the last twenty-five years, spent somewhere between a fifth and a third of my time inside an editor, shipping production code.
That number is not an accident, and it is not nostalgia. It is the line in my values page that I am least willing to negotiate: architecture decisions decay quickly if you're not the one paying for them in the editor. This post is about why I hold it, what 20–30% actually looks like inside a working week at this seniority, the work I refuse to delegate, the work I have learned to let go of, and the honest counter-arguments — what you lose, what only works because of who you work with, and the moments where the rule has to bend.
The dichotomy is mostly a HR taxonomy
Most engineering ladders I have worked under split somewhere around senior engineer into two columns: a "management track" and an "IC track," sometimes branded as staff or principal. The split is a useful artefact for HR. It tells compensation teams how to benchmark roles, gives recruiters a vocabulary, and lets companies promote people without forcing them into line management.
It is also, in my experience, a poor description of how the work actually flows once you are at principal or architect level. The most effective principal engineers I have worked with — and I am pulling here from twenty-five years across FinTech, HealthTech, AI platforms, IoT, regulated medical systems and industrial software — do roughly four things in parallel. They shape technical direction. They unblock other engineers. They translate between executives and the codebase. And they write code. The split is not "manager versus IC." The split is between people who do all four and people who only do three.
Drop any one of those and something quietly breaks. Drop the code in particular, and the other three degrade in ways that are hard to see from the outside but obvious from inside the team.
What 20–30% buys you
The blunt version: if you are not in the codebase, you do not know what your architecture costs.
I have watched senior architects sketch beautiful diagrams of event-driven systems where the actual cost — in build times, local developer ergonomics, retry semantics under load, the shape of the on-call rota at 03:00 — was carried by other people. Those architectures were not wrong in the abstract. They were wrong for the specific team holding them, and the architect could not see it because they had not paid the price themselves in a year.
The 20–30% is a tax I pay against that drift. When I am the one writing a feature against the platform I designed, the feedback loop is direct. If the local dev environment takes nine minutes to start, I feel it. If the generated client SDK has an awkward auth flow, I feel it. If our error envelope is inconsistent across services, I feel it the first time I have to handle one in code. None of that lands the same way through a Slack message or a retrospective.
The other thing it buys is credibility, but in a narrower sense than people usually mean. I am not interested in proving I can still code. I am interested in being a useful person to argue with. When a staff engineer pushes back on a direction I have proposed and I can respond with "I tried that pattern last week against the new ingestion path and here is exactly where it breaks," the conversation moves forward. When my response is "in principle, that pattern is fine," it usually stalls.
Where it lives in the week
A normal working week, at AVEVA or anywhere else I have been at this level, runs to around forty hours of focused work. 20–30% of that is roughly eight to twelve hours. The mistake people make is trying to find that time in fifteen-minute slivers between meetings. It does not work. The cost of context-switching into the codebase is high; if you only have twenty minutes, you will spend it reading and never make any progress.
The shape that works for me is roughly this. I protect two half-days a week, ideally non-consecutive, where my calendar shows as busy and where I genuinely am — usually Tuesday afternoon and Thursday morning. Those are the engineering blocks. I treat them with the same seriousness as a board review. Cancelling them carries a real cost, so I have to actively argue myself out of them, and most of the time I lose that argument.
Around those, I keep one or two hours most mornings before the calendar gets noisy. That is usually for smaller, completable work — reviewing a thorny pull request properly rather than skimming it, prototyping an idea for an upcoming RFC, fixing a paper-cut in the developer experience that has been irritating someone on the team. The two protected half-days are for work that needs a deeper run-up.
I do not pretend this is always clean. Some weeks I lose Thursday to an exec review and have to recover the time on Friday or write the week off. But the default is the protected blocks, and the default holds maybe three weeks out of four. Over a quarter, the maths works out.
What I refuse to delegate
Inside that 20–30%, there are categories of work I am unusually protective of, because they are the categories where principal-level judgement and editor-level proximity have to meet.
Platform seams. At AVEVA I am building Core AI Services — a shared cloud-native platform on Azure and AKS that standardises how product teams consume AI capabilities. The interesting part is not the LLMs. It is the seam where product teams meet the platform: the SDK shape, the auth flow, the versioning contract, the error envelope, the way streaming responses propagate. Those seams calcify quickly once a few teams have integrated. I want to be the person writing the first integration against any seam I am proposing, because that is the only honest test of whether the design works.
Reference implementations. When the team is moving onto a new pattern — agentic coding workflows, a new contract-testing approach, a new way of structuring our Helm charts — I write the first end-to-end example myself, or pair on it with whoever will own it next. Not because nobody else can. Because the act of writing it surfaces all the unspoken assumptions in the design, and those assumptions become the documentation everybody else inherits. I learned this the hard way at BrightInsight, where the JSON-based DSL for indemnity rules worked partly because the early reference products were written by the same people who designed the DSL, and the underwriters could see exactly what the abstraction was and was not promising.
Spikes for hard questions. If the team is genuinely unsure about something — does this third-party API actually support the throughput we need, can we get acceptable cold-start times on this AKS pod configuration, what does our authentication story look like end-to-end if we adopt this new identity provider — I will often take the spike myself, particularly if the answer is going to set direction. The reason is mechanical: I have the lowest opportunity cost for a one- or two-day spike, because nothing else on my plate has a single-day shape. Most of the team's work is multi-week. A principal's calendar is actually well-suited to short, decisive investigations, and the answer tends to carry more weight when it is brought back with code attached.
The first cut of anything thorny in agentic coding. This is specific to my current role and the Hypervelocity Engineering work — I am one of the people shaping how the wider organisation uses Claude Code, GitHub Copilot CLI and ChatGPT Codex. I cannot have a coherent point of view on agentic coding workflows if I am not actively using them on real production work. Reading other people's reports is not the same. The texture of where the tools work and where they fail is something you only get from a hundred hours of use, and it changes monthly.
What I have learned to let go of
The corollary matters as much as the protected list. There is plenty of code I deliberately do not write.
I do not pick up production tickets in the backlog that anyone else on the team could take. Doing so deprives a senior or staff engineer of work that would stretch them, and turns me into a slightly slower version of an engineer two levels below me. The opportunity cost is wrong.
I do not own long-running features end-to-end. I cannot. My calendar is too fragmented over a month for me to be a reliable owner of a four-week feature, and pretending otherwise punishes the team waiting on me. If I find myself becoming a bottleneck on a feature, I have already made a planning mistake; the fix is to hand over and instead pair with whoever now owns it.
I do not personally write production CI/CD pipelines, infrastructure modules or operational tooling unless I am specifically prototyping a new pattern. The platform engineers on my team are better at this than I am day-to-day, and my proximity should be at the design level, not the implementation level for steady-state work.
The way I think about it: my 20–30% should look more like the work of a curious senior engineer who keeps stumbling into the hardest, most ambiguous bits of the system, than like the work of a tech lead with a sprint board. If it starts looking like the latter, something has slipped.
The honest counter-arguments
There is a version of this argument that is glib, and I want to be careful not to write it. So here are the genuine pushbacks.
You cannot run a 200-person org this way. Correct. I have never claimed to. The orgs of up to 200 engineers I have led, I led as an architect or principal embedded in the technical leadership, not as a VP or director. The roles where my hands-on percentage would have had to drop closer to zero — proper line management of multiple managers, board-level accountability for a product line — those are different jobs, and I have deliberately not chased them. If I had, the 20–30% would not survive. The framing in this post assumes the principal/architect lane, not the executive lane.
You will be slower than a full-time engineer in the same code. Also correct. I am not the fastest engineer on any team I am on, and I should not be. A senior engineer who lives in the codebase forty hours a week will out-execute me on any given ticket; that is exactly how it should work. My contribution is shaped differently — I bring pattern fluency and cross-stack memory to specific points in the work, not consistent throughput on a sprint board.
You will write code that does not match the team's evolved conventions. This is the one that bites most often. The team's tacit conventions move faster than I can track if I am only in the code two days a week. The mitigation is pair programming. Most of the code I commit at AVEVA is pair-written with a senior or staff engineer, or reviewed deeply by one before it lands. That is the right shape: my judgement, their grip on the current codebase.
It only works because of who is around you. This is the most important caveat in the whole piece. The 20–30% is only sustainable because I have strong staff and senior engineers around me who own the day-to-day flow of the codebase. They cover the throughput, the conventions, the on-call rota, the long-running feature ownership. My time in the editor sits on top of that, not instead of it. Take away the staff/principal cohort and the model collapses; I become a bottleneck, and the team is better off if I either commit fully to coding or fully to architecture. I have seen principals try to hold this rule in teams without that cohort and watched it go badly.
You cannot keep up with the depth. True, on any given stack. I am not the deepest Rust engineer at any company I have worked for. I am not the deepest Kubernetes operator at any company I have worked for. The expert-generalist framing — Fowler, Joshi and Venkatraman, July 2025 — describes this well: multiple stripes of genuine depth, not one. My job is to be deep enough in the platform, regulated systems and AI/ML platform stripes that I can hold a real conversation with the specialists, recognise the patterns underneath, and apply them across the seams. That is a different kind of depth, and it is the one the 20–30% protects.
The decay test
If I want a single test for whether the rule is still working, it is this: when I propose an architecture change, am I the one volunteering to write the first integration against it, or am I assuming someone else will discover the costs for me?
When the answer is the former, the rule is working. The proposal is grounded; I can defend it concretely; the team trusts that I have eaten my own cooking. When the answer is the latter, I have drifted out of the editor for long enough that I am back to drawing diagrams whose price I am not paying. That has happened to me. It happens to most people at this level if they are not deliberate about it. The recovery move is always the same: pick up something small, finish it end-to-end, feel the platform from the inside again, and let the next architectural conversation be informed by that week.
This is not a rule I hold because I think it makes me a better engineer than someone who has gone fully into architecture or fully into management. It is a rule I hold because, given how I think, it is the only configuration where my architectural judgement is reliably worth listening to. Take away the editor time and I can still draw diagrams; I just cannot tell you which of them are real.
So I keep two half-days a week, and a few mornings, and a fairly opinionated list of what I will and will not delegate. Twenty-five years in, it has not stopped paying.
— Madu