Value Streams & Verticals

Organizing cross-functional teams around end-to-end customer value flows rather than functions or geographies.

Also known as: verdistrøm (value stream), verdistrøm, Value stream, vertikal / horisontal verdistrøm, vertikal, verticals, vertical teams, tvernordisk

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (10)

• DevOps Topologies Matthew Skelton (devopstopologies.com) · 2026-10-08 source ↗ Reader 🖥️
  There is no single universally correct Dev/Ops team structure for achieving DevOps's actual goal — improved delivery of customer and business value — because the right topology is contingent on an organization's product count (via Conway's Law) and on whether its Operations function has the capability and appetite to move from infrastructure-racking toward genuine value-stream alignment; a reference catalog of named anti-patterns and working patterns lets an organization diagnose and choose among structures rather than assume one conformation fits all.
• Beyond Autonomous Teams in Software Product Development Ben Linders · 2026-09-10 source ↗ Reader 🖥️
  Because a team's contribution in a complex organization is really a share of an ever-shifting web of value dependencies rather than a discrete 'product,' organizations should replace 'autonomous product team' thinking with 'value center' thinking, in which every unit at every level (person, team, team-of-teams, org) answers the same five recursive questions and trades off autonomy against coherence according to the shape of the value it carries, not according to ideology.
• Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard Fabrice Bernhard · 2026-06-06 Reader 🖥️
  The headline 17.3x speedup that AI async agents produce at the start of the software value stream collapses to a 1.3x increase in release frequency at the end of the stream — because human and organisational bottlenecks (unclear business needs, organisational dependencies) dominate end-to-end throughput; therefore AI creates real value only when it is targeted at the actual bottleneck, and identifying that bottleneck is what Lean Tech is for.
• 8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-01-04 source ↗ Reader 🖥️
  Becoming Nordic-aligned (not pan-European, not purely national) is the right level at which to consolidate digital marketplaces, and getting there requires leading at the right abstraction layer — setting direction and 'why' from the top while delegating the 'how' to distributed cross-Nordic vertical teams — because the previous failure of pan-European centralisation taught Printzell Halvorsen that scale only works when the people whose work is being reorganised are kept, respected, and reassembled around problem verticals rather than dispossessed by a new hub.
• 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-10-13 source ↗ Reader 🖥️
  What warrants the Steve Jobs analogy in Larsen's case is not product taste in a consumer sense but the disciplined construction of a 'strategic narrative' so concrete and personally believed that it can pull a large bureaucracy through a paradigm shift — and this only works when paired with a complementary engineering apparatus (reverse Conway architecture, cross-functional value streams, common components discovered rather than designed, a 'golden-path' platform that makes the right thing the easy thing) operated by a leader who keeps an 'inngangsbillett' to the technical conversation so that the narrative remains connected to what is actually happening on the floor.
• State Of AI-Assisted Software Development DORA · 2025-09-23 Reader 🖥️
  AI's effect on software delivery is not a property of the tool but of the organizational system it is embedded in: across nearly 5,000 developers, AI consistently amplified whatever team dynamics already existed — toward 'harmonious high-achievement' or toward a 'legacy bottleneck' — and organizations only convert individual AI-driven effectiveness gains into durable team, product, and organizational performance by deliberately building a cluster of systemic capabilities (AI-policy clarity, data health, version-control discipline, small batches, user-centricity, and platform quality) and treating AI adoption as a whole-system transformation rather than a tooling rollout.
• Optimizing teams: A dual perspective on Team Topologies Elias Lieberich · 2024-09-26 source ↗ Reader 🖥️
  Team Topologies' four-type model is a useful starting vocabulary, but both authors argue that applying it well requires practical, product-aware judgment calls it doesn't itself supply — Lieberich's engineering-facing checklist (well-defined scope, disambiguated boundaries, minimal dependencies) and Wille's product-facing one (small teams, end-to-end ownership of a user journey, splitting by product/user-group/value-moment/funnel-stage rather than by technology) — because the book's own categories never fully resonated with a product-management, rather than engineering, view of where team boundaries should fall.
• Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 SQUER Solutions · 2024-06-11 source ↗ Reader 🖥️
  Successful architecture modernization is primarily an organizational and narrative problem, not a technology-upgrade problem: it succeeds when architects treat the value stream (business domain + outcomes + team autonomy + deployability) as the real unit of design, triage the system as a portfolio rather than rebuild it wholesale, and use social tools (listening, impact mapping, event storming, enabling teams, early visible wins) to earn and sustain the organizational permission that technical skill alone cannot secure.
• Software Teaming: A Mob Programming, Whole-Team Approach Woody Zuill and Kevin Meadows · 2022-11-04 Reader 🖥️
  A whole team working together, all day, at one computer, on one thing at a time — using a Driver-Navigator discipline and a self-chosen agreement to treat each other with Kindness, Consideration, and Respect — is more effective than the conventional practice of separating specialists, because nearly all of software development's hidden costs (queueing, context-switching, faulty communication, indecision, defects, politics) are side effects of separation that fade away once the whole team works in one continuous flow, rather than problems that must be solved individually.
• Sociotechnical Architecture as Enabler of Product Thinking Eduardo da Silva · 2021-04-30 source ↗ Reader 🖥️
  An organization can only achieve Product Thinking's goal — maximizing continuous, high-velocity value exchange with the customer — by holistically co-designing three interrelated systems together (the customer/market, the teams/organization, and the software architecture), a discipline the author names Sociotechnical Architecture, building on Conway's Law, Team Topologies, and Ackoff's Systems Thinking.

Propositions touching this concept (17)

By publication month, oldest first (extraction month when no publication date is known).

2019-09

• implicitcorroboratedThe team, not the individual or the value stream as a whole, is implicitly treated as the correct atomic unit of software ownership — a premise the book itself helped popularize but does not independently defend against alternative units of organization (e.g., value streams spanning many teams, or individual-level ownership).
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p23

2021-04

• explicitA product's value streams, each owned by different teams, must be integrated with systems-thinking holism rather than optimized locally/in isolation, because local 'siloed' optimization of parts does not maximize the whole system's value exchange with the customer.
  Sociotechnical Architecture as Enabler of Product Thinking · p3

2024-06

• explicitThe effective unit of architecture is the value stream: a loosely coupled business domain paired with clear business outcomes, local team decision authority, and low-friction, on-demand deployability.
  Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 · p3

2025-09

• explicitValue stream management acts as a force multiplier for AI investment: by exposing where coordination costs, delays, and bottlenecks accumulate, it ensures local AI-driven productivity gains are converted into organizational-level performance gains instead of being lost to downstream chaos.
  State Of AI-Assisted Software Development · p13

2025-10

• explicitWhat used to require a gigantic moon-landing project with a couple of hundred consultants is now needed daily — value streams of cross-functional teams replace projects as the organisational form for continuous change.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs · p11
• explicitHorisontale verdistrømmer / platforms can only exist if they accelerate verdiskaping in vertikale (market-facing) verdistrømmer — measured through leading indicators of innovation speed, time-to-market and time-to-value in the verticals they serve.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs · p13
• explicitGood common components are discovered, not invented — solve problems in verticals close to customers, then let patterns that turn out to be genuinely shared gravitate down into a platform.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs · p14
• explicitTelenor's matrix separates leveranseoptimalisering (value streams, with verdistrømsleder + lead architect + lead product lead but no personalansvar in principle) from kompetanseutvikling (people-and-competence dimension, where personalansvar, rekruttering and karriereutvikling sit).
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs · p19
• explicitThe current hardest organisational problem is moving from project mindset to outcome-driven verdistrøm-mindset — making verdistrømmer (and the teams within) into læringsarenaer and innovasjonsarenaer rather than order takers.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs · p20

2026-01

• explicitLocal consumer brands (Finn, Blocket, DBA, Bilbasen, Tori, Oikotie) must be preserved because they live in consumers' heads — but the organisation behind them should be tvernordisk.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet · p3
• explicitAI capability should be organised as enablement (a Department of AI of 30-40 AI experts supporting the verticals' product teams) rather than as a monopoly on AI innovation.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet · p18
• explicitStrategic focus (rentyrket markedsplass on four verticals with leading positions) implies discontinuing adjacent services that have no path to market leadership — the Finnish job board (#2-3) was shut down, and Finn Reise is being kept Norway-only despite host enthusiasm for its quality.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet · p23

2026-06

• explicitcontestedThe only number that matters is 1.3x — because customer value lives at the end of the value stream, not the beginning.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p3
• implicitcorroboratedMost current AI coding adoption is targeted at the wrong place in the value stream — at code production, not at the actual bottleneck.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p11
• explicitCode-writing speed was never Vipps's bottleneck; AI coding tools make this more obvious, not less, so the real productivity question is the rest of the engineering value stream.
  18) Vipps: Fra app til verb til nordisk infrastruktur · p17

2026-09

• explicitIn a moderately complex organization, what an individual team delivers is not a stable 'product' but a share of a value stream that changes every quarter, project, initiative, and feature.
  Beyond Autonomous Teams in Software Product Development · p2

2026-10

• explicitWhether an organization's IT Operations department has the capability or appetite to shift from racking hardware and configuring servers toward genuine alignment with the value stream — with operational concerns taken seriously by software teams — is a second major variable determining which topology fits.
  DevOps Topologies · p4

Open gaps (27)

• incompleteThe claim that the five questions apply unchanged 'at all levels: team, team-of-teams, department, whole organisation' is asserted but only ever demonstrated with a single team-level worked example (Scrum backlog, sprint goal); no worked example is given at the team-of-teams, department, or whole-organization level, so the universality/recursiveness claim is untested within the piece itself.
  Beyond Autonomous Teams in Software Product Development
• incompleteThe article explicitly defers 'how to implement these ideas' and 'who should do this' to other articles in the author's broader Sociotechnical Architecture series, some of which were still unwritten at publication — so the holistic framework is argued for conceptually but not demonstrated through an implementation case study beyond the illustrative Restaurant Product analogy.
  Sociotechnical Architecture as Enabler of Product Thinking — read next: The author's later Sociotechnical Architecture and Systems series, if subsequent installments addressing implementation exist.
• illogicalThe claim that siloed/local optimization 'almost never' maximizes overall customer value is asserted via Ackoff's systems-thinking authority and the restaurant analogy, not demonstrated through a comparative case (siloed optimization tried and found wanting versus holistic co-design succeeding under otherwise comparable conditions).
  Sociotechnical Architecture as Enabler of Product Thinking — read next: extract-dora-2024-accelerate-state-of-devops for metrics-based evidence on this trade-off.
• incompleteThe post claims release frequency is 'the only number that matters' but doesn't argue why — and Lean's own toolkit would suggest cycle time, quality, and customer outcomes belong alongside release frequency. The reduction of 'real value' to a single metric is rhetorically clean but theoretically thin.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: DORA's four-key-metrics literature; Reinertsen on cost of delay; Steve Yegge / Gene Kim on quality-vs-speed under AI; Beck's recent newsletters on what to measure when AI changes throughput.
• incompleteTheodo's consultancy context is a selection bias engine that Bernhard doesn't address. Consultants typically work on greenfield engagements or on well-bounded modernisation projects where business needs are pre-scoped by a client brief. The very bottlenecks Bernhard names (unclear business needs, organisational dependencies) are precisely the bottlenecks consultancy contracts pre-filter for. Whether the 3x result transfers to in-house teams operating in the muck is the load-bearing open question.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Compare to Anthropic enterprise PDF findings on in-house deployments; Cutler on internal-team organisational drag; case studies of in-house legacy modernisation at scale (e.g. NAV, Entur reports already in corpus).
• incompleteLegacy modernisation is presented as 'a' bottleneck-aligned use case but Bernhard doesn't enumerate what makes it bottleneck-aligned and what other use cases would qualify. A more complete argument would name the properties (translation-heavy, human-comprehension-bound, well-specified target, measurable acceptance criteria) that make AI bottleneck-effective.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Mary Poppendieck on Lean software value-stream mapping; Theory-of-Constraints applied software literature; specific case studies of AI-driven greenfield vs migration projects.
• incompleteThe post takes the MIT/UPenn paper as authoritative but doesn't disclose the dataset, sample, or timeframe. Async agents in 2024-25 (the likely study window) are not the same product category as 2026 long-running harnesses — the 1.3x number may understate what later-generation tooling can do at the release-frequency end, OR may be optimistic if the study captured the early enthusiasm phase.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: The Demirer/Musolff/Yang paper itself; recent METR / RCT-style AI productivity studies; Pocock workshop on what changes with harness-level tooling.
• incompleteThe 'we generate better learnings' claim is asserted without describing Theodo's actual learning mechanisms — internal write-ups, retros, replication across client engagements, etc. For an audience interested in adopting the approach, the learning infrastructure is the load-bearing part.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Theodo's engineering blog (theodo.com / padok.fr); Mike Rother's Toyota Kata on learning routines; A3 thinking literature.
• uninformedThe post predates / doesn't engage with the harness-engineering thread that this corpus has been tracking (Anthropic harness paper, Pocock workshop, Cloudflare Mythos). Harness-level tooling specifically aims at the integration between code generation and release — exactly the gap Bernhard names. Whether harness engineering is a third path (between 'roll out Copilot' and 'consultancy-led bottleneck targeting') is an obvious adjacency.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Pocock workshop extraction; Anthropic harness design paper; Cloudflare Mythos extraction; the Anthropic enterprise PDF extraction.
• incompleteThe Jobs analogy is named but not fully cashed out against its disanalogies. Jobs's reality distortion field was famously paired with cruelty, factional purges and product taste applied to consumer aesthetics. Larsen's framing is the opposite — toppdivisjon-ledelse runs on indre motivasjon, not fear; authenticity / easy-to-read-ness is the asset; the product is a public-sector welfare system. The conversation does not name these disanalogies, so the analogy carries more rhetorical work than it earns.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read Walter Isaacson's Jobs alongside Tracy Kidder's Soul of a New Machine and Marc Andreessen-tradition writing on charismatic founder leadership to surface the disanalogies; for the NAV case specifically, read Cutler on 'institutionalized overload' to see what indre-motivasjon-based mobilisation can hide. Connects to the gap in the Skjærpe ep 17 extract on transformations that fail in the liminal phase.
• incompleteThe NAV transformation is described entirely from the inside by one of its architects. There is no counterfactual: comparable Norwegian agencies that did not transform similarly, post-Larsen reversion at NAV, what failed within NAV and why. The 'hagiography risk' the hosts flagged is real and unexamined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Compare Skatteetaten, Statens Pensjonskasse, Helsedirektoratet trajectories during the same period; read the NAV-flow article in the user's library (Optimizing for Fast Flow in NAV) for the inside-but-different-author view; read the Skjærpe ep 17 extract for the immediate-successor's view from inside the system. Look for what the NAV transformation displaced or made impossible (e.g. casualties among legacy fagsystemer staff).
• incompleteThe 'common components are discovered, not designed' thesis is asserted with the NAV fakturering case as the load-bearing example, but the inverse failure mode (premature divergence — many verticals each solving the same problem badly because no one promoted the pattern to the platform) is acknowledged in passing ('we have capabilities in the platforms that strictly speaking are only needed one or two places ... it is a little behagelig that it got fixed over there') without being theorised. The position is one-sided.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read the Wardley Mapping / pioneers-settlers-town-planners tradition for an explicit account of when components should be designed up front (the 'industrialised' part of the map). Read Cutler on 'horizontal team accountability' for how teams refuse to own platform-like problems they should own. The Vipps ep 18 extract may have a relevant view from the perspective of an organisation that did design infrastructure up front.
• incompleteThe 'easy to read' / authentic-leadership claim collides with the strategic-narrative claim. Strong strategic narrative is itself a construction; sustained reality-distortion presupposes some performance discipline. The conversation treats easy-to-read-ness and disciplined narrative as compatible without examining the tension. When does the constructed narrative cross into managed-impression territory, and what is the leader's check on that?
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Erving Goffman's Presentation of Self; Edgar Schein on the discrepancy between espoused theory and theory-in-use; Bent Flyvbjerg on narrative in megaprojects (where the same person both believes and constructs the future). The Cutler 'signals that look like decisions' thread is also relevant — for an easy-to-read leader, even contemplative musings can be read as commitments.
• incompleteThe inngangsbillett method is a personal description, not a teachable account. Larsen says he spends 'many hours a day' on craft and uses the hermeneutic-circle approach, but does not name which key terms, which structural maps, which sources, or how to know when the inngangsbillett is sufficient for a given fagdomene. The 'Fred George reads no books, he talks to authors' punchline gestures at one upper-bound technique but leaves the floor undefined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Hubert Dreyfus's five-stage skill model (novice → expert) for a more precise grammar of 'how much do I need to know'; Cal Newport's deep work / deliberate practice tradition; the recent harness-engineering and AI-coding research extracted in this repo on what 'understanding a system' actually requires before AI can help you scale that understanding.
• uninformedThe conversation invokes Peter Senge's learning organisation as one of the three common denominators of Larsen's narrativer but does not interrogate how durably the organism-organisation framing has held up under real conditions over the 30 years since Fifth Discipline. There is a tradition of critique (e.g. Mintzberg on the messiness of organisational learning; recent operations-research literature on actual learning loops in software organisations) that the conversation does not engage with.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Mintzberg's Rise and Fall of Strategic Planning; Argyris on double-loop learning vs Senge's framing; the more recent DORA / Accelerate research on what kinds of learning actually correlate with performance — and what kinds (e.g. 'just keep adapting') do not.
• incompleteThe episode ends on Larsen's most quotable problem — moving from project mindset to outcome-driven verdistrøm-mindset — but does not specify what makes this so hard at Telenor specifically. Is it inherited governance? Board reporting cadence? Career incentives for people who have always shipped to scope? The hosts move on. This is the single most actionable place the conversation could have gone deeper.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Cutler on outcome-orientation and operating-system design; Marty Cagan's 'product team vs feature team' distinction; the Una Aamodt-Mathisen ep 10 extract (lede uten fasit) likely has direct material on the same problem at a different scale. The Vidar Moe ep 5 ('det eneste Vidar vil er å ha det lett') may have a relevant view on operating-model simplification.
• incompleteThe hagiography risk is structural: Truls worked for Larsen, Audun met him at a formative moment, both are visibly inspired. The format does not include any adversarial pressure. The episode is therefore best read as Larsen's self-presentation lightly facilitated by admirers — strong as primary source, weak as evaluation.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: For an evaluation lens, read external accounts of NAV's transformation (audit reports, Riksrevisjonen, Aftenposten / NRK coverage of NAV IT projects during the Larsen era), and look for counter-narratives in the Norwegian public-sector tech community. Compare to Holte ep 2 (the senior public-sector counterpart) for a different view of the same period.
• incompleteThe case for 'lokalt forankret, nordisk samlet' rests heavily on the three favourable conditions (small cultural distance, similar maturity, no hub story) that Printzell Halvorsen names. The conversation does not seriously interrogate what happens in cases where one or more of those conditions does not hold — e.g. a Nordic group with one dominant and three start-up markets, or a public-sector federation where national differences (legal, fiscal) are large. The model may be narrower than its rhetorical appeal suggests.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Compare to Nordic banking (Nordea), Nordic telecom (Telia/Telenor), and Nordic public-sector federations to see where the conditions hold and where they don't. Read Geert Hofstede / Erin Meyer on the actual measured cultural distances within the Nordics.
• incompletePrivileged-Schibsted-vantage shapes what's visible vs. invisible. The lessons are drawn from a Schibsted-internal lineage of marketplaces with strong brands, a developer-heavy talent pool, and a long maturation as commercial businesses. The conversation is silent on: public-sector contexts, non-media startups, B2B enterprise software, government-mandated platform consolidations, and platforms where brand-in-consumers'-heads is not the load-bearing asset. The framework is presented as broadly applicable without owning these scope conditions.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read public-sector platform consolidation case studies (NAV, Skatteetaten, NHS Digital, Estonian e-government); read B2B platform consolidation studies (Salesforce-MuleSoft, Adobe-Figma). The presence/absence of the Vend pattern in those contexts would map the model's actual reach.
• incompleteThe methodological claim that big-bang beats phased for integration projects with a known target state is grounded in three Vend cases and asserted as a general lesson. The conversation does not consider failure cases (industry has many) or the boundary conditions (rehearsal infrastructure, rollback capability, cohesion of the cut team). Listeners may over-apply.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read post-mortems on famous failed big-bang migrations (UK NHS NPfIT, TSB Bank 2018, Hertz/Accenture) to identify what made Vend's big-bangs work that those did not have.
• incompleteBob the Builder is presented as low-code AI tooling that produces useful prototypes and personal-productivity solutions but is firewalled from product production code. The conversation does not address how outputs ever cross that firewall — what happens when a marketing team's Bob the Builder solution becomes load-bearing and needs the engineering quality bar.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read low-code/citizen-developer governance literature (Gartner's 'fusion teams,' Microsoft Power Platform CoE patterns) for how organisations handle the citizen-to-production handoff.
• incompletePrintzell Halvorsen names the senior/junior asymmetry of technology fluency implicitly (his own developer past as anchor; CFO going through Bob the Builder to stay relevant) but never engages the question of how Vend develops the next generation of leaders without a developer past. The transferability of the abstraksjonslag instinct to non-technical leaders is left open.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read Beane on apprenticeship in mixed-expertise contexts; read deliberate-practice literature on developing abstraction skill without a code substrate.
• incompleteThe destination-vs.-chat scenario framing is treated as binary. The conversation does not engage the third possibility — that marketplaces become specialised APIs feeding many fronts (chat, AR shopping, voice assistants), with the consumer-facing brand decoupled from the consumer-facing surface. That would require a different bet on data infrastructure and brand strategy.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read literature on platform economics under generative AI distribution (Anu Hariharan, a16z's recent marketplaces writing); Matthew Prince's own writing at Cloudflare on the AI-content-economy collapse and 'pay-per-crawl' proposals (which Printzell Halvorsen alludes to when citing him).
• uninformedThe conversation does not engage with the consumer-welfare or competition-policy implications of Nordic consolidation. Consolidating into Vend reduces marketplace competition within each vertical at a Nordic level. The hosts do not raise this; Printzell Halvorsen does not address it.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read EU competition decisions on Adevinta/eBay Classifieds, Schibsted's spin-off rationale, and Nordic competition authorities' marketplace cases for the regulatory frame the conversation omits.
• incompleteThe autobiographical-prescriptive proposition ('do a good job where you are; opportunities follow; developer → product → business is the natural path') is presented without engaging the question of how much of Printzell Halvorsen's trajectory is reproducible vs. how much depends on McKinsey-as-accelerator, Norway's small leadership pool, and the specific historical moment of FINN. The advice may be more biographically contingent than it sounds.
  8) Christian Printzell Halvorsen om å lede på riktig nivå: Lokalt forankret, nordisk samlet — read next: Read against the Cutler thread on what conditions enable senior individual-contributor-to-leader transitions inside specific organisations, and against literature on path-dependence in executive careers.
• illogicalWille's claim that Team Topologies' four-type model doesn't resonate from a product perspective, paired with her own worked example containing a complicated-subsystem/platform-style team (the job board's shared 'base data' or pricing logic, by analogy to Lieberich's booking-engine example), suggests her rejection of the taxonomy may be more about vocabulary/framing than about the underlying need the taxonomy is tracking (that some real boundaries are technical, not product-journey-shaped) — a tension the piece doesn't surface or resolve.
  Optimizing teams: A dual perspective on Team Topologies — read next: Compare against extract-team-topologies#p12 (fracture planes should match team-first, cognitive-load boundaries) and #p23 (the team, not the value stream, as the implicit atomic unit) to test whether product-journey-first and engineering-first decompositions are actually reconcilable or structurally in tension.
• uninformedThe book devotes a dedicated chapter to Remote Software Teaming, which this extraction did not analyze in depth — it is the one place the book directly engages with distribution, the default condition for many of the AI-era, geographically dispersed teams this corpus otherwise tracks.
  Software Teaming: A Mob Programming, Whole-Team Approach — read next: Re-read the 'Remote Software Teaming' chapter directly against current distributed/async-first team norms and tooling.