Planning Under Uncertainty for IT Professionals

At 9:12 on a wet Tuesday morning in Warsaw, a backend engineer I will call Pavel opened his laptop to find that the sprint board, carefully groomed the previous afternoon, had already become a historical document. A client escalation had jumped the queue, a security patch needed review before lunch, and the product manager had posted a note in Slack that began with the phrase every technical worker recognises as trouble: “small change, should be quick.” By 9:40, Pavel had four tabs open, two half-written replies, and the familiar sensation that the day was slipping away before any real work had started.

People often describe this condition as poor planning, but that misses the mechanics of what is happening inside a modern technical job. In software teams, uncertainty is not a scheduling error that can be corrected with a better template; it is part of the operating environment, shaped by changing dependencies, invisible waiting time, brittle systems, and the social demand to remain continuously reachable. After two decades coaching engineers, analysts, designers, and technical managers, I have found that the real difficulty rarely lies in choosing priorities once, on a calm Sunday evening, and far more often in preserving attention when the ground keeps moving under ordinary weekdays.

The research helps explain why the usual advice feels thin. Herbert Simon wrote, as early as 1971, that a wealth of information creates a poverty of attention, and that line has aged unusually well in open-plan offices and Slack-heavy teams. Sophie Leroy’s work on attention residue, published in Organization Science in 2009, showed how unfinished tasks continue to occupy the mind after a switch, which means that the average engineer is not merely losing minutes when context changes; they are carrying cognitive drag from one half-finished obligation into the next. Add the “continuous partial attention” Linda Stone described in the late 1990s, and you have a decent sketch of the real Tuesday: not laziness, not lack of discipline, but a nervous system trying to track too many moving objects at once.

What most productivity advice misses is that planning in these conditions cannot be built around prediction alone. It has to be built around recovery, triage, and the protection of scarce cognitive bandwidth, because the plan that survives uncertainty is usually the one that assumes interruption from the start. When I sit with clients who work in infrastructure, QA, data engineering, or support-heavy product teams, I am less interested in whether their task manager is elegant than in whether their week contains any mechanism for absorbing surprise without capsizing the whole day.

The first mistake usually appears before the week has even begun. Sunday-night planning feels responsible, and for some people it offers genuine relief, yet it often produces a fantasy version of the coming week, one in which every task proceeds at the speed imagined by a rested brain in a quiet room. Daniel Kahneman and Amos Tversky spent years documenting the planning fallacy, our stubborn tendency to underestimate how long work will take even when past evidence says otherwise, and technical workers are not somehow exempt because they use Jira. In fact, the more competent someone is, the easier it becomes to imagine a clean run at a difficult task and forget the meeting, outage, clarification, code review, and emotional friction that will arrive in the middle.

That is why I ask clients to stop treating a weekly plan as a contract with reality and start treating it as a draft with shock absorbers. The week still needs shape; without shape, attention leaks into whatever is newest, loudest, or easiest to finish. But shape is different from density, and this is where many high-performing people get themselves into trouble, because they fill every available hour with named intentions and then experience the entirely predictable changes of the week as personal failure rather than normal variance.

One product analyst in Berlin, Elena, showed me a colour-coded calendar that looked, at first glance, like a triumph of adult competence. Her week had themes, her tasks had estimates, and her mornings were reserved for deep work. By Wednesday, the whole system had turned punitive. “I keep moving the same blocks,” she told me during a session, scrolling through her calendar with a kind of embarrassed fury. “Then I feel guilty, so I work late, and then the next morning I’m slower, which means I move them again.” The problem was not her seriousness; the problem was that the calendar assumed a stable environment while her job, split between analytics requests and stakeholder support, was structurally unstable.

The problem with Sunday-night planning

A plan made too far from the point of execution tends to confuse intention with capacity. Capacity is not a moral quality; it is an estimate shaped by sleep, meetings, ambiguity, interruptions, and the hidden tax of switching between kinds of work. Roy Baumeister’s work on self-regulation became overextended in popular culture, but one lesson remains useful in practice: decision-making and inhibition are effortful, and a day full of small unresolved choices drains more than people notice while they are making them. A plan that requires heroic levels of self-command by 3 p.m. is usually a bad plan, however elegant it looked in Notion on Sunday night.

In real coaching sessions, I often replace the question “What must get done this week?” with a more grounded one: “What can move even if the week becomes noisy?” That shift sounds modest, yet it changes the architecture of work. Instead of creating a long inventory of desirable outcomes, the client identifies two or three pieces of meaningful progress that can survive disruption because they are scoped to fit into the actual cavities of the week. This matters especially in technical roles, where a task can be too small to deserve planning and too large to finish in one sitting, which is how it ends up haunting five consecutive days.

There is also a social layer that spreadsheets never capture. Many IT professionals work inside cultures that reward responsiveness more visibly than concentration, and the result is a strange theatre of usefulness in which the person who answers fastest appears more reliable than the person who protects a difficult block of problem-solving time. Leslie Perlow’s research at Harvard, particularly in Sleeping with Your Smartphone, documented how organisational norms around availability can deform attention and family life alike; anyone who has watched a team live inside Slack pings until 10 p.m. will recognise the pattern. Under those conditions, a plan fails less because it was inaccurate than because it was politically fragile.

A sturdier weekly practice begins with fewer promises and more explicit margins. I usually recommend one visible list for incoming obligations, a separate and much shorter list for work that would materially improve the week if completed, and calendar blocks that reflect energy rather than fantasy. For many clients, the crucial move is to stop assigning high-cognition tasks to hours that are already perforated by stand-ups, check-ins, and message traffic, because once a demanding task is repeatedly started and abandoned, it begins to acquire emotional weight in addition to technical complexity.

Where the matrix fails on a real Tuesday

Classic prioritisation matrices have their uses, especially when a team needs a shared language for urgency, but they break down quickly in the lived texture of technical work. A production issue may be urgent for reasons that are obvious, while a quiet architectural decision is important in a way that remains invisible until six weeks later, and a manager’s “quick question” may be neither urgent nor important in theory while still carrying enough interpersonal force to derail an hour. Real work is not sorted by clean quadrants; it is filtered through dependency chains, partial information, and the politics of who is waiting on whom.

This is why I teach clients to make three distinctions before they decide what today is for. First, what requires high-quality thinking rather than mere completion, because these tasks need the freshest attention available. Second, what is time-sensitive because another person or system is blocked, since delay there creates compound costs. Third, what can be advanced in a bounded way, even if it cannot be finished, because uncertainty often rewards visible progress more than private perfection. These distinctions are less pretty than a matrix, but they fit the conditions of a real Tuesday, when the issue is not philosophical clarity but deciding what deserves the next ninety minutes.

Pavel, the engineer from Warsaw, eventually changed his method in a way that looked almost disappointingly plain. He kept one capture list for every incoming request, whether it arrived in email, Slack, or during a call, and he stopped trying to resolve priority in the same moment he received the message. Twice a day, once around 10 a.m. and again after lunch, he reviewed that list against three questions: what will break if ignored, what demands my best thinking, and what can be moved forward in one contained session. Within three weeks, he told me that the day still changed constantly, but the changes no longer felt like theft; they had somewhere to go, which is a small sentence for a large psychological difference.

The hidden variable in all of this is energy, a term that gets abused in corporate writing until it sounds mystical. I mean something narrower and more useful: the fluctuating ability to initiate, sustain, and recover from effort. Barbara Tversky’s work on mind in motion, alongside decades of cognitive psychology on working memory and attentional limits, points toward an uncomfortable fact for ambitious adults: the brain is not a flat resource available on demand in identical units from breakfast to bedtime. Planning that ignores this will produce shame with remarkable efficiency, because it keeps asking the person to perform at a level their nervous system cannot consistently supply.

The calendar that respects attention

When I review calendars with clients, I am often struck by how little they resemble the work those clients say matters most. The week is arranged around external claims, while cognitively expensive work is squeezed into leftover spaces as if concentration were a liquid that naturally fills gaps. For people in technical roles, this usually means that the most demanding tasks are postponed until late afternoon, after meetings, messages, and minor emergencies have already consumed the day’s best attentional hours. Then comes the self-critique, which is often fierce and almost always misdirected.

A more honest calendar starts by identifying windows of probable usefulness rather than ideal ambition. Some people think best before the first meeting; others need an hour of warm-up before they can reason clearly about code, systems, or data. The point is not to discover a perfect rhythm and preserve it forever, because few adult lives permit that luxury, but to notice recurring patterns and protect them where possible. In practice, this may mean reserving two mornings a week for work that requires design judgment, writing, or debugging, while deliberately placing admin, routine reviews, and low-stakes replies into lower-energy periods.

For neurodivergent readers, and indeed for many adults who have never used that language about themselves, the decisive benefit of this approach is that it reduces the number of live negotiations the brain must conduct in the moment. A day with no predefined container for demanding work requires repeated acts of initiation, and initiation is often where people burn the most energy. A day with one protected block, one realistic administrative window, and one short review point is still vulnerable to disruption, yet it contains enough structure to keep uncertainty from spreading into every corner.

There is a final point that deserves more attention than it usually gets: closure. At the end of a turbulent day, many technical workers stop working physically while remaining mentally open, with loose threads still circling in the background during dinner or at 2 a.m. A brief closing ritual, five or ten minutes at most, can reduce that carryover by naming what moved, what did not, and what the next visible step will be tomorrow. Teresa Amabile and Steven Kramer, in The Progress Principle, showed how strongly even small signs of progress affect motivation and inner work life; in coaching rooms, I have seen the same thing repeatedly, especially among people whose days are full of invisible labour that produces few satisfying endings.

Planning under uncertainty, then, is a craft of restraint more than optimism. The useful plan is the one that leaves room for interruption, distinguishes thinking from reacting, and treats energy as a real constraint rather than a character flaw. Technical work will keep changing shape beneath your feet; the aim is to build a week that bends without turning every surprise into a verdict on your competence.

If this kind of working life feels familiar, moinaki has more writing that treats attention as a practical skill rather than a personality test.