Startup culture is built on multitasking, but human brains aren’t. Here is how we redesigned the Ewake SDLC to ruthlessly protect our focus.

I'm a multitasking Luddite. I don't like it, never have. It's an occupational hazard in our line of work, and codegen has only made it faster (worse). My theory that constant multitasking is a bad way to live has only got stronger.

The proof, tragically, came in the form of an Instagram reel. In my defence, it was an unusually well-cited Instagram reel. I interrupted my doomscroll to follow up on their research, went down a rabbit hole, and emerged with evidence.

It turns out the consensus in neuroscience is pretty unambiguous: Multitasking is a myth. Human brains literally don't have the architecture for it. What we think is multitasking is just rapid task-switching.

Researchers have been sounding the alarm about this for a while. Mark et al. (2008) proved that while thrashing between tasks might make us feel faster in the short term, it inevitably leads to burnout. Even when people are completely free to organise their own schedules, the ones who choose to multitask perform significantly worse than those who force themselves to work sequentially (Buser & Peter, 2012).

This rapid task switching isn’t free. It’s not even cheap. Every time you shift focus, your brain has to drop its current cognitive framework and load a new one. Hasan (2024) found that the mental load required to constantly reorient yourself can cost up to 40% of your productive time. Worse, dividing your resources like this overloads your working memory, which directly leads to mental fatigue and poor decision-making.

So if it makes us slower, worse at our jobs, and actively drains our mental health, why do we keep doing it?

Because of the dopamine illusion. In his book The Organized Mind, neuroscientist Daniel J. Levitin explains that our brains are uniquely wired to reward novelty. Every time you context-switch, your brain gets a hit of dopamine for uncovering new information. You feel productive because you are actively "doing things". In reality, you're just rewarding your brain for being distracted.

tl;dr: Cian read 3 (three) research papers and a synopsis of a book, all of which supported his opinion that constant multitasking is slow and bad for you.

The 40% number was a bit of a shock. The rest was validation.

When I started looking at our engineering process with the dopamine illusion in mind, I saw it everywhere. Our “agile” startup culture was actually just an excuse for team-wide, institutional multitasking.

We were thrashing

When we started, we were doing the Startup™️ thing. The instinct was that the shortest distance from an idea to a signal was the way to go. We planned once a week. We interrupted nearly every cycle with customer asks. We started on things and kept going with them until something more important came up, which was often.

I remember one week back in September clearly. We were head-down on "real" work all week, with no time to plan, and walked into planning on Friday with half-baked ideas. The meeting was the first time we'd actually interrogated those ideas, and within twenty minutes it was clear they weren't ready. So we had to do planning again on Monday. We were spinning our wheels.

We've written before about the PR-queue side of this - what happens when your review cadence can't keep up with the rate of new code. That was the tactical layer. This is the strategic layer, and it starts before any code gets written. Individually, we felt fast. Across a month, we were getting less done. The cost was just off the books.

Shape Up Lite

We went shopping for methodologies, and landed on Shape Up for how it treats scope. Rather than estimating how long a piece of work will take (weird and difficult these days with codegen tooling), we define an appetite up front. We say “as a team, we are willing to invest this much time in this project”. If we hit the appetite limit, we cut scope, or we increase the appetite. The crucial thing is that we make a decision about what to do.

We design the scope up front using a document called a one-pager. This document explicitly defines the appetite, what’s in scope, (crucially) what’s out of scope, and the risk factors that could result in the project missing its appetite.

Each project started with a one-pager. We got better at defining scope in advance. But we weren't ready to commit to the full-on Shape Up active-cycle-plus-cooldown model yet, so we kept doing normal sprint planning every two weeks alongside it.

The other change we made was around our approach to technical design. We were trying to parallelise, and ended up siloing. We kept landing on design discussions in PRs, debating whether the underlying approach was correct after the code had already been written. We started emphasising design on paper before touching code.

Shift the work left

The principle is simple: Time spent on scope saves more time on design, and time spent on design saves more time on code review and implementation.

The efficiency gains were immediate. Design debates that would have taken a day on a PR were handled in an hour at the design review stage. Missed requirements were caught at the scope review instead of having to be retrofitted. Bad features were cancelled before they got off the ground rather than having their PRs blocked.

Codegen made this more important. Fadó fadó, when an engineer used to take three days to implement a feature, we had time to make directional adjustments to the design as we went. Claude Code is fire and forget. If you point it in the wrong direction, it will happily implement a terrible design for you in no time. Because generating code is practically free now, human architectural thought has become the most valuable commodity in our SDLC. Knowing exactly what we’re building before getting into it isn’t optional anymore. It’s the whole job.

For a few weeks, this felt like a revelation. We had fixed the scoping problem, the PR queue was breathing again, and engineers felt like they had real agency over their technical choices.

So we were in business. Problem solved, right?

Not quite.

We were still squeezing in one-pagers between “real” work. We rarely had the time to prep them properly, so we often ended up throwing a one-week appetite at a sparse ticket just to keep things moving - which forced us to figure out scope in real time instead of actually shaping it.

Because we were writing one-pagers sequentially, engineers would finish their current project and find no shaped work waiting. They'd hit the brakes, draft a one-pager, wait for async reviews, and pick up small "quick wins" while they waited. Momentum on the things that actually mattered kept stalling.

Finally, we still didn’t have a great mechanism for changing priorities mid-cycle. Work would come in and we would either jump on it, or stick it in Linear and hope that we’d get to it.

By half-doing Shape Up, we had created a spork - still better than a fork for eating soup, but we wanted more.

Going all in

Our fix was to commit to Shape Up properly. An active cycle for aggressive development, followed by a cooldown period for maintenance, planning, and prep. Basecamp’s default cadence here is six weeks on, two weeks off. The ratio seemed to work for them, but for an 8-person startup, 6 weeks was too long to commit to. We halved it, going for a three-week active cycle followed by a cooldown week.

The cooldown week isn’t a week off. It’s for prep. Engineers act as Shapers, iterating with founders async on the one-pagers for the next active cycle. Appetites get debated and locked. By the end of cooldown, we have a slate of shaped bets (projects) ready to go.

The planning meeting for each active cycle has become a short Betting Table. We look at the shaped one-pagers and decide which bets to fund for the next three weeks. Once we get out of that meeting, the team is unblocked for a month. Nobody has to draft a one-pager or argue about scope during the active cycle. We just build.

The zero-sum game

At this point you’re probably thinking that three weeks is a long time for a startup to lock into a plan. You’d be right. The only way to make it work is to treat the cycle as a zero-sum game.

If something super-important comes in mid-cycle, we should do it. But we have to understand that doing this means that something else drops out of the cycle. This shifts the conversation from “Can we do this?” (to which the answer is almost always “yes, technically”), to “should we do this instead of that?”.

This is the part where the cognitive science comes back into play - briefly. Interruptions feel free to the interruptor. The team bears the cost. We call this the Context Tax, and the cycle makes it visible. We don't avoid paying it - sometimes the new thing genuinely is more important. We just make sure we're paying it on purpose, and that what we're buying is worth the price.

How does this work in practice?

1. New Ideas: We pull an idea from somewhere - conversations with customers, market research or the inherent creativity of our talented, humble team. The idea goes into our ideas pool in Notion, waiting to be shaped.

2. Scoping with One-Pagers: During a cooldown week, an engineer takes the idea and works async with the founders and the team to decide on the appetite, strictly define the scope and identify risk factors. This can take anywhere from an hour to about a day. Once the scope is nailed down, it’s ready for the next step.

3. The Betting Table: We look at all of the shaped one-pagers, and decide which ones we want to pull into the next cycle. If it doesn’t make it into this cycle, we park it and come back to it during the next cooldown week.

4. Active Cycle: This is the easy bit - all the team has to do is put their heads down and build for three weeks. No scope debates or planning. If we run out of appetite, we either cut scope or extend the project at the expense of something later in the cycle.

5. Handling Interruptions: Something new comes in mid-cycle. We pause for a moment. We ask ourselves “if we want to do this, what drops?” The Context Tax is named out loud, and we make an intentional decision. Either the new thing wins, and something else gets punted, or it waits for the next Betting Table.

How it feels

The first cooldown sounded like a light week. No feature work, no sprint goal. How busy could we be?

Pretty busy, as it turned out. Bug fixes we’d been waiting to get to, tech debt we'd been stepping around, DevEx improvements the team had wanted to make for ages. We still had three releases that week. There was a strange guilty pleasure to it. We weren't building anything new, but we were laying the groundwork for the next cycle.

The cycle was different from the drop. We had a plan, everyone knew exactly what they were working on and where to start with it. We could just get stuck in from day one. It felt calm and composed. Not perfect, but not frantic either.

We moved faster because we stopped starting and stopping. The work was better because people could hold a whole problem in their head for longer than twenty minutes at a stretch. The decisions were better because they'd been made before we were under pressure to make them.

We weren't less busy. We hadn't found some secret reserve of extra hours. We just stopped paying the Context Tax by accident, and when we did pay it (because sometimes you have to), we paid it on purpose.

What’s still hard

In a word: Calibration.

The zero-sum rule forces us to be honest about scope, but we don't always get it right. Some one-pagers that looked tight at the Betting Table turned out to be wider than they appeared. We're getting better at it.

The other hard thing is judging urgency. The cycle forces a clear distinction between what is urgent and what feels urgent. That's a judgement call, and we'll get it wrong sometimes. Such is life.

We're still figuring out the details, but the broad strokes seem to be working. The frantic feeling is gone and we’re getting through work fast. That's the whole point.

The thing that changed isn't what we ship. It's the feeling of being mid-thought and knowing that no one is about to pull you out of it.

We still work hard, ship constantly, get curveballs. But there's a shared plan that everyone had a hand in making. When something urgent lands, we know how to handle it. When the cycle ends, there's something finished to point at.

And honestly, it feels gooood.

If this resonated, The Cost of Cheap Code is the companion piece. It covers what codegen did to our PR review process, and why fixing that tactical problem made this strategic one impossible to ignore. You can find all our articles on the Ewake blog.

Ewake is an AI SRE Agent built on a living map of your production system, designed for SREs, platform engineers, and on-call teams running production at scale.