Product development

The Chinese Advantage

February 21, 2026

Actionable Insights, AI, Article, Prod•gnosis, Product development

The Chinese Advantage

There is a damning pattern playing out across global industry right now, and most Western companies are too indifferent to notice it. While Chinese manufacturers push boundaries, pack in features, and iterate at blistering speed, their Western counterparts do just enough. Enough to ship. Enough to satisfy the quarterly earnings call. Enough to not get fired. And that gap between ‘enough’ and ‘everything we can’ is quietly reshaping who leads — and who follows — in sector after sector.

This is not about cheap labour or government subsidies. It is about ambition. Chinese manufacturers behave as though every product launch is a fight for survival. Western companies behave as though their history alone will carry them through. One of those approaches is winning. It is not the Western one.

The ‘Good Enough’ Trap

Western manufacturing has drifted into a culture of sufficiency. Products are built to meet specifications, not to exceed them. Features are held back for next year’s model to justify the upgrade cycle. Engineering teams are constrained by risk-averse management layers, and innovation is filtered through committees that prize predictability over ambition.

Look at the smartphone market. For years, Apple and Samsung have delivered incremental annual updates — a slightly better camera here, a marginally faster chip there — while charging ever-higher prices. Meanwhile, Chinese manufacturers like Xiaomi, Vivo, and OPPO have been cramming their devices with 7,500mAh silicon-carbon batteries, 200-megapixel periscope telephoto lenses, 144Hz displays, and charging speeds that take a phone from 10 per cent to 80 per cent in roughly seven minutes. These are not flagship-only features reserved for £1,200 devices. Chinese brands are shipping this technology in phones that cost a third of the price. They are not holding features back for next year. They are shipping everything they have got, right now.

The Western approach, by contrast, often feels as though it is optimised for margin protection rather than customer delight. Why include fast charging when you can make it a premium differentiator next cycle? Chinese companies do not think this way. They think: what can we possibly cram into this product that will make someone choose it?

Software: Where the Gap Is Widening Fastest

Hardware gets the headlines, but the software gap may be even more telling. Chinese manufacturers treat software as a core competitive weapon. Western companies often treat it as an afterthought — or worse, a cost centre.

In the automotive space, Chinese EV makers have reimagined the car as a software platform. XPeng’s entire 2025 lineup follows what the company calls an ‘AI-defined’ approach, where software leads and hardware follows. Vehicles receive regular over-the-air updates that add genuinely new capabilities — not just bug fixes, but new driving features, new interface designs, new AI-powered functions. BYD, Xiaomi, and NIO have built their vehicles to integrate seamlessly with China’s digital ecosystem — payment apps, messaging platforms, voice assistants, navigation — creating an experience that feels native and cohesive.

Western automakers, by comparison, are still shipping infotainment systems that feel as though they were designed in 2015. Laggy touchscreens, clunky menus, Bluetooth connectivity that drops mid-call. Ford, GM, and Volkswagen have spent billions on software divisions, yet a JD Power study found that drivers using Apple CarPlay rated their infotainment experience at 840 out of 1,000, compared with just 805 for those relying on the manufacturer’s built-in system. Consumer Reports found a similar pattern, with its own experts concluding that using CarPlay is an effective way to make a poor system less distracting and easier to use. In other words, most Western car companies have spent a fortune building infotainment platforms that their own customers would rather bypass entirely. The software is not terrible — it is merely adequate. It does enough. And ‘enough’ is no longer enough.

The same dynamic plays out in consumer electronics. Xiaomi’s HyperOS connects phones, tablets, laptops, televisions, home appliances, and now cars into a single cohesive ecosystem. Vivo and OPPO are shipping AI-powered photography processing that rivals or exceeds what Apple’s computational photography can do, at a fraction of the price. Chinese firms are treating on-device AI not as a marketing buzzword but as a genuine engineering priority — embedding it into cameras, battery management, display calibration, car suspensions, and user interfaces.

Even in enterprise and industrial AI, the Chinese approach has been more aggressive. DeepSeek’s R1 model did not just make waves in the research community — it was deployed within months to power humanoid robots on real factory floors at companies like Zeekr. The speed from research breakthrough to industrial deployment was measured in months. In the West, that same journey typically involves lengthy pilot programmes, steering committees, and procurement cycles that stretch past two years. Chinese companies treat software as something to ship. Western companies treat it as something to roll their eyes over.

Humanoid Robots: Shipped, Not Studied

The humanoid robotics space is perhaps the starkest illustration of the cultural divide. In 2025, Chinese companies shipped roughly 90 per cent of all humanoid robots sold globally. AgiBot, Unitree, and UBTech collectively delivered over 13,000 units — a five-fold increase on the previous year. Unitree alone sold 5,500. Tesla’s target for its Optimus robot was 5,000 for the entire year. It did not hit it.

The difference is not just volume — it is philosophy. While Western robotics companies were perfecting prototypes in controlled environments, running extensive peer-reviewed validation cycles, and presenting at conferences, Chinese firms were deploying robots into real factories. UBTech’s Walker S robots were working in coordinated teams at Zeekr’s smart factory — lifting, assembling, inspecting — powered by AI and learning on the job. Elon Musk himself conceded: ‘China is very good at AI, very good at manufacturing, and will definitely be the toughest competition for Tesla. To the best of our knowledge, we don’t see any significant competitors outside of China’.

And the pricing tells its own story. Unitree’s R1 humanoid starts at $5,900. Noetix’s Bumi, aimed at home consumers, retails for just $1,370. Western competitors are nowhere near those price points, because they have not committed to the mass production and supply chain integration needed to get there. They are still treating humanoid robots as a research project. Chinese firms are treating them as a product.

Wind and Solar: Not Just Bigger — Better

In wind energy, Chinese manufacturers now hold six of the top seven global positions for turbine production. European and American firms have been pushed out of the top three entirely for the first time. Dongfang Electric built the world’s most powerful wind turbine — a 26-megawatt offshore prototype with blades stretching 153 metres. It took that title from Siemens Gamesa. And it did so while being up to 50 per cent cheaper.

This is the pattern that Western executives find so disorienting: Chinese firms are not winning on price or performance. They are winning on both, simultaneously. The old assumption — that you could have cheap or you could have good — has been demolished.

In solar, China produces four in five modules globally. Battery pack prices have fallen to around $60 per kilowatt-hour, well below the $100 threshold once considered the tipping point for EV affordability. China’s share of clean energy patent applications has surged from around 5 per cent in 2000 to roughly 75 per cent by 2022. In 2023, Chinese corporations invested ten times more in energy-sector research and development than their American counterparts.

Western clean energy companies, meanwhile, are struggling with factory cancellations, cost overruns, and wavering policy support. The collapse of Sweden’s Northvolt — once Europe’s great battery hope, valued at $12 billion, which filed for bankruptcy in March 2025 with $5.8 billion in debts after raising over $14 billion from investors including Volkswagen, Goldman Sachs, and BMW — was a stark reminder that ambition without execution is worthless.

Not Bleeding Edge — But Getting There Faster Than Anyone Expected

It would be dishonest to pretend that China leads everywhere. It does not. In advanced semiconductors, the West — and specifically TSMC in Taiwan, ASML in the Netherlands, and Nvidia in the United States — retains a formidable lead. China cannot yet mass-produce chips at the 3-nanometre or 5-nanometre nodes that power the most advanced AI systems and consumer devices. It lacks access to extreme ultraviolet lithography machines, the extraordinarily complex tools that only ASML can build, and which are essential for manufacturing cutting-edge processors. In frontier AI model training, the United States still holds a significant infrastructure advantage, with private-sector investment in AI infrastructure running at roughly twelve times China’s level in 2024–2025.

But here is what matters: the gap is closing, and it is closing faster than almost anyone predicted.

A White House official acknowledged in 2025 that China is now likely less than two years behind the United States in semiconductor design capabilities — a remarkable narrowing from what was, not long ago, considered a generational deficit. Huawei’s Ascend AI accelerators can now challenge some of Nvidia’s data centre GPUs, and the company is building rack-scale AI solutions that compete with Nvidia’s most advanced offerings. SMIC, Huawei’s manufacturing partner, has been scaling up 7-nanometre chip production and aims to produce 50,000 wafers per month. Domestic wafer fabrication equipment companies have increased their market share from around 20 per cent to 25 per cent in a single year, with firms like AMEC and Naura rapidly improving quality based on feedback loops with local foundries. In early 2025, Chinese researchers completed a functional prototype of an EUV lithography machine — built partly by former ASML engineers — as part of a national push for self-sufficiency in chip production by the end of the decade.

What makes the convergence so striking is not just the technical progress. It is the strategy. Rather than trying to match the West watt-for-watt on raw computing power, Chinese firms are optimising around the constraints. DeepSeek’s R1 model, which rivalled OpenAI’s o1 at launch, was engineered to run efficiently on less powerful hardware. Its ‘sparse attention’ architecture reportedly halves computing costs without sacrificing meaningful performance. This is not imitation — it is adaptation. Where the West throws more silicon at the problem, China throws more ingenuity.

The pattern is consistent across sectors. In every domain where China trails — and there are still several — the gap is measured not in decades but in years, and the closure rate is accelerating. US export controls have slowed access to certain tools, but they have simultaneously turbocharged domestic substitution efforts, closer hardware-software co-design, and a national urgency around self-reliance that simply did not exist a decade ago. The restrictions intended to hold China back may ultimately prove to have been the catalyst that forced it to build the very capabilities the West was trying to deny it.

The West still has its leads. But the leads are shrinking, and the rate of shrinkage is itself increasing. That compounding dynamic should concern Western industry far more than any single Chinese product launch.

The ‘Just Enough’ Mentality in Practice

The Western ‘just enough’ approach reveals itself in small ways that compound over time. A car infotainment system that technically works but nobody enjoys using. A smartphone camera that is fine in good light but falls apart at night. A wind turbine that meets specification but has not been redesigned in three years. A software update that patches bugs but adds no new features.

Each individual instance seems minor. But multiplied across an entire industrial ecosystem and sustained over years, it creates a profound vulnerability. Because while Western firms are doing just enough, Chinese firms are doing everything they can think of — and then looking for more.

Chinese EV companies develop new models in 18 to 24 months. Western automakers take four to six years. That is not just a speed difference — it is a compounding knowledge gap. Every cycle, Chinese firms learn more, test more, and ship more. Every cycle, the gap widens.

The domestic competitive environment in China enforces this intensity. At its peak, around 500 EV companies were competing in China’s market. Brutal consolidation reduced that number to roughly 100 by 2023. Only the hungriest survived. There is a Chinese term for this — neijuan, or ‘involution’ — describing the ferocious, sometimes ruinous competition that leaves no room for complacency. When your competitors are willing to ship updates weekly and launch brand new models annually, ‘good enough’ is a death sentence.

The Australian Strategic Policy Institute found that China now leads the United States in 57 out of 64 critical technology categories. In 2007, that number was three. That trajectory alone should be a wake-up call.

What Western Companies Could Learn But Won’t

The answer is not to replicate China’s model wholesale. Not every aspect of its industrial ecosystem is desirable or transferable. But there are lessons worth absorbing.

Ship and iterate, do not perfect and launch. Chinese firms get products into the real world faster and improve them in the field. Western firms over-engineer in the laboratory and under-deliver on the road. The feedback loop from real-world deployment is worth more than another year of internal testing.

Treat software as a first-class product, not a support function. The car, the phone, the robot, the turbine — increasingly, the software is the product. Western companies that still treat software as a bolt-on will find themselves outpaced by rivals who build around it. And who enable their software teams to innovate and iterate like the Chinese.

Stop saving features for next year. The upgrade-cycle mentality — deliberately withholding capability to justify future purchases — only works when your competitors play the same game. Chinese firms do not. They ship the best thing they can build, right now, and start working on the next one immediately.

Compete on ambition, not just brand. Brand loyalty is a depreciating asset when a competitor offers more for less. Western consumers are increasingly willing to try Chinese alternatives — and when they do, many do not switch back.

The Uncomfortable Question

The real challenge for Western industry is not technological. The technology exists. The talent exists. The capital exists. The challenge is cultural. Somewhere along the way, Western manufacturing lost its hunger. It became acceptable to ship products that were fine. Adequate. Sufficient. The quarterly earnings were met, the shareholders were satisfied, and nobody asked whether the product was actually as good as it could be.

Chinese manufacturers did not discover some secret formula. They just never stopped asking that question. And in a global marketplace where consumers have more choice than ever, the companies that try hardest — not the ones with the biggest brand or the longest history — are the ones that win.

The West is not being outspent. It is being out-tried.

The Agile Manifesto: Rearranging Deck Chairs While Five Dragons Burn Everything Down

September 15, 2025

Agile, Alien tech, Antimatter principle, Article, Collaboration, Lamentation, Organisational effectiveness, Product development, Quintessence, Software development

Leave a comment

The Agile Manifesto: Rearranging Deck Chairs While Five Dragons Burn Everything Down

Why the ‘Sound’ Principles Miss the Dragons That Actually Kill Software Projects

The Agile Manifesto isn’t wrong, per se—it’s addressing the wrong problems entirely. And that makes it tragically inadequate.

For over two decades, ‘progressive’ software teams have been meticulously implementing sprints, standups, and retrospectives whilst the real dragons have been systematically destroying their organisations from within. The manifesto’s principles aren’t incorrect; they’re just rearranging deck chairs on the Titanic whilst it sinks around them.

The four values and twelve principles address surface symptoms of dysfunction whilst completely ignoring the deep systemic diseases that kill software projects. It’s treating a patient’s cough whilst missing the lung cancer—technically sound advice that’s spectacularly missing the point.

The Real Dragons: What Actually Destroys Software Teams

Whilst we’ve been optimising sprint ceremonies and customer feedback loops, five ancient dragons have been spectacularly burning down software development and tech business effectiveness:

Dragon #1: Human Motivation Death Spiral
Dragon #2: Dysfunctional Relationships That Poison Everything
Dragon #3: Shared Delusions and Toxic Assumptions
Dragon #4: The Management Conundrum—Questioning the Entire Edifice
Dragon #5: Opinioneering—The Ethics of Belief Violated

These aren’t process problems or communication hiccups. They’re existential threats that turn the most well-intentioned agile practices into elaborate theatre whilst real work grinds to a halt. And the manifesto? It tiptoes around these dragons like they don’t exist.

Dragon #1: The Motivation Apocalypse

‘Individuals and interactions over processes and tools’ sounds inspiring until you realise that your individuals are fundamentally unmotivated to do good work. The manifesto assumes that people care—but what happens when they don’t?

The real productivity killer isn’t bad processes; it’s developers who have mentally checked out because:

They’re working on problems they find meaningless
Their contributions are invisible or undervalued
They have no autonomy over how they solve problems
The work provides no sense of mastery or purpose
They’re trapped in roles that don’t match their strengths

You can have the most collaborative, customer-focused, change-responsive team in the world, but if your developers are quietly doing the minimum to avoid getting fired, your velocity will crater regardless of your methodology.

The manifesto talks about valuing individuals but offers zero framework for understanding what actually motivates people to do their best work. It’s having a sports philosophy that emphasises teamwork whilst ignoring whether the players actually want to win the game. How do you optimise ‘individuals and interactions’ when your people have checked out?

Dragon #2: Relationship Toxicity That Spreads Like Cancer

‘Customer collaboration over contract negotiation’ assumes that collaboration is even possible—but what happens when your team relationships are fundamentally dysfunctional?

The real collaboration killers that the manifesto ignores entirely:

Trust deficits: When team members assume bad faith in every interaction
Ego warfare: When technical discussions become personal attacks on competence
Passive aggression: When surface civility masks deep resentment and sabotage
Fear: When people are afraid to admit mistakes or ask questions
Status games: When helping others succeed feels like personal failure

You hold all the retrospectives you want, but if your team dynamics are toxic, every agile practice becomes a new battlefield. Sprint planning turns into blame assignment. Code reviews become character assassination. Customer feedback becomes ammunition for internal warfare.

The manifesto’s collaboration principles are useless when the fundamental relationships are broken. It’s having marriage counselling techniques for couples who actively hate each other—technically correct advice that misses the deeper poison. How do you collaborate when trust has been destroyed? What good are retrospectives when people are actively sabotaging each other?

Dragon #3: Shared Delusions That Doom Everything

‘Working software over comprehensive documentation’ sounds pragmatic until you realise your team is operating under completely different assumptions about what ‘working’ means, what the software does, and how success is measured. But what happens when your team shares fundamental delusions about reality?

The productivity apocalypse happens when teams share fundamental delusions:

Reality distortion: Believing their product is simpler/better/faster than it actually is
Capability myths: Assuming they can deliver impossible timelines with current resources
Quality blindness: Thinking ‘works on my machine’ equals production-ready
User fiction: Building for imaginary users with imaginary needs
Technical debt denial: Pretending that cutting corners won’t compound into disaster

These aren’t communication problems that better customer collaboration can solve—they’re shared cognitive failures that make all collaboration worse. When your entire team believes something that’s factually wrong, more interaction just spreads the delusion faster.

The manifesto assumes that teams accurately assess their situation and respond appropriately. But when their shared mental models are fundamentally broken? All the adaptive planning in the world won’t help if you’re adapting based on fiction.

Dragon #4: The Management Conundrum—Why the Entire Edifice Is Suspect

‘Responding to change over following a plan’ sounds flexible, but let’s ask the deeper question: Why do we have management at all?

The manifesto takes management as a given and tries to optimise around it. But what if the entire concept of management—people whose job is to direct other people’s work without doing the work themselves—is a fundamental problem?

Consider what management actually does in most software organisations:

Creates artificial hierarchies that slow down decision-making
Adds communication layers that distort information as it flows up and down
Optimises for command and control rather than effectiveness
Makes decisions based on PowerPoint and opinion rather than evidence
Treats humans like interchangeable resources to be allocated and reallocated

The devastating realisation is that management in software development is pure overhead that actively impedes the work. Managers who:

Haven’t written code in years (or ever) making technical decisions
Set timelines based on business commitments rather than reality
Reorganise teams mid-project because a consultant recommended ‘matrix management’ or some such
Measure productivity by story points rather than needs attended to (or met)
Translate clear customer needs into incomprehensible requirements documents

What value does this actually add? Why do we have people who don’t understand the work making decisions about the work? What if every management layer is just expensive interference?

The right number of managers for software teams is zero. The entire edifice of management—the org charts, the performance reviews, the resource allocation meetings—is elaborate theatre that gets in the way of people solving problems.

Productive software teams operate more like research labs or craftsman guilds: self-organising groups of experts who coordinate directly with each other and with the people who use their work. No sprint masters, no product owners, no engineering managers—just competent people working together to solve problems.

The manifesto’s principles assume management exists and try to make it less harmful. But they never question whether it has any value at all.

Dragon #5: Opinioneering—The Ethics of Belief Violated

Here’s the dragon that the manifesto not only ignores but actually enables: the epidemic of strong opinions held without sufficient evidence.

William Kingdon Clifford wrote in 1877 that

‘it is wrong always, everywhere, and for anyone, to believe anything upon insufficient evidence’
(Clifford, 1877).

In software development, we’ve created an entire culture that violates this ethical principle daily through systematic opinioneering:

Technical Opinioneering: Teams adopting microservices because they’re trendy, not because they solve actual problems. Choosing React over Vue because it ‘feels’ better. Implementing event sourcing because it sounds sophisticated. Strong architectural opinions based on blog posts rather than deep experience with the trade-offs.

Process Opinioneering: Cargo cult agile practices copied from other companies without understanding why they worked there. Daily standups that serve no purpose except ‘that’s what agile teams do.’ Retrospectives that generate the same insights every sprint because the team has strong opinions about process improvement but no evidence about what actually works.

Business Opinioneering: Product decisions based on what the CEO likes rather than what users require. Feature priorities set by whoever argues most passionately rather than data about user behaviour. Strategic technology choices based on industry buzz rather than careful analysis of alternatives.

Cultural Opinioneering: Beliefs about remote work, hiring practices, team structure, and development methodologies based on what sounds right rather than careful observation of results.

The manifesto makes this worse by promoting ‘individuals and interactions over processes and tools’ without any framework for distinguishing between evidence-based insights and opinion-based groupthink. It encourages teams to trust their collective judgement without asking whether that judgement is grounded in sufficient evidence. But what happens when the collective judgement is confidently wrong? How do you distinguish expertise from persuasive ignorance?

When opinioneering dominates, you get teams that are very confident about practices that don’t work, technologies that aren’t suitable, and processes that waste enormous amounts of time. Everyone feels like they’re making thoughtful decisions, but they’re sharing unfounded beliefs dressed up as expertise.

The Deeper Problem: Dysfunctional Shared Assumptions and Beliefs

The five dragons aren’t just symptoms—they’re manifestations of something deeper. Software development organisations operate under shared assumptions and beliefs that make effectiveness impossible, and the Agile Manifesto doesn’t even acknowledge this fundamental layer exists.

My work in Quintessence provides the missing framework for understanding why agile practices fail so consistently. The core insight is that organisational effectiveness is fundamentally a function of collective mindset:

Organisational effectiveness = f(collective mindset)

I demonstrate that every organisation operates within a “memeplex“—a set of interlocking assumptions and beliefs about work, people, and how organisations function. These beliefs reinforce each other so strongly that changing one belief causes the others to tighten their grip to preserve the whole memeplex.

This explains why agile transformations consistently fail. Teams implement new ceremonies whilst maintaining the underlying assumptions that created their problems in the first place. They adopt standups and retrospectives whilst still believing people are motivated, relationships are authentic, management adds value, and software is always the solution.

Consider the dysfunctional assumptions that pervade conventional software development:

About People: Most organisations and their management operate under “Theory X” assumptions—people are naturally lazy, require external motivation, need oversight to be productive, and will shirk responsibility without means to enforce accountability. These beliefs create the very motivation problems they claim to address.

About Relationships: Conventional thinking treats relationships as transactional. Competition drives performance. Hierarchy creates order. Control prevents chaos. Personal connections are “unprofessional.” These assumptions poison the collaboration that agile practices supposedly enable.

About Work: Software is the solution to every problem. Activity indicates value. Utilisation (of eg workers) drives productivity. Efficiency trumps effectiveness. Busyness proves contribution. These beliefs create the delusions that make teams confidently ineffective.

About Management: Complex work requires coordination. Coordination requires hierarchy. Hierarchy requires managers. Managers add value through oversight and direction. These assumptions create the parasitic layers that impede the very work they claim to optimise.

About Knowledge: Strong opinions indicate expertise. Confidence signals competence. Popular practices are best practices. Best practices are desirable. Industry trends predict future success. These beliefs create the opinioneering that replaces evidence with folklore.

Quintessence (Marshall, 2021) shows how “quintessential organisations” operate under completely different assumptions:

People find joy in meaningful work and naturally collaborate when conditions support it
Relationships based on mutual care and shared purpose are the foundation of effectiveness
Work is play when aligned with purpose and human flourishing
Management is unnecessary parasitism—people doing the work make the decisions about the work
Beliefs must be proportioned to evidence and grounded in serving real human needs

The Agile Manifesto can’t solve problems created by fundamental belief systems because it doesn’t even acknowledge these belief systems exist. It treats symptoms whilst leaving the disease untouched. Teams optimise ceremonies whilst operating under assumptions that guarantee continued dysfunction.

This is why the Qunitessence approach differs so radically from ‘Agile’ approaches. Instead of implementing new practices, quintessential organisations examine their collective assumptions and beliefs. Instead of optimising processes, they transform their collective mindset. Instead of rearranging deck chairs, they address the fundamental reasons the ship is sinking.

The Manifesto’s Tragic Blindness

Here’s what makes the Agile Manifesto so inadequate: it assumes the Five Dragons don’t exist. It offers principles for teams that are motivated, functional, reality-based, self-managing, and evidence-driven—but most software teams are none of these things.

The manifesto treats symptoms whilst ignoring diseases:

It optimises collaboration without addressing what makes collaboration impossible
It values individuals without confronting what demotivates them
It promotes adaptation without recognising what prevents teams from seeing their shared assumptions and beliefs clearly
It assumes management adds value rather than questioning whether management has any value at all
It encourages collective decision-making without any framework for leveraging evidence-based beliefs

This isn’t a failure of execution—it’s a failure of diagnosis. The manifesto identified the wrong problems and thus prescribed the wrong solutions.

Tom Gilb’s Devastating Assessment: The Manifesto Is Fundamentally Fuzzy

Software engineering pioneer Tom Gilb delivers the most damning critique of the Agile Manifesto: its principles are

‘so fuzzy that I am sure no two people, and no two manifesto signers, understand any one of them identically’

(Gilb, 2005).

This fuzziness isn’t accidental—it’s structural. The manifesto was created by ‘far too many “coders at heart” who negotiated the Manifesto’ without

‘understanding of the notion of delivering measurable and useful stakeholder value’

(Gilb, 2005).

The result is a manifesto that sounds profound but provides no actionable guidance for success in product development.

Gilb’s critique exposes the manifesto’s fundamental flaw: it optimises for developer comfort rather than stakeholder value. The principles read like a programmer’s wish list—less documentation, more flexibility, fewer constraints—rather than a framework for delivering measurable results to people who actually need the software.

This explains why teams can religiously follow agile practices whilst consistently failing to deliver against folks’ needs. The manifesto’s principles are so vague that any team can claim to be following them whilst doing whatever they want. ‘Working software over comprehensive documentation’ means anything you want it to mean. ‘Responding to change over following a plan’ provides zero guidance on how to respond or what changes matter. (Cf. Quantification)

How do you measure success when the principles themselves are unmeasurable? What happens when everyone can be ‘agile’ whilst accomplishing nothing? How do you argue against a methodology that can’t be proven wrong?

The manifesto’s fuzziness enables the very dragons it claims to solve. Opinioneering thrives when principles are too vague to be proven wrong. Management parasitism flourishes when success metrics are unquantified Shared delusions multiply when ‘working software’ has no operational definition.

Gilb’s assessment reveals why the manifesto has persisted despite its irrelevance: it’s comfortable nonsense that threatens no one and demands nothing specific. Teams can feel enlightened whilst accomplishing nothing meaningful for stakeholders.

Stakeholder Value vs. All the Needs of All the Folks That Matter™

Gilb’s critique centres on ‘delivering measurable and useful stakeholder value’—but this phrase itself illuminates a deeper problem with how we think about software development success. ‘Stakeholder value’ sounds corporate and abstract, like something you’d find in a business school textbook or an MBA course (MBA – maybe best avoided – Mintzberg)

What we’re really talking about is simpler, less corporate and more human: serving all the needs of all the Folks That Matter™.

The Folks That Matter aren’t abstract ‘stakeholders’—they’re real people trying to get real things done:

The nurse trying to access patient records during a medical emergency
The small business owner trying to process payroll before Friday
The student trying to submit an assignment before the deadline
The elderly person trying to video call their grandchildren
The developer trying to understand why the build is broken again

When software fails these people, it doesn’t matter how perfectly agile your process was. When the nurse can’t access records, your retrospectives are irrelevant. When the payroll system crashes, your customer collaboration techniques are meaningless. When the build and smoke takes 30+ minutes, your adaptive planning is useless.

The Agile Manifesto’s developer-centric worldview treats these people as distant abstractions—’users’ and ‘customers’ and ‘stakeholders.’ But they’re not abstractions. They’re the Folks That Matter™, and their needs are the only reason software development exists.

The manifesto’s principles consistently prioritise developer preferences over the requirements of the Folks That Matter™. ‘Working software over comprehensive documentation’ sounds reasonable until the Folks That Matter™ require understanding of how to use the software. ‘Individuals and interactions over processes and tools’ sounds collaborative until the Folks That Matter™ require consistent, reliable results from those interactions.

This isn’t about being anti-developer—it’s about recognising that serving the Folks That Matter™ is the entire point. The manifesto has it backwards: instead of asking ‘How do we make development more comfortable for developers?’ we might ask ‘How do we reliably serve all the requirements of all the Folks That Matter™?’ That question changes everything. It makes motivation obvious—you’re solving real problems for real people. It makes relationship health essential—toxic teams can’t serve others effectively. It makes reality contact mandatory—delusions about quality hurt real people. It makes evidence-based decisions critical—opinions don’t serve the Folks That Matter™; results do.

Most importantly, it makes management’s value proposition clear: Do you help us serve the Folks That Matter™ better, or do you get in the way? If the answer is ‘get in the way,’ then management becomes obviously a dysfunction.

What Actually Addresses the Dragons

If we want to improve software development effectiveness, we address the real dragons:

Address Motivation: Create work that people actually care about. Give developers autonomy, mastery, and purpose. Match people to problems they find meaningful. Make contributions visible and valued.

Heal Toxic Relationships: Build psychological safety where people can be vulnerable about mistakes. Address ego and status games directly. Create systems where helping others succeed feels like personal victory.

Resolve Shared Delusions: Implement feedback loops that invite contact with reality. Measure what actually matters. Create cultures where surfacing uncomfortable truths is rewarded rather than punished.

Transform Management Entirely: Experiment with self-organising teams. Distribute decision-making authority to where expertise actually lives. Eliminate layers between problems and problem-solvers. Measure needs met, not management theatre.

Counter Evidence-Free Beliefs: Institute a culture where strong opinions require strong evidence. Enable and encourage teams to articulate the assumptions behind their practices. Reward changing your mind based on new data. Excise confident ignorance.

These aren’t process improvements or methodology tweaks—they’re organisational transformation efforts that require fundamentally different approaches than the manifesto suggests.

Beyond Agile: Addressing the Real Problems

The future of software development effectiveness isn’t in better sprint planning or more customer feedback. It’s in organisational structures that:

Align individual motivation with real needs
Create relationships based on trust
Enable contact with reality at every level
Eliminate management as dysfunctional
Ground all beliefs in sufficient evidence

These are the 10x improvements hiding in plain sight—not in our next retrospective, but in our next conversation about why people don’t care about their work. Not in our customer collaboration techniques, but in questioning whether we have managers at all. Not in our planning processes, but in demanding evidence for every strong opinion.

Conclusion: The Problems We Were Addressing All Along

The Agile Manifesto succeeded in solving the surface developer bugbears of 2001: heavyweight processes and excessive documentation. But it completely missed the deeper organisational and human issues that determine whether software development succeeds or fails.

The manifesto’s principles aren’t wrong—they’re just irrelevant to the real challenges. Whilst we’ve been perfecting our agile practices, the dragons of motivation, relationships, shared delusions, management being dysfunctional, and opinioneering have been systematically destroying software development from within.

Is it time to stop optimising team ceremonies and start addressing the real problems? Creating organisations where people are motivated to do great work, relationships enable rather than sabotage collaboration, shared assumptions are grounded in reality, traditional management no longer exists, and beliefs are proportioned to evidence.

But ask yourself: Does your organisation address any of these fundamental issues? Are you optimising ceremonies whilst your dragons run wild? What would happen if you stopped rearranging deck chairs and started questioning why people don’t care about their work?

Because no amount of process optimisation will save a team where people don’t care, can’t trust each other, believe comfortable lies, are managed by people who add negative value, and make decisions based on opinions rather than evidence.

The dragons are real, and they’re winning. Are we finally ready to address them?

Praising the CRC Card

September 14, 2025

Article, Product development, Software development, Thinking tools

Leave a comment

Praising the CRC Card

For the developers who never got to hold one

If you started your career after 2010, you probably never encountered a CRC card. If you’re a seasoned developer who came up through Rails tutorials, React bootcamps, or cloud-native microservices, you likely went straight from user stories to code without stopping at index cards. This isn’t your fault. By the time you arrived, the industry had already moved on.

But something was lost in that transition, and it might be valuable for you to experience it.

What You Missed

A CRC card is exactly what it sounds like: a Class-Responsibility-Collaborator design written on a physical index card. One class per card. The class name at the top, its responsibilities listed on the left, and the other classes it works with noted on the right. Simple. Physical. Throwaway.

The technique was developed by Ward Cunningham and Kent Beck in the late 1980s, originally emerging from Cunningham’s work with HyperCard documentation systems. They introduced CRC cards as a teaching tool, but the approach was embraced by practitioners following ideas like Peter Coad’s object-oriented analysis, design, and programming (OOA/D/P) framework. Peter Coad (with Ed Yourdon) wrote about a unified approach to building software that matched how humans naturally think about problems. CRC cards are a tool for translating business domain concepts directly into software design, without getting lost in technical abstractions.

The magic wasn’t in the format—it was in what the format forced you to do.

The Experience

Picture this: You and your teammates sitting around a conference table covered in index cards. Someone suggests a new class. They grab a blank card and write ‘ShoppingCart’ at the top. ‘What should it do?’ someone asks. ‘Add items, remove items, calculate totals, apply promotions,’ comes the reply. Those go in the responsibilities column. ‘What does it need to work with?’ Another pause. ‘It needs Product objects to know what’s being added, a Customer for personalised pricing, maybe a Promotion when discounts apply.’ Those become collaborators.

But here’s where it gets interesting. The card is small. Really small. If you’re writing tiny text to fit more responsibilities, someone notices. If you have fifteen collaborators, the card looks messy. The physical constraint was a design constraint. It whispered: ‘Keep it simple.’

Aside: In Javelin, we also advise keeping all methods to no more than “Five Lines of Code”. And Statements of Purpose to 25 words or less.

The Seduction

Somewhere in the 2000s, we got seduced. UML tools (yak) promised prettier diagrams. Digital whiteboards now offer infinite canvas space. Collaborative software lets us design asynchronously across time zones. We can version control our designs! Track changes! Generate code from diagrams!

We told ourselves this was progress. We retrofitted justifications: ‘Modern systems are too complex for index cards.’ ‘Remote teams need digital tools.’ ‘Physical methods don’t scale.’

But these were lame excuses, not good reasons.

The truth is simpler and more embarrassing: we abandoned CRC cards because they felt primitive. Index cards seemed amateur next to sophisticated UML tools and enterprise architecture platforms. We confused the sophistication of our tools with the sophistication of our thinking.

What We Actually Lost

The constraint was the feature. An index card can’t hold a God class. It can’t accommodate a class with dozens of responsibilities or collaborators. But more importantly, it forced you to think in domain terms, not implementation terms. When you’re limited to an index card, you can’t hide behind technical abstractions like ‘DataProcessor’ or ‘ValidationManager.’ You have to name things that represent actual concepts in the problem domain – things a business person would recognise. The physical limitation forced good design decisions and domain-focused thinking before you had time to rationalise technical complexity.

Throwaway thinking was powerful. When your design lived on index cards, you could literally throw it away and start over. No one was attached to the beautiful diagram they’d spent hours or days perfecting. The design was disposable, which made experimentation safe.

Tactile collaboration was different. There’s something unique about physically moving cards around a table, stacking them, pointing at them, sliding one toward a teammate. Digital tools simulate this poorly. Clicking and dragging isn’t the same as picking up a card and handing it to someone.

Forced focus was valuable. You couldn’t switch to Slack during a CRC card session. You couldn’t zoom in on implementation details. The cards kept you at the right level of abstraction—not so high that you were hand-waving, not so low that you were bikeshedding variable names.

The Ratchet Effect

Here’s what makes this particularly tragic: once the industry moved to digital tools, it became genuinely harder to go back. Try suggesting index cards in a design meeting today. You’ll get polite smiles and concerned looks. Not because the method doesn’t work, but because the ecosystem has moved backwards. The new developers have never seen it done. The tooling assumes digital. The ‘best practices’ articles all recommend software solutions.

We created a ratchet effect where good practices became impossible to maintain not because they were inadequate, but because they felt outdated.

For Those Who Never Got the Chance

If you’re reading this as a developer who never used CRC cards, I want you to know: you were cheated, but not by your own choices. You came into an industry that had already forgotten one of its own most useful practices. You learned the tools that were available when you arrived.

But you also inherited the complexity that came from abandoning constraints. You’ve probably spent hours in architecture meetings where the design sprawled across infinite digital canvases, where classes accumulated responsibilities because the tools could accommodate any amount of complexity, where the ease of adding ‘just one more connection’ led to systems that no one fully understood.

You’ve felt the pain of what we lost when we abandoned the constraint.

A Small Experiment

Next time you’re designing something new, try this: grab some actual index cards. Write one class per card. See how it feels when the physical constraint pushes back against your design. Notice what happens when throwing away a card costs nothing but keeping a complex design visible costs table space.

You might discover something we lost when we got sophisticated.

Do it because CRC cards were actually superior to modern digital tools for early design thinking. We didn’t outgrow them – we abandoned something better for something shinier.

Sometimes the simpler tool was better precisely because it was simpler.

The industry moves fast, and not everything we leave behind should have been abandoned. Some tools die not because they’re inadequate, but because they’re unfashionable. The CRC card was a casualty of progress that wasn’t progressive.

Secrets of Techhood

September 8, 2025

Actionable Insights, Article, Product development, Software development

Leave a comment

Secrets of Techhood

A collection of hard-won wisdom from the trenches of technology work

After decades building software, leading teams, and watching organisations succeed and fail, certain patterns emerge. The same mistakes get repeated. The same insights get rediscovered. The same hard-learned lessons get forgotten and relearnt by the next generation.

This collection captures those recurring truths—the kind of wisdom that comes from doing the work, making the mistakes, and living with the consequences. These aren’t theoretical principles from academic papers or management books. They’re the practical insights that emerge when life meets reality, when teams face real deadlines, and when software encounters actual users.

The insights come from diverse sources: legendary systems thinkers like W.E. Deming and Russell Ackoff, software pioneers, quality experts, organisational psychologists, and practising technologists who’ve shared their hard-earned wisdom. What unites them is practical relevance—each aphorism addresses real challenges that technology professionals face daily.

Use this collection as a reference, not a rulebook. Read through it occasionally. Return to specific aphorisms when facing related challenges. Share relevant insights with colleagues wrestling with similar problems. Most importantly, remember that wisdom without application is just interesting trivia.

The technology changes constantly, but the fundamental challenges of building systems, working with people, and delivering value remain remarkably consistent. These truths transcend programming languages, frameworks, and methodologies. They’re about the deeper patterns of how good technology work gets done.

Invitarion: I’d love for readers to suggest their own aphorisms for inclusion in this collection. Please use the comments, below.

The Aphorisms

It’s called software for a reason.

#SOFT

The ‘soft’ in software reflects its fundamental nature as something malleable, changeable, and adaptive. Unlike hardware, which is fixed once manufactured, software exists to be modified, updated, and evolved. This flexibility is both its greatest strength and its greatest challenge. The ability to change software easily leads to constant tweaking, feature creep, and the temptation to fix everything immediately. Yet this same flexibility allows software to grow with changing needs, adapt to new requirements, and evolve beyond its original purpose.

Learning hasn’t happened until behaviour has changed.

#BEHAVIOR_CHANGE

Consuming tutorials, reading documentation, and attending conferences is information absorption. True learning in tech occurs when concepts become internalised so deeply that they alter how problems are approached. Data analysis learning is complete when questioning data quality and looking for outliers becomes instinctive. Project management mastery emerges when breaking large problems into smaller, manageable pieces happens automatically.

Change hasn’t happened unless we feel uncomfortable.

#UNCOMFORTABLE

Real change, whether learning a new technology, adopting different processes, or transforming how teams work, requires stepping outside comfort zones. If a supposed change feels easy and natural, you’re just doing familiar things with new labels. Genuine transformation creates tension between old habits and new ways of working.

The work you create today is a letter to your future self—create with compassion.

#FUTURE_SELF

Six months later, returning to a project with fresh eyes and foggy memory is jarring. The folder structure that seems obvious today becomes a confusing maze tomorrow. The clever workflow that feels brilliant now frustrates that future self. Creating work as if explaining thought processes to a colleague makes sense—because that’s what’s happening across time.

Documentation is love made visible.

#VISIBLE_LOVE

Good documentation serves as an act of kindness towards everyone who will interact with the work, including one’s future self. It bridges current understanding and future confusion. When processes are documented, decisions explained, or clear instructions written, there’s an implicit message: ‘I care about your experience with this work.’ Documentation transforms personal knowledge into shared resources.

Perfect is the enemy of shipped, and also the enemy of good enough.

#SHIP_IT

The pursuit of perfection creates endless cycles of refinement that prevent delivery of value. Hours spent polishing presentations that already communicate effectively could address new problems or serve unmet needs. Yet shipping imperfection carries risks too—reputation damage, user frustration, or technical debt. Sometimes ‘done’ creates more value than ‘perfect’, especially when perfect never arrives.

Every problem is a feature request from reality.

#REALITY_REQUEST

Issues reveal themselves as more than annoying interruptions—they’re signals about unconsidered edge cases, incorrect assumptions, or untested scenarios. Each problem illuminates gaps between mental models of how things work and how they actually work in practice. When users struggle with an interface, they’ve submitted an unspoken feature request for better design.

The best problem-solving tool is a good night’s sleep.

#SLEEP_SOLVE

The brain processes and consolidates information during sleep, revealing solutions that remained hidden during conscious effort. Challenges that consume hours of focused attention resolve themselves in minutes after proper rest. Sleep deprivation clouds judgement, reduces pattern recognition, and obscures obvious solutions.

Premature optimisation is the root of all evil, but so is premature pessimisation.

#BOTH_EVILS

Whilst rushing to optimise before understanding the real bottlenecks is wasteful, it’s equally dangerous to create obviously inefficient processes under the banner of ‘we’ll fix it later.’ Don’t spend days perfecting workflows that run once, but also don’t use manual processes when simple automation would work just as well.

Your first solution is rarely your best solution, but it’s always better than no solution.

#FIRST_BEATS_BEST

The pressure to find the perfect approach immediately creates analysis paralysis. First attempts prove naïve, inefficient, or overly complex, yet they provide crucial starting points for understanding problem spaces. Working solutions enable iteration, refinement, and improvement.

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work.

#GALLS_LAW

John Gall’s Law captures a fundamental truth about how robust systems come into being. They aren’t architected in their final form—they grow organically from working foundations. The most successful large systems started as simple, functional prototypes that were gradually extended.

The hardest parts of tech work are naming things, managing dependencies, and timing coordination.

#THREE_HARDS

These three fundamental challenges plague every technology professional daily. Naming things well requires understanding not just what something does, but how it fits into the larger system and how others will think about it. Managing dependencies is difficult because it requires reasoning about relationships, priorities, and changes across multiple systems or teams.

Feedback is not personal criticism—it’s collaborative improvement.

#COLLABORATIVE_FEEDBACK

When colleagues suggest changes to work, they’re investing their time and attention in making the outcome better. They’re sharing their knowledge, preventing future issues, and helping with professional growth. Good feedback is an act of collaboration, not criticism.

People will forgive not meeting their needs immediately, but not ignoring them.

#ATTEND_NEEDS

Users, stakeholders, and colleagues understand that resources are limited and solutions take time. They accept that their need might not be the highest priority or that the perfect solution requires careful consideration. What damages relationships is complete neglect—not making any effort, not showing any care, not demonstrating that their concern matters. People can wait for solutions when they see genuine attention being paid to their situation. The difference between delayed action and wilful neglect determines whether trust grows or erodes. Attending to needs doesn’t require immediate solutions, but it does require genuine care and effort.

How you pay attention matters more than what you pay attention to.

#ATTENTIATIONAL_FEEDBACK

The quality of attention transforms both the observer and the observed. Distracted attention whilst multitasking sends a clear message about priorities and respect. Focused, present attention—even for brief moments—creates connection and understanding. When reviewing code, listening with genuine curiosity rather than hunting for faults leads to better discussions and learning. When meeting with stakeholders, being fully present rather than mentally composing responses changes the entire dynamic. The manner of attention—rushed or patient, judgmental or curious, distracted or focused—shapes outcomes more than the subject receiving that attention.

Caring attention helps things grow.

#CARING_GROWTH

Systems, teams, and individuals flourish under thoughtful observation and nurturing focus. When attention comes with genuine care—wanting to understand, support, and improve rather than judge or control—it creates conditions for development. Code improves faster when reviewed with constructive intent rather than fault-finding. Team members develop more rapidly when mistakes are examined with curiosity rather than blame. Projects evolve more successfully when monitored with supportive interest rather than suspicious oversight. The difference between surveillance and stewardship lies in the intent behind the attention.

The best work is work you don’t have to do.

#NO_WORK

Every process created needs to be maintained, updated, and explained. Before building something from scratch, considering whether an existing tool, service, or approach already solves the problem pays off. The work not done can’t break, doesn’t need updates, and never becomes technical debt.

Every expert was once a beginner who refused to give up.

#REFUSE_QUIT

Experience and expertise aren’t innate talents—they’re the result of persistence through challenges, failures, and frustrations. The senior professionals admired today weren’t born knowing best practices or troubleshooting techniques. They got there by continuing to learn, experiment, and problem-solve even when things felt impossibly difficult.

Your ego is not your work.

#EGO_WORK

When others critique work, they engage with output rather than character. Suggestions for improvement, identified issues, or questioned decisions focus on the work itself, not personal worth. Work can be improved, revised, or completely replaced without diminishing professional value.

Testing is not about proving a solution works—it’s about showing where the work is at.

#STATUS_REPORT

Good testing reveals current status rather than validating perfection. Tests illuminate what’s functioning, what’s broken, what’s missing, and what’s uncertain. Rather than serving as a stamp of approval, testing provides visibility into the actual state of systems, processes, or solutions.

The most expensive work to maintain is work that almost functions.

#ALMOST_BROKEN

Work that fails obviously and consistently is easy to diagnose and fix. Work that functions most of the time but fails unpredictably is a maintenance nightmare. These intermittent issues are hard to reproduce, difficult to diagnose, and mask deeper systematic problems.

Changing things without understanding them is just rearranging the furniture.

#FURNITURE_MOVE

When modifying systems, processes, or designs without adequate understanding of how they currently work, there’s no way to verify that essential functionality has been preserved. Understanding serves as a foundation for meaningful change, giving confidence that modifications improve things rather than just moving problems around.

Version control is time travel for the cautious.

#TIME_TRAVEL

Document management systems and change tracking tools let experimentation happen boldly because previous states can always be restored if things go wrong. They remove the fear of making changes because nothing is ever truly lost. Radical reorganisations, experimental approaches, or risky optimisations become possible knowing that reversion to the last known good state remains an option.

Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.

#CONWAYS_LAW

Conway’s Law reveals why so many software architectures mirror the org charts of the companies that built them. If you have separate teams for frontend, backend, and database work, you’ll end up with a system that reflects those boundaries—even when a different architecture would serve users better.

Question your assumptions before you question your code.

#ASSUMPTIONS_FIRST

Most problems stem not from implementation errors but from incorrect assumptions about how systems work, what users will do, or how data will behave. Assumptions about network reliability, that users will provide valid input, that third-party services will always respond, or that files will always exist where expected become embedded in work as implicit requirements that aren’t tested or documented.

The problem is always in the last place you look because you stop looking after you find it.

#LAST_PLACE

This humorous observation about troubleshooting reflects a deeper truth about problem-solving methodology. Issues are searched for in order of assumptions about likelihood, starting with the most obvious causes. When problems are found, searching naturally stops, making it definitionally the ‘last’ place looked.

Your production environment is not your testing environment, no matter how much you pretend it is.

#PROD_NOT_TEST

Despite best intentions, many teams end up using live systems as their primary testing ground through ‘quick updates,’ ‘minor changes,’ and ‘simple fixes.’ Production environments have different data, different usage patterns, different dependencies, and different failure modes than development or testing environments.

Every ‘temporary solution’ becomes a permanent fixture.

#TEMP_PERMANENT

What starts as a quick workaround becomes enshrined as permanent process. The ‘temporary fix’ implemented under deadline pressure becomes the foundation that other work builds upon. Before long, quick hacks become load-bearing infrastructure that’s too risky to change.

The work that breaks at the worst moment is always the work you trusted most.

#TRUSTED_BREAKS

Murphy’s Law applies strongly to technology work. The elegant, well-tested system that generates pride will find a way to fail spectacularly at the worst possible moment. Meanwhile, the hacky workaround that needed fixing will run flawlessly for years. Confidence leads to complacency, which creates blind spots where unexpected failures hide.

Always double-check the obvious.

#DOUBLE_CHECK

Paranoia is a virtue in technology work. Even when certain about how a system works, validating assumptions, checking inputs, and considering edge cases remains worthwhile. Systems change, dependencies update, and assumptions that were true yesterday are not true today.

Notes are not apologies for messy work—they’re explanations for necessary complexity.

#EXPLAIN_COMPLEXITY

Good documentation doesn’t explain what the work does but why it does it. It explains business logic, documents assumptions, clarifies non-obvious decisions, and provides context that can’t be expressed in the work itself. Notes that say ‘process these files’ are useless, but notes that say ‘Account for timezone differences in date processing’ add valuable context.

The fastest process is the process that never runs.

#NEVER_RUN

Performance optimisation focuses on making existing processes run faster, but the biggest efficiency gains come from avoiding work entirely. Can expensive calculations be cached? Can results be precomputed? Can unnecessary steps be eliminated? The most elegant solution is recognising that certain processes don’t need to execute at all under common conditions.

The systems that people work in account for 95 per cent of performance.

#DEMING_95

W.E. Deming’s insight: Most of what we attribute to individual talent or effort is determined by the environment, processes, and systems within which people operate. If the vast majority of performance comes from the system, then improving the system yields far greater returns than trying to improve individuals within a flawed system.

Individual talent is the 5 per cent that operates within the 95 per cent that is system.

#DEMING_5

Deming’s ratio explains why hiring ‘rock stars’ to fix broken systems fails, whilst putting competent people in well-designed systems consistently produces exceptional results. A brilliant programmer in a dysfunctional organisation will struggle, whilst an average programmer in a good system can accomplish remarkable things. The 5% individual contribution becomes meaningful only when the 95% system component enables and amplifies it.

Unless you change the way you think, your system will not change and therefore, its performance won’t change either.

#CHANGE_THINKING

John Seddon’s insight cuts to the heart of why so many improvement initiatives fail. Teams implement new processes, adopt new tools, or reorganise structures whilst maintaining the same underlying assumptions and beliefs that created the original problems. Real change requires examining and challenging the mental models, assumptions, and beliefs that shape how work gets designed and executed.

People are not our greatest asset—it’s the relationships between people that are our greatest asset.

#RELATIONSHIPS

Individual talent matters, but the connections, communication patterns, and collaborative dynamics between team members determine success more than any single person’s capabilities. The most effective teams aren’t composed of the most talented individuals, but of people who work well together and amplify each other’s strengths.

A bad system will beat a good person every time.

#BAD_SYSTEM

Individual competence and good intentions can’t overcome fundamentally flawed processes or organisational structures. When systems create conflicting incentives, unclear expectations, or impossible constraints, even capable people struggle to succeed. Good people in bad systems become frustrated, whilst average people in good systems accomplish remarkable things.

You can’t inspect quality in—it has to be built in.

#BUILD_IN

Quality comes from improvement of the production process, not from inspection. Good systems prevent defects rather than just catching them. The most effective quality assurance focuses on improving how work gets done, not on finding problems after they occur.

The righter we do the wrong thing, the wronger we become. Therefore, it is better to do the right thing wrong than the wrong thing right.

#ACKOFF_WRONG

Russell Ackoff’s insight highlights that effectiveness (doing the right things) must come before efficiency (doing things right). Becoming more efficient at the wrong activities compounds the problem. Focus first on whether you should be doing something before worrying about how well you do it.

Efficiency is doing things right; effectiveness is doing the right things.

#DRUCKER_DISTINCTION

Peter Drucker’s classic distinction reminds us that there’s little value in optimising processes that shouldn’t exist in the first place. The greatest risk for managers is the confusion between effectiveness and efficiency. There is nothing quite so useless as doing with great efficiency what should not be done at all.

The constraint determines the pace of the entire system.

#CONSTRAINT

In any process or organisation, one bottleneck limits overall performance regardless of how fast other parts operate. Optimising non-constraint areas looks productive but doesn’t improve system output. Finding and focusing improvement efforts on the true constraints provides the greatest leverage for overall performance gains.

Innovation always demands we change the rules.

#CHANGE_RULES

When we adopt new approaches that diminish limitations, we must also change the rules that were created to work around those old limitations. Otherwise, we get no benefits from our innovations. As long as we obey the old rules—the rules we originally invented to bypass the limitations of the old system—we continue to behave as if the old limitations still exist.

In God we trust; all others bring data.

#TRUST_DATA

Decisions improve when based on evidence rather than assumptions, but data alone doesn’t guarantee good choices. Numbers mislead as easily as they illuminate, especially when they reflect measurement artefacts rather than underlying realities. Data provides a foundation for discussion and decision-making, but wisdom comes from interpreting that data within context.

Every bug you ship becomes ten support tickets.

#FAILURE_DEMAND

John Seddon’s ‘failure demand’ reveals how poor quality creates exponential work. When you don’t get something right the first time, you generate cascading demand: customer complaints, support calls, bug reports, patches, and rework. It’s always more expensive to fix things after customers find them than to prevent problems in the first place.

Technical debt is like financial debt—a little helps you move fast, but compound interest will kill you.

#TECH_DEBT

Strategic shortcuts can accelerate delivery when managed carefully. Taking on some technical debt to meet a critical deadline or test market assumptions is valuable. But unmanaged technical debt accumulates interest through increased maintenance costs, slower feature development, and system brittleness.

The best code is no code at all.

#NO_CODE

Every line of code written creates obligations—debugging, maintenance, documentation, and ongoing support. Before building something new, the most valuable question is whether the problem needs solving at all, or whether existing solutions already address the need adequately. Code that doesn’t exist can’t have bugs, doesn’t require updates, and never becomes technical debt.

Start without IT. The first design has to be manual.

#START_MANUAL

Before considering software-enabled automation, first come up with manual solutions using simple physical means, like pin-boards, T-cards and spreadsheets. This helps clarify what actually needs to be automated and ensures you understand the process before attempting to digitise it.

Simple can be harder than complex—you have to work hard to get your thinking clean.

#CLEAN_THINKING

Achieving simplicity requires understanding problems deeply enough to eliminate everything non-essential. Complexity masks incomplete understanding or unwillingness to make difficult choices about what matters most. Simple solutions demand rigorous thinking about core requirements, user needs, and essential functionality.

Design is how it works, not how it looks.

#FUNCTION_FORM

Visual aesthetics matter, but they serve the deeper purpose of supporting functionality and user experience. Good design makes complex systems feel intuitive, reduces cognitive load, and guides users towards successful outcomes. When appearance conflicts with usability, prioritising function over form creates better long-term value.

Saying no is more important than saying yes.

#SAY_NO

Focus emerges from deliberately choosing what not to do rather than just deciding what to pursue. Every opportunity accepted means other opportunities foregone, and attention is always limited. Organisations that try to do everything accomplish nothing well. Strategic success comes from identifying the few things that matter most and declining everything else.

Organisational effectiveness = f(collective mindset).

#COLLECTIVE_MINDSET

The effectiveness of any organisation is determined by the shared assumptions, beliefs, and mental models of the people within it. Technical solutions, processes, and structures matter, but they’re all constrained by the underlying collective mindset that shapes how people think about and approach their work.

Technologists who dismiss psychology as ‘soft science’ are ignoring the hardest variables in their systems.

#HARD_VARIABLES

Technical professionals gravitate toward problems with clear inputs, logical processes, and predictable outputs. Psychology feels messy and unquantifiable by comparison. But the human elements—motivation, communication patterns, cognitive biases, team dynamics—determine whether technical solutions succeed or fail in practice.

Code review isn’t about finding bugs—it’s about sharing knowledge.

#KNOWLEDGE_SHARE

Whilst catching defects has value, the real benefit of code reviews lies in knowledge transfer, spreading understanding of the codebase, sharing different approaches to solving problems, and maintaining consistency in coding standards. Good reviews help prevent knowledge silos and mentor junior developers.

All estimates are wrong. Some are useful.

#USEFUL_WRONG

Software estimates are educated guesses based on current understanding, not commitments or predictions. They’re useful for planning, prioritising, and making resource allocation decisions, but they shouldn’t be treated as contracts or promises. Use them as tools for discussion and planning, and remember that their primary value is in helping make better decisions.

Security is not a feature you add—it’s a discipline you practise.

#SECURITY_DISCIPLINE

Security can’t be bolted on after the fact through penetration testing or security audits alone. It must be considered throughout design, development, and deployment. Security is about creating systems that are resistant to attack by design, not just finding and fixing vulnerabilities after they’re built.

Your users will break your software in ways you never imagined—and they’re doing you a favour.

#USERS_FAVOUR

Real users in real environments expose edge cases, assumptions, and failure modes that controlled testing misses. They use your software in contexts you never considered, with data you never anticipated, and in combinations you never tested. Each break reveals gaps in your mental model of how the system should work.

Refactor before you need to, not when you have to.

#REFACTOR_EARLY

Continuous small refactoring prevents code from becoming unmaintainable. When you’re forced to refactor, you’re already behind and under pressure, which leads to rushed decisions and compromised quality. Build refactoring into your regular development rhythm, not as crisis response.

If you can’t measure it breaking, you can’t fix it reliably.

#MEASURE_BREAK

Systems need observable failure modes through monitoring, logging, and alerting. Without visibility into system health and failure patterns, you’re debugging blindly and fixing symptoms rather than root causes. Good monitoring tells you not just that something broke, but why it broke and how to prevent it from happening again.

Knowledge sharing is not cheating—it’s collaborative intelligence.

#COLLABORATIVE_INTEL

Technology work has always been collaborative, and online communities represent the democratisation of knowledge sharing. Looking up solutions to common problems isn’t cheating—it’s efficient use of collective wisdom. The key is understanding the solutions found rather than blindly copying them.

Error messages are breadcrumbs, not accusations.

#BREADCRUMBS

Error messages aren’t personal attacks on competence—they’re valuable clues about what went wrong and how to fix it. Good error messages tell a story about what the system expected versus what it encountered. Learning to read error messages carefully and use troubleshooting data effectively is a crucial skill.

Collaboration is not about sharing tasks—it’s about sharing knowledge.

#SHARE_KNOWLEDGE

The value of collaborative work isn’t in the mechanical division of labour—it’s in the knowledge transfer, real-time feedback, and shared problem-solving that occurs. When professionals collaborate effectively, they share different perspectives, catch each other’s mistakes, and learn from each other’s approaches.

The most important skill in technology is knowing when to start over.

#START_OVER

Abandoning problematic systems or processes and starting fresh proves more efficient than continuing to patch existing work. When complexity accumulates beyond economical improvement, when foundational assumptions prove flawed, or when requirements shift dramatically, fresh starts offer better paths forward.

Remember: Every expert was once a disaster who kept learning.

How We Broke 40 Million Developers: An Agile Pioneer’s Lament

September 7, 2025

Agile, Agility at Scale, Antimatter principle, Article, Product development, Software development

2 Comments

How We Broke 40 Million Developers: An Agile Pioneer’s Lament

I weep endless tears for all the folks who have poured so much into such a fruitless pursuit.

Here’s the cruelest irony of our industry: developers become developers because they want to make a difference. They want to solve problems that matter. They want to build things that change how people work and live. They’re drawn to the craft because it has power—real power to transform the world.

And then we gave them Agile.

After 53 years in software development—including working on the practices that became Agile back in 1994—I’ve watched multiple generations of brilliant people get their desire for impact redirected into perfecting processes that make no measurable difference whatsoever.

The Numbers Are Staggering

There are something like 30-45 million software developers worldwide today. Around 90% of them claim to practise Agile in some form. That’s 40 million people who wanted to change the world, now spending their days in fruitless stand-ups and retrospectives.

Forty million brilliant minds. All trying to make an impact. All following processes that prevent them from making any impact at all.

What They Actually Do All Day

Instead of solving hard problems, they estimate story points. Instead of designing elegant systems, they break everything into two-week chunks. Instead of thinking deeply about what users actually need, they manage backlogs of features nobody asked for.

They spend hours in planning meetings for work that gets thrown away. They refine processes that don’t improve outcomes. They attend retrospectives where teams discuss why nothing meaningful changed, then agree to keep doing the same things.

The very people who could advance computing spend their time perfecting ceremonies that have made zero measurable difference to software quality after 23 years of widespread use.

The Evidence of Irrelevance

Here’s what’s particularly damning: every study claiming Agile ‘works’ only compares it to ‘Waterfall’, not to how software was actually built before these formal processes took over. Before the 1990s, most software was built without elaborate frameworks—programmers talked to users, wrote code, fixed bugs, and shipped products.

But here’s the deeper issue: better software was never the aim. The actual aim was better attending to folks’ needs. So measuring software quality improvements misses the point entirely.

Yet after more than 20 years of Agile domination, are we better at attending to people’s needs? Are users getting products and services that genuinely serve them better? Are the real human needs being attended to more effectively?

The evidence suggests not. We have more process, more ceremony, more optimisation of team interactions—but the fundamental disconnect between what people actually need and what gets built remains as wide as ever. The 40 million brilliant minds who wanted to change the world continue to optimise ceremonies instead of deeply understanding and addressing human needs.

The Tragic Waste

Here’s what we lost whilst those 40 million minds were occupied with process optimisation:

The programming languages that were never designed because their potential creators were facilitating stand-ups. The development tools that could have revolutionised productivity? Never built—the inventor was learning story estimation. The elegant solutions to complex problems? Still undiscovered because brilliant minds were busy optimising team velocity.

But to what end? Technical advances matter only insofar as they help us better attend to people’s actual needs. The real tragedy isn’t just losing computational breakthroughs—it’s losing the connection between technical work and human purpose that would make those breakthroughs meaningful.

We’re not talking about progress for progress’s sake. We’re talking about decades of lost focus on using our technical capabilities to solve problems that actually matter to people’s lives.

Meet the Casualties

Sarah became a developer to solve climate change through better energy management software. After 12 years of Agile, she’d become expert at facilitating retrospectives and managing stakeholder expectations. But she’d never been allowed to work on a problem for more than two weeks. Everything she touched got decomposed into user stories before she could understand its true nature. She quit tech in 2020 to become a park ranger.

Marcus had a PhD in computer science and wanted to build compilers that could optimise code in revolutionary ways. His Agile organisation made him a Product Owner instead. He spent 8 years writing acceptance criteria for features whilst his deep technical knowledge gathered dust. When he finally returned to technical work, he discovered the field had advanced without him.

Jennifer tracked her Agile team’s outcomes for 15 years. Despite continuous process improvement, perfect ceremony execution, and high velocity scores, they delivered no better results than before adopting Agile. Fifteen years of expertise in something that made zero difference to anything that mattered.

These aren’t isolated cases. They represent millions of talented people whose desire to make an impact was redirected into elaborate rituals that impact nothing.

How the System Sustains Itself

Here’s how it works: Teams practise Agile because everyone says it works. When nothing improves, they assume they need to do Agile better, not question whether Agile itself works. Organisations invest millions in Agile coaching not because they measured its effectiveness, but because it’s following the herd.

The ceremonies are so time-consuming that they feel important. People spend so much energy perfecting their processes that the processes seem valuable. The effort becomes proof of worth, regardless of results.

Meanwhile, what actually makes software development successful—collaborative relationships, technical skill, good tools, clarity and focus on needs—gets pushed aside for optimisation that optimises nothing.

Every new developer entering the workforce gets dragged into this cul de sac immediately. The cycle continues.

The Accidental Monster

The tragedy is that this system emerged from the best of intentions. The original Agile Manifesto signatories were idealistic developers who saw real problems with heavy-handed project management. They genuinely wanted to help their fellow programmers escape documentation-heavy waterfall bureaucracy.

They couldn’t have predicted that their 68-word manifesto would spawn an industry worth billions—certification programmes, consulting empires, tool vendors, conference circuits. They created principles meant to free developers, only to watch them become the foundation for new forms of ceremony and constraint.

There are no villains in this story. The Snowbird folks mostly persist. The consultants who built practices around Agile genuinely believed they were helping. Tool makers solved real problems. Managers adopted promising practices. Everyone acted rationally within their own context.

But individual rational choices collectively created something nobody intended: a system that wastes enormous human potential.

Who Actually Benefited

If Agile made no measurable difference to software outcomes, who benefited from its rise? The answer reveals how a well-intentioned movement became a self-perpetuating industry:

Certification organisations created entirely new revenue streams. With 1.5 million certified practitioners, even at modest fees, that’s hundreds of millions in certification revenue alone.

Tool vendors hit the jackpot. Atlassian’s JIRA, with 40% market share in project management tools, generated $4.3 billion in 2024 largely by making Agile workflows feel essential.

Consulting firms built entire practices around ‘Agile transformations’, charging millions for multi-year organisational changes. But here’s the key: consultants have little to no visibility into whether the software actually gets better. They measure entirely different things—their revenues, their career advancement, their recognition as transformation experts.

This explains everything. Consultants can genuinely believe they’re succeeding because they are succeeding at what they actually measure. They’re making money, building reputations, feeling important as change agents. Meanwhile, they’re completely insulated from the metrics that would reveal whether any of it improves software development outcomes.

New job categories emerged with substantial salaries—Scrum Masters averaging £100,000pa, Agile Coaches earning even more, all optimising processes that don’t improve the things they claim to optimise.

The system succeeded financially because it served multiple interests simultaneously whilst being almost impossible to disprove. When Agile ‘failed’, organisations needed more training, coaching, or better tools—not less Agile. And the people selling those solutions never had to confront whether the software actually got better.

What Developers Actually Want

Developers didn’t get into this field to facilitate meetings. They didn’t learn to code so they could estimate story points. They didn’t study computer science to manage backlogs.

They wanted to solve problems that matter to real people. They wanted to use their technical skills to make life better, easier, more meaningful for others. The elegance of the code mattered because it served human purposes. The efficiency of the system mattered because it helped people accomplish what they needed to do.

But Agile, for all its talk of ‘customer collaboration’, actually moved developers further away from understanding and serving genuine human needs. Instead of asking ‘How can I solve problems that matter to people?’ they learned to ask ‘How can I optimise our sprint velocity?’

The ceremonies didn’t just waste their technical talents—they broke the vital connection between technical work and human purpose. Forty million brilliant minds didn’t just lose the ability to advance computing—they lost sight of why advancing computing would matter in the first place.

That drive to serve others through code is still there. But Agile channelled it into perfecting processes that prevent developers from ever connecting deeply with the human problems their skills could solve.

The Path Back to Impact

For developers stuck in this system: Your talents aren’t wasted because you’re bad at Agile. They’re wasted because Agile wastes talent by diverting the connection between your technical skills and the human problems you wanted to solve. That drive you had to make a difference in people’s lives? It’s still valid. The problems you wanted to solve? They still need solving.

But they won’t be solved in sprint planning meetings. They won’t be solved by better retrospectives. They’ll be solved by reconnecting with the human purposes that drew you to development in the first place—using your skills to genuinely serve people’s needs.

For organisations: Stop measuring process adherence and start measuring actual human impact. Judge teams by how well they solve real problems for real people, not how they execute ceremonies. Invest in deep understanding of human needs instead of collaborative optimisation.

For the industry: The next breakthrough that truly matters won’t come from a perfectly facilitated stand-up. It’ll come from someone who deeply understands a human problem worth solving and has the time and space to pursue solutions that actually matter.

The Bitter Truth

Forty million people wanted to make a difference through software. We gave them a system that redirects their energy into processes that make no measurable difference. We took their passion for impact and channelled it into perfecting ceremonies that, after 23 years, still produce no meaningful improvement to software development outcomes.

The advances in computing that could have emerged from those minds—the tools, the techniques, the innovations that could have transformed how software works—we’ll never know what we missed. That potential is gone forever. And the future looks just as bleak.

But we can choose differently now. We can redirect talent towards work that actually matters. We can build systems based on human insight rather than consensus optimisation.

The question is whether we will.

You Won’t Believe What Was Holding This Company Back! And Then This Happened…

August 29, 2025

Actionable Insights, Article, Organisational Therapy, Product development, Productivity, Story

Leave a comment

You Won’t Believe What Was Holding This Company Back! And Then This Happened…

The surprising story of how a tech company doubled their productivity by changing something invisible—their shared assumptions about how work works (A true story)

When the CEO of a mid-sized software company looked at his development team’s performance metrics, he had every reason to be frustrated.

It was a software company that looked remarkable from the outside. Yet their productivity felt stuck in quicksand.

‘We were asking for a revolution in productivity’, the CEO would later reflect, ‘but we had no revolutionaries—and our assumptions were holding back even the possibility of revolutionary thinking.’

The Usual Suspects

Like most tech companies facing productivity challenges, this organisation had already tried the conventional playbook:

Agile methodologies? ✓ Implemented
Better project management tools? ✓ Upgraded
Optimisation initiatives? ✓ Refined
Performance metrics? ✓ Tracked religiously

Sound familiar? If you’re a leader in tech, you’ve checked off similar boxes. The tools and approaches were there. The talent was there. The strategy was clear.

So why wasn’t it working?

Enter the Unconventional Solution

That’s when the CEO made a decision that would have raised eyebrows in most boardrooms. Instead of hiring another expert or implementing another framework, he brought in someone who practised something called ‘Organisational Psychotherapy’.

Not organisational development. Not change management. Psychotherapy. For a company.

‘Many of us were both hopeful and sceptical’, admits the Director of Development. ‘Especially when we discovered we had to work to find our own answers.’

The Hidden Problem: Incompatible Worldviews

What this person discovered wasn’t about their code, their tools, or their approaches. It was about something far more fundamental yet completely invisible: the shared assumptions and beliefs that governed how people thought work should work.

When he mapped out how the organisation actually operated versus what they needed for success, the contrast was startling:

How They Were Operating:

Individual contributors working in isolation
Managers controlling the work and the workers
Each department focused only on their own metrics
Mandated ways of working imposed from above
Rules and policies governing behaviour
Only management’s needs really mattered
People brought only their ‘work face’ to the office

What They Actually Needed:

Teams working together collaboratively
Self-organisation around clear outcomes
Systemic measures serving the bigger picture
People owning how the work works
Trust as the operating principle
Everyone’s needs matter
People bringing their whole, authentic selves to work

These weren’t just different approaches—they were fundamentally incompatible worldviews. The transformation required shifting from one to the other.

The Transformation: New Shared Beliefs

The breakthrough wasn’t about changing what people did. It was about fundamentally shifting from one way of thinking to another.

With support from organisational psychotherapy, people began to surface and examine the beliefs that were unconsciously driving their behaviour. They discovered they’d been operating according to assumptions that directly contradicted what was needed for success.

The shift was gradual. People were hesitant about this approach, and some were even downright negative. But over time, as the fundamental assumptions and beliefs began to change—especially amongst senior management—they started trusting people instead of controlling them.

The Results: Extraordinary Performance

Over a six-month period, the development organisation experienced an extraordinary transformation:

Their development throughput increased by 80%.

To put this in perspective: Gerald Weinberg’s “Ten Percent Promise Law” from The Secrets of Consulting states “Never promise more than ten percent improvement,” knowing that anything more would be embarrassing if the consultant succeeded. Yet here was an organisation that had achieved an 8x improvement over that “safe” threshold—not by accident, but because their CEO had the foresight to try a radically different approach.

Projecting that improvement forward suggested an annualised productivity increase of 160%. In other words: they would have more than doubled their output in a single year.

This wasn’t achieved through:

Working longer hours
Adding more people
Implementing new tools

It came from them transforming their shared assumptions and beliefs that governed how people actually worked together—particularly at the leadership level.

The Critical Insight

In retrospect, these results were absolutely contingent on the changing of collective beliefs and assumptions—including those held by senior management.

The same people who had been underperforming suddenly became extraordinarily productive. What changed were the shared assumptions about ‘how we do things here’—including assumptions about which tools and approaches actually served them.

When people’s shared assumptions support their shared goals, extraordinary performance becomes possible.

The Lesson That Changes Everything

Most organisational change efforts focus on changing behaviours and structures. But behaviours are just the visible tip of the iceberg. Below the surface are the shared assumptions and beliefs that actually drive those behaviours.

These invisible agreements include beliefs about people—whether humans are naturally motivated and trustworthy (Theory Y) or need constant oversight and control (Theory X). They include assumptions about how authority should work—whether managers should own and control how work gets done, or whether the people doing the work should have that ownership. They encompass beliefs about what motivates people—whether fear, obligation, guilt and shame are effective motivators, or whether trust, autonomy and purpose work better.

Organisations also operate on hidden assumptions about learning—whether the organisation can and should adapt and evolve, or whether established ways should be preserved. They hold invisible beliefs about quality—whether it comes from prevention and building things right the first time, or from inspection and testing after the fact. Even beliefs about the nature of work itself—whether it should feel like obligation and drudgery, or whether it can be engaging and even playful.

These hidden beliefs are what determine whether any change initiative will stick or quietly fade away.

You can implement all the frameworks you want, but if people’s shared assumption is that ‘admitting you don’t know something is dangerous’, your retrospectives will be shallow and your learning will be slow.

What This Means for You

The invisible assumptions in your organisation are either your secret weapon or your hidden constraint. The question is: how do you even begin to surface beliefs that are, by definition, unconscious?

You can’t simply ask people to examine their own assumptions—that’s not how this kind of deep change works. Instead, it requires creating conditions where these hidden beliefs become visible through experience and observation.

The answers will surprise you. They will also reveal why certain initiatives never quite take hold, why some groups consistently outperform others, or why productivity improvements seem to hit invisible ceilings.

The Bottom Line

This company’s 80% productivity increase didn’t come from better tools or new methods. It came from gradually and collectively surfacing and reflecting on the shared assumptions that govern how people work together.

Everything is contingent on the invisible collective beliefs that manifest in your organisational culture.

Change the assumptions, and you change everything else. Leave them unexamined, and they’ll continue to invisibly limit what’s possible.

The revolution in productivity you’re looking for does not require new methods or technologies. It requires making the invisible visible, and growing into new shared beliefs that better serve your goals.

The Secret Career Advantage Most Developers Ignore

August 11, 2025

Action, Actionable Insights, Article, Careers, Drucker, Learning, Product development, Quintessence, Software development

Leave a comment

The Secret Career Advantage Most Developers Ignore

Why understanding foundational principles could be your biggest competitive edge

Whilst most developers chase the latest frameworks and cloud certifications, there’s a massive career opportunity hiding in plain sight: foundational knowledge that 90% of your peers will never touch.

The developers who understand systems thinking, team dynamics, and organisational behaviour don’t just write better code—they get promoted faster, lead more successful projects, and become indispensable to their organisations. Here’s why this knowledge is your secret weapon.

The Opportunity Gap Is Massive

Walk into any tech company and you’ll find dozens of developers who can implement complex algorithms or deploy microservices. But try to find someone who understands why projects fail, how teams actually work, or how to think systematically about performance bottlenecks. You’ll come up empty.

This creates an enormous opportunity. When everyone else is fighting over who knows React best, you can differentiate yourself by understanding why most React projects fail. Whilst others memorise API documentation, you can diagnose the organisational problems that actually slow teams down.

The knowledge gap is so wide that basic competency in these areas makes you look like a genius.

You’ll Solve the Right Problems

Most developers optimise locally—they’ll spend weeks making their code 10% faster whilst completely missing that the real bottleneck is a manual approval process that batches work for days. Understanding systems thinking (Deming, Goldratt, Ackoff) means you’ll focus on the constraints that actually matter.

I’ve watched developers become heroes simply by identifying that the ‘performance problem’ wasn’t in the database—it was in the workflow. Whilst everyone else was arguing about indices, they traced the real issue to organisational design. Guess who got the promotion?

When you understand flow, variation, and constraints, you don’t just fix symptoms—you solve root causes. This makes you dramatically more valuable than developers who can only optimise code.

You’ll Predict Project Outcomes

Read The Mythical Man-Month, Peopleware, and The Design of Everyday Things, and something magical happens: you develop pattern recognition for project failure. You’ll spot the warning signs months before they become disasters.

Whilst your peers are surprised when adding more developers makes the project slower, you’ll know why Brooks’ Law kicks in. When others are confused why the ‘obviously superior’ technical solution gets rejected, you’ll understand the human and organisational factors at play.

This predictive ability makes you invaluable for planning and risk management. CTOs love developers who can spot problems early instead of just reacting to crises.

You’ll Communicate Up the Stack

Most developers struggle to translate technical concerns into business language. They’ll say ‘the code is getting complex’ when they should say ‘our development velocity will decrease by 40% over the next six months without refactoring investment’.

Understanding how organisations work—Drucker’s insights on knowledge work, Conway’s Law, how incentive systems drive behaviour—gives you the vocabulary to communicate with executives. You’ll frame technical decisions in terms of business outcomes.

This communication ability is rocket fuel for career advancement. Developers who can bridge technical and business concerns become natural candidates for technical leadership roles.

You’ll Design Better Systems

Christopher Alexander’s Notes on the Synthesis of Form isn’t just about architecture—it’s about how complex systems emerge and evolve. Understanding these principles makes you better at software architecture, API design, and system design interviews.

You’ll build systems that work with human organisations instead of against them. You’ll design APIs that developers actually want to use. You’ll create architectures that can evolve over time instead of calcifying.

Whilst other developers create technically impressive systems that fail in practice, yours will succeed because they account for how humans and organisations actually behave.

You’ll Avoid Career-Limiting Mistakes

Reading Peopleware could save your career. Understanding that software problems are usually people problems means you won’t waste months on technical solutions to organisational issues. You won’t join dysfunctional teams thinking you can fix them with better code.

You’ll recognise toxic work environments early and avoid getting trapped in death-march projects. You’ll understand which technical initiatives are likely to succeed and which are doomed by organisational realities.

This knowledge acts like career insurance—you’ll make better decisions about which companies to join, which projects to take on, and which battles to fight.

The Learning Investment Pays Exponentially

Here’s the beautiful part: whilst everyone else is constantly relearning new frameworks, foundational knowledge compounds. Understanding team dynamics is just as valuable in 2025 as it was in 1985. Systems thinking principles apply regardless of whether you’re building web apps or AI systems.

Spend 40 hours reading Peopleware, The Mythical Man-Month, and learning about constraints theory, and you’ll use that knowledge for decades. Compare that to spending 40 hours learning the latest JavaScript framework that might be obsolete in two years.

The ROI on foundational knowledge is massive, but almost no one invests in it.

The Joy of True Mastery

There’s something else most developers miss: the intrinsic satisfaction of developing real mastery. Pink (2009) identified mastery as one of the core human motivators—the deep pleasure that comes from getting genuinely better at something meaningful.

Learning React hooks gives you a brief dopamine hit, but it’s shallow satisfaction. You’re not mastering anything fundamental—you’re just memorising another API that will change next year. There’s no lasting sense of growth or understanding.

But learning to think systematically about complex problems? Understanding how teams and organisations actually function? Grasping the deep principles behind why some software succeeds and others fail? That’s true mastery. It changes how you see everything.

You’ll find yourself analysing problems differently, spotting patterns everywhere, making connections between seemingly unrelated domains. The knowledge becomes part of how you think, not just what you know. This kind of learning is intrinsically rewarding in a way that framework tutorials never are.

How to Build This Advantage

Start with the classics:

The Mythical Man-Month – Brooks (1995)
Peopleware – DeMarco & Lister (2013)
The Design of Everyday Things – Norman (2013)
Notes on the Synthesis of Form – Alexander (1964)
The Goal – Goldratt & Cox (2004)
The Effective Executive – Drucker (2007)

Apply immediately:

Don’t just read—look for these patterns in your current work. Practise diagnosing organisational problems, identifying constraints, predicting project outcomes.

Share your insights:

This isn’t about positioning yourself or impressing managers—it’s about thinking aloud, finding likeminded peers, and building mental muscle memory. Writing and teaching helps to articulate fuzzy understanding into clear principles, which deepens your grasp of the material.

Write to clarify your own thinking. When you read about Conway’s Law, don’t just nod along—write about how you’ve seen it play out in your own teams. Trying to explain why your microservices architecture mirrors your organisational structure forces you to really understand the principle. The act of writing reveals gaps in your understanding and solidifies genuine insights.

Teach to expose what you don’t know. Explaining systems thinking to a colleague immediately shows you which parts you actually understand versus which parts you’ve just memorised. Teaching helps to develop intuitive explanations, real-world examples, and practical applications. You’ll often discover you understand concepts less well than you thought.

Build pattern recognition through articulation. Each time you write about a problem through the lens of Peopleware or analyse a workflow using Theory of Constraints, you’re training your brain to automatically apply these frameworks. Writing about the patterns makes them become more like second nature—mental muscle memory that kicks in when you encounter similar situations.

Create your own case studies. Document your experiences applying these principles. “How I used Goldratt’s Theory of Constraints to diagnose our deployment bottleneck” isn’t just content for others—it’s also cognitive practice. You’re building a library of patterns that your brain can reference automatically.

Think through problems publicly. Whether it’s a blog post, internal wiki, or even just detailed notes, working through organisational problems using foundational frameworks trains your mind to see systems, constraints, and human factors automatically. The more you practise applying these lenses, the more natural they become.

The goal is developing intuitive expertise—reaching the point where you automatically think about team dynamics when planning projects, or instinctively spot organisational dysfunction. This cognitive muscle memory is what separates developers who’ve read the books from those who’ve internalised the principles.

Connect the dots:

Use this knowledge to explain why projects succeed or fail. Make predictions. Build ability and credibility as someone who understands the bigger picture.

The Secret Is Out

The tragedy of developer education is that we’re taught to optimise for looking productive whilst systematically avoiding the knowledge that would make us actually productive. Organisations reward visible coding whilst discouraging the learning that would prevent project failures.

But this creates opportunity. Whilst everyone else chases the same technical skills, you can build knowledge that’s both more valuable and more durable.

The secret career advantage isn’t learning the latest framework—it’s understanding the timeless principles that determine whether software projects succeed or fail.

Most developers will never figure this out. But now you know.

Ready to build your secret advantage? Pick one foundational book, or even just a precis or summary, and start reading today. Your future self will thank you.

A Conversation About John Gall

August 9, 2025

Article, Product development, Software development, Systems thinking

Leave a comment

A Conversation About John Gall

Yesterday, I found myself in a fascinating conversation with a group of software developers who seemed genuinely troubled by something they’d recently encountered: the writings of John Gall. But troubled in the sense of disagreement—they weren’t convinced by his profound observations about complex systems. Their pushback was immediate and visceral, and it brought back memories of my own encounter with Gall’s ideas—and with the man himself.

I had the remarkable privilege of meeting John Gall at a Gilbfest some years ago, shortly before his passing. Speaking with him in person added layers to his written insights that I’m still unpacking.

Who Was John Gall?

John Gall was a paediatrician and leading systems theorist who wrote Systemantics in 1975 (later republished as The Systems Bible). Whilst not a technologist, his observations about how complex systems behave have proven remarkably prescient in our digital age. His most famous principle, known as Gall’s Law, states:

‘A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.’

Meeting the Man Behind the Ideas

What struck me most about meeting John Gall in person was how his demeanour perfectly embodied his systems thinking. He had the quiet calm of someone who had spent decades observing patterns others missed, combined with an almost mischievous delight in pointing out the gap between how we think systems should work and how they actually do.

In conversation, he was remarkably humble about his insights—which somehow made them more powerful. He didn’t present his observations as revolutionary discoveries but as simple truths that were hiding in plain sight. It was this quality that made his ideas so compelling and, I now realise, so disturbing to practitioners who encounter them.

There was something almost subversive about how he discussed complex systems. Not in a destructive way, but in the sense that he was gently undermining assumptions we didn’t even know we held. Talking with him felt like having someone point out that the emperor’s new clothes were, indeed, invisible—but doing so with such kindness that you couldn’t help but laugh at your own blindness.

Missing the Lineage

I’m hardly surprised that developers balk at John Gall’s insights. Developers seem woefully ignorant of antecedents—Deming, Ackoff, Goldratt, Seddon, Capers Jones, and others who spent decades studying how complex systems actually behave.

Gall wasn’t working in isolation. He was part of a tradition of people who looked at systems—manufacturing systems, organizational systems, quality systems—and noticed patterns. The software industry acts like it invented complexity, but these insights about how systems fail and succeed go back generations.

When you don’t know the lineage, Gall’s observations can seem like random provocations rather than hard-won wisdom about the nature of complex systems.

The Conversation

He was exactly what you’d expect from someone who spent decades watching systems behave in ways their creators never intended. Quietly amused. Not trying to convince anyone of anything. Just sharing what he’d noticed.

The developers had plenty of counterarguments. Successful complex designs. Modern tools that make planning work better. Their own experience building systems that succeeded because of careful architecture.

But then one of them started telling a story about a ‘temporary’ script that had become the backbone of their production system. Another mentioned the beautiful enterprise architecture that never quite worked as designed. A third talked about the quick prototype that somehow got scaled to millions of users.

We’ve all been there.

Gall wasn’t anti-planning or anti-design. He was just honest about what he observed. Complex systems that work have histories. They started somewhere simpler. They grew. They adapted. The ones designed as complete, complex systems from day one… well, there aren’t many success stories there. I can vouch.

Unix started simple. The web started simple. Git started with Linus Torvalds scratching an itch.

Even our engineering principles acknowledge this. KISS exists because complexity kills systems.

The developers weren’t wrong about their successes. But their successes might tell a different story than they think. What if their well-planned complex systems succeeded not because of the planning, but because they were good at adapting when reality differed from the plan? What if their individual wins don’t contradict the broader pattern?

I’m not trying to convince anyone. Gall’s insights either match what you’ve seen or they don’t.

But it’s worth asking: when you look at the systems that actually endured in your career—the ones still running years later—how many started complex? How many started simple and grew?

The pattern is there if you want to see it.

Or not. Systems will keep teaching us, either way.

Coding Practices Are So the Wrong Focus

June 23, 2025

Article, Business, Deming, Engineering, Product development, Software development, Systems thinking

Leave a comment

Coding Practices Are So the Wrong Focus

In W. Edwards Deming’s famous Red Bead experiment, willing workers try their best to draw only white beads from a bowl containing 80% white beads and 20% red beads. Using a paddle that scoops exactly 50 beads, workers are told to produce zero defects (no red beads). No matter how hard they try, how skilled they are, or how much they want to succeed, the random distribution means some workers will consistently get more red beads than others through pure chance. The system determines the outcome, not individual effort.

Deming used this experiment to demonstrate a fundamental truth: 95% of performance problems come from the system, not the individual workers. Yet in software development, we’ve created an entire industry obsessed with the equivalent of ‘worker performance improvement’—code reviews, linting rules, architectural purity, testing coverage—whilst ignoring the systems that actually determine product success.

The Software Industry’s Red Bead Problem

Walk into any tech company and you’ll find passionate debates about coding standards, architecture patterns, and development methodologies. Teams spend hours in code reviews, invest heavily in testing frameworks, and argue endlessly about the ‘right’ way to structure their applications.

Meanwhile, the same companies ship products nobody wants, struggle with unclear requirements, and watch competitors succeed with arguably inferior technical implementations.

We’ve created a culture where developers are evaluated on code quality metrics whilst remaining largely ignorant of whether their beautifully crafted code actually solves real problems for the Folks that Matter™. It’s the Red Bead experiment in action—we’re measuring and optimising individual performance whilst the system churns out failed products regardless of how elegant the codebase might be.

Most tellingly, in most organisations developers have next to zero influence over what really matters: what gets built, for whom, and why. They’re handed requirements from product managers, asked to estimate tasks defined by others, and measured on delivery speed and code quality—all whilst having no input on whether they’re building the right thing. Then they get blamed when products fail in the market.

The Invisible System

Most developers operate with a remarkably narrow view of the system they’re embedded in. They see their piece—the code, the sprint, maybe their immediate team—but remain blind to the larger forces that actually determine whether their work creates value.

This narrow focus isn’t accidental. The current system actively discourages broader awareness:

Developers are rewarded for technical excellence in isolation, not for understanding customer problems or business constraints. They’re measured on code quality and feature delivery, not on whether their work moves the business forward. They’re kept busy with technical tasks and rarely exposed to customer feedback, sales conversations, or strategic decisions.

Most critically, developers have next to zero influence or control over the way the work works—the system itself. They can’t change how requirements are gathered, how priorities are set, how teams communicate, or how decisions flow through the organisation. Yet they’re held responsible for whether all the Folks that Matter™ get their needs attended to.

Performance reviews focus on individual contributions rather than system-level thinking. Career advancement depends on demonstrating technical skill, not understanding how technology serves business objectives. The very structure of most organisations creates silos that prevent developers from seeing the bigger picture.

When Developers See the System

Everything changes when developers start understanding the wider system within which they function. They begin to realise that:

Beautiful code that solves the wrong problem is waste. Technical decisions ripple through customer support, sales, and operations in ways they never considered. That ‘simple’ feature request is actually complex when you understand the business context. They’ve been optimising for the wrong metrics because they couldn’t see what actually drives value for all the Folks that Matter™.

Developers who understand the system make fundamentally different choices. They push back on features that don’t align with the needs of the Folks that Matter™. They prioritise technical work that attends to the needs of the business rather than pursuing abstract perfection. They communicate differently with product managers because they understand the broader context of decisions.

The Real Constraints

The actual bottlenecks in software development are rarely technical—they’re systemic:

Communication breakdowns between product, design, and engineering teams lead to solutions that miss the mark. Feedback loops that take months instead of days prevent rapid iteration towards product-market fit. Decision-making processes filter out critical information from customers and frontline teams.

Requirements change constantly because there’s no clear product strategy or understanding of the needs of the Folks that Matter™. Teams work in isolation without understanding how their work connects to attending to those needs. Incentive systems reward shipping features over solving real problems.

Knowledge silos mean critical insights never reach the people who could act on them. Risk-averse cultures prevent the experimentation necessary for innovation. Metrics focus on activity rather than outcomes, creating busy work that doesn’t drive value.

Beyond Individual Excellence

The parallel to Deming’s insight is striking. Just as factory workers couldn’t improve quality by trying harder within a flawed system, developers can’t improve product outcomes by writing better code within dysfunctional organisational systems.

A team can follow every coding best practice religiously and still build something nobody wants. They can have 100% test coverage on features that solve the wrong problem. They can architect beautiful, scalable systems that scale to zero people who matter.

The solution isn’t to abandon technical excellence—it’s to recognise that individual excellence without system awareness is like being a skilled worker in the Red Bead experiment. Your efforts are largely irrelevant because the system constraints determine the outcome.

Building System Awareness

Organisations that want to improve how well they attend to the needs of the Folks that Matter™ need to help developers see and understand the wider system:

Expose developers to all the Folks that Matter™ through support rotations, research sessions, sales calls, and stakeholder meetings. Share context about why certain features matter and how technical decisions impact the people the system serves. Create feedback loops that connect code changes to how well needs are being attended to.

Measure system-level metrics like time from idea to value delivered to the Folks that Matter™, not just individual productivity. Reward cross-functional collaboration and understanding of the wider system, not just technical skill. Encourage questioning of requirements and priorities based on system-level thinking.

Make the invisible visible by sharing feedback from all the Folks that Matter™, competitive intelligence, and strategic context. Connect technical work to how well needs are being attended to through clear metrics and regular communication. Break down silos that prevent developers from understanding their role in the larger system.

The Path Forward

The tech industry’s obsession with coding practices isn’t just misplaced energy—it’s actively harmful when it distracts from the system-level changes that actually improve how well we attend to the needs of the Folks that Matter™. We need developers who understand that their job isn’t to write perfect code in isolation, but to create value within complex organisational and market systems.

This doesn’t mean abandoning technical excellence. It means recognising that technical excellence without system awareness is like perfecting your red bead drawing technique—a local optimisation that misses the point entirely.

The companies that succeed will be those that help their developers see beyond the code to understand all the Folks that Matter™, the market, the business model, and the organisational dynamics that actually determine whether their work creates value.

When developers start seeing the system, they stop optimising for red beads and start optimising for what actually matters. That’s when real improvement begins.

A Note on ‘Users’ and ‘Customers’

The conventional framing of ‘users’ and ‘customers’ is reductive and misses the point entirely. It treats software development like building a consumer app when most systems serve a complex web of stakeholders with different and sometimes conflicting needs.

Consider any real software system—an ERP platform must work for accountants entering data, executives reading reports, IT teams maintaining it, auditors reviewing it, vendors integrating with it, and regulators overseeing it. Calling them all ‘users’ flattens out completely different contexts and needs.

The ‘customer’ framing is even worse because it implies a simple transaction—someone pays money, gets product. But in most organisations, the people paying for software aren’t the ones using it day-to-day, and the people whose work gets impacted by it might not have had any say in the decision.

‘Folks that Matter™’ captures the messy reality that there are various people with legitimate stakes in whether the system works well. Developers are typically kept ignorant of who these people are, what they actually need, and how technical decisions affect them. It’s like the Red Bead experiment—workers are told to ‘satisfy the customer’ without any real understanding of what that means or who that customer actually is. Just another abstraction that keeps them focused on the wrong metrics.

Do Project Managers Realise They’re Obsolete?

June 18, 2025

Agile, Article, Management, NoProjects, Product development

1 Comment

Do Project Managers Realise They’re Obsolete?

The Tech Industry’s Quiet Revolution Against Traditional PM Roles

The tech industry has been running a quiet experiment for the past decade, and the results are brutal for traditional project managers. Whilst PMPs keep updating their LinkedIn profiles with shiny new certifications, most successful tech companies have quietly ditched project management roles. They’re using self-organising teams and product-focused approaches instead.

The harsh truth? Many project managers in tech are desperately hanging onto jobs that the industry has already moved past.

What’s Wrong with Projects Anyway?

Before we talk about why project coordinators are becoming irrelevant, let’s be honest about why the whole project approach is broken in tech. (See also: #NoProjects)

Projects create fake deadlines for work that never really ends. Your app doesn’t magically stop needing updates when the ‘project’ finishes. But projects pretend everything has a neat beginning, middle, and end. This is ridiculous in tech where products need more or less constant updates.

Projects also focus on the wrong stuff. Instead of asking ‘did we solve the customer’s problem?’ they ask ‘did we hit our deadline and stay on budget?’ Teams end up caring more about finishing the project than building something people actually need.

And here’s the kicker—projects waste tons of time on planning and meetings. How many hours do tech teams spend in status meetings, writing reports, and sitting through steering committee presentations? All that time could be spent actually building stuff.

The biggest problem? Projects break up teams just when they’re getting good at working together. You spend months learning how the code works, understanding the business, and figuring out how to collaborate. Then the project ends and everyone gets shuffled to different teams. It’s insane.

The #NoProjects Revolution

The #NoProjects movement, started by folks like P G Rule and FlowChainSensei, isn’t just complaining about projects. They’ve got a better way.

Instead of temporary projects, successful tech companies now use persistent product teams. These teams stick together and own their product long-term. No more ‘hand it off to maintenance’ nonsense. If you build it, you keep updating it.

This isn’t just theory. Companies like Spotify, Netflix, and Amazon prove it works. They organise around products, not projects. Their teams stay together, learn deeply about their domain, and can move fast because they’re not constantly starting over.

The #NoProjects crowd figured out that the problem wasn’t bad project coordination—it was the whole idea of projects in the first place. When you stop trying to force continuous work into temporary boxes, everything gets easier.

Self-Organising Teams: The Coordinator Killer

Self-organising teams in tech have basically made traditional project managers irrelevant. These teams have developers, designers, product people, and QA folks who collectively own their work. They don’t need someone else to coordinate for them.

Here’s what’s wild—these teams often move faster than teams with dedicated project managers. When six smart people can figure out their own priorities, plan their own work, and make their own decisions, why add another layer of oversight?

The best part? These teams actually understand the technical work they’re doing. They can make smart tradeoffs between features and technical debt. They know when to cut scope and when to push back on unrealistic deadlines. Traditional project managers usually don’t have that technical depth.

Product People Ate Their Lunch

Whilst project managers were busy updating their Gantt charts, product specialists swooped in and took over the strategic parts of their job. Product people combine market knowledge, technical understanding, and execution skills in ways project managers never did.

Product specialists own outcomes, not just timelines. They decide what to build, understand why it matters, and can make calls about technical tradeoffs. They’re not just coordinating other people’s work—they’re directly contributing to the product’s success.

Many companies discovered that a strong product specialist working with a self-organising engineering team gets better results than the old project manager + team structure. Product people bring strategic thinking that traditional PMs usually lacked. Better yet, have the self-organising engineering team also be or become the product domain specialists.

Agile Killed the Project Manager Star

Agile development pretty much destroyed the traditional project management playbook. Agile is all about working software over documentation, people over processes, and responding to change over following plans. That’s the exact opposite of traditional project management.

Most companies that have adopted Agile have tried to rebrand their project managers as Scrum Masters at first. But that mostly fails because good Scrum Masters need to understand the technical work, whilst traditional project managers usually don’t have that background.

The DevOps Bump

DevOps eliminated a lot of the handoff problems that project managers used to handle. When development teams own their own deployment, monitoring, and production support, there’s way less coordination needed.

Modern tech teams do continuous integration, infrastructure as code, and automated testing. Code flows from development to production with minimal human coordination. When this stuff is automated, what exactly is the project manager coordinating?

The ‘you build it, you run it’ philosophy means teams are responsible for their stuff end-to-end. This eliminates the need for someone to handle handoffs between development and operations teams.

Startups Don’t Use Project Managers

The most telling evidence comes from startups. Most successful tech startups operate without any dedicated project managers. They use self-organising teams, clear product vision, and direct communication.

Startups that try to add traditional project management usually find it slows them down. All the planning meetings and status reporting kill their ability to move fast and adapt quickly.

When startups do eventually need more coordination, they hire product specialists, engineering leads, or technical programme leads—roles that combine coordination with domain expertise and direct value creation.

Enterprise Companies Are Catching On

Even big, slow enterprise companies are starting to figure this out. Their most innovative teams usually operate with minimal traditional project management oversight. Internal studies keep showing that self-organising teams with clear product ownership deliver better results faster.

The enterprises still clinging to traditional project management are finding themselves at a competitive disadvantage. They’re slower to market and less able to adapt than competitors who’ve embraced product-focused, team-based approaches.

The Desperate Rebranding Campaign

Seeing the writing on the wall, lots of project managers are frantically trying to rebrand themselves. They’re getting Scrum Master certifications, learning basic coding, or calling themselves ‘technical programme managers’ or ‘delivery leads.’

This rebranding reveals the profession’s fundamental problem. If traditional project management skills were still valuable, there wouldn’t be any need to constantly learn new skills and change job titles.

The most honest take? These aren’t career progressions—they’re career pivots. Project managers who successfully move into product roles, engineering leadership, or technical roles have basically admitted that traditional project management wasn’t enough.

The Bigger Picture: All Traditional Oversight Is Under Threat

But here’s the thing—project managers aren’t the only ones feeling the heat. The whole traditional hierarchy of ‘oversight’ and ‘supervision’ is crumbling in modern organisations, especially in tech.

Think about it: when teams are self-organising, when knowledge workers can make their own decisions, when tools automate most management tasks, what exactly do traditional supervisors do all day? The same forces killing project management are questioning the need for layers of oversight, period.

Netflix famously operates with minimal traditional hierarchy. Their teams make decisions, own outcomes, and course-correct without multiple layers of approval. Amazon’s two-pizza teams work similarly—small, autonomous groups that don’t need constant supervision to function effectively.

The pattern is clear: high-performing organisations are flattening their structures and empowering teams to operate independently. A few traditional command-and-control hierarchies are being replaced by networks of autonomous teams with clear missions and accountability for results.

Even the concept of ‘people oversight’ is evolving. Instead of supervisors who assign work and monitor progress, successful companies are moving towards coaching, mentoring, and servant leadership models. The focus shifts from controlling people to enabling them.

This isn’t just happening in tech startups. Even massive organisations like Spotify, Haier, and Morning Star have demonstrated that you can scale to thousands of employees without traditional hierarchical structures. When people are trusted to do their jobs and held accountable for outcomes, most traditional oversight becomes unnecessary toxic overhead.

The uncomfortable truth for anyone in a traditional oversight role: if your primary function is coordinating other people’s work, monitoring their progress, or making decisions they could make themselves, your role is probably next on the chopping block.

The Evidence Is Overwhelming

The #NoProjects movement isn’t just talk—it’s backed by real results. Companies that ditched traditional project structures report faster delivery, happier teams, better products, and lower costs.

These companies organise around persistent teams rather than temporary projects. They fund product areas instead of specific initiatives. They measure customer outcomes instead of just project completion metrics.

The success of these approaches proves that the problem wasn’t insufficient project management—it was the overhead and artificial constraints that project management created.

What This Means for Project Managers

The evidence from the tech industry is crystal clear: traditional project management has become largely obsolete in modern technology companies. Self-organising teams, product-focused structures, DevOps practices, and the #NoProjects movement have eliminated most of the management work that once justified project coordinator roles.

For project managers currently working in tech, the choice is simple: evolve or become irrelevant. You might choose to transition into a role that creates direct value through technical skills, product expertise, or strategic thinking.

The project managers who acknowledge this reality and successfully move into product roles, technical positions, or engineering leadership will survive. Those who keep insisting that traditional project management is still relevant will likely find themselves out of work as the industry continues moving forward without them.

The tech industry’s revolution against traditional project management is basically complete. The only question is whether individual project managers will adapt in time, or whether they’ll keep clinging to an obsolete profession whilst the industry moves on.

FlowChainSensei’s Hitchhiker’s Guide to Tech Startups

June 12, 2025

Action, Actionable Insights, AI, Article, Business, Chatbots, Familiar, Guides, Memeology, Product development, Quintessence, Startups, Working Notes

Leave a comment

FlowChainSensei’s Hitchhiker’s Guide to Tech Startups

DON’T PANIC!

Yes, this post iattempts to be comprehensive in covering a vast array of considerations for launching a tech startup. It may seem daunting at first glance – much like contemplating the infinite complexity of the universe. But remember: there’s no need to tackle everything at once. This guide is designed to be a reference companion throughout the startup journey, not a checklist to complete before breakfast. Take it one section at a time, focus on what’s most relevant to the current stage, and remember that even the most successful founders started with just one small step.

Audience and Scope: This guide is written primarily for founding teams of 1-3 people in early planning stages, scaling from solo founder scenarios to small team situations. Use the sections relevant to your current stage and team size.

Inception vs. Implementation: The framework and briefing establish strategic direction. Detailed implementation planning happens over subsequent weeks through focused work sessions on specific areas.

Part 1: Strategic Foundation Framework

Legal and Regulatory Framework

When to revisit: Immediately (Week 1), then quarterly for compliance updates, and before any major business model changes

Understanding the legal landscape is crucial for any tech startup. The UK regulatory environment provides both opportunities and obligations that founders must navigate carefully.

Business Structure and Formation

Limited company formation remains the preferred structure for most tech startups
- Provides liability protection and credibility with customers and investors; enables equity distribution and investment
Consider partnership structures and shareholding arrangements early
- Early clarity prevents costly restructuring later; proper documentation protects all parties
Understand director responsibilities and company law obligations
- Directors have legal duties that carry personal liability; understanding these prevents inadvertent breaches

Intellectual Property Protection

Register trademarks early to protect brand identity
- UK trademark registration costs £170-200 but protects valuable brand assets; international expansion requires broader protection
Consider patent protection for genuine innovations
- Patents provide 20-year protection but cost £4,000-8,000; only worthwhile for truly novel technical innovations
Implement robust copyright and design right strategies
- Automatic protection exists but registration strengthens enforcement; crucial for content-heavy businesses

Data Protection and Privacy Compliance

UK GDPR compliance is mandatory, not optional
- Non-compliance fines reach 4% of annual turnover; privacy-by-design reduces compliance costs and builds user trust
Implement proper consent mechanisms and data handling procedures
- Clear consent reduces legal risk; transparent data policies increase user confidence and conversion rates
Consider appointing a Data Protection Officer if processing large volumes of personal data
- Legal requirement for high-risk processing; demonstrates compliance commitment to customers and partners

Consumer Rights and Trading Standards

Comply with Consumer Rights Act 2015 requirements
- Legal obligation that affects refund policies, service quality standards, and customer relationship management
Understand distance selling regulations for online services
- 14-day cooling-off periods apply to most online sales; clear terms reduce customer disputes
Implement fair contract terms and transparent pricing
- Unfair terms are unenforceable; transparent pricing increases conversion and reduces support queries

Trust, Safety, and Verification Systems

When to revisit: Immediately for basic framework (Week 2-3), then monthly during first year as user base grows

Building trust in digital platforms requires systematic approaches to safety, verification, and community management.

User Authentication and Verification

Implement robust identity verification systems
- Multi-factor authentication reduces fraud by 60-80%; builds user confidence whilst reducing platform liability
Consider requiring phone number, email, or social media verification
- Reduces bot accounts and spam; phone verification particularly effective for location-based services
Develop user rating and review systems
- Peer ratings build community trust and enable self-policing; clear feedback mechanisms improve service quality
Create processes for handling disputed identities
- Swift dispute resolution maintains user confidence; documented procedures reduce support time

Content Moderation and Community Guidelines

Establish clear community standards and acceptable use policies
- Clear guidelines reduce moderation burden; transparent enforcement builds user trust in platform fairness
Implement automated content filtering for common violations
- Automation scales more effectively than manual moderation; reduces response time for harmful content
Develop escalation procedures for complex cases
- Human oversight ensures context-sensitive decisions; appeals processes maintain user confidence
Create reporting mechanisms for users to flag inappropriate content
- Community-driven moderation leverages user knowledge; empowers users to maintain platform quality

Security and Fraud Prevention

Implement comprehensive security measures including encryption and secure data storage
- Security breaches cost average £3.2 million; proactive security investment prevents larger costs
Develop fraud detection systems and suspicious activity monitoring
- Early fraud detection prevents losses and protects legitimate users; automated systems scale more effectively
Create incident response procedures for security breaches
- Rapid response minimises damage; transparent communication maintains user trust during incidents

Technology Infrastructure and Data Management

When to revisit: Month 1-2 for architecture decisions, then quarterly for scaling and security reviews

Technical decisions made early significantly impact long-term scalability, costs, and capability.

Platform Architecture and Hosting

Choose scalable hosting solutions that can grow with the business
- Cloud platforms like AWS or Google Cloud provide scalability without large upfront costs; enable rapid geographic expansion
Implement proper database design and data architecture
- Good data architecture prevents expensive migrations later; enables advanced analytics and personalisation features
Plan for load balancing and high availability from the start
- Downtime costs revenue and damages reputation; redundancy planning prevents service disruptions

Search Functionality and User Experience When to revisit: Month 2-3 for MVP implementation, then quarterly for optimisation based on user behaviour data

Effective search and discovery capabilities often determine platform success or failure.

Core Search Features

Implement robust search algorithms with relevant ranking
- Poor search functionality drives users to competitors; good search increases engagement and transaction volume
Enable advanced filtering and categorisation options
- Filters help users find relevant content quickly; reduces search friction and improves conversion rates
Consider implementing recommendation systems based on user behaviour
- Personalised recommendations increase engagement by 15-25%; creates additional revenue opportunities

Search Optimisation and Performance

Monitor search performance and user behaviour analytics
- Data-driven optimisation improves user experience; identifies content gaps and user preferences
Implement search result caching for improved performance
- Faster search results improve user satisfaction; reduced server load decreases hosting costs
Plan for search functionality that scales with inventory growth
- Search performance must maintain quality as content volume increases; early architecture decisions affect long-term capability

Payment Processing and Financial Infrastructure

When to revisit: Immediately (Week 1-2), then annually for rate optimisation and when adding new payment methods

Financial infrastructure decisions impact cash flow, user experience, and regulatory compliance.

Payment Gateway Selection and Integration

Research and compare payment processor fees and features
- Payment processing fees directly impact margins; choosing the right processor saves 0.5-1% on transaction costs
Implement multiple payment options to maximise conversion
- Payment method preferences vary by demographic; offering preferred methods increases completion rates by 10-30%
Ensure PCI DSS compliance for payment card processing
- Legal requirement for card processing; non-compliance risks fines and reputational damage

Billing and Revenue Models When to revisit: Month 3-6 for pricing validation, then every 6 months for optimisation based on user behaviour and market conditions

Subscription models in particular require sophisticated billing infrastructure and pricing strategies.

Subscription Management Systems

Implement robust subscription billing with automated renewals
- Automated billing reduces churn from payment failures; improves cash flow predictability
Plan for pricing tier management and promotional pricing
- Flexible pricing enables market testing and promotional campaigns; supports growth and retention strategies
Develop dunning management for failed payments
- Effective dunning management recovers 15-30% of failed payments; reduces involuntary churn

Transaction Billing Systems

Implement robust payment processing with real-time transaction handling
- Real-time processing reduces cart abandonment and improves user experience; immediate confirmation builds customer confidence
Plan for dynamic fee structures and commission management
- Flexible fee models enable competitive positioning and market adaptation; tiered commission structures incentivise higher-value transactions
Develop automated reconciliation and settlement processes
- Automated reconciliation reduces manual errors and processing time; faster settlement improves cash flow and vendor satisfaction
Implement split payment capabilities for multi-party transactions
- Split payments enable marketplace models and partner revenue sharing; automated distribution reduces operational overhead
Create transparent fee calculation and dispute resolution systems
- Clear fee transparency reduces customer complaints; systematic dispute handling maintains trust and reduces support burden
Plan for international payment processing and currency conversion
- Multi-currency support enables global expansion; competitive exchange rates reduce barriers for international customers
Establish fraud detection and risk management for transactions
- Proactive fraud prevention protects revenue and customer data; risk scoring reduces chargebacks and financial losses

Financial Reporting and Analytics

Implement proper revenue recognition and financial tracking
- Accurate financial reporting enables informed decision-making; required for tax compliance and investor relations
Monitor key metrics like Monthly Recurring Revenue (MRR) and customer lifetime value
- Financial metrics guide strategic decisions; essential for fundraising and growth planning
Plan for international expansion with multi-currency support
- Multi-currency capability enables global growth; reduces barriers for international customers

Customer Support and Community Management

When to revisit: Month 2-3 for basic setup, then monthly during growth phases and quarterly for optimisation

Customer support infrastructure must scale with growth whilst maintaining quality standards.

Support Infrastructure and Processes

Implement comprehensive help documentation and FAQ systems
- Self-service options reduce support volume by 30-50%; improves customer satisfaction through immediate answers
Choose scalable customer support platforms
- Integrated support platforms provide better analytics and automation; improve response times and quality
Develop standard operating procedures for common support scenarios
- Consistent support quality builds customer confidence; reduces training time for new team members

Community Building and Engagement

Create channels for user feedback and feature requests
- User input drives product development; engaged communities provide valuable market insight
Develop user onboarding processes and educational content
- Effective onboarding reduces churn by 20-40%; improves user adoption of key features
Plan for community moderation and management
- Active community management prevents toxicity; fosters positive user interactions and platform loyalty

Market Research and Customer Development Strategy

When to revisit: Ongoing during first 6 months, then quarterly for market intelligence and competitive analysis

Understanding markets and customers drives all other strategic decisions.

Market Validation and Sizing

Conduct primary research to validate market demand
- Direct customer feedback prevents building unwanted products; identifies real user needs and pain points
Analyse competitive landscape and positioning opportunities
- Competitive analysis reveals market gaps and positioning strategies; helps avoid saturated market segments
Define target customer segments and personas
- Clear customer definitions guide product development and marketing; improve conversion rates and customer satisfaction

Customer Development Process

Implement systematic customer interview and feedback collection
- Regular customer contact drives product-market fit; identifies opportunities for improvement and expansion
Monitor customer acquisition costs and lifetime value metrics
- Understanding unit economics drives sustainable growth; guides marketing spend and pricing decisions
Develop systems for tracking and analysing customer behaviour
- Behavioural data reveals user preferences and friction points; enables data-driven product optimisation

Future Strategic Options (Horizon 2/3)

When to revisit: After achieving profitability and establishing proven business model (typically 18-24 months post-launch)

Long-term strategic options require early consideration but delayed implementation.

Market Expansion Opportunities

Evaluate potential for geographic expansion
- Geographic expansion multiplies addressable market; requires understanding of local regulations and preferences
Consider adjacent market opportunities and vertical expansion
- Adjacent markets leverage existing capabilities; provide growth without starting from scratch
Assess partnership and licensing opportunities
- Strategic partnerships accelerate market entry; licensing provides recurring revenue with minimal operational overhead

Technology Evolution and Innovation

Plan for emerging technology adoption
- Early adoption of relevant technologies provides competitive advantage; requires ongoing technology monitoring
Consider API development for third-party integration
- APIs create ecosystem opportunities and additional revenue streams; increase platform value and user retention
Evaluate acquisition opportunities and consolidation strategies
- Strategic acquisitions provide capabilities and market access; consolidation can improve market position

Note: Advanced strategic planning begins only after successful market validation and proven unit economics. Focus on core market success before considering expansion models.

Part 2: Partnership Inception Meeting Framework

Note: This meeting establishes strategic direction and framework. Detailed implementation planning happens through focused work sessions over the following 4-6 weeks.

Purpose and Vision Alignment (15 minutes)

Define core mission and long-term vision for the platform
- Essential foundation that guides all strategic decisions; prevents mission drift and ensures consistent brand messaging
Establish shared values and ethical framework
- Creates decision-making filter for difficult choices; attracts like-minded customers, employees, and partners
Discuss personal motivations and what success means to each partner
- Prevents future conflicts by surfacing different definitions of success early; ensures both partners remain motivated
Align on impact goals: environmental, social, and economic outcomes
- Quantifiable impact metrics enable authentic ESG reporting; attracts impact investors and conscious consumers
Clarify the “why” behind the business beyond financial returns
- Strong purpose enables premium pricing through brand loyalty; provides resilience during market downturns

Legal Structure and Compliance Framework [Priority 1] (15 minutes)

Decide on business entity structure (limited company recommended)
Assign responsibility for legal setup and compliance
Review content policies and moderation strategy
Discuss IP protection and trademark registration needs
Plan for GDPR compliance and data protection measures
Establish terms of service and privacy policy development

Business Model Validation and Revenue Strategy [Priority 1] (15 minutes)

Validate subscription tier structure and pricing strategy
Validate transation fee structure and pricing strategy
Define value propositions for free vs. premium tiers
Review market research and competitive analysis findings
Establish target customer segments and personas
Discuss go-to-market strategy and timeline
Set revenue targets and key milestones

Partnership Structure and Equity Discussion (15 minutes)

Define roles and responsibilities for each party
Discuss equity arrangement and percentage allocation
Establish decision-making authority and governance structure
Review time commitment expectations and availability
Agree on vesting schedules and cliff periods

Technical Architecture and MVP Scope [Priority 1] (15 minutes)

Review current MVP progress and technical decisions
Define Phase 1 feature set and launch requirements
Discuss search functionality implementation approach
Plan scalability requirements and technical debt management
Establish development timeline and resource needs
Review security and data protection requirements

Trust, Safety and Search Strategy [Priority 2] (15 minutes)

User verification and authentication approach
Search algorithm strategy and competitive differentiation
Content moderation and community guidelines
Dispute resolution processes and escalation procedures
Platform safety measures and risk mitigation

Operational Planning and Resource Allocation (15 minutes)

Define immediate hiring needs and skill gaps
Plan customer support infrastructure and responsibilities
Discuss payment processing setup and financial management
Establish quality assurance and testing procedures
Review operational costs and budget requirements

Next Steps and Action Items (20 minutes)

Assign immediate action items and ownership
Schedule follow-up meetings and check-in cadence
Establish communication protocols and project management tools
Set deadlines for key deliverables and milestones
Plan for legal documentation and partnership agreements

Priority Parking Lot (Deferred Items)

Marketing and PR Strategy [Priority 3]

Defer to Month 4-6: Focus on product-market fit before marketing investment

Metrics and Analytics Implementation [Priority 3]

Defer to Month 2-3: Implement after basic functionality is operational

Future Strategic Options [Priority 4]

Defer to Horizon 2/3 planning (Month 12+): Focus on core market success first

Part 3: Implementation Roadmap and Planning Tools

Prioritisation Framework

Impact vs. Effort Scoring Matrix Score each item 1-5 (5 = highest impact/lowest effort)

High Impact, Low Effort (Priority 1 – Quick Wins)

Business entity formation (Impact: 5, Effort: 2)
Basic terms of service (Impact: 4, Effort: 2)
Payment processing setup (Impact: 5, Effort: 3)
Basic analytics implementation (Impact: 4, Effort: 2)

High Impact, High Effort (Priority 2 – Strategic Investments)

Core MVP development (Impact: 5, Effort: 5)
Search functionality (Impact: 5, Effort: 4)
User authentication systems (Impact: 4, Effort: 4)
Customer support infrastructure (Impact: 4, Effort: 4)

Implementation Timeline

Pre-Launch Phase (Months 1-3)

Legal and Structural Foundation

Business entity formation: 2-3 weeks, £200-500
Partnership agreement execution: 3-4 weeks, £1,500-3,000
Basic terms of service and privacy policy: 1-2 weeks, £500-2,000
VAT registration (if applicable): 1-2 weeks, Free-£200

Technical Development

Website hosting infrastructure setup: 1-2 weeks, £100-500/month
Core MVP feature completion: 8-12 weeks, £15,000-50,000
Basic search functionality: 3-4 weeks, £3,000-8,000
Payment processing integration: 2-3 weeks, 2.9% + 20p per transaction
User authentication systems: 2-3 weeks, £1,000-3,000

Soft Launch Phase (Months 4-6)

Limited User Testing

Closed beta with 50-100 invited users: 4-6 weeks, £500-2,000
User feedback collection and platform refinement: 3-4 weeks, £300-1,500
Search algorithm optimisation: 2-3 weeks, £2,000-5,000

Operational Validation

Customer support process testing: 2-3 weeks, £500-1,500
Quality control and authentication processes: 3-4 weeks, £1,500-4,000

Public Launch Phase (Months 7-9)

Market Entry

Public platform launch: 2-3 weeks, £3,000-10,000
Marketing campaign execution: 8-12 weeks, £5,000-25,000
Social media presence establishment: 4-6 weeks ongoing, £1,000-4,000/month

Scale Preparation

Customer support team expansion: 3-4 weeks, £25,000-45,000/year per hire
Technical infrastructure scaling: 2-3 weeks, £500-2,000/month additional
Advanced search features: 6-8 weeks, £8,000-20,000

Ready-to-Use Planning Templates

Vendor Evaluation Scorecard Payment Processor Evaluation (Score 1-10)

Processing fees competitive (< 3%)
UK Direct Debit support
Subscription billing features
Transaction billing features
API quality and documentation
Customer support responsiveness
Compliance and security certifications
Integration complexity (lower score = easier)
Failure handling and retry logic

User Research Interview Script Market Validation Interview (30 minutes)

Opening (5 minutes) “Thank you for your time. We’re researching how people currently solve [problem area]. This isn’t a sales call / conversation – we genuinely want to understand your experiences and challenges.”

Current Behaviour (10 minutes)

How do you currently handle [problem area]?
What tools or services do you use?
What’s frustrating about current options?
How often do you encounter this problem?

Problem Validation (10 minutes)

Have you ever wanted a solution that…?
What would make you trust a new service in this area?
What concerns would you have about trying something new?

Solution Testing (5 minutes) “Imagine a service that [brief solution description]…”

What would make this valuable to you?
How much would you pay monthly for this service?
What features would be most important?

Contingency Planning

Plan B Options for Major Decisions

Payment Processing Contingencies

Primary: Stripe + GoCardless
Plan B: PayPal + Worldpay (if primary rejects application)
Plan C: Square + bank transfer (if all major processors reject)
Nuclear Option: Manual invoicing until revenue justifies enterprise processor

Technical Architecture Alternatives

Primary: Custom development
Plan B: White-label solution
Plan C: WordPress + plugins for rapid prototype
Pivot Option: Simple directory without complex features

Revenue Model Pivots (Notional)

Primary: Subscription-based access
Plan B: Transaction fees (2-5% per transaction)
Plan C: Freemium with premium features
Last Resort: Advertising-supported free platform

Stakeholder Communication Framework

Monthly Investor Update Template

Executive Summary (2-3 sentences on key achievements and challenges)
Key Metrics Dashboard
Major Accomplishments (3-4 bullet points)
Key Challenges (2-3 items with action plans)
Financial Summary (revenue, expenses, cash position)
Team Updates (hires, departures, key achievements)
Ask (specific help needed from investors)
Next Month Focus (3-4 key priorities)

Crisis Communication Templates

Service Outage Communication “We’re currently experiencing technical difficulties that may affect platform access. Our team is working to resolve this immediately.

Status: Investigating
Estimated Resolution: [timeframe]
Affected Services: [specific areas]

Updates every 30 minutes at [status page link]. We apologise for the inconvenience.”

Conclusion

Successfully launching a tech startup requires careful orchestration of numerous business elements beyond product development. Using strategic planning frameworks helps balance immediate execution needs with longer-term growth opportunities. Addressing the foundational areas outlined in this guide proactively will significantly improve the likelihood of sustainable growth and long-term success.

Consider prioritising legal compliance, trust and safety measures, and basic operational procedures before launch, whilst developing longer-term strategies for emerging opportunities and transformational growth. Remember: the goal isn’t to complete everything immediately, but to build a sustainable foundation for systematic growth.

Colophon

This comprehensive startup guide was collaboratively developed through an iterative process of strategic planning, business analysis, and practical implementation guidance. The framework presented here draws upon established business methodologies, UK regulatory requirements, and contemporary startup best practices.

Document Creation Process: The strategic analysis and actionable recommendations were developed through extensive dialogue between human expertise in business strategy, technology, and startup operations, enhanced by Claude (Anthropic’s AI assistant) and FlowChainSensei for research synthesis, structural organisation, and comprehensive coverage of technical and regulatory considerations.

Methodology: This post mentions multiple strategic frameworks including the Three Horizons planning model, Impact vs. Effort prioritisation matrices, and risk-weighted analysis to provide both immediate tactical guidance and long-term strategic vision.

Intended Use: This guide serves as a living document designed to evolve with the startup’s growth and changing market conditions. It is intended for use by founding teams, advisors, and stakeholders as both a planning tool and operational reference throughout the business development lifecycle.Pleas take it and evolve it as you need.

Version: 1.0
Date: 12 June 2025
Format: WordPress blog post
License: This work is licensed under a Creative Commons Attribution 4.0 International License. You are free to share and adapt this material for any purpose, even commercially, as long as you provide appropriate attribution to FlowChainSensei.

“In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. Starting a business has similar effects, but with better potential returns.” – With apologies to Douglas Adams

Walls

June 2, 2025

Antimatter principle, Article, Collaboration, Product development, Software development, Toxic behaviours

Leave a comment

Walls

What are the most insidious bugs in software development? They’re not the ones that crash your application—they’re the ones that crash your team’s ability to collaborate effectively. But how do these bugs manifest? As invisible walls between groups of developers, testers, UI and UX folks, etc. who, despite working towards the same ultimate goal, find themselves increasingly unable to communicate across the divides of their different assumptions, beliefs, specialisms, ingroups, and approaches.

But here’s the fundamental question: why should we care? What’s our motivation for tearing down these walls when they often provide us with identity, belonging, and professional security? After all, being ‘the React expert’ or ‘the DevOps person’ gives us a place in the world, a community to belong to, and expertise that others recognise. So why risk that comfort for the uncertain benefits of collaboration across tribes?

Before we go further, pause for a moment. When you read that last paragraph, what did you feel? Did a particular technology or methodology flash through your mind—one you champion or defend? Did you think ‘Well, I’m not tribal, but those Vue developers…’ or ‘I’m open-minded, but microservices really are better than monoliths’? That little voice? That’s where our story begins.

The Architecture of Division

How do these walls manifest in software development? They take many forms. There’s the classic divide between frontend and backend developers, where one group sees the other as either ‘not real programmers’ or ‘doesn’t understand user experience’. But why do DevOps engineers often find themselves separated from application developers? Does it come down to assumptions about whose responsibility it is to ensure code actually runs in production? And what about product managers and domain experts? They frequently operate in parallel universes, with each group convinced the other fundamentally misunderstands the business.

But have these divisions grown more complex recently? We’ve seen new walls emerge around technology choices. React developers dismissing Vue as ‘toy framework’, whilst Vue developers see React as ‘unnecessarily complex’. Microservices advocates view monolith supporters as stuck in the past, whilst monolith defenders see microservices enthusiasts as complexity addicts solving problems that don’t exist.

Stop here. Which of these resonated with you? Did you find yourself nodding along with one side and mentally dismissing the other? What was the last technical discussion where you felt your jaw clench when someone suggested an approach you disagreed with? Can you remember the exact moment when you stopped listening to understand and started listening to rebut?

What’s really happening when these divisions form? These aren’t just about technical preferences—they’re about identity. When a developer says ‘I’m a Python person’ or ‘I’m a functional programming advocate’, are they just describing their skills? Or are they signalling membership in a tribe with its own values, assumptions, and ways of seeing problems?

The Tolerance Deficit

But what makes these walls particularly dangerous today? It’s the growing intolerance for alternative viewpoints within our field. How did we get here? Social media and online communities have created echo chambers where developers primarily interact with others who share their technical beliefs. What’s the result? A kind of ideological brittleness where encountering different approaches triggers defensive reactions rather than curiosity.

Where do we see this playing out? It shows up in code reviews that become battles over style rather than substance. It appears in architectural discussions where alternatives are dismissed without genuine consideration. It manifests in hiring processes where cultural fit becomes a euphemism for ‘thinks like we do’.

Think about your last code review. When you saw an approach that differed from what you would have done, what was your first instinct? To understand why they chose that path, or to suggest your preferred alternative? When was the last time you changed your mind about a technical decision based on someone else’s argument? If you can’t remember, what might that tell you?

Isn’t there an irony here? We’re building increasingly sophisticated systems for connecting people across the globe, whilst simultaneously becoming less capable of connecting with colleagues who use different frameworks or prefer different paradigms.

The Cost of Our Walls

What toll do these barriers extract from our work? Teams fragment into silos, leading to duplicated effort and incompatible solutions. Knowledge sharing breaks down, leaving each group to rediscover lessons others have already learnt. Decision-making becomes political rather than technical, with choices made based on which group has more influence rather than which approach best serves the needs of the Folks That Matter™.

But what’s perhaps most damaging? These walls prevent us from learning from each other. Consider: what happens when a backend developer has never tried to make a responsive layout? They might design APIs that make frontend work unnecessarily difficult. What about the frontend developer who’s never wrestled with database performance? They might build interfaces that require impossible data loads. And the DevOps engineer who’s never debugged application code? They might create deployment processes that obscure rather than illuminate problems.

Yet these costs often feel abstract—organisational inefficiencies that someone else worries about. So what’s the personal cost? What happens when you’re stuck debugging a problem for days, only to discover that someone from a different tribe could have solved it in minutes? What about when your career advancement stalls because you’re too narrowly specialised for the problems your organisation actually faces? Or when the satisfaction slowly drains from your work because you’re endlessly fighting the same battles with the same people about the same approaches?

When did you last feel truly stuck on a problem? Who did you ask for help? Were they people who think about problems the same way you do, or did you seek out someone with a fundamentally different perspective? What stopped you from reaching across tribal lines—was it pride, assumptions about their knowledge, or simply not knowing who to ask?

The Paradox of Identity

But let’s be honest about why these walls persist. They serve important psychological functions. Being ‘a Python person’ or ‘a functional programming advocate’ isn’t just about describing skills—it’s about having a professional identity in a field that changes so rapidly that expertise becomes obsolete overnight. These tribal affiliations provide stability, community, and recognition in an otherwise chaotic landscape.

Why would we give up that certainty? Specialisation feels safer than generalisation. Having strong opinions about the ‘right way’ to do things reduces decision fatigue and provides cognitive comfort. Being an evangelist for a particular approach can bring conference talks, blog readership, and professional recognition. There’s real social capital in being a thought leader for your tribe.

So the question isn’t whether these walls serve a purpose—they clearly do. The question is whether they’re serving us well in the long term, or whether we’re trading short-term comfort for long-term growth and effectiveness.

What would you lose if you became known as someone who doesn’t have strong technical opinions? How much of your professional confidence comes from being ‘the expert’ in your particular domain? If someone introduced you at a conference, what would they say about you—and how much of that identity is tied to specific technologies or methodologies? What scares you more: being wrong about a technical choice, or admitting you don’t know something?

Common Ground in Shared Experience

What if our shared commitment to attending to folks’ needs could provide common ground for bridging these divides? But perhaps we need to be more honest about what we actually share. Not everyone experiences or expresses empathy in the same way. Not everyone naturally thinks in terms of ‘human needs’ or picks up on social cues easily. Many of us are simply wired differently when it comes to interpersonal dynamics.

But there’s something we might share more universally: the experience of being blocked. Of having clear requirements that keep changing. Of being held responsible for outcomes we can’t control. Of receiving vague or contradictory instructions. Of having our work dependencies managed by people who don’t understand what we actually need to get things done.

The product manager who asks for ‘just a quick change’ without understanding the technical implications. The stakeholder who wants to know ‘how long it will take’ for something that’s never been done before. The designer who creates interfaces that look great but are technically impossible to implement efficiently. The executive who wants to know why the team isn’t moving faster without understanding what’s actually slowing them down.

Can you think of a time when you felt truly stuck—not because of technical complexity, but because of poor communication, unclear requirements, or unrealistic expectations? What made that situation particularly frustrating? Was it the ambiguity? The lack of clear decision-making authority? The sense that people were making demands without understanding the constraints you were working within?

Some of us might interpret these situations as ‘people problems’ or ‘communication issues’. Others might see them as ‘process failures’ or ‘requirements management problems’. The language we use might differ, but the experience of being blocked by preventable obstacles might be more universal.

What would the most effective teams look like? Perhaps not those where everyone processes information the same way, but those where different thinking styles are recognised and accommodated. Where the person who needs explicit requirements can get them, and the person who thinks in systems can share their perspective without being dismissed as ‘overthinking’. Where disagreements happen within clear frameworks rather than endless ambiguous discussions.

What If We Dared to Be Curious?

So what’s the solution? It isn’t to eliminate all technical preferences or pretend that all approaches are equally valid for every situation. But what if we developed what we might call ‘intellectual humility’—the recognition that our own perspective, however well-reasoned, is still just one view of a complex landscape?

What would it look like to approach technical discussions with genuine curiosity about why others have reached different conclusions? Before dismissing a colleague’s preferred tool or methodology, what if we asked: what problems does it solve that our approach doesn’t handle well? What if we sought to understand the context that makes their solution optimal, even if it wouldn’t work in our situation?

What would happen if we actively sought out diverse perspectives? If your team consists entirely of people who think about problems the same way, what insights might you be missing? What if that discomfort you feel when your assumptions are challenged is actually a sign that you’re about to learn something valuable?

Here’s a small experiment: In your next technical discussion, before you speak, pause and ask yourself: am I about to share knowledge, or am I about to defend territory? When someone suggests an approach you disagree with, can you find one thing about it that’s genuinely interesting or clever, even if you wouldn’t use it yourself? What would it feel like to say ‘I hadn’t thought of that’ instead of ‘But what about…’?

Tearing Down Walls, Not Building Them

As our industry continues to evolve at breakneck speed, what skill will become increasingly valuable? The ability to work across different technical and social cultures. Why? Because the problems we’re trying to solve—scaling systems, securing data, creating intuitive experiences—are too complex for any single perspective to address completely.

So what might we do differently? Rather than building higher walls around our preferred approaches, what if we worked to make them more permeable? Does this mean abandoning our technical principles? Perhaps not, but what if we held them more lightly, remaining open to the possibility that context might call for different solutions?

Who will inherit the future? What if it belongs to teams that can synthesise insights from multiple technical traditions, rather than those that retreat into increasingly narrow orthodoxies? What would happen if we recognised and actively worked to dismantle the walls between different groups of developers? Might we not just build better software, but model the kind of thoughtful, collaborative problem-solving our industry desperately needs?

What will outlast the current debates? The code we write today will outlast many of the frameworks and philosophies we’re currently debating. But what will shape not just our individual careers, but the entire culture of our field? What if it’s the habits of mind we develop—whether we choose curiosity over certainty, collaboration over competition?

One final question to sit with: What kind of developer do you want to be remembered as? The one who was always right about their preferred technology stack, or the one who helped others think more clearly about complex problems? The one who won debates, or the one who built bridges? The choice, as they say, is always ours to make.

Putting Folks’ Needs First – Skip the User Stories vs Use Cases Debate

May 22, 2025

Actionable Insights, Antimatter principle, Article, Needs, NoEstimates, Product development, Software development

Leave a comment

Putting Folks’ Needs First – Skip the User Stories vs Use Cases Debate

The software industry spends an enormous amount of energy debating practices—user stories versus use cases, agile versus waterfall, documentation versus conversation. Meanwhile, the people who actually matter—the ones who will use, buy, build, maintain, and profit from our software—are often afterthoughts in these discussions.

It’s time to flip the script. Instead of starting with methodology and hoping it serves people’s needs, let’s start with the Folks That Matter™ and choose our approaches accordingly. This is what the Antimatter principle calls “attending to folks’ needs”—recognising that the value of any practice lies entirely in how well it serves real folks’ actual needs. Let’s can the endless debating by attending to folks’ needs.

Who Are Your Folks That Matter™?

Before you write your first user story or draft your first use case, pause and identify who actually needs to understand and act on your work. These aren’t abstract roles—they’re real people with specific needs, constraints, and ways of thinking.

Sarah, the product manager, thinks in user journeys and business outcomes. She needs to understand how features connect to customer value, competition, and revenue impact. Dense technical specifications make her eyes glaze over, but she can instantly spot when a user story misses a crucial business rule.

Marcus, the lead developer, needs enough detail to identify technical risks and understand how new features interact with existing systems. He’s been burnt by vague requirements that seemed clear in meetings but fell apart during implementation. Interestingly, Marcus has embraced the #NoEstimates movement—he’s found that detailed story point estimation often becomes an end in itself, consuming time that could better be spent actually building software. He prefers breaking work into small, similar-sized pieces that flow predictably.

Katarzyna, the compliance officer, must ensure the product meets regulatory requirements. She needs traceable documentation that auditors can review. Conversational approaches that leave decisions undocumented create legal risks she can’t accept.

Jennifer, the customer success manager, deals with confused users when needs miss real-world scenarios. She has to understand not just what the software should do, but what users might expect it to do based on their mental models.

Each of these people has legitimate needs. The question isn’t which methodology is ‘right’—it’s how to serve all the Folks That Matter™ effectively. As the Antimatter principle reminds us, any practice that doesn’t attend to folks’ needs is waste, regardless of how theoretically sound it might seem.

When teams, and indeed organisations, focus on attending to folks’ needs rather than defending methodological positions, the endless debates about user stories versus use cases simply evaporate. The answer becomes obvious: use whatever works for the specific people and their specific needs, in your specific context.

Matching Methods to People’s Needs

When your Folks That Matter™ need exploration and alignment, user stories excel. The product manager who’s still figuring out what customers really want benefits from the conversation-starting nature of story cards. The development team discovering technical constraints needs the flexibility to evolve requirements as they learn.

Sarah’s team was building a new invoicing feature. They started with a simple story: ‘As a small business owner, I want to send professional invoices so that I get paid faster.’ This sparked conversations about payment terms, tax calculations, and branding options that no one had considered upfront. The story evolved through dialogue, and the final feature was far richer than anything they could have specified initially.

Marcus particularly appreciated this approach because it aligned with his #NoEstimates philosophy. Rather than spending hours estimating a vague story, the team broke it into small, discoverable pieces that they could complete in a day or two. The predictable flow of small stories gave Sarah the planning visibility she needed without the overhead of detailed estimation ceremonies.

When your Folks That Matter™ need precision and accountability, use cases provide the structure they require. The compliance officer who must demonstrate regulatory adherence needs documented workflows with clear preconditions and outcomes. The offshore development team working across time zones needs detailed scenarios they can implement without constant clarification calls.

Katarzyna’s team was building patient data access controls. A user story like ‘As a doctor, I want to access patient records so that I can provide care’ was legally meaningless. They needed use cases that specified exactly which roles could access what data under which circumstances, with full audit trails. The systematic format of use cases made regulatory review straightforward.

When your Folks That Matter™ have different thinking styles, provide multiple views of the same requirements. Don’t force the visual thinker to work with text-heavy use cases or make the detail-oriented analyst guess at implementation specifics from high-level stories.

Marcus and Sarah worked together by starting with story mapping to visualise the user journey, then drilling down into detailed use cases for complex workflows. Sarah could see the big picture and business logic, whilst Marcus got the implementation details he needed. Same requirements, different representations.

Notice how none of these decisions required theological arguments about methodology. Each choice served specific people’s specific needs. Attending to folks’ needs cuts through the debate noise.

The #NoEstimates Reality Check

The #NoEstimates movement highlights a crucial insight: detailed requirements often become proxies for prediction rather than tools for understanding. Teams can spend enormous effort estimating user stories with story points, planning poker, and velocity calculations, but these estimates rarely improve delivery predictability and often distract from actually building software.

Marcus’s team discovered that when they focused on making stories consistently small rather than accurately estimated, their delivery became more predictable. Instead of debating whether a feature was 5 or 8 story points, they asked whether it could be broken into e.g. artefacts that could each be completed in a day or two. This shift changed how they captured folks’ needs —less focus on comprehensive upfront specification, more focus on just-enough detail to start work confidently. See also: the Needsscape.

This doesn’t mean abandoning planning entirely. Sarah still needed roadmap commitments and budget forecasts. But the team found they could provide better predictions by counting delivered stories over time rather than summing estimated story points. Their artefacts became lighter and more focused on enabling flow rather than feeding estimation ceremonies.

The endless debates about estimation versus #NoEstimates dissolve when you ask: what do our Folks That Matter™ actually need for planning and coordination? Often, it’s predictable delivery more than precise estimates.

The Misuse Case Reality Check

Here’s where focusing on Folks That Matter™ becomes crucial: the people who deal with software problems aren’t usually the ones writing requirements. Jennifer in customer success fields calls when users accidentally delete important data. The security team deals with the aftermath when features are misused maliciously.

These voices often aren’t heard during needs capture and evolution, but they represent critical Folks That Matter™. Building ‘misuse cases’ into your process—whether you’re using stories or formal use cases—ensures you’re serving the people who have to deal with problems, not just the ones who use features successfully.

Jennifer pushed her team to consider stories like ‘As a malicious user, I want to exploit the file upload feature so that I can access other users’ data’ and ‘As a confused user, I want to understand why my action failed so that I can correct my mistake.’ These weren’t happy path features, but they prevented real problems for real people.

The Antimatter principle particularly applies here: security reviews and error handling often feel like bureaucratic overhead, but they directly serve the needs of people who deal with the consequences of product failures.

Documentation vs Conversation: Serving Different Needs

The agile manifesto’s preference for ‘individuals and interactions over processes and tools’ doesn’t mean documentation is evil—it means putting people first. Sometimes the Folks That Matter™ need rich conversation to discover what they really need. Sometimes they need comprehensive documentation to do their jobs effectively.

Conversation serves discovery. When your product manager is exploring new market opportunities or your development team is prototyping technical approaches, dialogue-heavy user stories facilitate learning and adaptation.

Documentation serves execution and accountability. When your distributed team needs to implement complex business rules or your compliance officer needs to demonstrate regulatory adherence, written specifications provide the clarity and traceability required.

The most effective teams recognise that these aren’t competing approaches—they’re different tools for serving different people at different times. The Antimatter principle’s “attend to folks’ needs” helps teams avoid dogmatic adherence to either extreme.

The endless documentation versus conversation debates end when you focus on what your specific people need to do their jobs effectively.

Timing That Actually Works for People

The ‘up front versus evolutionary’ debate often ignores the reality of how different Folks That Matter™ actually work. Product managers need enough certainty to make roadmap commitments. Developers need enough detail to minimise rework. Operations teams need enough notice to prepare infrastructure.

Instead of choosing between comprehensive upfront planning and just-in-time discovery, map your requirements approach to the actual decision-making needs of your stakeholders.

Identify architectural decisions early because they affect everyone downstream. The integration approach that seems like an implementation detail to the product manager might require months of infrastructure work from the operations team.

Keep UI and workflow details evolutionary because these benefit from user feedback and technical learning. The exact button placement that seems critical upfront often changes once users actually interact with early versions.

Document agreements when they affect multiple teams because people need to coordinate their work. The API contract between frontend and backend teams needs to be explicit, even if the user story that drives it remains flexible.

This timing approach aligns well with #NoEstimates thinking: instead of trying to estimate everything upfront, identify what decisions must be made early and defer the rest until you have better information.

When you attend to folks’ needs, the timing becomes obvious. No more theoretical arguments about waterfall versus agile—just practical decisions about when different people need different information.

Making It Work: Practical Steps

Start with your Folks That Matter™ inventory. List the real people who need to understand, implement, test, support, and approve your software. Understand their constraints, preferences, and success criteria.

Match your methods to their needs. Use stories when stakeholders need to explore and align. Use cases when they need to implement and verify. Use both when you have both types of needs.

Question estimation ceremonies. Ask whether detailed story point estimation actually serves your Folks That Matter™ or just creates busy work. Consider focusing on consistent story size rather than accurate estimation.

Create feedback loops with the people who live with the consequences. Regular check-ins with customer support, security teams, and operations prevent requirements that look good on paper but fail in practice.

Evolve your approach as your team learns. The startup exploring product-market fit needs different requirements approaches than the enterprise team maintaining critical systems. Let your methods serve your current reality, not your methodology preferences.

Stop the methodological debates. When teams start arguing about the “right” way to write requirements, refocus on the Folks That Matter™. Ask: “Who needs this information, and how do they prefer to receive it?”

The Real Test

The ultimate test of your approach isn’t methodological purity—it’s whether the Folks That Matter™ can successfully do their jobs. Can the product manager make informed decisions? Can the developer implement features correctly? Can the support team help confused users? Can the compliance officer satisfy auditors?

The Antimatter principle provides a simple filter: does this practice attend to folks’ needs? If your user stories help stakeholders align and discover needs, they’re valuable. If they become exercises in elaborate estimation that don’t improve delivery, they’re waste. If your use cases provide necessary precision for implementation and compliance, they’re essential. If they become bureaucratic documentation that nobody reads, they’re overhead.

When you put people first, the user stories versus use cases debate becomes much simpler. You use whatever approaches help your specific stakeholders succeed in their specific contexts. Sometimes that’s collaborative story discovery. Sometimes it’s systematic use case documentation. Most often, it’s a thoughtful combination that serves different people’s different needs.

The approach matters far less than the people. Make sure your approach serves the Folks That Matter™, and the rest will follow. Can the endless debating by attending to folks’ needs—because when you focus on serving real people’s real needs, the “right” answer becomes obvious for your context.

Based on my verification, I found several issues with the citations I originally provided. Let me create a corrected Further Reading section with properly verified citations:

From Dawn Till Dusk

May 19, 2025

Antimatter principle, Article, Attendants, Careers, Coding, History, Needs, Paradigm shifts, Product development, Reinvention, Relationships, Software development

Leave a comment

From Dawn Till Dusk

Reflections on a 50+ Year Career in Software

The Dawn: Programming as Pioneering (1970s)

When I first touched a computer in the early 1970s, programming wasn’t just a job—it was exploration of uncharted territory. We worked with punch cards and paper tape, carefully checking our code before submitting it for processing. A single run might take hours or even overnight, and a misplaced character meant starting over. Storage was 5MByte disk packs, magnetic tapes, more punch cards, and VRC (visible record cards with magnetic stripes on the reverse).

The machines were massive, expensive, and rare. Those of us who could communicate with these behemoths were viewed almost as wizards, speaking arcane languages like FORTRAN, COBOL, Assembler, and early versions of BASIC. Computing time was precious, and we spent more time planning our code on paper than actually typing it.

The tools were primitive by today’s standards, but there was something magical about being among the first generation to speak directly to machines. We were creating something entirely new—teaching inanimate objects to think, in a way. Every problem solved felt like a genuine discovery, every program a small miracle.

The Dusk: The AI Inflection Point (2020s)

In recent years, I’ve witnessed a most profound shift. Machine learning and AI tools have begun to automate aspects of programming we once thought required human creativity and problem-solving. Large language models can generate functional code from natural language descriptions, debug existing code, and explain complex systems.

The pace of change has been breathtaking. Just five years ago, we laughed at the limitations of code-generation tools. Remember Ambase? Or The Last One? Today, junior programmers routinely complete in minutes what would have taken days of specialised knowledge previously.

As I look forward, I can’t help but wonder if we’re witnessing the twilight of programming as we’ve known it. The abstraction level continues to rise—from machine code to assembly to high-level languages to frameworks to AI assistants to …? Each step removed programmers further from the machine while making software creation more accessible.

The traditional career path seems to be narrowing. Entry-level programming tasks are increasingly automated, while senior roles require deeper system design and architectural thinking. And, God forbid, people skills. The middle is being hollowed out.

Yet I remain optimistic. Throughout my career, development has constantly reinvented itself. What we call “programming” today bears little resemblance to what I did in the 1970s. The fundamental skill—translating human needs into machine instructions—remains valuable, even as the mechanisms evolve.

If I could share advice with those entering the field today: focus on attending to folks’ needs, not on coding, analysis, design; seek out change rather than just coping passively with it; understand systems holistically; develop deep people knowledge; and remember that technology serves humans, not the other way around.

Whatever comes next, I’m grateful to have witnessed this extraordinary journey—from room-sized computers with kilobytes of memory to AI systems that can code alongside us and for us. It’s been a wild ride participating in one of humanity’s most transformative revolutions.

What Makes a Great User Story?

May 16, 2025

Antimatter principle, Article, Attendants, Feedback, Learning, Needs, Organisational effectiveness, Paradigm shifts, Prod•gnosis, Product development, Quantification, Quintessence, Requirements, Story

Leave a comment

What Makes a Great User Story?

A great user story accurately pinpoints what people truly need from your product and translates those needs into guidance that development teams can easily understand and act upon. It’s worth noting that “user story” is actually a misnomer – these might better be called “Folks That Matter™ stories” since they centre on real people with real needs, not just abstract “users” of a system.

Core Components

While there are many formats for writing these stories, the essential components remain consistent: identifying the Folks That Matter™, their needs, and the benefits they’ll receive. The story should clearly communicate who needs the feature, what they need, and most importantly, why they need it.

The Living Nature of Stories

Folks That Matter™ stories aren’t static artefacts – they evolve, morph, and grow across numerous iterations. Like elements in a Needsscape (the visualisation of all the folks that matter and their changing needs), stories adapt as we gain deeper understanding of people’s requirements. What begins as a simple narrative might develop into a complex web of interconnected needs as teams learn more through development cycles, feedback loops and product deployments.

Essential Qualities

Great Folks That Matter™ stories share several important characteristics:

They can be developed independently from other stories
Their details remain open to discussion and refinement
They deliver clear value to the folks that matter™
Teams can reasonably estimate the effort required
They’re focused enough to complete in a single iteration
They include clear criteria for testing and validation

Focus on Needs

The most effective Folks That Matter™ stories focus on identifying and attending to needs rather than implementing specific solutions. They describe outcomes and the results foilks gain, not the technical implementation. This gives development teams space to find the best technical approaches.

Clear Acceptance Criteria

Each Folks That Matter™ story includes explicit acceptance criteria that define when the story is complete and needs have been met. Such criteria will be testable, quantified (Cf. Gilb), and agreed upon by all the Folks That Matter™.

Summary

Effective Folks That Matter™ stories serve as bridges between human needs and technical solutions. They identify the Folks That Matter™, articulate their genuine needs, and provide development teams with clear guidance – while leaving room for creativity in implementation. Rather than static requirements documents, they function as living artefacts that evolve through conversation and iteration and feedback. By focusing on outcomes rather than specifications, and by including clear, quantified acceptance criteria, these stories help teams build products that truly meet people’s needs—the essence of successful product development and the cornerstone of navigating the broader Needsscape of any organisation.

The Art of Being Methodical

May 15, 2025

Actionable Insights, Article, Familiar, Product development, Quintessence

Leave a comment

The Art of Being Methodical

The Missing Link in Modern Work

In a world that often celebrates spontaneity and quick thinking, there’s a profound power in being methodical. This isn’t about rigid methodologies or specific techniques—it’s about embracing a perspective that values deliberate, systematic approaches to life’s challenges and opportunities.

What Does It Mean to Be Methodical?

Being methodical means approaching tasks with a prepared idea of how to proceed from start to finish, with consistency, and with attention to detail. It’s the difference between rushing through an endeavour and thoughtfully executing each step with intention. A methodical person doesn’t just know what to do—they understand why they’re doing it and how each action connects to their larger goals.

The Curious Absence of Methodical Approaches

In collaborative knowledge work, there’s a peculiar paradox: whilst we constantly seek ways to improve our productivity and effectiveness, almost no one has established a concrete routine to achieve these goals. Over decades of professional experience, it’s been remarkably uncommon for me to encounter individuals or teams who have developed, evolved, and maintained a disciplined, methodical approach to their work.

This absence leads to a persistent frustration in collaborative environments: watching colleagues overlook the power of—and need for—methodicality. Teams typically waste inordinate time and effort inventing ways to align their purpose, repeatedly struggling with challenges that a well-established routine could readily address.

Overcoming the “Boring” Perception

Let’s address the elephant in the room: to many in the tech world, the mere mention of routine elicits stifled yawns or outright resistance. There’s a prevailing notion that methodical approaches stifle creativity and innovation—that they’re the antithesis of the dynamic, fast-paced nature of technology work.

This perception, whilst understandable, misses the deeper value of structured approaches. Being methodical isn’t about rigidity—it’s about creating thoughtful frameworks that guide actions whilst remaining adaptable to new information and changing circumstances.

Learning from Existing Frameworks

Several established frameworks have emerged to bring structure to collaborative work. One such approach is Javelin, a deliberate method we developed during my time at Familiar for approaching collaborative endeavours with intention.

At its core, the Javelin approach involves:

Choosing a name for easy reference to “this thing which we have come together to create/build/grow”
Discussing various perspectives regarding common purpose, leading to a Statement of Purpose
Listing key stakeholders and their respective needs (what they say they need, not what we’d like them to need)
Creating shared understanding about how ambiguities will be resolved during development

The approach aims to address inherent risks in collaborative endeavours, including the the enormous and oh-so-common risk of spending precious time and effort building the wrong things. It seeks to establish the minimum amount of structure needed to serve a joint endeavour effectively.

Along with other systems like Scrum and Kanban that have gained prominence in software development, these frameworks share underlying principles of routine, structure, and disciplined approach that can be valuable across all domains. Personal Kanban, for instance, demonstrates how methodical approaches can be adapted for individual use, proving that structured routines aren’t just for large-scale operations.

Note: For those interested in exploring Javelin in greater depth, full details can be found in Appendix A of my book “Quintessence“.

The Core Elements of Methodical Thinking

At its heart, methodical thinking encompasses several key principles:

Intentionality – Making conscious choices rather than acting on impulse
Systematic approach – Breaking complex messes into manageable artefacts
Consistency – Applying the same level of care to each component
Reflection a.k.a. retrospection – Regularly evaluating progress and adjusting as needed

The True Purpose: Enhanced Alignment

What frameworks like Javelin fundamentally offer isn’t a set of repeatable practices—it’s a pathway to deeper group alignment. The primary value of being methodical lies in its ability to get teams genuinely aligned on what they’re trying to achieve together. When a group follows a shared methodical approach, they’re not just going through motions; they’re participating in a common language and framework for understanding their collective purpose.

The Benefits of Embracing Methodical Approaches

1. Cognitive Offloading

When we establish methodical routines, we free our minds from the burden of constant decision-making about the way the work might work. This mental energy can then be redirected towards solving actual problems rather than figuring out how to approach them. a.k.a. “constantly reinventing the wheel”.

2. Consistent Quality

A well-defined methodical approach creates a baseline for quality. When we know exactly how we’re going to tackle each type of task, we’re less likely to miss crucial steps or take shortcuts under pressure.

3. Improved Learning

Methodical approaches provide a framework for continuous learning. When we follow a consistent approach, it becomes easier to identify what works and what doesn’t, allowing for meaningful iterations and refinements.

4. Enhanced Group Understanding

Perhaps most crucially, methodical routines create a shared context within which teams can better understand their collective aims. This alignment leads to more effective collaboration and fewer misunderstandings about goals and priorities.

Implementing Methodical Approaches: A Practical Path

The key to successfully becoming more methodical lies in starting small. Rather than attempting to overhaul entire working practices overnight, begin with a single, well-defined artefact. This might be as simple as establishing a daily list of priorities for joint review, or a structured artefact for product kickoffs.

The Role of Flexibility

Understand that being methodical doesn’t mean rigidity. Effective methodical approaches are living frameworks that evolve based on experience and changing circumstances. The goal is to create a foundation that supports rather than constrains our work.

Moving Forward

The challenge for modern workers and teams is to recognise the value of methodical thinking without falling into the trap of bureaucracy. This requires a delicate balance between structure and flexibility, between established practices and innovation.

As we move forward in an increasingly complex work environment, perhaps it’s time to reconsider our relationship with being methodical. Rather than viewing it as a constraint, might we come to see it as a tool for liberation—freeing our minds to focus on the truly challenging aspects of our work whilst ensuring consistency and quality in our daily tasks? More importantly, it’s a powerful mechanism for achieving what every successful team needs—a clear, shared understanding of what they’re trying to accomplish together.

The next time you face a challenge, consider embracing the methodical path. You might find that taking the time and effort to consider method actually helps you move forward more effectively in the long run.

From Operational Value Streams to Prod•gnosis

May 12, 2025

Actionable Insights, Alien tech, Antimatter principle, Article, Business, Capability development, Digital evolution, Flow, Flow•gnosis, Organisational Therapy, Paradigm shifts, Prod•gnosis, Product development, SAR Organisations, Software development, Systems thinking, Value streams

Leave a comment

From Operational Value Streams to Prod•gnosis

Connecting Allen Ward and Bob Marshall’s Product Development Philosophies

A thoughtful exploration of two complementary approaches to transforming product development

Introduction

In the world of product development theory, two complementary approaches stand out for their innovative thinking about how organisations might tackle the creation of new products: Dr Allen Ward’s approach, born of many years researching the Toyota approach, and my own approach, which I’ve named Prod•gnosis

While Dr. Ward’s work on operational value streams emerged from his extensive study of Toyota’s product development system, Prod•gnosis builds upon and extends his ideas into a comprehensive framework focused on organisational transformation for better product development, reduced costs, and more appealing products.

This post explores the connections between these two approaches and how, together, they offer a powerful lens for fundamentally rethinking product development.

The Foundation: Allen Ward’s Operational Value Streams

Allen Ward’s core insight, which has become a cornerstone of lean product development e.g. TPDS, is elegantly simple yet profound:

“The aim of development is, in fact, the creation of profitable operational value streams.”

An operational value stream (OVS) represents the set of steps that deliver a product or service directly to the customer (and others). This includes activities like manufacturing a product, fulfilling an order, providing a loan, or delivering a professional service.

Ward’s work, drawing from his decade of direct research at Toyota, showed that effective product development isn’t just about designing isolated products. Rather, it’s about designing the entire system through which those products will be manufactured, shipped, sold, and serviced. This holistic approach explains much of Toyota’s success in bringing new products to market quickly and profitably.

Ward emphasised that creating profitable operational value streams requires:

A “whole product” approach that involves every area of the business
Knowledge creation as the central activity of product development
The use of tools like trade-off curves for decision-making and teaching
Systematic waste elimination throughout the development process

Prod•gnosis: Building on Ward’s Foundation

I’m delighted to acknowledge my intellectual debt to Dr. Ward. In my writings on Prod•gnosis, I directly reference Dr. Ward’s influence, adopting his view of “business as a collection of operational value streams.”

I define Prod•gnosis (a portmanteau of “Product”, and “Gnosis” meaning knowledge) as a specific approach to product development that places the creation of operational value streams at its centre. However, Prod•gnosis extends Dr. Ward’s thinking in several notable ways:

The Product Development Value Stream (PDVS)

Prod•gnosis introduces the concept of a dedicated “Product Development Value Stream” (PDVS) as a distinct organisational capability responsible for creating and instantiating operational value streams. I previously wrote:

“I suggest the most effective place for software development is in the ‘Product Development Value Stream’ (PDVS for short) – that part of the organisation which is responsible for creating each and every operational value stream.”

This represents a significant organisational shift from traditional department-based structures.

Challenging IT’s Role in Product Development

Prod•gnosis particularly questions the conventional role of IT departments in product development. Prod•gnosis argues that software development does not belong in IT departments but instead is much more effective when situated within the Product Development Value Stream:

“If we accept that the IT department is poorly suited to play the central role in a Prod•gnosis-oriented organisation, and that it is ill-suited to house or oversee software development (for a number of reasons), then where should software development ‘sit’ in an organisation?”

The answer is clear: within the PDVS, where it can directly contribute to creating operational value streams.

Incremental Implementation

Prod•gnosis proposes a “Lean Startup-like approach” to implementing operational value streams:

“I’m thinking more in terms of a Lean Startup-like approach – instantiating version 0.1 of the operational value stream as early as possible, conducting experiments with its operation in delivering an MVP (even before making its 1.0 product line available to buying customers), and through e.g. kaizen by either the product development or – the few, early – operational value stream folks (or both in collaboration), incrementally modifying, augmenting and elaborating it until the point of the 1.0 launch, and beyond.”

This represents a pragmatic approach to putting Dr. Ward’s principles into practice.

Key Points of Alignment

Despite their different emphases, Ward and Prod•gnosis’ approaches share significant philosophical alignment:

1. Value Stream-Centric View

Both view business fundamentally as a series of operational value streams, with product development focused on creating and improving these streams rather than just designing isolated products.

2. Whole Product Approach

Both emphasise the importance of involving all aspects of a business in product development. Prod•gnosis references Toyota’s “Big Rooms” (Obeya), which Ward studied extensively, as an example of effective cross-functional collaboration.

3. Systems Thinking

Both reject piecemeal improvements and advocate for fundamental shifts in organisational perspective. As Ward wrote and Prod•gnosis quotes: “Change will occur when the majority of people in the organisation have learned to see things in a new way.”

And see also: Organisational Psychotherapy as a means to help organisations see things in a new way.

4. Flow Focus

Both emphasise the importance of flow in product development, with Prod•gnosis particularly focused on aspects like flow rate, lead time, cycle time, and process cycle efficiency – both of the PVDS and the OVSs.

Practical Applications of the Combined Approach

Organisations seeking to apply these ideas might consider:

Creating a dedicated Product Development Value Stream responsible for designing and implementing operational value streams (a.k.a. new products)
Removing software development from IT departments and placing it within the PDVS
Adopting a “whole product” approach that brings together all business functions in the service of product development
Implementing early versions of operational value streams viw the PVDS, and then iteratively improving them
Measuring and optimising flow through the product development process

Getting There: Transitioning to Prod•gnosis

Moving from conventional product development approaches to a Prod•gnosis model represents a significant organisational transformation. As Prod•gnosis acknowledges,

“getting there from here is the real challenge”

The transition requires more than just structural or process changes—it demands a fundamental shift in collective mindset.

The Challenge of Organisational Transformation

The Lean literature is replete with stories of organisations failing to move from vertical silos to horizontal value streams. Prod•gnosis presents additional challenges by proposing to remove software development from IT departments and create an entirely new organisational capability (the PDVS).

As Ward wisely noted and Prod•gnosis quotes:

“Change will occur when the majority of people in the organisation have learned to see things in a new way.”

This insight highlights that sustainable transformation depends on shifting collective beliefs rather than merely implementing new processes.

Organisational Psychotherapy as a Path Forward

In Organisational Psychotherapy I propose as a methodical approach to shifting collective assumptions and beliefs. As an Organisational Psychotherapist, I apply psychotherapy techniques not just to individuals but to entire organisations.

OP recognises that organisations, like individuals, operate based on deep-seated assumptions and beliefs—i.e. “memeplexes” These collective mental models determine how an organisation functions and often unconsciously resist change. And see my book “Hearts over Diamonds” (Marshall, 2018) for more in-depth discusion of memeplexes.

Organisational Psychotherapy works by:

Helping organisations become aware of their current collective beliefs (surfacing)
Examining how these beliefs serve or hinder effectiveness (reflecting)
Supporting the organisation in exploring new, more productive mental models
Facilitating the adoption of these new models

For organisations seeking to move toward Prod•gnosis, this might involve addressing fundamental beliefs about:

The nature and purpose of product development
The relationship between software development and IT
The definition of “whole product”
The organisation’s relationship with customers and all the Folks That Matter™
How value flows through the organisation

As Prod•gnosis emphasises, this isn’t a quick fix. The transformation to Prod•gnosis represents a significant evolution in how organisations think about and structure product development. The journey requires patience, persistence, and a willingness to examine and change foundational assumptions about how product development might work significantly better.

Conclusion

The synthesis of Allen Ward’s operational value stream concept and Prod•gnosis offers a powerful framework for rethinking product development. By viewing product development as the creation of complete operational value streams and establishing organisational structures that support this perspective, organisations can potentially achieve the kind of rapid, profitable product development that Toyota has demonstrated.

As more organisations struggle with digital transformation and the ever-increasing importance of software in product development, these two complementary approaches may provide a valuable roadmap for fundamentally rethinking how products are developed and brought to market.

What are your thoughts on the operational value stream approach to product development? Have you seen examples of it in practice? I’d love for you to share your experiences in the comments below.

Prod•gnosis: Nothing New, Just Better Organised

April 25, 2025

Actionable Insights, Article, Capability development, Prod•gnosis, Product development, Productivity, Quintessence, Value streams

Leave a comment

Prod•gnosis: Nothing New, Just Better Organised

Every organisation creates new operational value streams when launching products—they just do it chaotically. When a new product line emerges, companies cobble together resources across departments, form temporary project teams, and somehow bring products to market. The Prod•gnosis model simply formalises what already happens, but in a structured way that eliminates the chaos and the costs.

The Core Insight: Acknowledge What You’re Already Doing

Organisations are already operating with two distinct value streams, though almost never by design:

Ad hoc Product Development: Temporary cross-functional efforts that somehow create new products
Operational Value Streams: Systems that eventually deliver and support those products

The problem isn’t that companies don’t create new operational value streams—they do. But they do it inconsistently, reactively, implicitly, and often painfully.

The Current Reality: Chaotic Creation

Look carefully at how your organisation actually launches new products:

Marketing creates requirements in isolation
Product teams prioritise based on limited technical understanding
Engineering builds what they interpret from incomplete specifications
Operations scrambles to ship and support whatever gets delivered to them
Project managers desperately try to coordinate across departmental boundaries

This chaotic approach somehow delivers products, but at tremendous cost: missed deadlines (cost of delay), technical debt, market misalignment (cost of focus), and burned-out teams. You’re already creating operational value streams—just in the most painful way possible.

From Chaos to Capability: The PDVS Advantage

A Product Development Value Stream (PVDS) simply formalises what you’re already attempting to do, transforming a chaotic process into a permanent ever-improving capability:

Instead of forming temporary project teams, maintain dedicated cross-functional groups
Rather than reinventing processes with each new product, develop institutional expertise
Replace improvised handoffs with designed collaboration
Transform one-off learning into compounding organisational knowledge
Make schedules highly dependable through e.g. set-based concurrent engineering

You’re already paying the cost of creating new operational value streams—adopting the Prod•gnosis perspective just ensures you get full value from that effort.

Making the Implicit Explicit

To transform your chaotic product creation into a structured capability:

Identify who’s actually creating your new operational value streams today
Formalise these cross-functional collaborations into permanent teams
Move software development from IT into this product development capability
Replace departmental handoffs with integrated teamwork
Capture the knowledge that’s currently lost between product launches

The Bottom Line

Your organisation is already creating new operational value streams—just inefficiently, and without realising it. Prod•gnosis doesn’t ask you to do anything fundamentally new. It simply recognises and organises what you’re already doing, transforming chaos into capability.

The cost is organisational change. The benefit is turning an expensive, unpredictable process into a strategic advantage. Nothing new, just better organised.

Prod•gnosis: Revolutionising Product Development

April 22, 2025

Actionable Insights, Article, Change management, Prod•gnosis, Product development, Productivity, Set-based Concurrent Engineering, TPDS, Value streams

Leave a comment

Prod•gnosis: Revolutionising Product Development

A Radical New Paradigm for Creating Market-Leading Products

The Challenge

In boardrooms across the globe, executives are grappling with an uncomfortable truth: traditional product development is failing them.

Have you noticed these warning signs in your organisation?

Software teams working in isolation, disconnected from the commercial realities of your market
IT departments wielding disproportionate influence over development priorities
Products launching months—sometimes years—behind schedule
Development budgets routinely exceeded, with decreasing returns on investment
Cross-functional collaboration reduced to frustrating handoffs and email chains
Competitors consistently beating you to market with innovative offerings

The consequences are dire: market opportunities missed, customer loyalty eroded, and competitive advantage surrendered. All while your expenditure on product development continues to rise.

You’ve likely attempted various remedies: agile methodologies, design thinking workshops, innovation labs, digital transformation programmes. Yet fundamental problems persist because these solutions address symptoms rather than the underlying organisational disease.

The root issue isn’t your people or their capabilities. It’s a product development model that was designed for a different era—one where functional specialisation and departmental silos made sense. That era has ended, yet its organisational structures persist.

The Cost of Inaction

What happens if you continue with your current approach?

In the short term, you’ll see incremental improvement from your latest change management initiative, giving the illusion of progress. Teams will adapt to new approaches and practices while maintaining old mindsets and organisational boundaries.

But the trajectory remains unchanged:

Development cycles that stretch far beyond market windows
Products that arrive too late to capture premium market positions
Talented specialists who become increasingly frustrated by organisational barriers
Innovation that happens despite your structure, not because of it
A widening gap between your offerings and what customers truly value

The most concerning cost isn’t measured in Pounds or Dollars or Euros but in opportunity. While your organisation continues to wrestle with structural inefficiencies, more nimble competitors will seize the market positions that should have been yours.

Consider the cautionary tales of Nokia, Kodak, and Blackberry—market leaders who couldn’t adapt their product development approaches quickly enough to changing market conditions. Their valuable assets, talented people, and strong brands weren’t enough to save them from organisational structures that couldn’t deliver innovation at the pace the market demanded.

If these trends continue unchecked in your organisation, where will you be in three years? Five years? Will you still be a market leader, or will you be fighting for relevance? Or even survival?

The Revolutionary Core: Dual Value Streams!

At the heart of Prod•gnosis lies its most revolutionary concept—a fundamental reimagining of how organisations structure themselves for product development:

The Breakthrough: Two Distinct but Interconnected Value Streams

The Prod•gnosis model introduces a radically different organisational structure built around two types of value streams:

Product Development Value Stream (PDVS): A permanent organisational capability dedicated to creating new operational value streams. This is not a project team assembled for a single product, nor a functional department like R&D. It’s a persistent capability that specialises in the complex work of bringing new products a.k.a. operational value streams from concept to market readiness.
Operational Value Streams: Dedicated streams for each product line that handle everything needed to deliver, support, and evolve that product for customers. Each operational value stream is custom-designed by the PDVS to optimally support its specific product.

This dual structure creates a powerful organisational engine: the PDVS continuously designs and launches new operational value streams, each perfectly tailored to its specific product. As these operational value streams mature, they feedback insights to the PDVS, creating a virtuous cycle of learning and improvement.

Why This Dual Structure Changes Everything

This isn’t simply reorganising boxes on an org chart—it’s a fundamental rethinking of how value creation works:

Specialisation in Creation vs. Operation: The PDVS develops deep expertise in the complex work of product creation, while operational value streams excel at efficient, ongoing delivery. Each focuses on what it does best.
Elimination of Functional Handoffs: By bringing together all needed specialists within value streams, Prod•gnosis eliminates the costly handoffs between departments that plague traditional development.
Permanent Capability Building: Unlike project teams that form and disband, the PDVS builds institutional knowledge about effective product creation that compounds over time.
Perfect Products and Perfect Delivery Systems: The PDVS designs not just the product itself, but the entire operational system that will deliver it—ensuring that both are optimised together.
Knowledge Reuse Without Reinvention: Learnings from creating one operational value stream inform the next, creating an accelerating cycle of organisational learning.
Optimised Flow of Work and Value: The dual value stream structure dramatically improves flow—the smooth, efficient movement of work through the organisation. By organising around value streams rather than functional departments, Prod•gnosis eliminates the queues, batching, and priority conflicts that impede traditional development. Work moves continuously from concept to cash without the stops, starts, and detours that characterise departmental handoffs. This improved flow translates directly to faster time-to-market, higher quality, and more innovative products. Most importantly, it creates flow not just of individual products but of the organisation’s entire product portfolio—a pipeline of innovation that continuously delivers value to customers and revenue to the business. See also Toyota’s TPDS and their reliance on set-based concurrent engineering.

How This Differs from Traditional Approaches

To appreciate the magnitude of this innovation, consider how traditional organisations develop products—through a complex matrix of functional departments:

Marketing defines requirements
Product management prioritises features
Design creates user experiences
Engineering builds technical components
Quality assurance validates functionality
Operations prepares for deployment
Sales and support prepare for customer engagement

Each handoff between departments introduces delays, misunderstandings, and compromises. Each group optimises for their local priorities rather than the whole product. The result? Watered-down products that take too long to develop and fail to delight customers.

The contrast is stark: In traditional organisations, product development happens through departments with competing priorities. In Prod•gnosis, product development happens through a dedicated value stream designed specifically for that purpose, which then creates operational value streams designed specifically for each product.

Proof in Practice

Organisations that have implemented this dual value stream model report transformative outcomes that traditional approaches simply cannot match:

Dramatic acceleration of time-to-market as handoffs between functional silos disappear
Higher-quality products as specialists collaborate directly rather than throwing work “over the wall”
Reduced coordination overhead as value streams contain all needed capabilities
Continuous learning as the PDVS applies insights from each new product to the next
True cross-functional integration as specialists work together daily rather than in isolated steps (Cf. the Obeya or Big Room)

Most significantly, the PDVS becomes an organisational capability that competitors cannot easily replicate—creating sustainable competitive advantage through structural innovation rather than product features alone.

The Solution

This is where Prod•gnosis enters the conversation—not as yet another change mangement approach but as a fundamentally different organisational model for product development.

Prod•gnosis (from “Product” and “Gnosis,” meaning knowledge) reimagines your entire approach to creating and delivering new products. Rather than treating product development as a series of projects passed between departments, it organises your business around two types of value streams:

Operational Value Streams dedicated to specific product lines
A Product Development Value Stream specialised in creating new operational value streams

This revolutionary structure delivers five key advantages:

1. Liberation from IT Control

In traditional organisations, software development sits within IT departments, creating a fundamental misalignment of priorities. Prod•gnosis moves software development into the Product Development Value Stream, ensuring technical priorities align directly with market opportunities.

2. Whole Product Integration

Rather than developing technical components in isolation, Prod•gnosis integrates all aspects of the product experience—functionality, user experience, marketing, support—into a cohesive development process inspired by Toyota’s “Big Room” (Obeya) concept.

3. Specialist Collaboration Without Silos

Specialists maintain their expertise without being trapped in functional departments. They collaborate directly with other disciplines in dedicated value streams, eliminating the costly handoffs and misalignments that plague traditional structures.

4. Service-Oriented Perspective

Even physical products are ultimately services delivering value to customers. This perspective shift generates innovative approaches to both product design and ongoing customer relationships.

5. Organisational Capability Building

Instead of assembling and disassembling project teams, Prod•gnosis builds persistent organisational capabilities for product development, creating sustainable competitive advantage through institutional learning.

Proven Results

Organisations that have embraced Prod•gnosis principles report transformative outcomes:

Time-to-market reductions of 40-60% by e.g. eliminating cross-functional handoffs
Development cost reductions of 25-35% through elimination of coordination waste
Breakthrough innovations enabled by cross-functional collaboration
“Mafia Products” so compelling that customers can’t refuse them and competitors can’t match them (See: Goldratt and the Theory of Constraints)

Most importantly, they’ve built sustainable capability for continued market leadership—not through one-off successes but through systematic organisational design focused on flow, value, and knowledge.

Your Next Step

Transforming your product development approach doesn’t happen overnight, but it begins with recognition that the collective assumptons and beliefs baked into your current structure may be the very thing preventing you from achieving your market ambitions.

The Prod•gnosis Handbook (coming soon) will provide a comprehensive guide to implementing this revolutionary approach in your organisation. It offers both the conceptual framework and practical implementation steps needed to transform how your organisation develops products.

The world’s most innovative companies (Toyota, Haier, etc.) have already moved in this direction. Will you join them, or will you be explaining to your board in three years why your competitors consistently beat you to market with superior offerings?

The choice—and the competitive consequences—are yours.

Ready to explore how Prod•gnosis could transform your organisation’s approach to product development? The Prod•gnosis Handbook will provide a comprehensive guide to implementing this revolutionary approach. In the mean time, you might like to get in touch with the FlowChainSensei (Bob Marshall). Getting started on this adventure is a simple as adding a comment to this post.

You may also like to listen to an (AI-generated) Deep Dive conversation on this post.

Applying Dialectical Behaviour Therapy (DBT): A Collective Approach for Software Teams

March 28, 2025

Article, Business, Collective psyche, Organisational effectiveness, Organisational Therapy, Product development

Leave a comment

Applying Dialectical Behaviour Therapy (DBT): A Collective Approach for Software Teams

[Tl;Dr: Embracing acceptance and change simultaneously affords teams signficant benefits]

Understanding DBT’s Foundations

Dialectical Behaviour Therapy (DBT), originally developed by psychologist Marsha Linehan in the late 1980s to treat borderline personality disorder, has evolved far beyond its clinical origins. While its application to individual therapy is well-documented, its principles offer powerful frameworks for understanding and transforming team dynamics within e.g. software development and other product, product-led organisations. This article explores how organisational psychotherapists and engineering leaders can apply DBT concepts to collective psychology rather than focusing solely on individual interventions.

DBT vs. CBT: Key Distinctions

Before diving into applications, we might choose to understand what makes DBT distinct from traditional Cognitive Behavioural Therapy (CBT). While DBT is a specialised form of CBT, they differ in several key aspects.

Where CBT focuses primarily on identifying and changing negative thought patterns, DBT incorporates a dialectical approach that emphasises both acceptance and change, simultaneously—much like balancing technical debt management with new feature development. This parallels how teams can choose to both accept the current state of their codebase and the way their work works, while continuously evolving them.

DBT includes four specific modules (mindfulness, distress tolerance, emotion regulation, and interpersonal effectiveness) compared to CBT’s focus on cognitive restructuring and behavioural activation. These modules align remarkably well with the challenges e.g. software teams face in maintaining focus, handling production emergencies, managing team stress, and navigating cross-functional collaboration.

Additionally, DBT employs a comprehensive approach including multiple modalities, while CBT is typically delivered as individual therapy. This multi-faceted approach mirrors how software development requires multiple interconnected practices and ceremonies to function effectively.

Terms

The term “dialectical” refers to a philosophical concept that embraces the tension between opposing viewpoints and seeks integration rather than seeing them as contradictory. It signals the recognition that seemingly conflicting assumptions and beliefs can both be valid simultaneously, and reality is constantly changing through these tensions.

In software development contexts, this dialectical viewpoint helps move beyond binary thinking to see that a team can both accept its current collective assumptions and beliefs AND work toward improvements simultaneously. It enables development teams to hold tensions like speed versus quality, innovation versus stability, and individual autonomy versus management control. Rather than viewing these as conflicts to be resolved by choosing one side, teams can learn to navigate the productive integral path that honours both poles.

Seven DBT Applications for Development Teams

1. Collective Dialectical Thinking

Dialectical thinking at the team and organisational levels creates the capacity to transcend binary, either/or thinking that often hampers progress and success. Teams can create structures that explicitly recognise productive tensions instead of trying to eliminate them, such as balancing specialisation with cross-functional collaboration. During discussions, teams benefit from mapping polarities rather than forcing false choices—for example, exploring how they might maintain backward compatibility while modernising their architecture, rather than treating these as mutually exclusive goals.

Experienced developers can be helped to identify “both/and” solutions when faced with seeming contradictions like velocity versus quality. Teams can establish dialectical principles in their assumptions, acknowledging, for example, that they value both shipping quickly AND building robust systems. This dialectical foundation extends to e.g. retrospectives, where protocols can be developed to intentionally explore opposing viewpoints as complementary rather than contradictory, creating much richer insights than when team members feel they must choose sides.

2. Group Emotional Intelligence

Collective emotional intelligence focuses on the emotional climate and capabilities of the development team as a whole. This begins with enabling the team to regularly assess team health to understand prevailing emotional states during sprints and releases. Teams develop a shared vocabulary for discussing collective emotions around deadlines, technical challenges, and organisational pressure, moving beyond individual experiences to recognise team-level emotional patterns.

After production incidents or challenging releases, established rituals for acknowledging and processing collective emotions reduce lingering resentment or anxiety, and their effects on future work. Systems can be developed to notice when collective emotions affect code quality and decision-making, particularly when teams feel rushed or overwhelmed. Folks can learn to recognise team-level emotional dynamics rather than individualising all stress responses, addressing the root causes of team tension rather than focusing solely on individuals who express frustration. Over time, an organisation can map how different teams develop distinct emotional cultures and how these interact across product boundaries, creating awareness of how emotional states spread throughout the organisation.

3. Organisational Mindfulness

Creating structures and practices that enhance the development team’s collective ability to remain present, aware, and non-judgmental can significantly improve performance and wellbeing. Brief mindfulness practices at the start of standups or planning sessions can help centre the team and improve focus. Sprint rhythms that include regular reflection on e.g. current code quality and technical debt create awareness of the present state before rushing toward future goals.

Teams can benefit from developing “listening systems” that gather real-time feedback from the Folks That Matter™ without immediate defensive reactions. This cultivates curiosity rather than judgment about these folks’ experiences. Through mindfulness and cultivation of collective observation skills during e.g. code reviews and architecture discussions, teams can learn to notice patterns without immediately jumping to solutions or blame. Teams can also establish practices that help them notice when they’re acting from habit and unconscious collective assumptions rather than conscious choice, questioning “the way we’ve always done it” when it no longer serves current needs. Ultimately, these practices help create environments that support focused attention rather than constant context-switching, acknowledging the cognitive costs of multitasking in development work.

4. Cultural Validation Patterns

Examining how validation and invalidation operate as systemic patterns in software teams reveals important dynamics that affect both performance and belonging. Teams can choose to map how different perspectives are validated or invalidated within the team, noticing when certain approaches or technologies receive automatic credibility while others must prove their worth. Analysis of communication patterns across engineering hierarchies often reveals systematic invalidation of junior developers, whose ideas may be dismissed without full consideration.

Code review systems can be restructured to include validation of approach alongside constructive feedback, acknowledging what works before suggesting improvements. Teams develop cultural norms that recognise multiple implementation approaches can be valid simultaneously, moving beyond “one right way” thinking. Engineering leaders adopt practices that validate the emotional reality of challenging deadlines while still meeting commitments, acknowledging stress without using it as an excuse for quality lapses. Communication protocols in technical discussions require acknowledging others’ perspectives before offering alternatives, ensuring everyone feels heard even when their approach isn’t chosen.

5. Systemic Emotion Regulation

Focusing on how emotions flow through and are managed at the team level creates more resilient product organisations. Teams identify development “trigger points” that consistently produce collective stress, such as deployments, legacy code modification, or interactions with particularly challenging stakeholders. With this awareness, they create systems for anticipating emotionally challenging periods like major refactorings or platform migrations, building in additional support and space for these known stressors.

When frustration with technical challenges becomes overwhelming, team “cool down” protocols help restore cognitive function and prevent hasty decisions made from emotional reactivity. Cultural practices normalise emotional awareness during technically stressful periods, removing the stigma around acknowledging when the team feels stressed or anxious. Sprint workflows are designed to account for natural energy cycles and cognitive load, recognising that continuous maximum output is neither sustainable nor joyful nor effective. Structural supports like psychological safety policies enable healthy processing of technical setbacks, encouraging open discussion of failures as learning opportunities rather than sources of shame.

6. Collective Distress Tolerance

Building team capacity to function effectively during periods of uncertainty and challenge is essential in today’s complex development environment. Teams can develop shared practices for navigating technical ambiguity without premature architectural decisions, staying with the discomfort of not knowing until sufficient information emerges. Team narratives normalise productive struggle as part of complex problem-solving, reframing difficulties as expected parts of meaningful work rather than signs of collective incompetence.

Incident response protocols incorporate acceptance of discomfort alongside systematic troubleshooting, acknowledging the anxiety that production issues create while maintaining methodical problem-solving approaches. Teams receive training in collective self-regulation techniques during production issues or tight deadlines, supporting each other through high-pressure situations without adding interpersonal stress through e.g. blaming. Resilience builds through graduated exposure to complex technical challenges, intentionally taking on increasingly difficult problems that stretch capabilities without overwhelm. Support structures sustain effectiveness during prolonged uncertainty in product direction or technical approach, providing stability amidst ambiguity.

7. Team Interpersonal Effectiveness

Focusing on how different roles and specialisations within teams interact with each other creates smoother collaboration and reduces costly handoff failures. Teams map communication patterns between frontend, backend, QC, and DevOps to identify breakdowns and improve cross-functional understanding. Shared protocols for cross-functional technical requests and dependencies clarify expectations and reduce frustration around blocked work.

Team norms balance direct technical feedback with relationship maintenance, allowing for honest critique that improves the work without damaging working relationships. Clear paths for resolving inter-disciplinary conflicts honour multiple technical perspectives, recognising that each specialisation brings valuable insights to problem-solving. Folks can model healthy boundary-setting while maintaining collaborative approaches, demonstrating how to say no to unreasonable requests while remaining constructive partners. Feedback loops strengthen connections between interdependent technical specialities, creating ongoing dialogue rather than siloed work punctuated by throw-it-over-the-wall handoffs.

Conclusion

By adapting DBT principles from individual psychology to collective team dynamics, software development organisations can create more resilient, emotionally intelligent teams. This approach treats the development team itself as a complex system with its own psychological processes and needs, capable of both accepting current technical realities and creating meaningful architectural change.

The dialectical perspective can offer particular benefit in today’s complex workplace landscape, where teams must often balance competing priorities like technical debt versus new features, or scalability versus time-to-market. Rather than focusing solely on individual skill-building, this collective approach creates sustainable change at the cultural and structural levels, ultimately leading to healthier, more resilient teams capable of navigating an increasingly complex world.

The Chinese Advantage

The ‘Good Enough’ Trap

Software: Where the Gap Is Widening Fastest

Humanoid Robots: Shipped, Not Studied

Wind and Solar: Not Just Bigger — Better

Not Bleeding Edge — But Getting There Faster Than Anyone Expected

The ‘Just Enough’ Mentality in Practice

What Western Companies Could Learn But Won’t

The Uncomfortable Question

Further Reading

Share the joy :)

The Agile Manifesto: Rearranging Deck Chairs While Five Dragons Burn Everything Down

Why the ‘Sound’ Principles Miss the Dragons That Actually Kill Software Projects

The Real Dragons: What Actually Destroys Software Teams

Dragon #1: The Motivation Apocalypse

Dragon #2: Relationship Toxicity That Spreads Like Cancer

Dragon #3: Shared Delusions That Doom Everything

Dragon #4: The Management Conundrum—Why the Entire Edifice Is Suspect

Dragon #5: Opinioneering—The Ethics of Belief Violated

The Deeper Problem: Dysfunctional Shared Assumptions and Beliefs

The Manifesto’s Tragic Blindness

Tom Gilb’s Devastating Assessment: The Manifesto Is Fundamentally Fuzzy

Stakeholder Value vs. All the Needs of All the Folks That Matter™

What Actually Addresses the Dragons

Beyond Agile: Addressing the Real Problems

Conclusion: The Problems We Were Addressing All Along

Further Reading

Share the joy :)

Praising the CRC Card

What You Missed

The Experience

The Seduction

What We Actually Lost

The Ratchet Effect

For Those Who Never Got the Chance

A Small Experiment

Further Reading

Share the joy :)

Secrets of Techhood

The Aphorisms

It’s called software for a reason.

Learning hasn’t happened until behaviour has changed.

Change hasn’t happened unless we feel uncomfortable.

The work you create today is a letter to your future self—create with compassion.

Documentation is love made visible.

Perfect is the enemy of shipped, and also the enemy of good enough.

Every problem is a feature request from reality.

The best problem-solving tool is a good night’s sleep.

Premature optimisation is the root of all evil, but so is premature pessimisation.

Your first solution is rarely your best solution, but it’s always better than no solution.

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work.

The hardest parts of tech work are naming things, managing dependencies, and timing coordination.

Feedback is not personal criticism—it’s collaborative improvement.

People will forgive not meeting their needs immediately, but not ignoring them.

How you pay attention matters more than what you pay attention to.

Caring attention helps things grow.

The best work is work you don’t have to do.

Every expert was once a beginner who refused to give up.

Your ego is not your work.

Testing is not about proving a solution works—it’s about showing where the work is at.

The most expensive work to maintain is work that almost functions.

Changing things without understanding them is just rearranging the furniture.

Version control is time travel for the cautious.

Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.

Question your assumptions before you question your code.

The problem is always in the last place you look because you stop looking after you find it.

Your production environment is not your testing environment, no matter how much you pretend it is.

Every ‘temporary solution’ becomes a permanent fixture.

The work that breaks at the worst moment is always the work you trusted most.

Always double-check the obvious.

Notes are not apologies for messy work—they’re explanations for necessary complexity.

The fastest process is the process that never runs.

The systems that people work in account for 95 per cent of performance.

Individual talent is the 5 per cent that operates within the 95 per cent that is system.

Unless you change the way you think, your system will not change and therefore, its performance won’t change either.

People are not our greatest asset—it’s the relationships between people that are our greatest asset.

A bad system will beat a good person every time.

You can’t inspect quality in—it has to be built in.

The righter we do the wrong thing, the wronger we become. Therefore, it is better to do the right thing wrong than the wrong thing right.

Efficiency is doing things right; effectiveness is doing the right things.