⊛
Annotations under each card, the connections between them, and any
thesis card are AI-generated. I screen for harmful content
only — citations may be fabricated; treat every
reference as a starting point for your own search, not as verified.
See ai-use.md.
↯ claim
Innovation carries an overwhelmingly positive connotation. Everyone, at least externally, claims they want to be innovative or to work in an innovative environment.
This positive halo is itself a critique target: Lee Vinsel and Andrew Russell's The Innovation Delusion (2020) argues the cult of innovation devalues maintenance, repair, and the unglamorous work that actually keeps systems running. There's also a status dimension — calling oneself "innovative" functions as identity signaling more than description, which is why the word survives despite being nearly meaningless in practice. Worth distinguishing novelty (new) from innovation (new + adopted + valuable); most self-described innovation fails the second two tests.
↯ claim
So why don't we see more innovative companies? Because innovation is genuinely hard, and only occasionally fun. What it actually requires is discipline above all else, a great deal of hard work, tolerance for failure, and intolerance for incompetence. None of those things are especially appealing.
This echoes Gary Pisano's Harvard Business Review argument (2019, "The Hard Truth About Innovative Cultures") that the celebrated traits of innovation cultures — tolerance for failure, psychological safety, experimentation — are always paired with brutal counterweights: rigorous discipline, candor, and accountability. Most companies adopt the fun half and skip the painful half, which is why 's observation about the positive connotation persists while actual innovation remains rare. The asymmetry is the point: tolerance for failure is not tolerance for incompetence, and conflating the two produces theater rather than output.
☾ reflection
It's hard to design an organization for innovation, and even harder to follow through with the necessary resources and strategic decisions. Still, some degree of improvement has to happen, even if only incrementally. Usually it falls on the shoulders of a high performer or a tech-inclined team member who has put together a small prototype—say, an automated Excel spreadsheet with VBA. The tools aren't optimal, the design rarely goes beyond prototype quality, and it's not really something built to be maintained for years. But it helps so much that the person ends up tagged with the "innovation" label.
This describes what Eric von Hippel calls user innovation or shadow IT—frontline employees building unsanctioned tools because formal channels are too slow. The pattern extends 's point about why innovation is rare: organizations reward the visible hero but rarely invest in productionizing the prototype, so the VBA spreadsheet becomes load-bearing infrastructure no one owns. Gartner has tracked this as citizen developer risk, where 41% of employees customize tech outside IT (per Gartner, 2021). The deeper tension: labeling someone "the innovator" individualizes what should be a systemic capability, and often burns out the person doing it.
↯ claim
When citizen development artifacts grow too large—in structural complexity and embedded domain knowledge—and begin requiring complex changes or fixes, they get handed off to IT departments to become their problem. Poor code quality only compounds the issue.
This is the classic "throw it over the wall" anti-pattern, and it inverts the promised ROI of low-code platforms — IT ends up absorbing technical debt they had no hand in creating, often in unfamiliar platforms (Power Platform, Mendix, etc.) without proper version control, testing, or documentation. Gartner has flagged this as a core governance risk, recommending a fusion team model where IT co-owns artifacts above a complexity threshold rather than inheriting them post-hoc. The deeper tension with : citizen development is sold as innovation enablement, but without lifecycle guardrails it produces shadow IT that actively suppresses the org's capacity for real change.
? question
I've found that people with a lot of enthusiastic energy are surprisingly tricky to work with. They're very excited—which is good—but I struggle to find a way to channel that excitement into anything concrete. Generating more excitement isn't productive; they're already excited. What they need to do is start innovating—that is, start building. But if they're this excited right now and still haven't taken even the smallest step toward building something (like actually launching a no-code app and working through a tutorial), then what else is there to do?
This maps onto the enthusiasm-action gap documented in behavioral research: Gollwitzer's work on implementation intentions shows that motivation without concrete "if-then" plans rarely converts to action, and Kahneman's planning fallacy compounds it — excitement inflates perceived progress while substituting for it. A useful diagnostic: are they excited about the outcome (being an innovator, the finished product) or the process (the messy tutorial, the broken first build)? Outcome-excitement is essentially consumption; only process-excitement predicts shipping. This connects to — organizations face the same gap at scale, where enthusiasm for innovation rarely survives the unglamorous follow-through.
↯ claim
There are far more people with needs and ideas than there are people who can build. This creates a problematic dynamic: builders are simultaneously in high demand and under pressure, yet undervalued when fixes or changes are needed—because only they understand the actual effort involved. To everyone else, the app is "delivered," and subsequent changes look like small incremental tasks.
This is the iceberg problem of software: stakeholders see the visible 10% (the UI, the "delivered" app) and price change requests against that, not the 90% of architecture, edge cases, and accumulated decisions underneath. Hal Abelson's framing that programs are written for people to read, and only incidentally for machines to execute, hints at why: the cost is in the comprehension load, not the typing. Connects to — when citizen-built artifacts balloon, the same asymmetry hits in reverse: non-builders discover too late how much hidden complexity they accumulated. Worth distinguishing scarcity-of-builders (a market claim) from undervaluation-of-effort (a perception claim); they have different fixes — pricing power vs. making the invisible work legible.
? question
Another question is whether non-builders can be turned into builders—at least for simple, no-code things they could build for themselves or their immediate team. Tools like Power Automate and Power BI can help enormously. I understand why people don't pick them up: they may not know these tools exist, work doesn't leave time for learning, and free time is, after all, free time. But the deeper question is whether the person has the personality to become a builder in the first place.
The personality question echoes research on self-efficacy (Bandura) and maker identity — many adults don't see themselves as "technical," and that self-concept predicts tool adoption more than aptitude does. Gartner's citizen-developer forecasts (2021–2023) repeatedly overshot reality for this reason: licenses get provisioned, but sustained building requires tolerance for debugging frustration, which is a disposition, not a skill. Worth pairing with 's warning — even when non-builders do build, their artifacts often outgrow them — and 's supply gap, which low-code only partially closes if the personality bottleneck is real.
※ opinion
I think builders are driven by a certain restlessness and dissatisfaction. When they come across a tool that works poorly, or one that demands unreasonable effort to use, they get irritated—and build something that actually works. Other people, by contrast, don't seem bothered by being asked to jump through hoops for no good reason. Or maybe what looks like acceptance is really learned helplessness.
This echoes Paul Graham's notion that hackers are driven by a low tolerance for friction — what he calls being "offended" by bad design. The learned helplessness framing (Seligman) is sharp: it reframes passivity not as preference but as conditioned defeat, which connects to 's asymmetry between needers and builders. A counter-tension though: that same restlessness can become yak shaving — rebuilding tools instead of doing the underlying work, which links to the energy-management problem in .
↯ claim
The citizen-developer produces the prototype that IT later inherits as debt — they externalises prototype's maintenance cost.
This is a classic negative externality — the prototype's creator captures the upside (problem solved, recognition) while IT absorbs the long-tail costs of security, integration, and maintenance. Gartner has flagged this as a core governance risk in low-code/no-code adoption, and Forrester's 2023 research on "shadow IT debt" estimates remediation often exceeds the original build cost by 3–5×. Extends 's threshold problem: the handoff rarely happens cleanly because by the time complexity demands IT involvement, the artifact is already load-bearing in someone's workflow.
↯ claim
In innovation projects, the resources allocated by the business are often not the most senior people—and when they are, they rarely have enough time to steer the project effectively. They may also lack the skills needed to shape the vision and define business requirements.
This is the classic resource allocation paradox in corporate innovation: the business treats innovation as discretionary, so A-players stay on revenue-generating work while B/C-players or junior staff get seconded part-time. Govindarajan and Trimble's The Other Side of Innovation (2010) argues this is why most innovation initiatives fail — they need a dedicated team with senior sponsorship, not borrowed capacity. It compounds the organizational difficulty noted in and helps explain : innovation isn't just hard intellectually, it's structurally starved of the seniority required to shape vision and unblock decisions.
↯ claim
Common issues with internal company innovation (process improvements, software changes, and development) include: (1) one department gets optimized at the expense of another; (2) lack of time to focus on improving business processes; (3) failure to recognize the full extent of the problem; (4) insufficient training; (5) people rely on whatever tool they have at hand—usually Excel—to patch problems; (6) inadequate infrastructure; (7) overly bureaucratic processes; (8) lack of motivation.
This list maps neatly onto well-documented failure modes: point (1) is the classic local optima trap that Goldratt's Theory of Constraints warns about, while (5) is what Gartner and others call shadow IT — the Excel-as-duct-tape phenomenon that and already flag as a debt source. Worth adding a ninth: misaligned incentives between sponsors and executors, which compounds (8) and links to 's point about junior resourcing. Per Beer & Eisenstat's HBR "Silent Killers of Strategy Implementation" (2000), several of these — especially (2), (4), and (7) — are symptoms of a deeper governance failure rather than independent issues.
¶ narrative
Someone once told me that Excel is the best tool ever. I asked what they do when they hit Excel's limits—say, more than 3 million rows, or a complex custom calculation like implementing a custom IRR. Their answer: at that point, they just give it to IT.
This perfectly illustrates the citizen-developer-to-IT-debt pipeline described in and : the business user treats Excel as omnipotent until it isn't, then tosses the prototype over the wall as inherited complexity. It's a textbook case of what Felienne Hermans (TU Delft) has documented in her spreadsheet research—Excel becomes a shadow IT system whose domain logic only the original author understands, making the IT handoff far costlier than building it properly upfront. The deeper tension: Excel's limit isn't really 3M rows, it's the moment tacit knowledge needs to be made explicit, which is precisely when most users disengage. See also Panko's long-running work on spreadsheet error rates (~88% of non-trivial sheets contain bugs).
↯ claim
Non-builders tend to treat tools as black boxes: "Throw AI at it" is, to them, a complete plan. The assumption is that selecting the tool is solving the problem—as if everything between "use AI" and "it works" is a mechanical step the builder just executes. In reality, that gap is where most of the actual work lives.
This is the specification gap — what software engineers have long called the hard part of building. Fred Brooks argued in No Silver Bullet (1986) that the essential complexity of software lies in specifying behaviour precisely, not in the tools used; LLMs compress syntax but expose this gap more brutally, since vague prompts yield vague systems. Recent work like Addy Osmani's Beyond Vibe Coding (2025) and the METR developer-productivity study (2025) both find that non-builders systematically underestimate the iteration, verification, and integration work between prompt and product. Connects directly to 's builder/non-builder asymmetry and 's prototype-as-debt dynamic — when the gap is invisible, it gets dumped on whoever inherits the artifact.
↯ claim
It's also worth asking why rewrites and system migrations are so often forecasted to be disasters. The answer is that, at the moment of the rewrite, a mountain of inherited issues surfaces all at once: missing business logic, severe data quality problems, and poor UI that needs to be redesigned. People may see the rewrite as a disaster, but the current system is also a disaster—one that happens to be producing numbers. And those numbers, because of the very issues just mentioned, can't actually be relied on in reports, since the data model and its constraints have been violated. The old system is simply familiar, and therefore trusted.
This maps onto the Lindy effect inverted: the old system is trusted not because it works, but because its failures have been absorbed into workarounds and tribal knowledge. Researchers call this normalization of deviance (Diane Vaughan, The Challenger Launch Decision, 1996) — violated constraints stop registering as problems. The rewrite's real sin isn't creating disasters; it's making the existing ones legible and therefore newly accountable, which connects to 's innovation barriers and 's prototype-as-debt dynamic. Worth noting Martin Fowler's StranglerFigApplication pattern argues the disaster framing largely disappears when migration is incremental rather than big-bang.
↯ claim
IT innovation inside companies would be far easier if a few foundational pieces were in place: a solid data warehouse; a database paired with a friendly interface for custom data—essentially an Excel replacement, à la Airtable; and a compute layer for custom apps and integrations, such as Azure Functions running Python with FastAPI, FastHTML, or similar.
This maps closely to what Wessel Gerlach and others call an internal developer platform — the thesis being that innovation velocity is bounded by paved-road infrastructure, not ideas. Worth noting the tension with and : lowering the floor with Airtable-style tools accelerates prototyping but also accelerates the rate at which IT inherits debt, so the warehouse + compute layer only pays off if there's a clear graduation path from citizen artifact to governed system. Gartner's 2023 work on "fusion teams" and Thoughtworks' Technology Radar both argue the missing piece is usually not the stack you list but the ownership model around it.
↯ claim
When a rewrite or migration happens, it's treated as a single project—and resourced accordingly—aimed at implementing new functionality and migrating data. In reality, there's a second project hidden inside: determining the actual business logic and fixing data in the original system. And that second project may not even be feasible, because the old system might not allow the data to be represented in the states it should be in—which is precisely why the data looks the way it does today, shaped by ugly hacks around system limitations.
This is the hidden data archaeology problem: every migration is really two projects stacked—a build project and a forensic one to reverse-engineer why the data drifted from the model. Martin Fowler calls related artifacts "StranglerFig" candidates precisely because the old schema encodes workarounds that cannot be cleanly lifted; per Michael Feathers' Working Effectively with Legacy Code (2004), the behavior IS the spec, hacks included. The deeper trap you name—that the old system may have been structurally incapable of representing the correct states—means the "clean" target model will reject records the business still depends on, forcing either schema compromises or a parallel remediation effort nobody scoped. Directly extends 's point about why rewrites are forecast as disasters.
↯ claim
Vendors don't help either. They ship products with tables that have no constraints and little to no documentation. Customizations built on top of their products—such as custom reports—are similarly undocumented and often contain untested logic. Reports are also built by teams using other teams' data without consultation, producing numbers that the data-owning team would never sign off on.
This points to a well-documented anti-pattern: schema-less vendor databases push integrity logic into application code, where it silently drifts. Martin Fowler calls this the application database trap — when constraints live only in code, any new consumer (like a report team) bypasses them and produces plausible-but-wrong numbers. The cross-team reporting issue you describe is what Zhamak Dehghani's Data Mesh (2022) frames as missing data product ownership: without a contract and a sign-off owner, downstream consumers fabricate semantics. Reinforces and on why migrations explode — the undocumented vendor layer is the hidden mass.
↯ claim
At its core, most back-office work is data work.
This reframing aligns with the data-as-product movement (Zhamak Dehghani's Data Mesh, 2022) and explains why back-office automation so often fails: teams optimize the workflow but inherit the upstream data quality debt described in . It also clarifies why citizen-development artifacts (, ) proliferate here — Excel and low-code tools are really data manipulation environments dressed as process tools. The counter-tension: if back-office work is data work, then most 'process improvement' projects are misdiagnosed; per Thomas Redman's Data Driven (2008), poor data quality consumes 20–30% of operational revenue, dwarfing workflow inefficiencies.
? question
Some of the people who get excited but never actually make the transition into builders report that they need more training. But what else is there to do, if training has already been offered and the internet is full of free material? Why don't they go and pick it up themselves?
The "need more training" response is often what psychologists call a learned helplessness signal or a socially acceptable proxy for lower intrinsic motivation — it externalises the gap rather than naming it. Research on MOOC completion (Reich & Ruipérez-Valiente, Science, 2019) shows abundant free material doesn't convert intent into action; completion rates hover near 3–6%. This connects to : builders are pulled by restlessness, while non-builders wait to be pushed, so more curriculum rarely closes the gap. The sharper question may be whether they want the outcome of building or just the identity of someone who could.
↯ claim
I've found it more productive to work with people who actively oppose change than with enthusiastic people who haven't taken a single step toward building. It's easier to reduce opposition than to channel raw enthusiasm into actual creation.
This inverts the typical change-management playbook, which treats resistors as obstacles and enthusiasts as allies. Yet it aligns with Kotter's observation in Leading Change (1996) that vocal opposition often signals engagement and concrete understanding of what's at stake, while surface-level enthusiasm can mask what Pfeffer and Sutton called the knowing-doing gap (The Knowing-Doing Gap, 2000). Opposition is a signal with specific objections you can negotiate; enthusiasm without action is entropy disguised as energy — extending and 's point that excitement rarely converts into building.
※ opinion
Innovation should be made uncool. It ought to be a normal function of the business, not something framed as extraordinary.
This echoes Jeffrey Phillips' argument in Relentless Innovation (2011) that treating innovation as a special event creates an "innovation theatre" — separate labs, hackathons, demo days — which signals to staff that it's not their day job. Gary Pisano's Harvard Business Review piece "The Hard Truth About Innovative Cultures" (2019) makes a similar point: celebrated innovation cultures often hide a discipline deficit, because the celebration itself substitutes for accountability. The tension with is sharp — if innovation is routine work, you can't keep staffing it with juniors, but de-glamorising it also removes the prestige incentive that currently attracts anyone at all. See also on why the framing-as-extraordinary may itself be a barrier.
↯ claim14
↯ claim
Innovation carries an overwhelmingly positive connotation. Everyone, at least externally, claims they want to be innovative or to work in an innovative environment.
This positive halo is itself a critique target: Lee Vinsel and Andrew Russell's The Innovation Delusion (2020) argues the cult of innovation devalues maintenance, repair, and the unglamorous work that actually keeps systems running. There's also a status dimension — calling oneself "innovative" functions as identity signaling more than description, which is why the word survives despite being nearly meaningless in practice. Worth distinguishing novelty (new) from innovation (new + adopted + valuable); most self-described innovation fails the second two tests.
↯ claim
So why don't we see more innovative companies? Because innovation is genuinely hard, and only occasionally fun. What it actually requires is discipline above all else, a great deal of hard work, tolerance for failure, and intolerance for incompetence. None of those things are especially appealing.
This echoes Gary Pisano's Harvard Business Review argument (2019, "The Hard Truth About Innovative Cultures") that the celebrated traits of innovation cultures — tolerance for failure, psychological safety, experimentation — are always paired with brutal counterweights: rigorous discipline, candor, and accountability. Most companies adopt the fun half and skip the painful half, which is why 's observation about the positive connotation persists while actual innovation remains rare. The asymmetry is the point: tolerance for failure is not tolerance for incompetence, and conflating the two produces theater rather than output.
↯ claim
When citizen development artifacts grow too large—in structural complexity and embedded domain knowledge—and begin requiring complex changes or fixes, they get handed off to IT departments to become their problem. Poor code quality only compounds the issue.
This is the classic "throw it over the wall" anti-pattern, and it inverts the promised ROI of low-code platforms — IT ends up absorbing technical debt they had no hand in creating, often in unfamiliar platforms (Power Platform, Mendix, etc.) without proper version control, testing, or documentation. Gartner has flagged this as a core governance risk, recommending a fusion team model where IT co-owns artifacts above a complexity threshold rather than inheriting them post-hoc. The deeper tension with : citizen development is sold as innovation enablement, but without lifecycle guardrails it produces shadow IT that actively suppresses the org's capacity for real change.
↯ claim
There are far more people with needs and ideas than there are people who can build. This creates a problematic dynamic: builders are simultaneously in high demand and under pressure, yet undervalued when fixes or changes are needed—because only they understand the actual effort involved. To everyone else, the app is "delivered," and subsequent changes look like small incremental tasks.
This is the iceberg problem of software: stakeholders see the visible 10% (the UI, the "delivered" app) and price change requests against that, not the 90% of architecture, edge cases, and accumulated decisions underneath. Hal Abelson's framing that programs are written for people to read, and only incidentally for machines to execute, hints at why: the cost is in the comprehension load, not the typing. Connects to — when citizen-built artifacts balloon, the same asymmetry hits in reverse: non-builders discover too late how much hidden complexity they accumulated. Worth distinguishing scarcity-of-builders (a market claim) from undervaluation-of-effort (a perception claim); they have different fixes — pricing power vs. making the invisible work legible.
↯ claim
The citizen-developer produces the prototype that IT later inherits as debt — they externalises prototype's maintenance cost.
This is a classic negative externality — the prototype's creator captures the upside (problem solved, recognition) while IT absorbs the long-tail costs of security, integration, and maintenance. Gartner has flagged this as a core governance risk in low-code/no-code adoption, and Forrester's 2023 research on "shadow IT debt" estimates remediation often exceeds the original build cost by 3–5×. Extends 's threshold problem: the handoff rarely happens cleanly because by the time complexity demands IT involvement, the artifact is already load-bearing in someone's workflow.
↯ claim
In innovation projects, the resources allocated by the business are often not the most senior people—and when they are, they rarely have enough time to steer the project effectively. They may also lack the skills needed to shape the vision and define business requirements.
This is the classic resource allocation paradox in corporate innovation: the business treats innovation as discretionary, so A-players stay on revenue-generating work while B/C-players or junior staff get seconded part-time. Govindarajan and Trimble's The Other Side of Innovation (2010) argues this is why most innovation initiatives fail — they need a dedicated team with senior sponsorship, not borrowed capacity. It compounds the organizational difficulty noted in and helps explain : innovation isn't just hard intellectually, it's structurally starved of the seniority required to shape vision and unblock decisions.
↯ claim
Common issues with internal company innovation (process improvements, software changes, and development) include: (1) one department gets optimized at the expense of another; (2) lack of time to focus on improving business processes; (3) failure to recognize the full extent of the problem; (4) insufficient training; (5) people rely on whatever tool they have at hand—usually Excel—to patch problems; (6) inadequate infrastructure; (7) overly bureaucratic processes; (8) lack of motivation.
This list maps neatly onto well-documented failure modes: point (1) is the classic local optima trap that Goldratt's Theory of Constraints warns about, while (5) is what Gartner and others call shadow IT — the Excel-as-duct-tape phenomenon that and already flag as a debt source. Worth adding a ninth: misaligned incentives between sponsors and executors, which compounds (8) and links to 's point about junior resourcing. Per Beer & Eisenstat's HBR "Silent Killers of Strategy Implementation" (2000), several of these — especially (2), (4), and (7) — are symptoms of a deeper governance failure rather than independent issues.
↯ claim
Non-builders tend to treat tools as black boxes: "Throw AI at it" is, to them, a complete plan. The assumption is that selecting the tool is solving the problem—as if everything between "use AI" and "it works" is a mechanical step the builder just executes. In reality, that gap is where most of the actual work lives.
This is the specification gap — what software engineers have long called the hard part of building. Fred Brooks argued in No Silver Bullet (1986) that the essential complexity of software lies in specifying behaviour precisely, not in the tools used; LLMs compress syntax but expose this gap more brutally, since vague prompts yield vague systems. Recent work like Addy Osmani's Beyond Vibe Coding (2025) and the METR developer-productivity study (2025) both find that non-builders systematically underestimate the iteration, verification, and integration work between prompt and product. Connects directly to 's builder/non-builder asymmetry and 's prototype-as-debt dynamic — when the gap is invisible, it gets dumped on whoever inherits the artifact.
↯ claim
It's also worth asking why rewrites and system migrations are so often forecasted to be disasters. The answer is that, at the moment of the rewrite, a mountain of inherited issues surfaces all at once: missing business logic, severe data quality problems, and poor UI that needs to be redesigned. People may see the rewrite as a disaster, but the current system is also a disaster—one that happens to be producing numbers. And those numbers, because of the very issues just mentioned, can't actually be relied on in reports, since the data model and its constraints have been violated. The old system is simply familiar, and therefore trusted.
This maps onto the Lindy effect inverted: the old system is trusted not because it works, but because its failures have been absorbed into workarounds and tribal knowledge. Researchers call this normalization of deviance (Diane Vaughan, The Challenger Launch Decision, 1996) — violated constraints stop registering as problems. The rewrite's real sin isn't creating disasters; it's making the existing ones legible and therefore newly accountable, which connects to 's innovation barriers and 's prototype-as-debt dynamic. Worth noting Martin Fowler's StranglerFigApplication pattern argues the disaster framing largely disappears when migration is incremental rather than big-bang.
↯ claim
IT innovation inside companies would be far easier if a few foundational pieces were in place: a solid data warehouse; a database paired with a friendly interface for custom data—essentially an Excel replacement, à la Airtable; and a compute layer for custom apps and integrations, such as Azure Functions running Python with FastAPI, FastHTML, or similar.
This maps closely to what Wessel Gerlach and others call an internal developer platform — the thesis being that innovation velocity is bounded by paved-road infrastructure, not ideas. Worth noting the tension with and : lowering the floor with Airtable-style tools accelerates prototyping but also accelerates the rate at which IT inherits debt, so the warehouse + compute layer only pays off if there's a clear graduation path from citizen artifact to governed system. Gartner's 2023 work on "fusion teams" and Thoughtworks' Technology Radar both argue the missing piece is usually not the stack you list but the ownership model around it.
↯ claim
When a rewrite or migration happens, it's treated as a single project—and resourced accordingly—aimed at implementing new functionality and migrating data. In reality, there's a second project hidden inside: determining the actual business logic and fixing data in the original system. And that second project may not even be feasible, because the old system might not allow the data to be represented in the states it should be in—which is precisely why the data looks the way it does today, shaped by ugly hacks around system limitations.
This is the hidden data archaeology problem: every migration is really two projects stacked—a build project and a forensic one to reverse-engineer why the data drifted from the model. Martin Fowler calls related artifacts "StranglerFig" candidates precisely because the old schema encodes workarounds that cannot be cleanly lifted; per Michael Feathers' Working Effectively with Legacy Code (2004), the behavior IS the spec, hacks included. The deeper trap you name—that the old system may have been structurally incapable of representing the correct states—means the "clean" target model will reject records the business still depends on, forcing either schema compromises or a parallel remediation effort nobody scoped. Directly extends 's point about why rewrites are forecast as disasters.
↯ claim
Vendors don't help either. They ship products with tables that have no constraints and little to no documentation. Customizations built on top of their products—such as custom reports—are similarly undocumented and often contain untested logic. Reports are also built by teams using other teams' data without consultation, producing numbers that the data-owning team would never sign off on.
This points to a well-documented anti-pattern: schema-less vendor databases push integrity logic into application code, where it silently drifts. Martin Fowler calls this the application database trap — when constraints live only in code, any new consumer (like a report team) bypasses them and produces plausible-but-wrong numbers. The cross-team reporting issue you describe is what Zhamak Dehghani's Data Mesh (2022) frames as missing data product ownership: without a contract and a sign-off owner, downstream consumers fabricate semantics. Reinforces and on why migrations explode — the undocumented vendor layer is the hidden mass.
↯ claim
At its core, most back-office work is data work.
This reframing aligns with the data-as-product movement (Zhamak Dehghani's Data Mesh, 2022) and explains why back-office automation so often fails: teams optimize the workflow but inherit the upstream data quality debt described in . It also clarifies why citizen-development artifacts (, ) proliferate here — Excel and low-code tools are really data manipulation environments dressed as process tools. The counter-tension: if back-office work is data work, then most 'process improvement' projects are misdiagnosed; per Thomas Redman's Data Driven (2008), poor data quality consumes 20–30% of operational revenue, dwarfing workflow inefficiencies.
↯ claim
I've found it more productive to work with people who actively oppose change than with enthusiastic people who haven't taken a single step toward building. It's easier to reduce opposition than to channel raw enthusiasm into actual creation.
This inverts the typical change-management playbook, which treats resistors as obstacles and enthusiasts as allies. Yet it aligns with Kotter's observation in Leading Change (1996) that vocal opposition often signals engagement and concrete understanding of what's at stake, while surface-level enthusiasm can mask what Pfeffer and Sutton called the knowing-doing gap (The Knowing-Doing Gap, 2000). Opposition is a signal with specific objections you can negotiate; enthusiasm without action is entropy disguised as energy — extending and 's point that excitement rarely converts into building.
? question3
? question
I've found that people with a lot of enthusiastic energy are surprisingly tricky to work with. They're very excited—which is good—but I struggle to find a way to channel that excitement into anything concrete. Generating more excitement isn't productive; they're already excited. What they need to do is start innovating—that is, start building. But if they're this excited right now and still haven't taken even the smallest step toward building something (like actually launching a no-code app and working through a tutorial), then what else is there to do?
This maps onto the enthusiasm-action gap documented in behavioral research: Gollwitzer's work on implementation intentions shows that motivation without concrete "if-then" plans rarely converts to action, and Kahneman's planning fallacy compounds it — excitement inflates perceived progress while substituting for it. A useful diagnostic: are they excited about the outcome (being an innovator, the finished product) or the process (the messy tutorial, the broken first build)? Outcome-excitement is essentially consumption; only process-excitement predicts shipping. This connects to — organizations face the same gap at scale, where enthusiasm for innovation rarely survives the unglamorous follow-through.
? question
Another question is whether non-builders can be turned into builders—at least for simple, no-code things they could build for themselves or their immediate team. Tools like Power Automate and Power BI can help enormously. I understand why people don't pick them up: they may not know these tools exist, work doesn't leave time for learning, and free time is, after all, free time. But the deeper question is whether the person has the personality to become a builder in the first place.
The personality question echoes research on self-efficacy (Bandura) and maker identity — many adults don't see themselves as "technical," and that self-concept predicts tool adoption more than aptitude does. Gartner's citizen-developer forecasts (2021–2023) repeatedly overshot reality for this reason: licenses get provisioned, but sustained building requires tolerance for debugging frustration, which is a disposition, not a skill. Worth pairing with 's warning — even when non-builders do build, their artifacts often outgrow them — and 's supply gap, which low-code only partially closes if the personality bottleneck is real.
? question
Some of the people who get excited but never actually make the transition into builders report that they need more training. But what else is there to do, if training has already been offered and the internet is full of free material? Why don't they go and pick it up themselves?
The "need more training" response is often what psychologists call a learned helplessness signal or a socially acceptable proxy for lower intrinsic motivation — it externalises the gap rather than naming it. Research on MOOC completion (Reich & Ruipérez-Valiente, Science, 2019) shows abundant free material doesn't convert intent into action; completion rates hover near 3–6%. This connects to : builders are pulled by restlessness, while non-builders wait to be pushed, so more curriculum rarely closes the gap. The sharper question may be whether they want the outcome of building or just the identity of someone who could.
※ opinion2
※ opinion
I think builders are driven by a certain restlessness and dissatisfaction. When they come across a tool that works poorly, or one that demands unreasonable effort to use, they get irritated—and build something that actually works. Other people, by contrast, don't seem bothered by being asked to jump through hoops for no good reason. Or maybe what looks like acceptance is really learned helplessness.
This echoes Paul Graham's notion that hackers are driven by a low tolerance for friction — what he calls being "offended" by bad design. The learned helplessness framing (Seligman) is sharp: it reframes passivity not as preference but as conditioned defeat, which connects to 's asymmetry between needers and builders. A counter-tension though: that same restlessness can become yak shaving — rebuilding tools instead of doing the underlying work, which links to the energy-management problem in .
※ opinion
Innovation should be made uncool. It ought to be a normal function of the business, not something framed as extraordinary.
This echoes Jeffrey Phillips' argument in Relentless Innovation (2011) that treating innovation as a special event creates an "innovation theatre" — separate labs, hackathons, demo days — which signals to staff that it's not their day job. Gary Pisano's Harvard Business Review piece "The Hard Truth About Innovative Cultures" (2019) makes a similar point: celebrated innovation cultures often hide a discipline deficit, because the celebration itself substitutes for accountability. The tension with is sharp — if innovation is routine work, you can't keep staffing it with juniors, but de-glamorising it also removes the prestige incentive that currently attracts anyone at all. See also on why the framing-as-extraordinary may itself be a barrier.
☾ reflection1
☾ reflection
It's hard to design an organization for innovation, and even harder to follow through with the necessary resources and strategic decisions. Still, some degree of improvement has to happen, even if only incrementally. Usually it falls on the shoulders of a high performer or a tech-inclined team member who has put together a small prototype—say, an automated Excel spreadsheet with VBA. The tools aren't optimal, the design rarely goes beyond prototype quality, and it's not really something built to be maintained for years. But it helps so much that the person ends up tagged with the "innovation" label.
This describes what Eric von Hippel calls user innovation or shadow IT—frontline employees building unsanctioned tools because formal channels are too slow. The pattern extends 's point about why innovation is rare: organizations reward the visible hero but rarely invest in productionizing the prototype, so the VBA spreadsheet becomes load-bearing infrastructure no one owns. Gartner has tracked this as citizen developer risk, where 41% of employees customize tech outside IT (per Gartner, 2021). The deeper tension: labeling someone "the innovator" individualizes what should be a systemic capability, and often burns out the person doing it.
¶ narrative1
¶ narrative
Someone once told me that Excel is the best tool ever. I asked what they do when they hit Excel's limits—say, more than 3 million rows, or a complex custom calculation like implementing a custom IRR. Their answer: at that point, they just give it to IT.
This perfectly illustrates the citizen-developer-to-IT-debt pipeline described in and : the business user treats Excel as omnipotent until it isn't, then tosses the prototype over the wall as inherited complexity. It's a textbook case of what Felienne Hermans (TU Delft) has documented in her spreadsheet research—Excel becomes a shadow IT system whose domain logic only the original author understands, making the IT handoff far costlier than building it properly upfront. The deeper tension: Excel's limit isn't really 3M rows, it's the moment tacit knowledge needs to be made explicit, which is precisely when most users disengage. See also Panko's long-running work on spreadsheet error rates (~88% of non-trivial sheets contain bugs).
claim question opinion reflection narrative
drag panwheel zoomhover readclick open panel
:linked notes
thesis claim question idea task entity definition reference quote opinion reflection narrative comparison general