Against Pseudo-Productivity - Engaging Cal Newport on AI, Shallow Work, and the Case for Institutional Knowledge in Architectural Practice

Wednesday, March 25, 2026

#technology #productivity #architecture

---

I often listen to Cal Newport’s podcasts because they give well-researched insights into technology and work. He is, by any measure, one of the more honest voices on the subject, which makes it worth engaging seriously when he is right, and worth pushing back when he is not quite. This episode on Why Do “Productivity Technologies” Make My Job Worse ¹, without its larger context, risks being read as a case against productivity tools broadly, when the more precise argument is about how those tools are deployed, and in whose hands. Allow me to engage with the arguments one by one, with a framing for architectural practice.

Context

Newport opens with a reference to ActivTrak’s 2026 State of the Workplace report, which analysed 443 million hours of work across 164,000 employees at over 1,000 companies and found that among AI users, time spent on email and messaging more than doubled, business management tool usage rose 94%, and time in deep, focused work fell 9%, while non-users saw virtually no change.²

He then notes that this outcome is not unique to AI, and can be seen across the history of productivity technology: email, mobile computing, video conferencing. “This matches a pattern that I have seen unfold many times before. Here’s how this pattern goes. One, a new technology promises to speed up some annoying aspect of our job. Two, we all get excited about freeing up more time for deep work and leisure. Three, we end up busier than before without producing more of the high value output that actually moves the needle.”¹

Newport is careful to establish, before any critique, that these tools genuinely work. Email really is faster per message than a phone call. AI really does reduce what he calls the “activation cost of thinking”: it is cognitively easier to back-and-forth with a chatbot than to sit and reason through a problem from scratch. Both qualify as genuine productivity gains by any reasonable definition. Newport’s question is not whether the tools deliver what they promise, but what happens to the systems and people around them when they do.

My argument is not that the pattern Newport describes is wrong. The ActivTrak data is large-scale and directionally clear. But a pattern is not a law. The data shows what happens when productivity tools are adopted without changing the structure of the work around them. It does not show that the outcome is inevitable. The problems Newport identifies are, in large part, problems of deployment, governance, and interface design, not of the tools themselves.

Argument 1: Speed Creates More Work, Not Less

Newport’s first mechanistic explanation targets what happens when any task becomes faster to complete. “For many types of common work activities, increasing the speed at which you complete these types of activities or tasks increases… the throughput of these tasks in your typical day. So if I go faster, then the rate at which new tasks of this type come into my life also increases.”¹ He uses email as the clearest historical proof: it was faster per message than a phone call, yet that speed reduction caused total communication volume to explode. Microsoft’s Work Trend Index found workers now check an inbox once every two minutes on average.¹

In systems theory, this dynamic is called induced demand. When capacity for handling a task increases, the volume of that task expands to fill the new capacity, a principle Parkinson described in 1955 as “work expands to fill the time available for its completion.”³ The ActivTrak data confirms this at scale: AI did not shrink the shallow-work queue, it emptied it faster so more refilled in.²

I agree on the mechanism. The induced demand argument is strongest when the task type has a practically bottomless supply: email, Slack messages, and administrative queries all qualify. But not every task behaves this way. A RAG-assisted response to an architectural RFI (Request for Information, a formal documented process used by contractors, subcontractors, or architects to clarify ambiguities, errors, or missing details in project plans and specifications) does not generate more RFIs by being faster. RFI volume is determined upstream, by how much ambiguity and unresolved coordination was left in the design documentation before construction began.⁴ Responding faster does not change that. What RAG offers here is not speed for its own sake, but the ability to quickly surface relevant precedents: past RFIs on similar details, applicable specification clauses, comparable design decisions, reducing the lookup effort that would otherwise slow a considered, accurate response.

Induced demand only operates on tasks where you control the tap. With email and direct messages, you are both producer and consumer. The faster you reply, the more replies you invite, in an open-ended feedback loop. With RFIs, the tap is controlled by site conditions, design gaps, and contractor queries that exist independently of how fast you respond. Replying to ten RFIs quickly does not cause an eleventh to appear; that eleventh either exists in the construction documentation or it does not. The induced demand trap is most dangerous for communication-heavy work, and least relevant for tasks whose frequency is set by the physical and contractual reality of the project, not by the speed of the worker.

Newport raises a related but distinct point within the same argument: even when speed does not increase the volume of tasks, it may increase how often you handle them throughout the day. Responding to RFIs immediately as they arrive rather than in dedicated batched windows still multiplies context switches and still impairs the cognitive quality of everything happening around it. But that is a workflow design problem, not an inherent property of the tool. A RAG-assisted RFI response handled within a designated administration window each morning imposes no more context switching than existed before, and arguably less, since the lookup friction that previously bled across the day is compressed into that window.

Argument 2: Easier Work Produces Lower-Quality Work, Creating More Total Work

Newport’s second mechanism is subtler than the first. It is not simply that AI produces bad output. The claim is that reducing cognitive effort on the part of the human worker in the moment systematically tends to lower the quality of what gets produced, which then increases total downstream work. He illustrates this with email: “it was way easier for me to send off a like, yeah, maybe thoughts, question mark. That was way less cognitive strain than to say, okay, hold on a second. What’s going on here? What are the possibilities? What’s the right thing to do?”¹ That vague reply spawns five more back-and-forth messages to resolve what one careful, considered reply would have ended. More total cognitive cost, not less.

With AI, Newport argues the same mechanism produces what the Harvard Business Review terms “workslop”, defined in the transcript as “AI-generated work content that masquerades as good work but lacks the substance to meaningfully advance a given task.”¹ A BetterUp Labs study found approximately 40% of workers encountered workslop in a given month, spending nearly two hours per incident correcting or navigating it.⁵

Where I part with Newport is on scope. His workslop critique targets a specific mode of AI use: the blank-page generator, prompting a chatbot to produce a document from nothing. That is a fair critique of generative AI used as a substitute for thinking. It applies far less to AI used as a retrieval and reference tool.

Newport’s underlying mechanism, that reduced cognitive effort tends to produce less considered output, does not disappear simply because the tool retrieves rather than generates. RAG also reduces friction: it removes the lookup and synthesis effort that would otherwise force a practitioner to work harder before forming a position. Applied rigorously, Newport’s argument asks whether lowering that friction encourages less careful responses, even from a technically superior tool.

A clarification of terms first. RAG (Retrieval-Augmented Generation) is an approach where an AI system searches a curated collection of your own documents, called a corpus, to find relevant precedents before producing any output. Rather than generating from nothing, it grounds its response in your own past decisions and documentation. Think of it as a very fast research assistant who has read every document your practice has ever produced and can surface the most relevant ones for any question you ask, in seconds rather than hours. The quality of what it surfaces depends entirely on the quality of what it searches through.

A well-designed RAG system mitigates Newport’s quality-degradation risk through two specific properties. First, the human user remains solely responsible for synthesis, evaluation, and professional sign-off. The tool surfaces references and recommendations, not conclusions.⁶

Second, RAG is only as good as what it retrieves from. A corpus built from raw project archives, with no organisation or quality control, is effectively a pile of filing cabinets: everything is in there somewhere, but there is no way to know which documents are reliable, which are outdated, and which contain decisions that caused problems. To be genuinely useful, the corpus needs to be curated and outcome-annotated, meaning each document is tagged not just by topic, but by what happened as a result of the decision it records.

Consider a junior architect receiving an RFI on fire-rated door clearances. A raw, uncurated archive retrieves three past responses on the same subject, all of which look equally authoritative on the page. What the architect cannot see is that one of them was wrong: it led to a site non-conformance report, a variation order, and two weeks of remedial work. An outcome-annotated corpus changes this. Each precedent carries a tag derived from what actually happened afterward: resolved cleanly and accepted, generated two follow-up RFIs requiring clarification, or triggered a variation order, do not use as precedent. The architect is no longer retrieving from a flat archive of past decisions. They are retrieving from a ranked record of past decisions and their real-world consequences, which is, in effect, what an experienced senior practitioner carries in their head after years of practice. That is structurally different from retrieving precedents with no quality information attached, and it is precisely what prevents the lowered friction of retrieval from collapsing into the lowered quality Newport describes.

But this only holds if the interface is designed to demand deliberate engagement. Research on automation bias confirms that well-formatted, confident output from any decision-support system tends to produce both omission and commission errors unless the operator is required to evaluate actively rather than confirm passively, and that this effect cannot be prevented by training or instructions alone.⁷ The tool’s architecture, not its category, determines whether cognitive engagement is preserved or quietly displaced. A system that pre-fills a response field that the practitioner simply approves is not meaningfully different from workslop in its effect on judgment. A system that presents ranked precedents with outcome histories and requires the practitioner to synthesise and compose preserves cognitive effort and output quality, while reducing only the friction of getting there.

Newport is right when it comes to the paradox. Where his argument stops short is in assuming that reduced friction always means reduced care. It does when the tool substitutes for judgment. It does not when the tool is designed to inform it.

Argument 3: We Embrace These Tools Because We Cannot Measure Real Productivity

Newport’s deepest structural point is about measurement. “Lacking more precise measures of productivity, we will use visible effort as a proxy for you doing something useful. So the busier you seem, the better. And this basically became the standard of how we think about productivity in the knowledge work class.”¹ He calls this pseudo-productivity, and argues that workers internalise it so completely that even a solo practitioner feels guilt during long, uninterrupted thinking sessions, even when those sessions are the most productive hours of their week.⁸

In industrial work, productivity had a clean denominator: units per worker-hour. In knowledge work, the output of a single day’s thinking may not manifest as a measurable result for months, and the causal chain from effort to outcome is long enough that visible activity becomes the only available signal — not because organisations are irrational, but because they have no better one.⁹ In architectural practice this problem is compounded: a designer’s output quality may not surface as a measurable consequence, or a dispute, until construction, by which time attribution across a multi-party team is nearly impossible.

Newport’s prescribed solution, “use a better scoreboard,” is right in principle but undersells the difficulty. “Priority projects completed per month” works for a software team. The architectural equivalent, design quality, repeat clients, competition shortlistings, operates on timescales of years, making real-time feedback loops nearly impossible. A proper scoreboard for architectural practice would have to track which RFI responses led to rework, which design decisions generated the most consultant conflicts, and which file structures caused the most downstream queries. Over project cycles, this creates a lagging but externally validated measure, one that pseudo-productivity cannot fake, because the inputs are hard documentary events: variation orders, follow-up RFIs, change-order cost impacts.

Building this scoreboard is not a data science problem. It is a knowledge management problem, and the instrument that makes it possible is what the rest of this piece is building toward.

Argument 4: Speed the Right Thing, Not the Easy Thing

Newport’s first practical strategy targets the rate-limiting constraint that actually controls how much valuable output a knowledge worker produces. “It’s not just enough to speed up any aspect of your job. You want to really focus on improving the true bottlenecks. When you’re looking for digital productivity tools, be especially tuned to those that help what’s going on with that bottleneck.”¹ He illustrates this with Adam Grant, whose bottleneck was not data analysis speed or writing time: it was access to unique datasets. Every tool that sped up formatting or plot generation was useful but irrelevant to throughput.

In architectural practice, ASCE research from 2023 confirms the equivalent: the primary driver of project delay and rework in AEC delivery is not drawing production speed but information bottlenecks at high-interdependency decision points between disciplines.⁴ A CSCE analysis of BIM coordination meetings identified five specific bottleneck categories, including insufficient issue documentation, delayed design-change notification, and inadequate coordination task management, none of which are drawing-speed problems.¹⁰ Rework attributable to design-phase errors accounts for a disproportionate share of total construction costs, with studies of building projects finding rework rates of 2-15% of contract value, skewing heavily toward the upper end when design information quality is poor.¹¹ A single RFI costs an average of $1,080 to process and typically generates two to four follow-up queries.¹²

Newport’s bottleneck argument maps directly onto the case for a practice knowledge system. The bottleneck in most architectural practices is not drawing speed or specification writing speed. It is the quality and consistency of design decisions under time pressure, the transfer of institutional knowledge across projects and team members, and the resolution of coordination ambiguities before they become costly RFIs or site disputes.

The conventional response is to ask someone more experienced. This works until it does not. The senior is in a meeting, on leave, or has left the practice entirely. The knowledge they carry exists in one person’s head, which makes it among the most fragile stores of institutional knowledge possible: unavailable on demand, and gone when the person is. Practices that have operated for a decade can find themselves functionally starting over each time a senior departs, re-accumulating through error and re-inquiry the same understanding the previous generation spent years building.¹³ Polanyi’s foundational distinction between tacit knowledge, held in individuals, and explicit knowledge, encoded in accessible systems, identifies precisely why this happens: the majority of what makes an experienced practitioner effective is tacit, gained through pattern recognition across projects, and it is lost not because it is complex, but because no mechanism exists to externalise it.¹⁴

A curated, searchable, outcome-annotated archive targets exactly this layer: not by making fast tasks faster, but by making the right information available at the moment a decision matters, regardless of who is in the room. The goal is not to replace the senior practitioner but to ensure what they know survives their absence.

Argument 5: Protect Deep Work Structurally, Not Optimistically

Newport’s final argument is that the only reliable defence against tools colonising your most important cognitive hours is structural separation, not willpower or good intentions. “Just have and protect the time for sitting and doing hard things with your brain and the activities that you know for sure create bottom line value. This just gives you like a safety barrier against some of the accidental negative side effects of digital productivity tools.”¹ The deep work block is non-negotiable, scheduled before the reactive day fills in, and treated as a firewall rather than a reward for inbox-zero.

The APA finds that frequent task-switching reduces cognitive efficiency by up to 40%.¹⁵ Research cited by Johann Hari found that an interrupted group scored roughly 10 IQ points lower on average than an uninterrupted control group, approximately twice the magnitude of acute cannabis impairment.¹⁶ A 2025 Frontiers in Psychology study on AI-era cognitive offloading found that consistently delegating cognitive tasks to external tools erodes metacognitive accuracy and self-monitoring over time, degrading the judgment capacity that deep work depends on.¹⁷ A Microsoft Research study on GenAI and critical thinking found that heavy AI reliance measurably reduces the generative cognitive engagement that builds expert judgment.¹⁸

Newport’s framing needs extending in one specific direction. Deep and shallow work are not only a time-allocation problem. In architectural practice they are also a spatial and social contract problem. An open-plan studio with constant verbal coordination, client calls, and consultant queries does not become a deep work environment just because a designer blocks two hours on their calendar. Structural separation requires environmental design as much as schedule design. In practice this means:

• Designated no-meeting mornings: the first two to three hours of the working day reserved for design and documentation work, with no coordination calls or internal meetings before midday
• Explicit response-time agreements: a practice-wide standard replacing the implicit expectation of immediate replies, where coordination queries receive a response within 24 hours and RFIs are batched into a dedicated daily window
• Availability signals: a shared calendar or Teams status convention indicating when a practitioner is unavailable for interruption, equivalent to a closed door in an open studio
• Physical workspace zoning: the studio layout itself distinguished between a quiet zone for individual design and documentation work and a collaboration zone for coordination, calls, and review. These need not be separate rooms. A clear spatial convention, reinforced by acoustic treatment, furniture arrangement, or floor markings, signals cognitive mode. The same task-switching research that confirms the cost of interruptions also confirms that environmental cues play a significant role in whether those interruptions occur at all.¹⁵ The studio that treats all work as the same kind of work will produce, on average, work of the same middling quality.

None of these are personal productivity habits, but practice-level agreements that must be made collectively to hold and supported by senior leadership to be taken seriously.

Argument 6: Newport Misses a Third Mechanism: Shallow Work Manufactured by Poor Tool Use

Newport identifies two mechanisms that turn productivity tools against us: speed that breeds more work, and ease that breeds lower quality. Both describe what tools do to workers. But there is a third mechanism he does not address, one that runs in the opposite direction: what workers do to their tools, and to each other, through poor software practice.

Consider two common examples. An architectural drawing file in which every element lives on layers that denote only drawing appearance: AELE, ASIT, ACUT, providing no information about what the CAD line actually represents beyond how it looks on the sheet. Or a Photoshop document with hundreds of unnamed, ungrouped layers stacked in no logical order. To the person who made it, the file works fine; they know what everything is. To the next person who opens it, a collaborator, a contractor, a team member six months later, it is a puzzle. They must interrogate the original author to reconstruct intent, or worse, guess. That interrogation is shallow work. That guessing is a source of error. Neither was necessary. Both were created not by a productivity tool making something easier, but by a user operating that tool without discipline.

Newport’s framework does not capture this: shallow work can be manufactured upstream, by the person producing information, and deposited downstream for everyone else to deal with. His email analogy applies directly. Newport’s vague reply that spawns five follow-up messages is the same phenomenon. The difference is that in architecture, the deposit is not a message thread but a file that may be touched dozens of times across the life of a project. The compounding is far greater.

BIM adoption research confirms this at scale. One of the primary documented advantages of BIM over traditional 2D CAD is precisely that it encodes semantic and parametric information — what an element is, what material it represents, what system it belongs to — removing the cognitive burden of interpretation from every downstream reader.¹⁹ Where that encoding is absent, inconsistently applied, or ignored, coordination inefficiency follows directly: not from the technology failing, but from practitioners not using it as intended. Rework attributable to poor design information quality in construction projects has been documented at 2-15% of contract value in peer-reviewed studies of building projects, with the upper end of that range consistently associated with weak documentation standards and information handover failures.¹¹

The cause is not ignorance alone. Poor file hygiene is a symptom of three overlapping conditions: inadequate software understanding, absent or unenforced standards, and time pressure that makes doing things properly feel like overhead, even when the evidence consistently shows it saves time downstream. A digital training study found a strong correlation (r = 0.72, p < 0.01) between structured digital literacy programmes and productivity outcomes,²⁰ but training without structural reinforcement reverts. More fundamentally, a Harvard Business School study found that high-powered individual performance incentives are directly associated with less standards compliance and less knowledge sharing, because they signal a transactional psychological contract: do your task, hit your hours, move on.²¹ In a practice where everyone bills to project codes under time pressure, producing well-structured files for the benefit of future team members is structurally disincentivised.

The fix requires three structural interventions working together:

• Enforced templates: every project begins from a pre-structured Revit template, pre-layered CAD file, or pre-configured Photoshop document with named layer groups. A practitioner starting from the correct template cannot accidentally produce an unlayered file. The standards are inherited, not chosen.
• Phase-gate reviews: documentation that does not meet standards does not proceed to the next project phase. Compliance is checked at project milestones, with non-conforming files returned before sign-off. Non-compliance is made more expensive than compliance.
• Incentive realignment: documentation quality is included in project reviews and treated as part of professional output. The cost of poor documentation, downstream queries, rework hours, RFIs generated by ambiguous information, is made visible and attributed to its source.

Newport’s three solutions, better scoreboard, identify the bottleneck, separate deep from shallow, all assume that the shallow work being managed is generated by tools. A significant portion of it in architectural practice is generated by practitioners themselves, through information that is expensive to consume even when cheap to produce. No scoreboard, no bottleneck analysis, and no deep work schedule addresses that. It requires a different intervention at the point of production.

And it bears directly on any AI knowledge system built on top of this practice. A retrieval system searching through unnamed layers and semantically empty CAD files is not surfacing knowledge. It is retrieving noise. Software discipline is therefore not just a professional habit. It is the data quality prerequisite on which the entire value of a knowledge system depends.

Toward a Solution: The Practice Knowledge System

The problems Newport identifies are not solved by working harder, working less, or switching tools. They require building the structural conditions under which tools can actually work: a practice-level knowledge infrastructure that encodes standards, captures outcomes, and makes institutional knowledge accessible at the moment decisions are being made. The system has five sequential layers, each depending on the one before it.

Layer 1: The Single Source of Truth

Before any technology is deployed, there must be one authoritative, searchable, maintained place where all practice standards, templates, guides, and playbooks live. A practice wiki, with named owners per page, review cycles, and version numbers. Not a shared drive, not a WhatsApp group: one place. When someone wants to know the correct CAD layer structure, the RFI response protocol, or the phase-gate checklist, there is exactly one answer and exactly one place to find it. Without this, any subsequent system retrieves from a fragmented base.

That place has specific requirements:

• Full-text search across content, not filenames. Search must reach inside documents. A system you can only navigate by knowing what a file is called is a system that only works for the person who named it.
• Tags instead of folders. A document about fire-rated door clearances belongs under specifications, RFI precedents, DD phase, and fire compliance simultaneously. Folders force a choice and produce duplicates. Tags create connections without copies.
• Version history with named authors. Not “final_v2_FINAL_USE_THIS” — a timestamped record of what changed, who changed it, and when. This matters when a standard is revised mid-project and someone needs to know which version was in force.
• Review expiry flags. Pages unreviewed beyond a set period are automatically surfaced to their named owner for confirmation or update. This is the mechanism that keeps the wiki alive rather than becoming another abandoned drive.
• Machine-readable structure. Every page is eventually a potential document in the RAG corpus of Layer 4. Consistent, well-headed prose is retrievable. Scanned PDFs and context-free tables are not. The wiki’s formatting conventions are also its data quality standards.

Layer 2: Enforced File Standards

Populate the wiki with templates that encode standards at the point of creation: a Revit project template, a pre-layered CAD file, a pre-configured Photoshop document with named layer groups. Couple this with phase-gate reviews and automated compliance checks. Assign a named Information Manager who owns standards maintenance across the practice. Without this layer, the corpus the knowledge system retrieves from is built on ambiguous, inconsistently structured files, and the system retrieves noise.

Layer 3: The Outcome-Annotated Project Corpus

From the next project forward, capture documentation with outcome linkage. When a variation order is raised, link it to the originating document. When an RFI generates follow-up queries, tag the original response. At project close, apply resolution quality labels to each RFI and significant design decision. Over two to three projects, patterns become legible: which detail types, which consultant interfaces, which design phases generate the most downstream friction. This is the empirical layer, what actually happened, and it is the real scoreboard Newport calls for, built from hard documentary events that pseudo-productivity cannot fake.

Layer 4: The RAG Retrieval System

With a quality-annotated corpus in place, the retrieval system surfaces relevant precedents ranked by outcome quality. It does not draft responses autonomously. When a new RFI arrives, the system presents the most analogous past RFIs with their resolution labels and cost outcomes. The practitioner synthesises, applies judgment, and writes the response. The tool informs; the practitioner decides. This is where Newport’s bottleneck, the quality and contextual depth of decisions made under time pressure, is directly addressed.

Layer 5: Protected Deep Work

With shallow-work compression provided by the retrieval system, the capacity freed must be structurally redirected, not left to be consumed by the next item in the queue. Designated no-meeting mornings, batched communication windows, practice-wide availability norms. The knowledge system compresses lookup and reference work into a smaller window; the schedule structure ensures the time it frees is spent on the cognitive work that actually advances the practice.

The tools are not the problem. The absence of the structure and system that makes them useful is.

Footnotes