Earlier quoted context omitted.
It's a reference to cost of context shift. Context shift matters a bit less for a manager since they are by definition juggling things already. Doesn't not matter...but less
I'm aware of context switching but that doesn't apply to finite tasks that fit within a predefined timebox of e.g. less than half a day. And there are a lot of those out there. Presupposing that all programming is in the pursuit of grand designs (i.e. it take half a day to a day to make meaningful progress on any task) is the only thing that would justify it. But the reality is, it isn't like that except for a subset…
In professional context, development is driven by a business need: a "feature", a "change", or a "fix". Feature usually requires large number of tickets and multiple iterations, change require few tickets and one or two iterations, fix usually 1 ticket. Each ticket may require number of required steps to be completed, such a coding, testing, integration testing, documenting, reviewing, CI, QA, pushing to production, in production monitoring, reporting,etc. Nobody, except junior developers, will write a unit test out of blue sky. The simplest ticket: a "fix", may require reproduction, automatic test case, debugging, fix in the code, testing, update of documentation, review, CI, QA, push to production, reporting. You can do all that in one sit (half a day), keeping details in the head (harder, but faster), OR you can write off details from the head to the ticket, and then do tasks step by step in small bites, hour by hour, in multiple days (easier, but order of magnitude slower).