Every engineering organization I have led has eventually run into the same quiet crisis. The team is busy. Calendars are full. Slack never stops. And yet the things that actually move the product forward — the hard refactor, the new ledger reconciliation engine, the payment routing rewrite — keep slipping. When I dig in, the cause is almost never laziness or lack of talent. It is the slow erosion of uninterrupted, deep working time. What we call maker time.
In regulated fintech, this matters more than in most places. The cost of a context-switched mistake is not a cosmetic bug. It is a misposted transaction, a compliance gap, or an incident that ends up in a regulator's inbox. Protecting maker time is not a wellness perk. It is a reliability strategy. I have come to treat it as one of the core responsibilities of engineering leadership, and I want to lay out how I think about it and what I do.
Maker Time Versus Manager Time
The distinction between maker schedules and manager schedules is well worn, but it is worth restating precisely because so few organizations act on it. A manager's day is built from interruptions: a calendar of thirty and sixty minute blocks, each one a context in which to be present and responsive. That rhythm is correct for the work. A manager who disappears for four hours has usually failed at something.
A maker's day is the inverse. Writing a non-trivial piece of software requires holding a large, fragile mental model in your head — the data flow, the edge cases, the failure modes, the half-finished function you were three lines into when the meeting reminder fired. That model takes real time to load and is destroyed instantly by a single interruption. A thirty minute meeting does not cost thirty minutes. It can cost two hours: the meeting, the wind-down before it, and the slow reconstruction of context afterward.
The trouble is that engineering organizations are run by people on manager schedules, and we unconsciously impose our rhythm on people who need the opposite. We schedule a quick sync at 11am because it is convenient for us, never noticing that we have just bisected someone's entire morning. The first step is simply internalizing that the two schedules are genuinely different and that one of them is invisible from the outside.
The Real Cost of Fragmentation
I once audited a team that felt chronically behind despite working long hours. We mapped the gaps between scheduled events. The median uninterrupted block during core hours was forty-three minutes, and almost nobody had a stretch longer than ninety minutes more than once a week. These were strong engineers being asked to build a settlement system in forty-three minute increments.
Fragmentation does not announce itself. It shows up as a vague sense that work is slow, as estimates that keep getting blown, as engineers staying late because the only quiet time is after everyone goes home. That last symptom is the one I watch for most carefully. When your best people are doing their real work at 7pm, you do not have a dedicated team. You have a team that has been denied the conditions to do its job during the day and is quietly subsidizing bad scheduling with their evenings.
If your most senior engineers consistently tell you their best work happens after hours, that is not a sign of commitment. It is a defect report about the working day you have designed.
Protecting the Calendar as Shared Infrastructure
The most concrete lever I have is the calendar, and I treat it as shared infrastructure rather than personal property. The single highest-leverage policy I have implemented is no-meeting blocks that the whole team honors. On my teams, mornings until noon are protected by default. Meetings get scheduled in the afternoon unless there is a genuine reason — an incident, a customer escalation, a time zone constraint — that justifies breaking the rule.
This only works if leadership defends it visibly. The first time someone senior schedules a casual sync at 10am, the policy is dead, because everyone learns it is optional for the powerful. So I decline those invitations publicly and politely, and I explain why. I would rather absorb the friction of a declined meeting than let the protection quietly decay. A few practices have made this durable:
- Default core hours are blocked on every engineer's calendar, so booking over them requires a deliberate, visible choice.
- Recurring meetings are reviewed quarterly and deleted by default unless someone argues to keep them.
- Status updates move to asynchronous written form, so the standing meeting is not the only way to know what is happening.
- Any meeting without an agenda is treated as cancelable, no questions asked.
- One full day a week — for us, Wednesday — carries no recurring meetings at all.
None of these are radical. What is radical, apparently, is actually enforcing them past the first inconvenient week. The policies are easy to write and hard to hold, and holding them is precisely the leadership work.
Making Asynchronous the Default Channel
A lot of meetings exist only because the organization has no good asynchronous alternative. If the only reliable way to get an answer is to grab someone, people will grab someone, and every grab is an interruption. So the path to fewer interruptions runs through better written communication, not through asking everyone to be more disciplined.
I push hard on writing things down. Design decisions go in documents, not in someone's head. Status lives in a shared place that anyone can read without asking. Questions go in a channel where they can be answered when the recipient surfaces, rather than in a direct message that carries an implicit demand for immediate attention. The goal is to make the asynchronous path the path of least resistance, so synchronous interruption becomes the exception people reach for only when it is genuinely warranted.
There is a real cost to this. Writing well takes longer than talking, and it requires a culture that values clear documents. But in a regulated environment we need that written record anyway — for audits, for incident reviews, for the fact that the person who built the reconciliation logic will eventually leave. The discipline that protects maker time and the discipline that satisfies our compliance obligations turn out to be the same discipline.
Containing On-Call and Interrupt-Driven Work
Some interruptions are not optional. We run payment infrastructure; things break and someone has to respond. The mistake is letting that unavoidable interrupt load spread across the entire team like a fine mist, so that everyone is half-distracted and nobody is fully focused. The better model is to concentrate the interruptions deliberately.
I run a rotation where one engineer per week is the designated interrupt handler. They own on-call, the support escalations, the random questions from other teams, and the small unplanned fixes. Their week is explicitly not for deep project work, and we plan their capacity accordingly. In exchange, everyone else gets a genuinely protected week. The deal is honest: you take the interruptions for one week in five, and for the other four you are shielded.
This requires accepting that the interrupt handler's week is lower in feature throughput, and resisting the temptation to load them with planned work because they look available. They are not available. They are absorbing the chaos that would otherwise shatter four other people's focus, and that absorption is the job. When I have skimped on this and quietly assigned the on-call engineer a feature too, the result was predictable: the feature slipped and the support quality dropped.
Designing Meetings That Earn Their Place
I am not against meetings. Some problems genuinely need synchronous, high-bandwidth conversation, and pretending otherwise just pushes the cost into endless document threads that never resolve. The point is not zero meetings. It is that every meeting should earn its place against the maker time it consumes.
So I ask a few unglamorous questions of any recurring meeting. Does it have a decision to make or is it a status broadcast that could be a written update? Are the right people in it, and only the right people? Could it be shorter or less frequent? A weekly meeting that becomes biweekly has just returned a meaningful amount of focus time to everyone in the room, and most weekly meetings have nowhere near enough content to justify the cadence.
I also try to cluster meetings rather than scatter them. Three meetings in a row in the afternoon costs far less maker time than the same three sprinkled across the day, because the scattered version destroys three separate blocks of focus while the clustered version sacrifices one afternoon and leaves the morning whole.
Modeling the Behavior From the Top
Culture follows the visible behavior of leaders far more than it follows stated policy. If I send messages at all hours with an unspoken expectation of fast replies, no policy document will convince anyone that focus time is real. So I am deliberate about the signals I send. I schedule messages to land during working hours. I do not ping people during the protected morning unless it is a true emergency, and I am honest with myself about what counts as one.
When I need deep focus myself, I make it visible. I block the time, I mark myself unavailable, and I let people see that I treat my own maker time as something worth defending. This gives everyone else permission to do the same. An engineer who blocks their morning and declines a meeting should be able to point to the fact that the CTO does exactly that.
The inverse is the more common failure. Leaders who quietly admire the engineer who answers every message in thirty seconds, regardless of what that constant availability is costing in deep work, are teaching the whole team that responsiveness beats output. People optimize for what gets rewarded. If I reward interruptibility, I will get an interruptible team, and an interruptible team cannot build hard things.
Measuring Focus Without Surveilling People
I want to know whether maker time is actually being protected, but I refuse to do it through surveillance. Tracking keystrokes or activity dashboards corrodes trust and measures the wrong thing entirely. Instead I rely on a few honest, low-fidelity signals that tell me about the system rather than policing the individual.
The simplest is to ask directly, in one-on-ones, how the week felt and whether people got the uninterrupted stretches they needed. The answers are honest when people trust that the question is genuine. I also watch the aggregate calendar data — not who is in what meeting, but how fragmented the typical day has become across the team. And I watch the after-hours signal: a rise in late-night commits is usually a symptom that the daytime has stopped working.
The point of measuring is to catch erosion early, because protection always erodes. A new project spins up, a few extra syncs get added, an exception becomes a habit, and within a quarter the protected morning is half gone. Treating maker time as something that needs continuous tending, rather than a policy you set once and forget, is the only way it survives a growing organization.
Conclusion
Protecting maker time is not a soft concern, and it is not in tension with shipping. It is the precondition for shipping the kind of careful, correct software that regulated fintech demands. The hard parts of our work — the settlement engine, the ledger, the routing logic that cannot afford to be wrong — cannot be built in the gaps between meetings. They require sustained, undistracted attention, and that attention is a scarce resource that leadership either defends or squanders. The teams that build the best systems are not the busiest ones. They are the ones whose engineers are reliably given long, quiet stretches in which to think, and whose leaders understand that defending those stretches is the job.