# Make Time: Why Focus Is an Energy Problem, Not a Discipline Problem
> Jake Knapp and John Zeratsky's Make Time argues that focus follows energy and design, not willpower. Ten quotes from the book, and what they mean for developers and engineering leaders.

*7 August 2026* · Jamie Taylor


This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: [Continual Professional Development](/tags/continual-professional-development/)


Most of us treat focus as a test of character. You sit down to do the one piece of work that actually matters, you last about eleven minutes, and then you are reading a Slack thread about nothing in particular with a vague sense of having failed. The story we tell ourselves afterwards is always the same: I need more discipline. I need to try harder. The problem is me.

Jake Knapp and John Zeratsky's "[Make Time: How to Focus on What Matters Every Day](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)" makes a more useful and slightly uncomfortable argument: the problem is usually not your character. It is your energy and your defaults. The authors are not productivity gurus in the usual mould. They are product designers who spent years at Google and Google Ventures building the very apps that are engineered to capture your attention, and Knapp is the person who invented the Design Sprint. They know exactly how the distraction is made, because they helped make it. That is what gives the book its particular credibility. When someone who designed attention-grabbing products tells you the apps are winning on purpose, it lands differently from the usual advice to just put your phone in a drawer.

Their framework is built around four daily moves: choose a single Highlight, get into focused Laser mode to pursue it, Energise your body and mind to fuel that focus, and Reflect to adjust. What I want to pull out here is the thread running underneath all of it, because it is the part that changed how I think about my own working days. Focus is downstream of energy. When the battery is full you can hold your priorities and think clearly. When it is empty you default to whatever is closest, and no amount of gritted teeth fixes that. This sits alongside [the lessons I drew from Alex Soojung-Kim Pang's Rest](/blog/continual-professional-development/rest-why-stepping-away-from-the-screen-is-part-of-the-work/), but where Rest is about recovery once the work has stopped, Make Time is about how you manage energy and design your environment while the work is still going on.

This post draws on the ten quotes I found most useful from the book, and what they mean for software developers and the people who lead them.

## Focus Runs on a Battery


> Our thesis is simple: If you have energy, it's easier to maintain your focus and priorities and avoid distraction and demands. With a full battery, you have the power to be present, think clearly, and spend your time on what matters, not default to what's right in front of you.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


This is the whole book in four sentences, and it is worth sitting with because it inverts the usual model. The usual model says focus produces good work and distraction is a failure of focus, so the fix is to focus harder. Knapp and Zeratsky put energy underneath all of it. Focus is not the root cause. It is a symptom of having enough energy to choose where your attention goes rather than letting the environment choose for you.

Any developer can confirm this from experience. The same person who writes clean, well-reasoned code at ten in the morning will, at four in the afternoon after three meetings and a skipped lunch, stare at a failing test for twenty minutes and reach for their phone every ninety seconds. The code did not get harder. The battery drained. The afternoon version of you is not less disciplined than the morning version. They have less to work with. Recognising that is the difference between fixing the problem and just feeling guilty about it.

For anyone leading an engineering team, this reframes a question you are probably already asking in the wrong terms. When focus on the team is poor, the instinct is to look for a motivation problem or a discipline problem. The more accurate question is what is draining the battery. Back-to-back meetings, a culture of instant Slack replies, constant context-switching across three half-finished tickets, an on-call rota that wrecks people's sleep. These are not motivational failures. They are energy leaks, and you have far more control over them than you have over anyone's willpower.

## You Only Waste Time When You Stop Choosing


> You only waste time if you're not intentional about how you spend it.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


I appreciate how much this single line refuses to moralise. It does not say screen time is bad, or that rest is lazy, or that an afternoon spent reading something unrelated to work is wasted. It says the only thing that makes time wasted is the absence of a choice. An hour you deliberately spend doing nothing is not wasted. An hour that simply happened to you, that you fell into without ever deciding, is the one you will regret, regardless of what filled it.

The trap that catches most knowledge workers is the second one, and the authors give it a sharp image:

> The faster you run on the hamster wheel, the faster it spins.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


This is the busyness trap, and software teams are unusually good at building it. Clear the inbox and you train people to expect fast replies, which generates more email. Answer Slack instantly and you become the person who answers Slack instantly, so more of it comes your way. Pick up every ticket the moment it lands and the queue learns it can interrupt you. The activity feels like productivity because it is genuinely effort, and it is genuinely tiring, but the wheel does not go anywhere. It just turns faster the harder you push it.

The leadership version of this mistake is measuring the wheel and calling it progress. I have written before about [how DORA metrics get misread and what they actually measure](/blog/when-agile-isnt-agile-how-dora-metrics-reveal-whats-really-broken/), and the hamster wheel is the failure mode in its purest form. A team can post rising velocity, more tickets closed, more commits, more messages sent, and be moving no closer to anything that matters. If the numbers you celebrate measure motion rather than outcomes, you are rewarding people for running faster on the wheel. The intentionality the authors describe for an individual has an organisational equivalent: deciding, deliberately, what the one thing the team needs to make progress on this week actually is, and protecting it from the endless supply of urgent-looking activity that would otherwise fill the time by default.

## Bring the Barriers Back


> Product designers like us have spent decades removing barriers to make these products as easy to access as possible. The key to getting into Laser mode and focusing on your Highlight is to bring those barriers back.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


This is the most important idea in the book for a technical audience, because it reframes distraction as an engineering problem rather than a character flaw. Every frictionless thing on your screen is frictionless on purpose. Someone whose job it was to remove the barriers spent months removing them. The notification that appears the instant a message arrives, the app that opens to an infinite feed, the single tap that takes you from your editor to somewhere far more entertaining. None of that is an accident, and losing to it is not a moral failure. You are losing to professional design work, often done by people as skilled as you are.

Once you see distraction as a design outcome, the response stops being try harder and becomes change the defaults. This is the move developers are best equipped to make, because reconfiguring environments is literally the job. Turn notifications off rather than promising yourself you will ignore them. Sign out of the accounts that pull you away, so getting back in takes the thirty seconds that breaks the impulse. Put the phone in another room, not face-down on the desk. Knapp and Zeratsky call the daily priority your Highlight, the single thing you most want to make progress on, and the practical point is to put deliberate barriers between yourself and everything that competes with it. You are not relying on willpower to win an unfair fight. You are adding friction until the fight becomes fair.

For leaders, the same principle scales to the team's environment, and here it cuts against a lot of received wisdom. We spent a decade removing barriers inside engineering organisations in the name of collaboration: open-plan offices, default-public channels, the expectation of availability, the badge of honour around replying quickly. A great deal of that is friction we removed on purpose, and it produces exactly the distraction you would predict. Putting some barriers back, protected focus blocks, meeting-free days, an explicit and stated norm that Slack is asynchronous and a delayed reply is fine, is not anti-collaboration. It is designing the environment so that the deep work your team is paid for becomes the path of least resistance rather than the thing they have to fight the building to do.

## Put the Laptop Down, Pick Up a Pen


> Paper improves your focus, because you can't waste time picking the perfect font or searching for something on the Web instead of working on your Highlight. Paper is less intimidating, too: whilst most software is designed to guide you through a series of steps that will lead to a finished product, paper allows you to find your own way to a cohesive idea. And paper opens up possibilities, because whereas Word is designed for lines of text and PowerPoint is designed for graphs and bullet points, on paper, you can do anything at all.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


There is something pleasingly contrary about two career software designers recommending paper, and they mean it precisely because they understand what software does to your attention. The moment you open a document, the tool starts making suggestions. It wants you to pick a font, format a heading, fix the underlined word, and every one of those small pulls is a tiny exit from the actual thinking. A blank page makes no suggestions at all. It does not autocomplete, it does not have a browser one tab away, and it cannot be searched, so the only thing left to do is think.

For developers this is most useful at exactly the moment the work is hardest, which is before any code exists. Designing a system, working out the shape of an API, untangling why a process keeps deadlocking. These are problems that want boxes and arrows and crossings-out, not a cursor blinking at line one demanding valid syntax. Sketching an architecture on paper lets you stay with the messy, half-formed version of an idea long enough for it to cohere, without the tool nagging you to make it tidy before it is right. The authors put it plainly: next time you are struggling to get into Laser mode, put the computer away and pick up a pen. It is a smaller change than it sounds and it works more often than you would expect.

The leadership read here is about meeting culture and the tools you reach for by default. A team that does its early thinking on a whiteboard, together, will frequently get further than one that opens a shared document and immediately starts arguing about structure and wording. The unfinished, scrappy medium keeps people in the problem rather than in the formatting. If your design discussions consistently produce tidy documents and shallow conclusions, the tool may be doing more of the talking than the people are.

## Boredom Is an Energy


> When you're deprived of distraction, you may feel bored, but boredom is actually a good thing. Boredom gives your mind a chance to wander, and wandering often leads you to interesting places. In separate studies, researchers at Penn State and the University of Central Lancashire found that bored test subjects were better at creative problem solving than were their nonbored peers.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


We have almost entirely eliminated boredom, and we did it without ever deciding to. The queue, the lift, the two minutes waiting for a build, the walk to get a coffee. Every one of those small gaps used to be empty, and now every one of them is filled by a glance at a phone. It feels like reclaiming dead time. What the research suggests is that we have been quietly removing the exact conditions under which the mind solves its harder problems.

Every developer knows the experience the studies are pointing at, even if they have never connected it to boredom. The bug you cannot crack at your desk solves itself in the shower. The design that would not come together arrives on the walk home. This is not luck and it is not mystical. It is what a mind does when it is given nothing to consume: it goes back over the unfinished problem and makes connections the focused, busy version of you was too occupied to make. By filling every idle moment with input, we are starving that process of the empty space it needs to run. I touched on the same mechanism in the piece on Rest: the wandering mind is not an idle mind, it is a mind working on something else.

For leaders, the practical implication is to stop treating every quiet moment as waste to be optimised away. A developer staring out of the window is not necessarily disengaged, and a team that never has a slack moment between deliveries is not necessarily a healthy one. The cultural pressure to look busy makes boredom feel like a sin, which means people fill the gaps where their best ideas would otherwise have surfaced. Protecting some genuine empty space, and visibly not punishing it, is part of protecting the team's capacity to solve the problems that do not yield to brute force.

## Perfection Is Just Another Shiny Object


> Perfection is a distraction, another shiny object taking your attention away from your real priorities.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


This one tends to sting, because perfectionism is the distraction that disguises itself as conscientiousness. Refreshing a feed is obviously a way of avoiding the work. Spending another hour polishing something that was already finished does not feel like avoidance at all. It feels like care, like high standards, like doing the job properly. The authors are pointing at the uncomfortable truth underneath it: time spent gold-plating something that was already good enough is time taken away from the thing that actually needed you, and the fact that it looks like diligence is what makes it so effective as a way to avoid the harder, scarier, more important task.

Software is fertile ground for this, because there is always one more refinement available. The abstraction that could be a little cleaner. The function name that could be marginally better. The configuration option nobody asked for that you add anyway, just in case. Some of that is craft and matters. A great deal of it is bikeshedding, polishing the parts that are comfortable to work on precisely because the part that genuinely matters is daunting. The discipline the book asks for is not lower standards. It is the honesty to notice when you have crossed from making something good into hiding inside the safe, infinite work of making it perfect, and to recognise that the second one is draining your battery without moving your real priority forward.

For leaders, this is worth watching for in the team's work and modelling in your own. A culture that treats every piece of work as needing to be flawless before it can ship will produce people who polish endlessly because shipping feels too exposed. Naming good enough as a legitimate and finished state, deciding together what level of finish a given thing actually warrants, frees a surprising amount of energy that was being quietly burned on diminishing returns.

## Your Brain Runs on Your Body


> When you don't take care of your body, your brain can't do its job. If you've ever felt sluggish and uninspired after a big lunch or invigorated and clearheaded after exercising, you know what we mean. If you want energy for your brain, you need to take care of your body.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


It is easy to think of focus as a purely mental resource, something that lives in the head and runs on motivation. The authors keep insisting it does not. The brain is an organ in a body, and it performs roughly as well as the body it depends on is doing. Most developers already know this from the inside, even if they organise their days as though they do not: the post-lunch slump where nothing makes sense, the way a hard problem suddenly has edges again after a walk, the difference a proper night's sleep makes to code you would have shipped with bugs the day before. None of that is in your imagination. It is the battery, and the body is how it charges.

The same logic extends from the body's machinery to the mind's, which is why the authors are equally interested in stillness:

> The act of slowing down and noticing your thoughts is exertion that leaves you invigorated, just as exercise does. In fact, the effects of meditation look a lot like the effects of exercise. Studies show that meditation increases working memory and the ability to maintain focus. Meditation even makes parts of the brain thicker and stronger, just as exercise builds muscle.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


The framing I find most useful here is that attention behaves like a muscle, and slowing down deliberately is how you train it rather than how you neglect it. For an individual developer the takeaways are unglamorous and reliable: protect your sleep, move during the day, take the lunch break away from the desk instead of eating at the keyboard, and treat a few minutes of doing nothing on purpose as maintenance rather than as time stolen from the work. These are not wellness niceties bolted onto the side of the job. They are the conditions under which the thinking the job actually requires becomes possible.

For leaders, the obligation is to make those conditions available rather than quietly punishing them. A culture where taking a real lunch reads as a lack of commitment, where the calendar is so dense there is no room to move, where being online late is admired, is a culture that drains the team's batteries and then wonders why the work has got slower and the bugs more frequent. As I argued in the [Rest piece](/blog/continual-professional-development/rest-why-stepping-away-from-the-screen-is-part-of-the-work/), the conditions of a team are set by behaviour rather than by policy documents. If you skip your own lunch and answer messages at eleven at night, no wellbeing statement will convince anyone that looking after the body is genuinely allowed.

## The Battery Charges Around Other People


> It's a cruel irony of modern life that we're surrounded by people yet more isolated than ever. This is a big deal, especially if you consider the findings from Harvard's 75-year Study of Adult Development: People with strong relationships are more likely to live long, healthy, fulfilling lives. We're not claiming that talking to strangers in the grocery store checkout line will help you to live to be 100, but spending time with people face-to-face can be a big energy booster.
>
> — Jake Knapp and John Zeratsky, [Make Time](https://app.thestorygraph.com/books/358a3133-b80c-48de-ae08-c432e736923d)


The authors include relationships in a book about focus because, for a lot of people, other people are a source of energy rather than a drain on it, and we have built a working world that quietly removes the good version of human contact while keeping all the draining bits. We are more connected than any generation before us and frequently more isolated, surrounded by notifications from people we never actually speak to. The Harvard study they cite is one of the longest-running pieces of research on what makes a life go well, and its headline finding is stubbornly unglamorous: the quality of your relationships is one of the strongest predictors of how the rest of it turns out.

For software teams, this has become sharper and more practical since so much of the work went remote. Asynchronous work has real advantages, and I am not arguing against it. But an all-text, all-async working life strips out the face-to-face contact that recharges a lot of people, and replaces it with a stream of messages that, for many, does the opposite. The energising version of working with other people is the actual conversation, the pairing session where you are genuinely solving something together, the call where you can see a face. The draining version is the endless notification feed that simulates contact without delivering any of its benefits. If the only way your team experiences each other is through unread badges, the social channel that should be charging batteries is flattening them instead.

For leaders, the design question is how to put the energising kind of contact back in deliberately, because in a distributed team it will not happen by accident the way it once did in an office. Real pairing rather than parallel solo work. Occasional time in the same room when it is feasible. Calls that exist to think together rather than to read status updates aloud. Treating human connection as part of the team's energy system, not as a soft extra you get to once the real work is done, is the practical version of taking the Harvard finding seriously.

## The Argument in One Sentence


Make Time is a deliberately small book, structured as a menu of tactics you are meant to try, keep what works, and discard the rest. That modesty is part of why it holds up. It is not selling a system that will transform your life if you follow all of it. It is making one well-supported claim and offering a lot of small ways to act on it.

The claim, reduced to a sentence, is this: focus follows energy and design, not willpower. When the battery is full and the environment is built to protect your attention rather than to harvest it, focus mostly takes care of itself. When the battery is empty and every default is tuned to pull you away, no amount of discipline will save you, and blaming yourself for losing that fight just wastes more of the energy you needed in the first place.

For a developer, that turns an apparently hopeless problem into a series of solvable ones. Manage the battery: sleep, move, eat, take real breaks, protect some empty space for the mind to wander. Redesign the defaults: kill the notifications, add the friction, choose the single Highlight that matters today and put barriers between yourself and everything that competes with it. None of it requires you to become a more disciplined person. It requires you to treat your own attention as a system worth engineering, which is a thing you already know how to do.

For a leader, the same logic raises the stakes, because you are not designing one person's environment, you are designing the conditions everyone on the team works inside. The question is whether those conditions charge the battery or drain it, whether the defaults protect deep work or quietly punish it, and how far your own visible habits give people genuine permission to manage their energy. Getting that right is one of the most consequential things an engineering leader can do, and it is the kind of work I do regularly with the leaders I support.

---

If the conditions your team is working in are draining the battery faster than anyone can charge it, that is a conversation I have often with engineering leaders. [Let's talk](/schedule-consultation/).