14) Øystein Ulseth pendler mellom å lede og levere

Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · podcast · 2026-04-07 source ↗ Reader 🖥️

practical · mixed — Long-form conversational interview (Norwegian podcast). Primarily a reflective career narrative with embedded practical claims about how to navigate the engineer-manager pendulum, what crossing the IC/leader boundary teaches, what good distributed architecture practice looks like, and how to prepare an organization for AI-assisted development. Practical in the Adlerian sense — most propositions ultimately argue for how to organize one's career and one's architecture function, not just for understanding.

Structure

Key terms

• pendle (verb) / pendel (noun) Hands-On Leadership & the Pendulum
  To deliberately move between leading and delivering across a career — not as indecision, but as a structuring principle. In Ulseth's usage it is bidirectional and ongoing; he has moved from leader of a 50+ unit back to enterprise architect, and even now as sjefsarkitekt he holds both dimensions (bredde og dybde) in one role. Pendling is not alternation of jobs but a stance: never get so far from one side that you lose the perspective it gives.
• Engineer-Manager Pendulum Hands-On Leadership & the Pendulum
  Fredrik Majors' (CTO Handelkamp) concept invoked by the hosts to name the pattern Ulseth exemplifies: technology leaders deliberately oscillating between IC and leadership work because each role keeps the other honest.
• drivkraft / bygge-glede (drive / build-joy) Intrinsic Motivation & Making
  The first-principle motivator Ulseth substitutes for 'ambition'. The joy of building something that didn't exist — felt equally when typing a BASIC program at age 10, when writing code, and when sketching a PowerPoint that crisply renders a complex idea. The 'click' when an abstraction lands precisely without losing essence.
• presisjon i abstraksjonen / å treffe på riktig abstraksjonsnivå Organizational Abstraction Levels
  Audun's (host's) re-statement of what pendling buys you: the ability to pick the right level of abstraction, because you have seen both sides of the equation — what it costs to implement at the low level and what it must mean at the strategic level.
• bredde og dybde (breadth and depth)
  Ulseth's two-dimensional design of the sjefsarkitekt role. Bredde: framework-building — architecture governance, architect community, conditions under which others make good architecture choices. Dybde: a personal portfolio of initiatives the sjefsarkitekt drives hands-on, in collaboration with others. He explicitly says he needs the dybde portfolio for the role to work for him.
• sosioteknisk arkitektur (sociotechnical architecture) Sociotechnical Architecture
  Architecture practice that explicitly designs organisation and technology together; treats Conway's law as a force to be deliberately harnessed (design the org for the architecture you want) rather than passively accepted. Ulseth notes this is a new acquaintance for him and Fremtind has adopted it as their target architecture model.
• fart og flyt (speed and flow) Evolutionary Architecture & Fitness Functions
  The properties a modern architecture should optimise for: teams shipping with minimum friction. Loose coupling and high cohesion are the levers; central architecture boards are now a flow-limiting factor at large scale.
• konversasjonell arkitektur (conversational architecture) Evolutionary Architecture & Fitness Functions
  Andrew Harmel-Law's model of distributed architecture decision-making: teams are empowered to make architecture choices the way they are empowered for development decisions, on the condition that they consult relevant stakeholders, document, and inform a central body — which then no longer 'approves' decisions but receives them.
• vibe-coding Vibe Coding
  AI-assisted development in which the developer does not understand the code the tool produces. Ulseth treats this as a distinct, distinguishable mode and is sceptical of it as a sustainable practice.
• god utviklingskultur (good engineering culture)
  The cluster of practices (continuous delivery is the named example) that Ulseth treats as a precondition for scaling AI-assisted development. Old practices, not new — but AI now provides a much larger incentive to actually live them.

Propositions

• explicitThe best technology leaders are never far from the keyboard, and the best architects are never far from the people.conf: high
• explicitPendling between leading and delivering is driven by build-joy, not by career ambition.conf: high
• explicitGoing from IC to leader teaches you to distinguish what is actually complex from what is not — and to avoid overestimating complexity as much as underestimating it.conf: high
• explicitGoing from leader back to IC brings a holistic perspective: budget awareness, risk awareness, the habit of seeing every choice as a trade-off, and a feel for commercial value.conf: high
• explicitPendling makes you precise about abstraction: because you have seen both sides of the equation, you can pick the right level.conf: high
• explicitBuild-joy is medium-agnostic: the same satisfaction can be reached in PowerPoint as in code, provided the artefact crisply renders something complex without losing essence.conf: high
• explicitThe frustration that pushes a builder upward is not loss of joy at the low level but the recognition that doing the fun thing well requires fixing things at the level above or around it.conf: high
• explicitA senior architecture role can institutionalise pendling: design it as bredde (governance, community, conditions) plus dybde (a personal portfolio of deep initiatives the role-holder owns).conf: high
• explicitCentralised architecture review no longer scales; in modern large IT organisations, central architecture becomes the limiting factor on speed and flow.conf: high
• explicitCentralised architecture also produces the illusion of control: people make decisions anyway and hide them when speaking up triggers friction.conf: high
• explicitGood architecture is the architecture that lets teams ship with minimum friction; loose coupling and high cohesion are the two levers, and they are general enough to settle most architecture arguments.conf: high
• explicitOrganisation and architecture cannot be designed independently of each other — Conway's law makes the org-shape the architecture-shape, so the sociotechnical view is the only honest one at scale.conf: high
• explicitAI-assisted coding is currently most valuable in the hands of skilled developers in organisations with good engineering culture — not as a way to bypass either.conf: high
• explicitAI does not change what architecture is for — the developer is still accountable for the code produced regardless of tool, and the product is in principle the same; what changes is the achievable cadence.conf: high
• explicitGood engineering practices (continuous delivery is the named example) have been well-described since the early 2000s but only patchily lived; AI raises the incentive enough that organisations now have to actually live them.conf: high
• explicitAI-assisted modernisation of legacy stacks (COBOL/RPG on IBM platforms) is a more interesting near-term arena than the green-field discourse currently dominates.conf: high
• explicitA pre-condition for safely scaling AI-assisted development in a regulated industry is good collaboration between technology and compliance/legal.conf: high
• explicitIt is healthy for senior leaders to leave a place they could comfortably stay in for the rest of their career — to see another organisation before 'legger inn årene'.conf: high
• implicitA career structured around build-joy will look from outside like a series of un-careerist moves (stepping back from a 50+ unit to enterprise architect, for instance), and may be misread on personality tests as low ambition.conf: high
• implicitThe leading/delivering tension is not symmetric: build-joy is the gravitational centre, leadership is the orbit, and the pendulum swings around the builder identity, not the leader identity.conf: medium
• implicitPendling between leading and delivering is a privilege of organisations that explicitly recognise technical depth as an alternative seniority track (Ulseth credits Storebrand with this).conf: high
• implicitThe 'wow' moments in software (mikrokomputer at 10, ChatGPT in Nov 2022, Claude Code post-Christmas 2025) follow a similar pattern: 30 seconds of use is enough to know something important has shifted.conf: medium
• explicitAI capability growth will not extrapolate cleanly; it will hit a stability point (limited by what humans can review, or by the safety machinery that has to be added back in) somewhere between current state and the maximalist projection.conf: high
• explicitThe architect role itself has not changed in its core function — the role-holder is still accountable for the same kinds of choices — even though the practice around it has changed dramatically.conf: medium

Arguments

Narratives

• Age 10, the microcomputer and the BASIC manual: Ulseth and a friend type in programs from a manual hoping for Donkey Kong; mostly they get sinuskurver. But the discovery that 'these machines can be made to do things, maybe things other people need' lights the fire that has steered his whole career.
  → Establishes that build-joy precedes any career structure — supports the claim that pendling is steered by an internal compass, not external incentives.
• The 2022 return: after three years leading the 50+ Architecture & Data unit (later IDA — Insight, Design, Architecture), Ulseth feels he has drifted 'a little too far from what I find most fun'. On the eve of his fourth parental leave he decides he will come back as enterprise architect, not as leader. He returns in November 2022 — the same month ChatGPT launches.
  → Concrete instance of the pendulum swinging down; supports the propositions that pendling is steered by build-joy and that build-joy can rationally override status.
• The move from Storebrand to Fremtind: 'I felt almost — either I stay here for the rest of my career, which would have been fine, or I leave. I wanted to see another organisation before I legger inn årene.' Now at Fremtind he is sjefsarkitekt working with a new IT strategy and a sociotechnical architecture target.
  → Supports the proposition that planned career rupture is valuable even when no escape is needed.
• The kitchen-renovation analogy for coupling and cohesion: high coupling = your pipes run through your neighbour's wall, you can't renovate your kitchen without coordinating their bathroom. Low cohesion = the electrician, plumber and carpenter are in different places, you have to coordinate them yourself. Good architecture = one place to turn to that handles it all.
  → Argument-by-analogy that loose coupling and high cohesion are the general levers for speed and flow; serves as the talk's 'explain it to non-architects' moment.
• The 'fullstack from PowerPoint to JavaScript' self-description: Ulseth describes his Storebrand tenure as pushing the fullstack idea past front/back-end into business strategy as well — he sees PowerPoint and JavaScript as ends of the same craft spectrum.
  → Implicit support for the claim that build-joy is medium-agnostic; foreshadows the later answer about whether sjefsarkitekt PowerPoint can be as satisfying as code.
• The git/subversion story: at some workplaces the de-facto version control choice was actually political — 'the only allowed thing was Subversion' — and only later did git become permitted. Audun retells this as a case where centralisation produced hidden non-compliance until reality forced the change.
  → Supports the proposition that centralised technical control creates the illusion of conformity while real decisions go underground.
• The two 'wow' moments: ChatGPT in November 2022 — 'within 30 seconds I understood something important had shifted' — and Claude Code after Christmas 2025, with similar suddenness. Ulseth has been using Cursor and Claude Code privately since launch but pinpoints a discrete capability jump in early 2026.
  → Supports the proposition that important AI capability shifts announce themselves quickly to a practised hand — and grounds his confidence (against the host's hedge) that this one is real.
• Audun's Finn.no anecdote: 'I noticed I could get bigger things built if I talked more and coded less — that gave me a certain joy when the size of things grew.' Restates the pendulum from a host's experience.
  → Cross-validation by a host of the medium-agnostic build-joy claim.

Questions addressed

• ✅ What drives an experienced technology leader to pendle between leading and delivering?
  Build-joy (drivkraft / bygge-glede), not ambition — the desire to keep making and to keep operating at the right level of abstraction.
• ✅ What do you learn going up that makes you better when you come down — and vice versa?
  Up: triaging real vs. perceived complexity. Down: holistic perspective, budget/risk realism, pragmatism on trade-offs, commercial value awareness.
• ✅ How should a senior architecture role be designed in a modern IT organisation?
  Two dimensions: bredde (governance, architect community, conditions for distributed decisions) and dybde (a personal portfolio of deep initiatives the role-holder owns).
• ⭕ How should distributed architecture decision-making work?
  Hypothesis: conversational architecture (Harmel-Law) — teams empowered, consultation and documentation required, central body receives rather than approves. Ulseth flags he hasn't seen it in practice yet.
• ✅ What must an organisation have in place before scaling AI-assisted development?
  Good engineering culture (continuous delivery is the named example) and, in regulated industries, strong technology–compliance collaboration. Without engineering culture, build it first.
• ⭕ How will AI-assisted development evolve?
  Two host-vs-host views: maximalist (Audun) vs. stabilising-mid-point (Truls). Ulseth refuses to over-predict but is high-conviction that the current capability is real and durable.
• ✅ Is the architect's core function changing?
  No — practice (locus, distribution, cadence) is changing dramatically; the function is the same. (But the 'function' is never defined — see gaps.)
• ⭕ Why don't more senior technologists pendle if it works so well?
  Ulseth speculates: most people's personality-test ambition profile points up-and-onward, and his does not. He explicitly declines a 'fasitsvar'.

Gaps

• incompleteScale dependence of pendling. The whole career story plays out inside two large Norwegian financial-services organisations (Storebrand, Fremtind) that recognise technical depth as legitimate seniority. The conversation never tests whether pendling is feasible — or how it changes shape — in small startups (no role to come back to), pure consultancies (the IC vs. leader frame may not apply), public-sector hierarchies (rigid grade structures), or US-style stock-comp tracks where stepping back is also stepping out financially.
  Read next: Pair with Charity Majors' 'Engineer-Manager Pendulum' original essay to see her conditions for it working; pair with Will Larson on staff-engineer archetypes for the IC-track question; pair with Norwegian-public-sector accounts (NAV optimising for fast flow) for the bureaucracy edge case.
• incompleteThe people who can't pendle. Ulseth's account is sympathetic to both directions but assumes the listener has the option of swinging both ways. It does not address those who are only-leaders (lost technical currency) or only-deliverers (no taste for organisational complexity) — and whether they should be coached, paired, or left in their lane. There is a real possibility that pendling is a personality privilege as much as an organisational one.
  Read next: Camille Fournier on technical-leadership transitions; Cutler on the costs of forcing technical contributors into managerial roles; Allen Holub on accountability and the limits of role-fluidity.
• incompleteThe architect's function is never defined. The talk asserts that architecture has not changed in its core function, only in practice — but it does not say what the function is. The closest thing to a definition is 'enabling speed and flow via loose coupling and high cohesion', which is more a goal than a function and which collapses architecture into platform engineering in some readings.
  Read next: Vlad Khononov on coupling in distributed systems; Ruth Malan on architecture as 'the design decisions that are hardest to change'; Team Topologies for the sociotechnical framing Ulseth invokes.
• incompleteBredde/dybde sounds clean but is operationally underspecified. How does a sjefsarkitekt choose which initiatives to take as 'mine'? Ulseth nods that they should be 'both important and interesting' and that the two usually overlap — but the harder cases (important-but-boring, interesting-but-marginal) are not discussed. This is the place where pendling-by-design either works or quietly collapses into one side.
  Read next: Cutler on how leaders allocate attention; deep-dive into 'staff-plus' patterns where senior ICs balance technical and political work.
• incompleteThe claim that AI raises the incentive to live good engineering culture is asserted but not mechanised. Continuous delivery has been well-described for 20 years and only patchily adopted. Why will AI succeed in changing this where the prior decade's tooling, DORA reports, and platform engineering did not? A causal story is missing.
  Read next: DORA 2025/2026 specifically on AI's interaction with delivery practices; Birgitta Böckeler and Martin Fowler on AI-coding feedback loops; Kent Beck's TCR work as the practice end of the same idea.
• incompleteNo data on whether pendling actually produces better outcomes. The argument is largely 'I felt better and have heard I do better.' The episode lacks any reference to organisational research on whether engineer-manager pendulum careers correlate with better team or product outcomes — and whether the benefits go to the individual, the team, or the organisation.
  Read next: Pragmatic Engineer / Newcomer on staff-plus role outcomes; LeadDev surveys on engineer-manager transitions; academic work on bidirectional career mobility in knowledge work.
• uninformedUlseth notes he has not yet seen conversational architecture practiced and that sociotechnical architecture is a new acquaintance — yet these are the frameworks he is now bringing into Fremtind's IT strategy. The talk does not engage seriously with the published critiques of these models (e.g. that Team Topologies under-specifies platform-team funding, or that Harmel-Law's model assumes a maturity teams may not have).
  Read next: Andrew Harmel-Law's own book and the Architecture Decision Records literature; critical reviews of Team Topologies (Manuel Pais et al.).

Related documents

• 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs
  Hands-On Leadership & the Pendulum Intrinsic Motivation & Making Sociotechnical Architecture Technology Leadership (Heis)
• 17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis
  Organizational Abstraction Levels Sociotechnical Architecture Technology Leadership (Heis)
• Leder du fra sidelinjen – eller ute på banen?
  Hands-On Leadership & the Pendulum Organizational Abstraction Levels Technology Leadership (Heis)
• Agents don't know what good looks like. And that's exactly the problem.
  Evolutionary Architecture & Fitness Functions Sociotechnical Architecture
• The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices
  Evolutionary Architecture & Fitness Functions Sociotechnical Architecture
• 0) Velkommen til Heis
  Hands-On Leadership & the Pendulum Technology Leadership (Heis)
• 4) Morten Eikeland: Det finnes alltid et hierarki
  Hands-On Leadership & the Pendulum Organizational Abstraction Levels
• 13) Tobias K. Torrissen om kodekvalitet, konferanser og AI
  Technology Leadership (Heis) Vibe Coding
• Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools)
  Hands-On Leadership & the Pendulum Intrinsic Motivation & Making
• Strategi som regi i møte med teknologi: En samtale med Walter Qvam
  Intrinsic Motivation & Making Technology Leadership (Heis)