5) Vidar Moe: Det eneste Vidar vil er å ha det lett

Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · podcast · 2025-11-17 source ↗ Reader 🖥️

practical · narrative — Long-form career-and-methodology interview. The form is conversational-narrative: Truls and Audun draw out Moe's 20-year arc at SpareBank 1 Utvikling — from consultant to insourced developer, from monolith to vertical teams, from no formal leadership to fixed-term faglederrolle and distributed personnel management. The intellectual content is practical/operational (Lean/Toyota, OKR, ADRs, fagtid, pair programming, scientific method as the unit of software development), but the delivery is autobiographical. Almost no abstract theorising; everything is grounded in 'da gjorde vi X fordi Y skjedde'.

Structure

Key terms

• gjøre det lett og rett (lett og rett) Golden Path
  Moe's load-bearing slogan — make the right action the easy action. Operationally: build tooling, frameworks, shared services, golden paths, application generators, ADR templates, hiring filters, fagtid cadence and åremål structures so that doing the right thing (secure, compliant, well-tested, well-designed) is also the path of least resistance for the practitioner. It is simultaneously a craft principle (good tools so the team can move fast safely), a leadership theory (lead through engineered defaults rather than through exhortation), and a Lean inheritance (poka-yoke; make the right way the easy way). The episode's wry title 'det eneste Vidar vil er å ha det lett' is the hosts' inversion of this: Moe wants the work to be easy precisely because he has done two decades of hard work to remove friction.
• ha det lett
  The hosts' ironic compression of Moe's slogan into the title. Read straight it sounds like laziness ('the only thing Vidar wants is to have it easy'); read with the rest of the conversation it is the opposite — a senior practitioner whose entire career has been about engineering the conditions in which others (and he himself) can have it easy because the friction has been engineered out. The irony is generative: Moe explicitly resists titles, formal leadership, and being-not-operative — he wants to keep his hands in the work, which only works if the work is structured so that he can.
• fagtid Craft Community
  Fixed protected craft time, every Thursday, across all fagmiljøer (professional communities). Two to eight hours depending on community. Introduced together with the faglederrolle and fagavdeling in response to the 2017–18 attrition crisis. An arena both for deep work within a discipline and for cross-pollination because everyone has fagtid simultaneously.
• åremål (åremålsrolle)
  Fixed-term leadership role — Moe and Stian agreed each would take the faglederrolle for one year if no-one else stepped forward, on a rolling basis. The point: lower the activation energy of trying leadership; make the leadership role itself an arena to test fit; preserve the option of returning to operative work. Has continued for years and is something the org is 'veldig glad for'.
• distribuert personalledelse
  Personnel management distributed across senior developers (rather than concentrated in dedicated managers), capped at five reports each. A Toyota-flavoured arrangement that let leaders remain operative; now being rolled back in favour of a more traditional section-leader model. Moe presents the rollback without defensiveness — the system was tuned to a moment and is being re-tuned for the next moment.
• tech-møtet Craft Community
  The cross-team forum where shared technical decisions get made — max 50 minutes, around 25 participants, everyone physically present speaks. If a topic needs more than five minutes, it spins off into a workshop with the people who care most. The arena where new Postgres versions, security issues, and language adoptions (Java→Kotlin) are negotiated; the forum that 'in practice decides'. Escalation paths exist (IT-direktør, larger arkitektur-forum) but are rarely needed because the format is engineered for productive flat-ish discussion.
• ADR (Architecture Decision Record) Architecture Decision Records
  Used as the working tool for explaining hard architectural choices — e.g. why the mobile bank is hybrid-native rather than pure native. Treated as the right instrument when the decision is non-intuitive and requires going 'grundig til verks' (thoroughly into the matter).
• organisatorisk gjeld Organizational Debt
  Organisational debt — Moe coins it as 'broren til teknisk gjeld' (the brother of technical debt). His one regret-of-omission for the decade: the org could have invested more in clearing organisational debt the way it clears technical debt, especially in standardising and automating non-code parts of product development.
• golden path Golden Path
  Used in passing to describe what he wishes existed for product development as such — a paved road with good practices baked in so that following it is easy and getting it right is automatic. Moe uses it specifically in the context of imagining roadmap-building tools with good practices encoded.
• Toyota Way / Lean Lean & Toyota Way
  The intellectual substrate. Moe brought the physical book to the episode; calls it 'instrumentell i alt som har foregått' — instrumental in everything that has happened. Lean is the source for: kaizen / continuous improvement; A3 root-cause analysis (used to diagnose the 2017–18 attrition crisis); standardisation as the foundation for getting more from less; and arguably for the 'easy and right' principle itself (poka-yoke).
• vitenskapelig metode (i systemutvikling) Lean & Toyota Way
  Scientific method applied to software development — Moe argues software development IS structured learning, and the best known method for structured learning is the scientific method: hypothesise (often in the form of a test), implement, verify in production, with risk minimised by making the change as small as possible. He explicitly draws the red thread from Toyota through agile to continuous delivery to scientific method, and calls this 'state of the art systemutvikling'.
• parprogrammering Pair & Mob Programming
  Pair programming — Moe presents it both as the most effective form of knowledge sharing and as the dimension that supports quality and risk reduction. He explicitly says SpareBank 1 is not yet at full pair programming across all teams and that change in this direction is 'ordentlig seig' (truly tough/slow).
• robuste team Pair & Mob Programming
  Robust teams — the indirect outcome of pair programming: when more than one person knows what is happening, a sick day or an absence does not stall the work.
• endringsdyktig (carried over from his essay) Changeability & Optionality
  Carried over from his 'KI, utvikling og følelser' essay — change-capable code as the engineering goal. Not used verbatim in this episode but implied throughout: the framework team and tooling stance exist precisely so that the code (and the organisation) remain endringsdyktig.

Propositions

• explicitThe most powerful form of leadership in a software organisation is engineered defaults — automating the right actions into tooling and frameworks so that the easy path and the right path coincide.conf: high
• explicitInvesting in meta-tools (application generators, scaffolding, shared frameworks) before pursuing velocity is what makes long-arc velocity possible at all; without that early investment, the org would not be where it is.conf: high
• explicitSoftware development is structured learning, and the best known method for structured learning is the scientific method — hypothesise in the form of a test, implement, verify, in changes as small as possible.conf: high
• explicitAfter 25 years in the industry, the field is only now starting to understand how to write software that produces the effect we are actually after.conf: high
• explicitdevelopedCrises are not exceptions but the recurring engine of progress in the SpareBank 1 Utvikling story — the discipline is to convert each one into structural change.conf: high
  refines ←17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis · p4 — Skjaerpe explains why crises drive structural progress — alignment comes for free — and adds the harder condition: non-crisis leadership must actively construct the shared narrative crises provide automatically.
• explicitFixed-term leadership rotation (åremål) makes leadership try-able and reversible, which is what lets technically excellent people accept the role at all.conf: high
• explicitThe two root causes of the 2017–18 attrition crisis were absence of professional development (faglig utvikling) and absence of belonging (tilhørighet) — not pay, not management style, not workload directly.conf: high
• explicitcorroboratedPair programming is the most effective form of knowledge sharing available, and the rest of the engineering infrastructure exists to support practices like it.conf: high
  supports ←Pair Programming Fixed Our Pull Request Bottlenecks · p8 — Both sources independently converge on pairing as the most effective channel for knowledge transfer, continuous and incidental rather than a separately scheduled activity.
• implicitFlat structure is impossible above ~5 people; the right response is not to pretend it is flat but to design the social arenas (tech-møtet, fagavdelinger, åremål, distributed personalledelse) so that the inevitable hierarchy is humane and productive.conf: high
• explicitOrganisational debt is the brother of technical debt — and the next frontier of 'lett og rett' is paying down organisational debt by automating and standardising more of product development, not just code.conf: high
• explicitcorroboratedCultural and structural alignment (values platform, OKRs, shared tooling that travels across teams) scales leadership in ways that direct communication cannot.conf: high
  supports ←A Leading Restaurateur on What It Takes to Scale a Winning Culture · p5 — Replacing vague stated values with named, specific, coachable behaviors ("center the salt shaker") is a concrete example of the cultural/structural alignment mechanism that scales leadership beyond direct communication.
• explicitSkalert smidig (scaled agile) at SpareBank 1 was not the product of a framework adoption but of consistent fagtid plus deliberate hiring for mindset over years.conf: high
• explicitTool-sharing across teams creates cultural cohesion as a side effect — when teams use the same tools, mobility between teams becomes easy and the system gains a felt fellesskap.conf: high
• explicitLanguage and architecture decisions can be left to organic team uptake (Java → 90/10 Kotlin) when the underlying decision arena (tech-møtet) is healthy.conf: high
• explicitToyota Way / Lean and the DORA / Accelerate / Team Topologies tradition are the same intellectual lineage — Lean's practices map directly onto modern continuous-delivery metrics.conf: high

Arguments

Narratives

• Moe arrives at SpareBank 1 around 2004 for a code analysis of A and B business layer, then is part of his third nettbank build there as a Capgemini consultant; eventually does a short stint at Oracle while still serving SpareBank 1 as main customer; in 2012 the bank decides to start insourcing and Moe 'switches card colour' from consultant to employee, becoming one of the first.
  → Establishes the depth of context — Moe was a 'mature customer' of the bank before becoming an employee, and the insourcing moment is the founding act for everything that follows. It also makes legible his unusual stance: a consultant by background who chose to stop being a consultant, and who therefore brings a consultant's design instinct to internal engineering culture.
• The crisis that started everything: SpareBank 1 could no longer deliver more software per unit time on a backbone (BEA WebLogic) that was being deprecated and could no longer be updated — 'a perfect storm' in 2012. Moe and Stian Conradsen (employee developer #1) build a proof of concept around 'samarbeid med web-applikasjoner', set up a strangler-pattern reverse manoeuvre, and over a couple of years restructure team boundaries around the verticals being extracted from the old monolith (cards, payments).
  → The founding crisis-and-response narrative. Lean enters here (Toyota Way physical book brought to the recording); the 'gjøre det lett og rett' instinct is articulated first as a framework-team design principle ('det skulle være så lett som mulig å kunne trekke ut en ny vertikal'); the application generators are built. This is the genesis instance from which all later instances of 'lett og rett' descend.
• The 2017–18 attrition crisis: nearly 25% of permanent developers leave in six months, dropping headcount from 25–30 down to 18–23. The team runs an A3 (Toyota problem-solving method) and finds two root causes: missing professional development and missing belonging. Response: fagavdelinger, fagtid every Thursday, and a faglederrolle on åremål because nobody wanted the formal leader role — Moe and Stian agree to take it in alternating years if no-one else steps forward.
  → The second canonical instance of 'lett og rett' — now at the organisational layer. It also produces the åremål design, which becomes a recurring positive structure ('det å ha muligheten til å tilby noen til å prøve utledelse, det setter vi pris på'). It is the deepest evidence that Moe treats organisational design as a continuous-improvement loop.
• Villa Paradiso at Grünerløkka, several times a year for many years — Moe meets a colleague (heavily implied from NAV: Audun's organisational world; the slogan's traceable joint provenance) over pizza and discusses fagting. The 'gjør det lett, gjør det rett' coinage emerges co-evolutionarily between the two organisations there.
  → Origin myth of the slogan itself. Both speakers want it on the record that the phrase has a specific cross-organisational provenance — not 'Moe's coinage' nor 'NAV's coinage' but a joint coinage from a pizza place. The story is itself an instance of the phenomenon Moe values: ideas that emerge in informal craft arenas and then travel into both institutions.
• The Java → Kotlin transition: leadership says 'everyone uses Java; if you want to use Kotlin, fine — Kotlin has nice properties.' Over time the org reaches ~90/10 Kotlin organically. When asked who decided, Moe points to the tech-møtet as the de-facto decision arena. Asked what happens at 12–12, he describes the explicit escalation path: IT-direktør and a larger arkitektur-forum with information architects and security architects.
  → Worked example of the social-arena argument. The transition is presented as an instance where 'gjøre det lett og rett' worked without top-down decree: shared decision arena + permissive default + competent participants = organic 90/10 outcome without explicit policy.
• The hybrid-native mobile-banking architecture: a case where the team had to go 'grundig til verks' multiple times to explain why the hybrid-native approach was the right choice for the org rather than a pure native approach. The argument was made in ADR form. (The hosts add that they spent a whole day with Moe arguing about what 'native' even means in that context.)
  → Worked example that 'gjøre det lett og rett' is not about avoiding hard arguments — when the right answer is non-intuitive, ADRs and patient explanation are themselves the easy-and-right tool. Also lets the hosts surface their craft kinship with Moe.
• Audun's NAV teamkatalog example: a structured, API-exposed catalogue of teams and members that lets other support tools integrate at team granularity rather than namespace granularity — so cost and security info attaches to teams, which strengthens teams as organisational units, which strengthens the org. Moe responds 'kanskje vi skal lage noe sånn, så blir vi millionær. Det hadde vært lurt.'
  → Shows the next instance of 'gjøre det lett og rett' that Moe still wishes for: standardising and automating organisational structures (his organisatorisk gjeld point) using the same engineering instinct that already standardised the technical layer. Pre-figures the forward direction of the philosophy.
• The closing meta-reflection: Truls notes that he kept hearing 'Toyota way' and DORA / Accelerate / Team Topologies converging — that Toyota and Lean have very clear parallels with modern DORA practice. Audun notes how striking it is that Moe always says 'we', and how hard it is to tell where the collective ends and where one person's thinking shapes it.
  → The hosts make explicit what the episode quietly enacts: the lineage that Moe operates within (Toyota → Lean → agile → DORA → Team Topologies) and the rhetorical pattern (consistent 'vi') that makes the leadership style itself an instance of engineered humility.

Questions addressed

• ✅ How did SpareBank 1 Utvikling get from a 2012 monolithic crisis to its current vertical-team organisation?
  Through a deliberate strangler-pattern restructuring driven by a framework team that built the meta-tools (application generators, scaffolding) before pursuing velocity, with team boundaries reorganised around the verticals being extracted (cards, payments).
• ✅ What does it actually mean to make 'easy and right' coincide?
  It means engineering the defaults — at the code layer (frameworks, generators, shared tooling for security and compliance), the social layer (tech-møtet, fagavdelinger, ADRs), and the career layer (åremål for leadership, distribuert personalledelse). Leadership through engineered defaults rather than through exhortation.
• ✅ Why did Moe ever accept a formal leadership role?
  Because the åremål structure (fixed-term, one year, with an explicit handover agreement with Stian) made it low-stakes to try; because it was preserved as operatively compatible (capped reports, outsourced economy and recruitment); and because nobody else wanted it and there was an institutional need.
• ✅ How do you scale alignment in a 130-developer organisation with high autonomy?
  Three layers: (1) good old-fashioned quarterly OKRs; (2) a values platform ('bedre sammen') and culture work that scales further than direct communication; (3) leadership through automation of the right defaults so the desired behaviours are the path of least resistance.
• ✅ How do you make decisions across teams without flattening or rigidifying?
  Tech-møtet (50 min max, ~25 participants, everyone speaks) with workshop spin-offs when a topic exceeds five minutes; ADRs for non-intuitive choices; an arkitektur-forum and IT-direktør as rarely-used escalation paths. Worked example: Java→Kotlin reached 90/10 organically.
• ✅ What is the unit of analysis for software development as such?
  Structured learning, with the scientific method as the best known instrument. Hypothesise as a test, implement, verify in production, in the smallest changes possible to minimise risk. Pair programming amplifies the learning rate.
• ✅ What would Moe have done differently across the 14 years?
  More automation and standardisation beyond pure code — paying down 'organisatorisk gjeld' the way the org pays down technical debt. Codifying product development as a process with engineered golden paths and good practices baked into roadmap tooling. He gestures at this but does not specify the shape.
• ⭕ What is the relationship between Moe's craft / scientific-method stance and the dominant agentic-AI development movement?
  Not explicitly addressed in this episode — pair programming, fagtid and scientific method are presented as the substrate but the agent question is deferred. (The same author's 'KI, utvikling og følelser' essay answers it; this episode is the philosophical prelude that the essay presupposes.)
• ⭕ Can engineered defaults / golden paths produce organisational sameness or block legitimate dissent?
  The hosts circle the question (how do you handle a team that wants to do something different?), and Moe describes the tech-møtet escalation path, but the deeper question of whether the framework-team's 'right' becomes a hidden organisational orthodoxy is not engaged.

Gaps

• incompleteThe AI / agentic-coding chapter is conspicuously absent from this 2025-recorded episode despite being the explicit subject of Moe's near-contemporaneous LinkedIn essay 'KI, utvikling og følelser'. The Heis conversation is recorded in late 2025 (published 17 November 2025, the same week Moe's essay marks as the Opus 4.5 inflection point at SpareBank 1 Utvikling) yet the agent question is never raised — the closest touch is Moe's observation that change is 'ordentlig seig' even at the pair-programming level. This is a productive gap: the Heis episode is the unstated philosophical foundation that the essay's alienation diagnosis presupposes. If software development is structured learning and pair programming is the most effective form of knowledge sharing, then 'specifying systems' through an agent is alienating precisely because it displaces the learning act and breaks the pairing dyad.
  Read next: Read the Heis episode and the 'KI, utvikling og følelser' essay together as one document. The essay's three mitigations (kode fundamentet selv; eksplisitt TDD med agenten; problemløsing fremfor programmering) are direct instances of 'gjøre det lett og rett' applied to the agent layer. Then read Beck's recent 'starving genies' / TCR work and Cutler's TBM 412 on institutionalised overload + AI as the anglophone analogues. Steve Yegge's vibe-coding manifesto is the live contrast position.
  closed by9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — Supplies the missing AI chapter for Moe's 'software development is structured learning' framework: AI threatens the learning act by displacing colleague interaction, and the mitigation is making AI use a collective, reflective team practice under tight supervision.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  Read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  Read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  Read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  Read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  Read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).

Related documents

• AI coding creates two kinds of debt. You're only measuring one
  Learning Culture & Slack Pair & Mob Programming
• From Async Code Reviews to Co-Creation Patterns
  Lean & Toyota Way Pair & Mob Programming
• Pair Programming Fixed Our Pull Request Bottlenecks
  Lean & Toyota Way Pair & Mob Programming
• Mob Programming – key issues it can solve, benefits, and learnings
  Lean & Toyota Way Pair & Mob Programming
• 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs
  Golden Path Team Topologies
• 11) AI-spesial med Vilde Opsal og Anders Sveen
  Changeability & Optionality Learning Culture & Slack
• 13) Tobias K. Torrissen om kodekvalitet, konferanser og AI
  Architecture Decision Records Craft Community
• How Open Source Enables Collaboration in Creating a Platform
  Craft Community Golden Path
• DORA Community Discussion - Operationalizing DORA within a large organization
  Golden Path Learning Culture & Slack
• Pascal BORNET's Post
  Learning Culture & Slack Organizational Debt