Chapter 14: The Operating Rhythm
A schedule defends from chaos and whim. It is a net for catching days. It is a scaffolding on which a worker can stand and labor with both hands at sections of time.
The Writing Life, 1989
I was diagnosed with inattentive ADHD at thirty-four. Before that, I had spent my entire career building compensatory systems without knowing what I was compensating for. I kept obsessive to-do lists because without them I forgot everything. I time-blocked my calendar because without structure the day dissolved into reactive chaos. I wrote things down compulsively because my working memory could not be trusted to hold a conversation’s action items across the walk back to my desk. I thought this was discipline. It was, in clinical terms, self-medication — an intuitive attempt to externalise the executive functions my brain does not reliably provide.
This chapter is designed for me. The operating rhythm described here is the system I built, refined, broke, rebuilt, and eventually stabilised across a decade as a startup CTO. It is informed by the clinical literature on ADHD and executive function. It is grounded in the practitioner frameworks of Will Larson, Lara Hogan, Charity Majors, Pat Kua, and Camille Fournier. And it is shaped, at every point, by the specific needs of a brain that does not self-regulate time, attention, or task initiation without external support.
I suspect I am not alone among this book’s readers, and the research bears this out.
You Are Probably Not the Only One in the Room
ADHD affects roughly 4–5% of the general adult population.[1] Among entrepreneurs, the numbers are different. A 2025 BDC survey of 1,463 Canadian entrepreneurs found that 7% had a formal ADHD diagnosis — and when including those with undiagnosed symptoms, the figure rose to one in four.[2] A study of more than 17,000 individuals published in the Journal of Business Venturing found that approximately 29% of entrepreneurs had ADHD, and that having the condition made people more inclined to choose entrepreneurship as a career.[3] A large-scale Dutch study of nearly 10,000 subjects found a positive connection between clinical ADHD and both entrepreneurial intentions and entrepreneurial action.[4] Adults with ADHD are estimated to be 1.7 times more likely to have entrepreneurial intentions than their neurotypical peers.[2]
Software engineering appears to follow a similar pattern. Stack Overflow’s 2022 Developer Survey — the first and, as of this writing, the last time the survey asked about neurodiversity — included 1,305 professional developers who self-identified as having ADHD.[5] The Institute of Engineering and Technology reported that 19% of their volunteer community identified as definitely or possibly neurodivergent.[6] An entire subreddit for ADHD programmers has grown to over 65,000 members.[6] Stack Overflow’s editorial team put it plainly: "There’s enough of an overlap between people with ADHD and people who code for a living" that the connection is impossible to ignore.[6]
The reason is not mysterious. Programming offers exactly the stimulus profile the ADHD brain craves: a revolving door of novel problems, immediate feedback loops (the code compiles or it does not), and the capacity to enter hyperfocus — what Neil Peterson calls "a state of laser-like concentration in which distractions and even a sense of passing time seem to fade away."[6] Startups add another layer: high novelty, high autonomy, minimal bureaucratic structure, and the intoxicating risk-reward profile that Ingrid Verheul of the Rotterdam School of Management describes as the "thrills to get their drive going."[7]
The trap is that these same traits — hyperfocus on interesting problems, comfort with risk, intolerance of routine — are assets during the founding phase and liabilities during the scaling phase. A 2025 meta-analysis spanning 47 studies and 298 effect sizes found that hyperactivity and impulsivity are positively associated with entrepreneurial behaviours, while inattention is negatively associated with post-launch outcomes.[8] The very ADHD subtype most common in high-functioning technical founders — the inattentive type, the "smart but daydreams a lot" profile — is the one that specifically impairs the execution demands of running a company after it has been built.
If you are reading this and recognising yourself — the chronic sense of underperformance despite objective success, the compulsive list-making, the 2 a.m. log-checking, the projects that start brilliantly and finish grudgingly, the school reports that said "bright but needs to apply himself" — I would encourage you to seek formal evaluation. Most CTOs are in their thirties to fifties. We grew up in an era when ADHD was understood primarily as hyperactive boys disrupting classrooms, not as quiet, high-achieving children whose intelligence masked their executive function deficits long enough to reach adulthood undiagnosed. Yale Medicine reports that ADHD diagnosis rates in adults aged 30–44 increased 61% between 2021 and 2024, and 64% in those aged 45–64.[9] This is not because ADHD is suddenly more common. It is because a generation of adults is finally discovering that the coping mechanisms they thought were personality traits are, in fact, accommodations for a neurological condition — and that better accommodations exist.
Less than 20% of adults with ADHD are estimated to be appropriately diagnosed and treated.[10] A clinical evaluation — not a social media quiz, not a self-diagnosis — is the starting point. It changed my career and my relationship with the role.
A Note for the Non-ADHD Reader
If you have read the preceding section and thought that does not sound like me, this chapter is still for you.
The CTO role is structurally hostile to executive function regardless of neurology. The operating rhythm described here — external checklists, predictable cadences, delegation triggers, shutdown rituals — is not an ADHD accommodation bolted onto a normal job. It is the scaffolding that the job requires and does not provide. The non-ADHD CTO who builds this system will find three differences in how they use it. First, the system will feel like a useful tool rather than a survival necessity — you can skip a day without the whole structure collapsing. Second, you may find shorter lists sufficient: where the ADHD CTO needs five explicit daily steps, you may need three. Third, the sensory transition cues (headphones on for deep work, a verbal shutdown phrase, different rooms for different cadences) will feel optional rather than critical — use them if they help, discard them if they don’t.
The underlying principle is the same: if you do not decide what you are doing with your time, other people’s urgencies will decide for you. The rhythm externalises that decision so you make it once, in advance, rather than fifty times a day under pressure.
Russell Barkley, the clinical psychologist who has spent four decades studying executive function, describes ADHD not as a deficit of attention but as a deficit of self-regulation — the ability to organise behaviour across time toward a future goal. His formulation is precise: "ADHD is not a disorder of knowing what to do. It is a disorder of doing what you know."[11] The person with ADHD can describe the right course of action in detail. They can explain why it matters. They can list the steps. The failure occurs at the point of performance — in the gap between intention and execution, between the plan conceived on Monday and the plan abandoned by Wednesday.
Every CTO reading this book will recognise that gap, whether they have ADHD or not. The CTO role is structurally hostile to executive function. Engineers have tickets. Sales has a pipeline. Product has a roadmap. The CTO has everything, all at once, with no external structure telling them what to do next. The role demands simultaneous attention to code, people, strategy, culture, investors, customers, and the CEO — while providing none of the organisational scaffolding that makes this possible. Chapter 13 argued that the CTO must stop writing code. This chapter answers the question that follows: if you are no longer a coder, what do you actually do with your days?
The answer is not a job description. It is an operating rhythm — a set of recurring activities at predictable cadences that externalise the executive function the role does not provide. Paul Graham described the CTO’s fundamental time problem in 2009: "A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."[12] The CTO lives at the intersection of Graham’s two schedules — the maker’s schedule (long, uninterrupted blocks for technical thinking) and the manager’s schedule (hour-long slots for people, decisions, and communication) — and must navigate both without the luxury of choosing one. Pat Kua, former CTO of N26, names the failure mode: the leader who tries to operate in Maker mode and Multiplier mode simultaneously is "doing the work of two full-time roles," and it "is unsustainable and will lead to burnout."[13]
The operating rhythm is the alternative to that unsustainable oscillation. It is not a rigid calendar — startups do not operate on predictable schedules, and any system that assumes they do will be abandoned by Thursday. It is a set of loops at five frequencies — daily, weekly, monthly, quarterly, and annually — each with a small number of specific activities, each with a trigger for when to delegate it, and each with a warning sign that tells you when you have been neglecting it. The rhythm accumulates as you scale: activities are added at each stage, rarely removed. The CTO at the Coder stage runs a subset. The CTO at the Strategist stage runs the full set, with most of the operational cadences delegated to the VP of Engineering.
Barkley’s research provides the design principle: "If the process of regulating behaviour by internally represented forms of information is impaired, then they will be best assisted by 'externalising' those forms of information."[11] Every item in the operating rhythm should have a physical representation at the point of performance — a checklist on the desk, a recurring calendar block with a specific agenda, a dashboard on a second monitor. If the right action is not visible at the moment you need to take it, the ADHD brain — and, under sufficient stress, any brain — will default to whatever is most immediately stimulating rather than whatever is most important.
The Daily Rhythm
The daily rhythm has five components. If it does not fit on an index card taped to your monitor, it is too long.
The morning launch. Before opening email, before opening Slack, spend fifteen minutes with a physical notebook. Review today’s calendar. Circle the one meeting that matters most. Write down the one decision you have been avoiding — not the one that is urgent, but the one you have been deferring because it is hard. Write three outcomes for the day — not tasks but outcomes, each with a completion criterion. Then set a timer for your first deep work block and begin.
Will Larson recommends that the CTO protect what he calls "five spare hours" each week — time not consumed by recurring meetings — and invest them deliberately across four categories: building deep context (reading code, reviewing architecture), building broad context (understanding peer functions), improving systems and process, and building relationships.[14] At a small company, the five hours should skew toward deep context. As the company grows, they shift toward broad context and relationships. The morning launch is where you decide which category today’s deep work block serves. Without this decision, the block will be consumed by whatever arrives in your inbox.
One deep work block. Ninety minutes, minimum. No Slack, no email, no context switching. The MIT Sloan research on meeting-free time found that a single meeting-free day per week increased productivity by 35% and decreased stress by 57%.[15] You may not be able to protect an entire day. Protect ninety minutes. The ADHD-specific adjustment: schedule the block for your peak cognitive window — for most people, two to four hours after waking — and add a physical transition cue. Headphones on means the block has started. Headphones off means it is over. The sensory signal gives the ADHD brain the transition marker that neurotypical brains generate internally.
Sophie Leroy’s research on attention residue demonstrates that when you switch from one task to another, part of your attention remains with the prior task — especially when you leave it unfinished.[16] Her recommendation: before switching, write down exactly where you stopped and what you planned to do next. This "Ready to Resume Plan" externalises working memory so the residue dissipates. For the CTO, this means: end the deep work block by writing a single sentence in the notebook about where you left off. Do not rely on your memory. Your memory is unreliable under load, and the CTO is always under load.
The CEO check-in. Ten to fifteen minutes, daily at the Coder and Manager stages, moving to weekly once a VP of Engineering owns execution (typically Series B). This is not a status update. It is an alignment check: are we agreed on today’s most important thing? Has anything changed since yesterday? Is there a customer signal or investor conversation I need to know about? The check-in is where the communication rhythm from Chapter 3 lives in practice. The CTO who skips it will learn about strategic shifts from an investor, not from their co-founder.
Triage and capture. Every input — every Slack message, every email, every hallway request — goes into a system: a task list, a calendar block, or a delegation. Nothing stays in working memory. The ADHD brain’s working memory is what Barkley calls "the mind’s GPS" — and in ADHD, the GPS is intermittent.[11] The CTO who carries commitments in their head will forget them. The team that experiences forgotten commitments will stop trusting the CTO’s word. Trust, once lost to unreliability, is expensive to rebuild.
Delegate this function when the team reaches approximately fifteen engineers: hire an executive assistant or chief of staff whose job includes first-pass triage. Charles Schwab described his own accommodation: "I have strong people around me who focus on day-to-day planning and organisation."[17] The EA is not a luxury. For the CTO whose executive function is the bottleneck, the EA is the single highest-ROI hire in the company.
The shutdown ritual. This is the most important item in the operating rhythm and the one most likely to be skipped. Cal Newport designed the shutdown ritual to address the Zeigarnik effect — the psychological finding that incomplete tasks dominate attention.[18] The ADHD brain amplifies this: every unresolved thread becomes a source of low-grade anxiety that follows you home, disrupts your sleep, and produces the 2 a.m. log-checking that Chapter 15 describes as a burnout precursor.
The ritual takes fifteen minutes, at the same time every day. Scan every task list — nothing should exist only in your head. Check the next three days on the calendar and flag anything that needs preparation. Write tomorrow’s three outcomes in the notebook. Note one thing that went well today — Barkley’s research shows that positive emotions replenish the self-regulatory resource pool that ADHD depletes faster than average.[11] Then say a termination phrase aloud — Newport’s is "schedule shutdown, complete" — and close the laptop. The verbal phrase and the physical act of closing the lid are transition cues. They tell the brain: this day is finished. The open loops have been captured. You have permission to stop.
|
AUTHOR: Your daily rhythm at CorralData — what does a typical day look like? Do you have a startup ritual? A shutdown ritual? Where does the day tend to go off the rails? The reader with ADHD needs to see a working CTO describing the specific moments where executive function fails and the specific accommodations that help. |
The Weekly Rhythm
The weekly rhythm is where the CTO’s job becomes visible. If the daily rhythm is about surviving the day, the weekly rhythm is about shaping the week — ensuring that the important work happens despite the urgent work that will try to displace it.
One-to-ones with every direct report. Weekly, thirty to sixty minutes each. Lara Hogan recommends weekly hour-long sessions at every management level.[19] This is the CTO’s most important recurring commitment. The warning sign that you are neglecting it: you cancel a one-to-one because something urgent came up. One cancellation is understandable. A pattern of cancellation tells the team that they are less important than whatever is on fire this week — and the team will respond by stop surfacing problems early, which guarantees more fires.
Delegate when you hire a VP of Engineering (typically at fifteen to twenty engineers). The VPE takes over one-to-ones with most engineers and engineering managers. You keep one-to-ones with the VPE, with one or two senior technical leaders, and with any direct report whose work touches the board or the CEO.
Technical spec or architecture review. Larson recommends this as a weekly standing meeting, anchored on written documents rather than presentations.[20] At the Coder stage, you are writing the specs yourself. At the Manager stage, you are reviewing them. At the Director stage, a staff or principal engineer leads the review and you attend selectively — for the decisions that are one-way doors (Chapter 4) or that cross team boundaries.
The warning sign: you have not looked at code or architecture in three weeks. The delegation trigger: a staff engineer or principal engineer can run the review without you. But even at the Strategist stage, the CTO who entirely disconnects from the technical work loses the credibility that justifies the role. Charity Majors describes the danger: the CTO who stops writing code "can increasingly rely on their credentials, to the detriment of the people around them."[21] The weekly architecture review is the minimum viable connection to the technical reality.
Incident review. Weekly when incidents occur, cancellable on quiet weeks. At the Coder stage, you are in the incident. At the Manager stage, you are running the review. At the Director stage, the VPE or an SRE lead runs it and you attend as a participant. The blameless postmortem culture from Chapter 7 lives or dies in this meeting.
Engineering leadership team meeting. Larson is explicit: "I would strongly push to meet weekly."[20] This is the meeting where your direct reports — engineering managers, tech leads, staff engineers — become a team rather than a collection of individuals reporting to the same person. Without it, teams work in silos, context gaps grow, and your directs do not think of each other as peers.
Recruiting pipeline review. Larson’s advice for any new engineering executive: "Within the first two weeks, get this on the calendar."[20] At seed, you are sourcing and interviewing candidates yourself. At Series A, a recruiting lead or the VPE takes over pipeline management and you participate only for senior and staff-level roles.
The weekly status update. Larson calls this the "5-15" — fifteen minutes to write, five minutes to read.[20] Send it up to the CEO and out to peer executives. It is the minimum viable visibility for engineering. The CTO who does not send it becomes invisible between board meetings — and the CEO who does not hear from engineering regularly will start telling the engineering story themselves, without the technical nuance that the CTO would have provided.
The Friday review. Fifteen minutes at the end of the week. Score the week against your Monday intentions. Set next week’s top three priorities. Process loose papers, notes, and open browser tabs into your task system. This is the weekly equivalent of the daily shutdown ritual — it closes the loop on the week and prevents the Sunday night anxiety that comes from not knowing whether you accomplished anything.
|
AUTHOR: Your weekly rhythm — which of these meetings exist at CorralData? Which are missing? The reader at your stage (scaling toward $6MM ARR, small team) needs to see what a real weekly cadence looks like when you cannot possibly do all seven items and must choose. |
The Monthly Rhythm
The monthly rhythm is where strategic work begins. Daily and weekly cadences keep the engine running. Monthly cadences ensure the engine is pointed in the right direction.
Technical debt review. Name the top three debt items, quantify them in business language (Chapter 5’s framework: how many engineering hours per month does this debt cost?), and allocate capacity in the upcoming sprints. Stephan Schmidt’s rule of thumb: dedicate a fixed percentage of each sprint to debt reduction — 15–25% — and treat it as non-negotiable.[22] The warning sign: more than 40% of engineering capacity is going to maintenance (Chelsea Troy’s threshold from Chapter 5), and nobody has named the cause.
Team health check. Attrition risk, engagement signals, workload distribution. At seed, this is a conversation over coffee. At Series A, it is a structured review of one-to-one notes, looking for patterns: who is frustrated? Who is overloaded? Who has not been challenged in months? The warning sign: three resignations before you notice the pattern. The delegation trigger: the VPE owns this at Series B, with the CTO reviewing a summary and acting on escalations.
Skip-level conversations. Larson budgets one to two hours per week for skip-levels.[20] At a startup with fewer than fifteen engineers, skip-levels happen naturally — you talk to everyone. At fifteen-plus, they must be scheduled deliberately. The warning sign: you are hearing a curated version of reality from your direct reports and have no independent signal from the team.
Advisory conversation. Majors recommends monthly meetings with experienced mentors who can tell you whether you are in a genuine crisis or merely feel overwhelmed.[21] Kellan Elliott-McCrea’s peer group recommendation from Chapter 15 serves the same function. This is the body double for the CTO — the external perspective that catches the patterns you cannot see from inside the isolation. Never delegate this. It is the ADHD CTO’s most important external accountability mechanism.
Engineering all-hands. Monthly at fifteen-plus engineers, weekly or fortnightly at smaller sizes. The VPE runs logistics. The CTO delivers the strategic context and takes live questions. The warning sign: the team has lost connection to why the work matters and has begun treating engineering as a ticket factory.
|
AUTHOR: Your monthly rhythm — do you have a formal technical debt review? A team health check process? An advisory conversation? The reader needs to see which monthly cadences a real founding CTO has established and which are aspirational. |
The Quarterly Rhythm
Quarterly tasks are invisible to a brain with what Barkley calls "temporal myopia" — nearsightedness for time.[11] The ADHD brain lives in two time zones: now and not-now. A quarterly review scheduled for three months from today exists in the "not-now" zone until the morning it arrives, at which point it is an emergency. The solution is a pattern interrupt: schedule a half-day offsite for each quarterly review. The different physical environment and the act of leaving the office create the transition signal that the ADHD brain needs to shift from operational to strategic mode.
OKR or goal review and reset. Score existing objectives. Retire or carry over. Set new ones aligned to the company’s goals for the next quarter. Dave Bailey’s lightweight adaptation from Chapter 9 applies: four-to-six-week cycles, one or two key results per objective, scoped to customers and team. The warning sign: the same OKRs roll over for two consecutive quarters without progress, and nobody acknowledges it.
Architecture review. Does the current architecture support next quarter’s roadmap? Where are the scaling bottlenecks? Which technical decisions need to be made before they become emergencies? Staff and principal engineers prepare the assessment. The CTO makes calls on trade-offs. The warning sign: architecture decisions accumulate in a queue that nobody is processing.
Technology strategy refresh. Update the rolling roadmap — next six months locked, next six tentative, final six vision. Larson’s warning applies: teams that lack a written technology strategy "remain stuck in reactive cycles, lurching from crisis to crisis, untethered from clear direction."[20] The CTO always owns the strategy. The VPE and staff engineers contribute.
Board preparation. Begin two weeks before the board meeting. Build the deck, rehearse the narrative, prepare for the questions the board will ask. The VPE provides operational metrics. Finance provides the numbers. The CTO owns the narrative and the technical strategy section. The warning sign: the CEO starts presenting the engineering story without you because you have not provided the material in time.
Personal energy audit. Track your energy levels hourly for one week — note when you feel sharp, when you feel depleted, and which activities drain or replenish you. Adjust the next quarter’s calendar accordingly. If your deep work blocks are at 2 p.m. but your cognitive peak is at 10 a.m., the schedule is working against your biology. Barkley’s finding that self-regulatory strength is a limited resource — temporarily depleted by each act of self-regulation and replenished by rest, exercise, and positive emotion — means the CTO’s energy is not a matter of discipline. It is a matter of design.[11]
|
AUTHOR: Your quarterly rhythm — do you do a formal technology strategy refresh? How do you prepare for board communication? Has the energy audit concept resonated, and if so, what did you learn about your own patterns? |
The Annual Rhythm
Annual tasks require the most deliberate intervention. Set a two-day offsite, in a physical space that is not your office, with a body double present — a co-founder, an advisor, or a coach. The first day is assessment and data. The second day is decisions and planning. End the second day with specific first-quarter actions, not abstract annual goals. The ADHD brain cannot hold a twelve-month intention. It can hold a next-Monday action.
Organisational assessment. Lena Reinhard’s five-dimension framework: delivery metrics, technical health, organisational structure, team-level dynamics, and people development.[23] The VPE prepares the data. The CTO interprets it and makes structural decisions — team topology changes, hiring plan adjustments, process redesigns. The warning sign: the company has outgrown you and you have not noticed.
Technology roadmap refresh. Major platform decisions, build-versus-buy-versus-partner choices, and technology bets for the next twelve to eighteen months. This is where the innovation tokens from Chapter 4 are allocated. The warning sign: competitors are shipping capabilities you are still debating.
Budget negotiation. Headcount plan, infrastructure costs, tooling investments, technical debt allocation. Finance prepares the models. The VPE co-authors the headcount plan. The CTO negotiates with the CEO and the board, using the business language from Chapter 10. The warning sign: engineering is chronically under-resourced, and the CTO has not made the case for why.
Career development and succession planning. Two conversations: one with your team (who is growing, who is stalled, who is a flight risk) and one about yourself (what is your own development plan? do you need a coach, a course, a sabbatical?). The warning sign: top talent leaves and you are surprised. The most dangerous version: you are the single point of failure, and nobody has been developed to share the load.
|
AUTHOR: Your annual rhythm — does CorralData have a formal annual planning process? Have you done an energy audit or a succession planning exercise? The reader who is a year or two into the CTO role needs to see what happens when you start asking the annual questions for the first time. |
The Delegation Ledger
Every activity in the operating rhythm has a delegation trigger — a stage or team size at which the activity shifts from "you do it" to "you ensure it happens." The purpose of the ledger is to make these transitions visible and pre-decided, so that delegation happens at the right time rather than under crisis pressure or, worse, never.
The pattern for the ADHD CTO is that delegation itself requires executive function — identifying the right person, defining the scope, monitoring the handoff — and therefore tends to be deferred. The ledger removes the decision: when the condition is met, the handoff happens. The CTO who is still running incident reviews at fifty engineers is not being thorough. They are avoiding the harder work of building a team that can run incident reviews without them.
The counterpart failure is impulsive delegation — handing off critical activities without adequate transition because they have become boring. The ledger prevents this too: activities marked "never delegate" (CEO relationship, technology strategy, advisory conversations, the shutdown ritual) remain with the CTO regardless of stage. These are the activities that justify the role’s existence. Delegate them and you are a title without a function.
Camille Fournier’s warning applies: "It is incredibly difficult to maintain influence and effectiveness as an executive with no reporting power."[24] The CTO who delegates everything to the VPE becomes an advisor rather than an executive. The operating rhythm keeps the CTO anchored to the work that only they can do — the strategic, relational, and cultural activities that compound over time — while freeing them from the operational activities that someone else should own.
Why This Chapter Exists
The CTO role has no natural structure. That is the source of its difficulty and, for the CTO whose brain requires external structure to function, the source of its danger. The operating rhythm is the structure the role does not provide. It externalises intention into action, breaks annual goals into daily steps, and makes the right behaviour visible at the moment of performance. It is, in Barkley’s language, a prosthetic for the executive function that the role demands and that no human — ADHD or otherwise — can sustain under chronic pressure without support.
Chapter 13 told you to stop coding. This chapter told you what to do instead. Chapter 15 describes what happens when you do not build this structure — the burnout, the isolation, and the slow erosion of the cognitive capabilities that justify the role. The operating rhythm is not a productivity system. It is a survival system.
Appendix E contains a one-page summary of the operating rhythm — daily through annual — designed to be printed, laminated, and kept at your desk. The chapter provides the argument. The appendix provides the tool.