# How to Winter: What Dark Seasons Say About Difficult Quarters
> Arctic Norwegians report better winters than people in Oslo, on far less daylight. Nine passages from Kari Leibowitz's How to Winter, for software teams.

*16 October 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/)


In 2014, a social psychologist called Kari Leibowitz moved to Tromsø on a US-Norway Fulbright scholarship. Tromsø sits well inside the Arctic Circle, far enough north that the sun does not clear the horizon at all for the better part of two months either side of the new year. She went expecting to study seasonal depression. What she found, before she had collected any data at all, was neighbours who were looking forward to the polar night.

The research that came out of it, published in the International Journal of Wellbeing in 2020, surveyed 238 people across southern Norway, northern Norway and Svalbard. The headline result is the one worth sitting with: people in the high North reported more positive experiences of winter than people in Oslo. Oslo is cold too. Oslo simply has considerably more daylight. If darkness and cold were doing the work, the ranking would run the other way.

[How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c) is the book that grew out of that finding. It is not a business book, it does not mention software once, and it is not trying to make anybody more productive. I read it over the winter of 2024 and it has kept resurfacing in a context its author never intended, which is why it has ended up in this column.

Here is the connection. Every software team I have worked with has periods that behave like a season. The eighteen-month migration where nothing visible ships. The quarter after a serious incident, when every change carries more weight than it should. The stretch where the roadmap is all maintenance and the interesting work has been deferred again. These arrive, they last a while, and they pass. The default organisational response is to treat each one as an aberration: something that has gone wrong, that somebody should have prevented, and that must be endured with gritted teeth until normal service resumes.

Before going further I want to be clear about what this argument is not, because there is a version of it that is worthless and an engineering audience will spot it immediately. Leibowitz is not claiming that a good attitude makes hard things easy, and I am not about to suggest that a bad quarter becomes pleasant if your team thinks about it correctly. The polar night is genuinely dark. Her point is narrower and considerably more useful: the conditions and your experience of the conditions are two different variables, and only one of them is fixed.

What follows is nine passages from the book, read through the lens of leading and working in software teams.

## Talking Yourself Into a Bad Quarter


> The predictions of our own minds, shaped by our mindsets, are meant to be helpful and prepare us for what comes next. But as research on placebo effects shows, they also make the reality we expect more likely.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


> When we have the mindset—subconscious or otherwise—that “winter is dreadful” or “winter is limiting,” we expect that winter will be lifeless and boring. By expecting winter to be terrible, we might be nocebo-ing our way into the season.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


The nocebo framing is an analogy rather than a clinical claim, and Leibowitz hedges it carefully; note the "might be". Read as an analogy, though, it describes something I have watched happen in project kickoffs more times than I can count.

Somebody stands up and says: this is going to be painful, but we have to do it. It is meant kindly. It is meant as honesty, and as solidarity, and it is usually accurate. The migration probably will be painful. But the sentence does something beyond describing the future, because it tells forty people what to look for over the next six months, and people are very good at finding what they have been told to look for.

A team primed to expect a grind reads every piece of friction as confirmation. The build that breaks on a Thursday becomes evidence. The dependency that turns out to be undocumented becomes evidence. Meanwhile the third week, where the schema changes went through cleanly and nobody had to work late, passes without comment, because a quiet week does not fit the story and so nobody bothers to file it. By month four the team's shared account of the project is a highlight reel of everything that went wrong, assembled honestly, from real events, and wildly unrepresentative.

The alternative is not to pretend the work is easy. It is to be equally honest about difficulty while pointing attention somewhere more useful. "This is going to be a hard six months, and at the end of it we will have a system nobody is frightened to deploy on a Friday" contains exactly the same warning as "this is going to be a slog". It simply tells people what to watch for as well as what to brace against.

## Mindset Is a Thermostat, Not a Switch


> While moments of insight can inspire us to adopt new mindsets, and a-ha moments can help strengthen those mindsets, changing our mindset is not a one-and-done. It is not as simple as flipping a switch that then remains “on” indefinitely. Rather, like thermostats, we might set our mindsets to a certain temperature, but the thermostat is then constantly readjusting, reacting to the ambient climate: making the room cooler when it gets too hot, and hotter when it gets too cold.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


This is the most practically useful passage in the book, and it explains the failure mode of almost every culture initiative I have been asked to look at.

The pattern is familiar. There is an offsite, or a workshop, or an all-hands where a new set of working principles is announced. The day itself goes well; people are engaged, the conversation is genuine, somebody says something honest that they would not normally have said in front of their manager. Six weeks later nothing has changed, and the organisation concludes that the initiative failed and that this sort of thing does not work here.

It did not fail. It was treated as a switch. A single day of insight was expected to hold its setting indefinitely against an ambient climate that pushes constantly in the other direction: the deadline, the reorganisation, the quarter where headcount is frozen, the incident that makes everyone cautious for a month.

> We adjust the thermostat regularly: making it cooler before bed or warmer when we wake up, turning it up or down depending on the weather. Similarly, our mindsets require regular check-ins, and cultivating more useful mindsets is an ongoing practice: our external conditions and internal states can make adopting desired mindsets more or less effortful.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


The check-in is the whole mechanism, and in a team it is unglamorous. It is the retrospective that asks how people are finding the work rather than only what went wrong in the sprint. It is the one-to-one that spends five minutes on something other than status. It is boring, it is regular, and it is the part that gets dropped first when things get busy, which is precisely when the ambient climate is working hardest against you.

I have made the same argument before about [psychological safety in development teams](/blog/building-psychological-safety-in-your-development-team/), and the mistake is identical in shape. Safety gets treated as a state a team achieves and then possesses, rather than a condition that has to be maintained against constant pressure. Nobody concludes that their heating is broken because the house got cold again overnight. Leibowitz's closing line on this is the one to keep: "Getting in the habit of checking in with our mindsets helps us cultivate them over time."

## Where You Point Everyone's Attention


> Our words direct our and others’ attention: What if we took that power seriously and vowed to start directing attention where we actually wanted it to go?
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


Think about how the systems in your organisation get named in casual conversation. The legacy platform. The monolith. That horrible old codebase nobody wants to touch. It is usually said affectionately, in the way people are affectionate about weather they cannot change, and nobody intends anything by it.

The people who maintain that system hear it differently. They hear a standing assessment of where their work sits in the organisation's estimation, repeated in every planning meeting, and after a couple of years of that it becomes very difficult to care about doing the work well. I have gone into organisations where the maintenance team had quietly stopped raising improvements, not because they had run out of ideas, but because the shared vocabulary had already settled the question of whether that codebase was worth improving.

The same mechanism operates in incident reviews, and there the difference is sharper. "Who broke it" and "what let this through" describe the same event and produce completely different investigations. The first directs attention at a person, and the honest answer is usually available within ten minutes, at which point the review stops. The second directs attention at a system, takes longer, and turns up the missing test, the deploy process that permits it, and the alerting that stayed quiet for forty minutes. Only one of those reviews leaves you better defended.

None of this requires pretending the codebase is good. Describing code accurately is a professional obligation and I would not want anyone to stop. The distinction is between an accurate description of an artefact and a running commentary that tells everyone the work is beneath notice. As I wrote when covering [what a team's silence is telling you](/blog/your-teams-silence-is-telling-you-something-psychological-safety-in-development-teams/), the actual culture of a team is set by what gets said repeatedly and casually, not by what is written down.

## Open, Without Being Dishonest About It


> The world responds differently to someone who is open, looking for wonder, and noticing the good than it does to someone who is closed-off, finding the flaws in any situation, and complaining. Our words direct our attention which, as we learned in chapter 3, profoundly shapes our experience. Saying something out loud gives it power—to ourselves, and to others.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


I expect this to be the passage that loses people, so let me take the objection seriously rather than talk around it.

Software engineering is a discipline built on finding flaws. Code review, testing, threat modelling, post-incident analysis, the whole apparatus, is organised professional pessimism, and it works. Told to stop finding the flaws in any situation, a good engineer should reasonably conclude they are being asked to be worse at their job. If that were the instruction I would ignore it too.

It is not the instruction. The distinction that rescues the passage is between being critical of an artefact and being closed toward a situation, and they come apart cleanly in practice. Two reviewers look at the same pull request and both find the same six genuine problems. The first writes up all six and, somewhere in the review, makes it clear they understood what the change was trying to achieve. The second writes up the same six and treats the author as an obstacle between them and their afternoon. Identical technical findings; entirely different effect on whether that author brings the next risky, half-formed, genuinely important change to review at all, or quietly routes around the process.

There is a line that gets used to close this conversation down. It comes from a speech Theodore Roosevelt gave in Paris in 1910, and it is where Brené Brown took the title of [Daring Greatly](/blog/continual-professional-development/into-the-arena-lessons-for-tech-leaders-from-daring-greatly/), which I wrote about only last month.

> It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly.
>
> — Theodore Roosevelt, [The Man in the Arena](https://en.wikipedia.org/wiki/Man_in_the_Arena)


I have watched that passage used in engineering organisations to wave away an entirely legitimate objection, on the grounds that the person raising it is merely a critic and should get into the arena themselves. It is worth being precise about who Roosevelt is describing, because it is not them. His critic is a spectator: someone who carries none of the consequences of what is being attempted and pays nothing at all if their assessment turns out to be wrong. That is a poor description of a code reviewer. The reviewer owns the system the change is being merged into, will be the one paged at four in the morning when it misbehaves, and wears the cost of having approved something they should have questioned. An engineer raising a concern about an authentication flow has more skin in the game than most people in the room, not less.

Which joins the two halves of this section together. What made the second of my two reviewers a spectator was never that they found six problems. It was that they had no stake in whether the author came back.

The complaint half matters too. There are teams where complaint has become the default register, the medium through which everything is discussed, and where saying that something worked feels faintly naive. The complaints are usually valid. The problem is that a team which has lost the vocabulary to notice what is working has also lost the ability to distinguish a genuinely bad quarter from an ordinary one, and once you cannot tell those apart you cannot tell your leadership anything useful about either. Adam Grant's argument about holding your own views loosely, which I covered in [Rethinking](/blog/continual-professional-development/learning-to-think-again-rethinking-lessons-from-adam-grant-for-technical-leaders/), applies to a team's settled opinion of itself as much as it does to technical positions.

## Tiredness Is Not a Moral Failing


> Fighting our winter tiredness—or any tiredness—is to fight our fundamental human needs. I don’t get mad at myself when I need to go to the bathroom, nor do I feel ashamed about needing oxygen. So why do I see it as a moral failing when I need sleep?
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


The rhetorical move here is what makes it land. Leibowitz does not argue that tiredness is acceptable or that we should be kinder to ourselves about it; she simply points out how strange it is to have moralised a physiological requirement at all, and lets the strangeness do the work.

Software teams moralise it constantly, and the tell is the apology. "Sorry, I'm not much use today." The message explaining a day of sick leave in considerably more detail than anyone needed or asked for. The engineer who took a page at three in the morning, resolved it by half four, and is in the nine o'clock planning meeting because the meeting is in the calendar and cancelling it would look like something.

If the people you lead apologise for being tired, they have learned that tiredness is a performance failure. Nobody set out to teach them that, and it is worth being honest that they usually learned it by watching what happened to somebody else, or by watching what their manager does with their own evenings.

The operational version of this is on-call. A rota that pages people overnight without building recovery into the following day is not a wellbeing problem in the first instance; it is a correctness problem, because you have arranged for tired people to make production decisions. I went into this at more length when writing about [Rest](/blog/continual-professional-development/rest-why-stepping-away-from-the-screen-is-part-of-the-work/), where the neuroscience is more thoroughly laid out, but the short version is that the recovery is part of the work rather than a reward for having done it.

## The Belief That Cancels the Break


> One study found that viewing leisure as “wasteful” and “unproductive” undermines enjoyment of relaxing or fun activities, even as leisure itself has been shown to lower blood pressure, reduce risk of depression, and strengthen relationships. Worse still, viewing this downtime as wasteful is associated with lower happiness, greater depression, and more stress and anxiety. This effect was strongest for leisure activities that are not in service of other goals (like exercising or meditating), but whose sole purpose is enjoyment (like relaxing, watching TV, or pursuing hobbies).
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


The specificity at the end is the part that caught me, because it closes off the escape route most developers I know have already taken.

The effect was strongest for leisure with no instrumental purpose. Not exercise, which is in service of health. Not meditation, which is in service of focus. The activities whose only justification is that you enjoy them. Which means the developer who spends a week of annual leave working through a book on distributed systems has not solved this problem; they have converted their leisure into professional development and kept the audit running.

That audit is the mechanism. The holiday where you check Slack twice a day is not really about the Slack messages, because there is rarely anything in them that could not wait. It is about continuing to evaluate whether taking the time was justified, and an evaluated break does not restore you. You have spent the week paying the cost of being away without collecting the benefit.

For anyone leading a team, the belief is not usually the individual's to begin with. It is learned from the environment, and it is learned fast. If time off is reliably followed by a quiet accounting of what slipped while somebody was away, people will draw the obvious conclusion, whatever the holiday policy says. Cal Newport makes the productivity case for this at length in [Slow Productivity](/blog/continual-professional-development/slow-productivity-why-looking-busy-is-costing-you-real-output/), and Knapp and Zeratsky arrive at the same place from the direction of energy management in [Make Time](/blog/continual-professional-development/make-time-why-focus-is-an-energy-problem-not-a-discipline-problem/).

## Seasons You Did Not Choose


> Ritualizing periods of change, wringing joy from the passage of time, and actively embracing shifts in external circumstances outside of our control are practices that can aid us during some of life’s most poignant and bittersweet moments. Like winter’s darkness, we will all face unwanted changes—or wanted changes that still hurt—at some point.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


"Wanted changes that still hurt" is doing a lot of work in that sentence, and it names something organisations are consistently bad at acknowledging.

The acquisition that everybody wanted still ends the company that people joined. The promotion that a team is genuinely pleased about still takes their best engineer off the team. The rewrite that finally ships, on time, to general relief, also renders three years of somebody's careful work obsolete, and the person who wrote it is expected to be delighted. When an organisation only has language for changes that are straightforwardly good or straightforwardly bad, everyone in the ambiguous middle learns to keep quiet about how they actually feel.

The ritual half is where software teams are weakest. We are good at marking beginnings; launches get announcements, demos, sometimes cake. We almost never mark endings. A service that ran for eight years, that somebody was proud of, that carried real load through two Christmases and a failed data centre migration, gets switched off in a Tuesday afternoon ticket with a two-word commit message.

This costs less to fix than most things I get asked about. Run a retrospective on the whole life of the thing rather than the last sprint of it: what it did, what it taught you, who kept it running at three in the morning and never mentioned it. Across the organisations I have worked with over the last twenty years, the teams that handle change worst have not been the ones facing the most of it. They have been the ones where change arrives unmarked and unexplained, so that every instance registers as an anomaly rather than as weather, and the team never develops the sense that they have come through this kind of thing before.

## What the Dark Is Good For


> One study found that both thinking about darkness and actual dim lighting increased creativity. Darkness increased people’s efficiency in dreaming up creative answers and the number of unique solutions they proposed. According to this research, darkness makes people feel free, loosening our usual constraints and encouraging us to take risks; perfect conditions for artistic pursuits.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


I would not redesign an office around that finding. It is a single study, reported as a single study, and the replication history of exactly this kind of priming result over the last fifteen years should make anybody cautious about building a working practice on top of it. Take it as suggestive.

The sentence that follows is where the real weight sits, and it needs no laboratory support because everyone reading this has lived it.

> It can be hard to bare our vulnerabilities and deep feelings in the glaring light of day; we admit more—to ourselves and others—under the safety of shadows.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


Exposure suppresses admission. The incident review with the CTO sitting in the room produces a different account of what happened than the same review without them, and everyone present knows it. The engineer who is out of their depth says so in a one-to-one, months after the point at which saying it would have helped, and never in the planning meeting where the estimate was given. The serious reservation about an architectural decision arrives as a comment on the design document at ten at night, because writing it felt less exposed than saying it while eleven people watched.

There is an organisational version of this too. The quiet stretch between launches, when nothing is shipping and the dashboards are unexciting, is very often when the genuinely difficult architectural thinking gets done. It looks like slack, and it gets filled, because a team with visible capacity attracts work the way a gap in a schedule attracts meetings. Teams held under continuous high visibility do not get the dark period, and they tend to produce a great deal of activity and remarkably little reconsideration.

This sits awkwardly against Brené Brown, and the awkwardness is the useful part. The argument [Daring Greatly](/blog/continual-professional-development/into-the-arena-lessons-for-tech-leaders-from-daring-greatly/) closes on is that we should find the courage to show up and be seen; that vulnerability is worth what the exposure costs. Leibowitz appears to say the reverse, that we admit more when we are less exposed. Both are right, and they are answering different questions. Brown is describing something an individual can cultivate in themselves. Leibowitz is describing the conditions under which disclosure actually occurs. A leader who holds only the first half ends up telling people to be braver, which quietly puts the entire cost of the culture on whoever has the least standing in the room.

Holding both halves points somewhere more practical. If you want people to admit things earlier, the lever is not encouragement. It is lowering the exposure: smaller rooms, fewer observers, written channels for the reservation that is not yet fully formed. Ask for courage after you have made it cheaper to show.

## Learning to Notice Again


> We don’t have to wait for awe to wash over us. In the awe-walk study, people in the awe-walk group were able to feel more awe on purpose. They became better at noticing awe-inspiring scenes or small objects of wonder. This suggests it’s possible to purposely increase our awe by harnessing our attention. By adopting the perspective that tiny miracles are all around, we can strengthen our ability to feel awe.
>
> — Kari Leibowitz, [How to Winter](https://app.thestorygraph.com/books/62a75a7b-fa89-4ebd-b15f-fb71aa5d5d0c)


The claim being made is that awe is trainable. Not a mood that arrives, but a capacity that improves with deliberate attention, in the same way that a developer who has spent a year doing code reviews starts seeing whole categories of bug they used to read straight past.

I have spent close to twenty years in this industry and worked with more than fifty organisations in that time, and the thing I notice about the people who are still good at this work decades in is not that they are cleverer. It is that they have not stopped finding any of it strange. That a set of machines with no shared clock can agree on the order of events is genuinely peculiar. That a garbage collector runs underneath your program, deciding what is no longer reachable, without you thinking about it once all week, is an extraordinary piece of engineering. That a request leaves a laptop in West Yorkshire, crosses an ocean and comes back with an answer in under a second is a thing that should probably not work as reliably as it does.

The engineer who has stopped noticing any of that usually gets described as burnt out, or as coasting. I think a more accurate description is often that their attention has narrowed to what is broken, which is, professionally, most of what they are paid to look at. Years of that will do it, and the narrowing is a reasonable adaptation rather than a character flaw.

I am not going to claim that noticing things fixes burnout, because it does not, and the causes of burnout are usually structural and require structural answers. What Leibowitz's research does suggest is that the noticing itself responds to practice. If your best senior engineer has stopped being interested in the systems they built, that is worth treating as a signal about the environment they have been working in rather than as a fixed property of the person.

## Winter Is Not a Failure of Summer


The single most useful thing in the book is a sentence Leibowitz uses about the passage of time: "Learning to meet these changes is learning to accept both the rhythms of the year and the rhythms of our lives."

Software organisations largely do not believe this. The implicit model is that the good state is continuous delivery of visible value, and that any period which fails to produce it is a problem to be explained, escalated, or blamed on somebody. So the migration quarter is a failure of planning. The maintenance stretch is a failure of prioritisation. The cautious months after a bad incident are a failure of nerve. Each one is treated as an aberration, and a team that believes its difficult periods are aberrations will spend most of its energy on the explanation rather than on the work.

The Tromsø finding is the counter-argument, and it is worth restating plainly, because it is the most rigorous thing in this whole post. People living through two months without sunrise report better winters than people a thousand kilometres south with considerably more daylight. The conditions are worse and the experience is better. Something other than the conditions is determining the outcome, and unlike the conditions, that something is available to be changed.

None of which makes a hard quarter shorter. It changes how much of your team's capacity the quarter consumes while it lasts, and whether they arrive at the other end of it with anything left.

If you are heading into one of these periods, or suspect you are already some way into one, the question worth asking is not how to get out of it faster. It is what your team currently expects from it, where that expectation came from, and whether anybody has told them what to look for besides the friction. That is the sort of thing I spend a lot of my time on with engineering leaders, and if it would be useful to talk it through, [a consultation is a reasonable place to start](/schedule-consultation/).