I am Lino
July 13, 2026

Multi-Project Hell: On Three Teams at Once and Truly on None

Posted on July 13, 2026  •  13 minutes  • 2736 words
Table of contents

There’s a moment in every tech career when you stop having “a project” and start having a collection.

You’re not a solutions architect; you’re a sampler platter. And we’re not even talking about two or three fronts here: we’re talking about a minimum of four projects at once, each with its own ecosystem, its own drama, and its own slide decks.

And then, of course, you wonder why you end so many days feeling like you never went deep on anything.

Let’s call it what it is: multi-project hell.

The Pretty PowerPoint Where This All Makes Sense

On paper, this always starts out very reasonable.

In some meeting, someone pulls up a slide with a box diagram: projects A, B, C, and D. Each box has names in it. Next to yours it says “20%,” “30%,” “10%,” “40%.”

The idea sounds almost scientific: this way we make better use of “the resource.” You’re no longer a person — you’re a percentage.

The narrative is flawless: we need to “maximize utilization,” make sure “nobody’s underutilized,” “leverage cross-functional knowledge.” All words that sound fantastic in a consulting deck.

Nobody mentions one small detail: your brain doesn’t bill by percentage. There’s no thread per project sitting paused until you wake it back up. There’s no cheap context switch.

The reality is a lot less elegant: you’re in a meeting for one project, people are talking dates, decisions, dependencies… and your head is still dragging around a chunk of the data model from another project, plus an architecture question from a third, plus the nagging worry that a fourth one has a risk nobody’s actually understood.

But hey, in the spreadsheet, the 20/30/10/40 adds up.

The Real Cost of Pond-Hopping

What PowerPoints do is hide a pretty uncomfortable fact that cognitive psychology has been repeating for decades: we don’t multitask, we task-switch.

Every time you switch context, your brain has to drop one set of mental models and load a new one. That’s not instant, it’s not free, and it doesn’t get better with practice — you just get better at fooling yourself.

There are studies that quantify this with unpleasant precision. In knowledge-work settings, every time you get interrupted or switch tasks, it can take about 20 to 23 minutes to get back to the focus level you had before.

And I’m not exaggerating — I’m talking about ordinary things: remembering where that edge case was, what limitations that API had, why you’d ruled out some design option. Small things that add up, as this piece on why the brain struggles with multitasking points out, and as this breakdown of the cost of context switching confirms.

When you look at real engineering teams, with thousands of developers, the numbers get scary: with three projects running in parallel, you can easily lose 40% of your day just to the cost of context switching.

It’s not that you’re scrolling Twitter — it’s that you’re rebuilding the mental map of each system in your head, over and over, according to this analysis of how context switching kills productivity and the same data on the cost of context switching .

There’s research specific to software development that describes this with almost surgical precision: switching tasks forces your working memory to juggle, you lose part of what you were holding in mind, and the odds of making mistakes go up.

And it doesn’t matter if you’ve been coding for twenty years: the hardware is the same, as shown by this study on the cognitive cost of interruptions in programming and this University of Essex research on multitasking in software development .

Multi-Project to “Use You Better”

Then comes the hilarious part: the people in charge, who haven’t read any of this, decide the most efficient thing is to spread you across as many projects as possible.

After all, if you “don’t have much to do right now” on one, they can slot you into another to fill the gap.

A study done at a big multinational, with hundreds of employees, looked at exactly this: how many projects a person can handle before everything starts to break.

What they found won’t surprise anyone who’s ever had a calendar: once you go past five projects at once, performance collapses. Deadlines slip, quality drops, people feel like they’re always running “late” everywhere.

It’s not just bad for you; it’s bad for the company, for the projects, and for the clients, according to this World Economic Forum piece on how too many projects hurt productivity and drive burnout and this RTE Brainstorm analysis of the same problem .

And here you are, with a minimum of four projects, already skirting the outer edge of the “scientific” limit, and probably with a bunch of mini side-fronts hanging off you too (some consulting here, an architecture review there, a technical favor somewhere else).

No wonder you feel like you never finish anything all the way. It’s not just a feeling; it’s what the data says: when your brain gets chopped up like that, it stops going deep and switches into survival mode, as the University of Essex research on multitasking in software development and the article on why the brain struggles with multitasking both show.

Being on Three Teams and Belonging to None

There’s another side to this that doesn’t show up in the studies but that you feel in your gut: belonging. When you’re on a real team, you have faces, rhythms, inside jokes. You know who struggles with which module, which user is hurt by what, which decisions have history behind them. There’s a shared narrative.

When you’re split across three or four teams, that sense of belonging thins out. You’re a permanent guest. You show up to a standup and everyone’s talking about something that started two days ago in a Slack thread you weren’t in. You miss the context; you get caught up in a rush; you weigh in with partial information. Then you go to the next project’s meeting and the same thing happens, just with a different cast of characters.

People always introduce you the same way: “This is X, our solutions architect. He’s with us… well, with other teams too.” In practice, you’re a traveling architect. You leave opinions and blueprints wherever you go, but you rarely stick around long enough to see how things actually settle.

That “being everywhere and nowhere” wears you down in a strange way. It’s not just workload. It’s the constant feeling of being halfway: halfway on context, halfway on commitment, halfway on depth. Like you’re always five minutes late to everything.

Tetris Calendars and Days Without Gaps

If you sketch out a typical day, it looks like a game of Tetris: project A meeting at 9, project B at 10, a 45-minute gap that’s barely enough to clear your inbox and open some code, project C at noon, lunch half spent reading a project D doc, another A meeting in the afternoon, one for B, and then that heroic little stretch from 5:30 to 7 p.m. where you try to squeeze in “real work.”

Companies that specialize in measuring this stuff have looked at the real cost of this fragmentation pattern and put numbers on it: the average knowledge worker has 6 to 8 heavy context switches a day, and that adds up to roughly $28,000 a year per person in lost time, once you factor in the cost of mentally re-entering a task.

Multiply that by a team of 50 and you get a number that would make any CFO cry. But since that money bleeds away in scattered minutes, nobody actually sees it, according to this study on the cost of context switching and how to schedule around it and the same data on the cost of context switching .

The study by Parnin, Blincoe, and colleagues on multitasking in software projects is pretty revealing: they analyzed activity patterns and found that many developers spend only 0.3 to 2 minutes straight on the same activity before switching. Not because they’re scatterbrained, but because that’s how the environment is set up. No brain, however sharp, goes deep like that, as this rundown on the myth of multitasking also points out.

You, as an architect, feel this with an extra twist: your job isn’t just writing code, it’s holding large mental models together. Whole domains, business flows, system breakdowns.

That doesn’t fit into 15-minute chunks. You need long blocks to think. In multi-project mode, those blocks are an endangered species.

Impossible Depth: “Hallway” Architecture

The most treacherous thing about multi-project work for anyone in architecture is that it turns decisions that deserve serious thought into hallway architecture.

Between one meeting and the next, between two calls, you juggle: you skim something, decide on something “reasonable” to unblock the team, and promise to look at it more closely later.

That “later” almost never comes.

Of course, later you wake up at three in the morning thinking: “wait, this integration pattern I agreed to here might conflict with what I proposed over there.”

That’s not tortured-architect posturing. It’s the reality of trying to hold four contexts in your head at once, each with its own legacy, its own constraints, and its own anxious stakeholders.

The literature on interruptions in software development makes exactly this point: interrupting design and architecture work costs more than interrupting mechanical tasks, because you break more internal state.

And when you’re the one interrupting yourself because you have to jump to another project’s meeting, it’s even worse: self-interruptions are, paradoxically, more damaging than external ones.

You move on before you’ve actually closed the mental chapter, as this study on the cognitive cost of interruptions in programming details.

The Permanent Feeling of Never Finishing Anything

Given all this, it’s no surprise that feeling of “never really finishing anything” shows up.

It’s not just a feeling; it’s a direct consequence of the system.

When your time gets chopped up across that many fronts, you tend to leave loose ends, patch together solutions that are good enough for today, and count heavily on “the team will finish it off.”

But you know that, more often than not, the team is going to finish it off in the usual rush, without the deep review you would’ve done if you’d had a whole day to live inside that one context. It’s not that you don’t want to — it’s that you don’t get to.

Research on multi-project management sums it up pretty bluntly: being on too many projects at once hurts deadlines, quality, and morale alike. Things ship later, with more stress, and with a much poorer subjective experience. People work harder to end up feeling less accomplished.

It’s like running on a treadmill: lots of effort, zero distance covered, as both RTE Brainstorm and the World Economic Forum point out.

“But This Way You’re More Visible,” They Said

There’s another poisoned argument people use to justify multi-project work: “this way you get exposure to more areas, you learn more about the business, you become more strategic.”

On paper it even sounds good. In practice it usually means “we’re going to throw you into every messy situation because you’re reliable, but without giving you room to breathe in any of them.”

You know a lot, sure, but all of it halfway. The payments domain over here? You know it well enough not to break it, but not well enough to redesign it from memory. The billing logic over there? You get it, but details slip through. The data model on the other side? It rings a bell, but you’d have to go back and read it again.

It’s tourist-style knowledge: you’ve been everywhere, but you’ve never really lived anywhere.

The Studies Say What You Already Suspected

When your inner nerd kicks in and you start digging up studies on this, you spot yourself in the data with a rueful little laugh at how accurately they describe you.

For example, this classic study on multitasking in software projects (also available as a preprint on arXiv ) analyzed activity logs from programmers across several industrial projects and found that people working on many projects at once were only more productive when they batched their work by day — that is, when each day they touched only a few fronts.

As soon as they started jumping between projects many times in the same day, productivity nosedived — in line with what the Parnin and Blincoe study already pointed to .

Another study, broader in scope, on knowledge workers, states outright that constantly switching tasks can cause up to a 40% loss in performance. Not because you’re lazy, but because your brain gets stuck restarting every single time, according to this rundown on the myth of multitasking and the article on why the brain struggles with multitasking .

And then there’s the number closest to home: the same five-project limit we already saw.

You’re at four as a baseline, right at the edge. If at some point they add “just one more, it’s like 10%,” you already know, mathematically, exactly where that puts you.

Is There a Way Out of This Hell, or Do You Just Get Used to It?

The tempting part here would be to wrap up by saying: “well, you know, just say no, focus, blah blah.” But I know that a lot of the time it’s not up to you. The systems that create multi-project chaos do it because of decisions made higher up: not hiring enough people, not prioritizing better, not accepting that some things simply can’t happen at the same time.

What you can do, at least at the margins, is put some shape on the chaos. For example, try to batch days by project. Say it out loud: “this day I’m on A, this one on B, this one on C; if you stick a project D meeting in here, you’re loading me with a context-switching cost we all end up paying.”

It won’t always work, but not saying it guarantees nobody ever finds out.

It also helps to leave more of a written trail: short RFCs, documented architecture decisions, small context summaries. The more context you keep outside your own head, the less you lose every time you jump around. It doesn’t turn four projects into one, but it does lower the cognitive bill a bit.

And above all, it helps to remind yourself that the feeling of never reaching the depth you’d like isn’t a failure on your part. It’s the symptom of a badly designed system, one that confuses squeezing every last drop out of the calendar with actually making good use of talent.

Your brain, with one well-focused project, could afford the luxury of dropping into serious deep-work mode. With four at once, it’s doing well just not to burn out.

And the studies, for once, are on your side.

Sources and references

For anyone who needs to show these numbers to their boss (tactfully), here are the sources:

Follow me

I write and share opinions about technology, software development and whatever crosses my mind.