Organizational Dysfunctions: Trond Hjorteland (Part 1)

The podcast discusses key ideas in organizational design, focusing on how the placement of coordination and control - either hierarchical (top-down) or within self-managing teams (bottom-up) - shapes organizational behavior and effectiveness. It highlights systemic dysfunctions that arise when traditional management structures persist, especially in agile environments, leading to confusion, lack of autonomy, and poor employee well-being. Foundational research such as the Tavistock coal mine studies illustrates how technological changes can disrupt social cohesion in work groups, emphasizing the need for joint optimization of social and technical systems.

Central to the discussion is Open Systems Theory (OST) and sociotechnical systems (STS), with an emphasis on applying these principles beyond academia into real-world practice. The conversation explores barriers to adopting OST, including resistance from middle management, misuse of terminology like "team," and superficial adoption of frameworks such as Agile, Team Topologies, and DORA without grasping their underlying design principles. The importance of psychological needs - such as autonomy, meaningful work, mutual support, and a shared vision - is underscored, with evidence showing that self-managing teams outperform traditional and even agile setups when these conditions are met.

• What if you restructured your solo project workflow to fully own coordination and control, eliminating dependency on external validation or direction?

  • Move: Design your development process using DP1 (team-based control) principles - define your own architecture, release schedule, and priorities without deferring to imagined stakeholders or "shoulds." Use weekly self-retrospectives to adjust.
  • Why Now?: As a solo operator, you're the only one who can unilaterally implement true self-management; there's no middle layer to resist change. The risk of hybrid failure modes (e.g., pretending to be autonomous while waiting for outside approval) is high and currently eroding your momentum.
  • Expected Upside: Increased clarity, faster iteration cycles, and stronger alignment between your work and personal motivation - directly improving elbow room, meaningfulness, and learning.

• What if you audited your current tools and workflows for hidden "guerrilla optimizations" that create long-term fragility?

  • Move: Map all current technical decisions (e.g., ad-hoc scripts, undocumented integrations, bypassed processes) and assess which were made unilaterally to solve short-term problems but now act as single points of failure only you understand.
  • Why Now?: Solo operators are prone to becoming the invisible "glue" person in their own systems. If you burn out or step away, everything collapses - this risk is already present but unmeasured.
  • Expected Upside: By documenting and systematizing these fixes, you reduce personal cognitive load, increase system resilience, and lay groundwork for future delegation or automation.

• What if you replaced abstract team frameworks like Agile or DORA with direct application of sociotechnical design principles tailored to your solo operation?

  • Move: Instead of adopting Team Topologies or Scrum rituals by rote, apply Open Systems Theory (OST) by aligning your technical stack with your working style - e.g., choose async-first tools if you value variety and autonomy, or batch releases if continuity matters more than speed.
  • Why Now?: Frameworks diluted by industry misuse (like "teams" without real autonomy) won't serve you unless grounded in first principles. You have full agency to implement joint optimization of social and technical factors - something organizations struggle to achieve.
  • Expected Upside: Avoidance of "lazy fair" dysfunction states; creation of a coherent, sustainable workflow where psychological needs (learning, support, purpose) emerge naturally from structure - not forced culture-building.

• Adopt a self-managing team structure by placing coordination and control directly within your development team, ensuring full ownership of decisions around architecture, process, and delivery - avoid delegating critical coordination upward to external managers.

• Audit your current workflow for hybrid dysfunction (e.g., claiming Agile autonomy while deferring release or architectural decisions to higher-ups); eliminate mixed-mode management by fully committing to either hierarchical control or genuine team-based control - not both.

• Identify and formally recognize informal "glue" contributors in your project - such as those enabling collaboration or solving problems behind the scenes - and integrate their roles into sustainable processes to prevent systemic fragility if they disengage.

• Replace vague use of terms like "team" with precise language (e.g., "squad," "crew") that reflects actual responsibilities and boundaries, reducing ambiguity and aligning expectations in solo or small-team software projects.

• Apply sociotechnical design principles when adopting new tools or technologies (e.g., AI, DevOps frameworks): assess not just technical fit but also how the change impacts autonomy, learning, and social cohesion - ensuring joint optimization of human and technical factors.