Senior Software Engineer

Pradtke Gmbh
Bochum, Germany
2 days ago
Apply on www.stepstone.de
Prepare application

Role details

Contract type
Permanent contract
Employment type
Full-time (> 32 hours)
Experience level
Expert
Experience required
4 years minimum
Working hours
Regular working hours
Languages
English, German

Tech stack

Clean Code Principles ASP.NET Application Programming Interfaces (APIs) Artificial Intelligence Microsoft Azure Software as a Service Cloud Computing Cloud Engineering Code Coverage Software Quality Extract Transform Load (ETL) Relational Databases
+23 more
Software Design Patterns DevOps Mobile Application Software PostgreSQL Microsoft SQL Server Software Architecture Cloud Services Software Engineering Toolchain TypeScript Web Applications Test-Driven Development (TDD) GitHub Copilot ReactJS Claude Code Backend Vue.js AngularJS Information Technology Front End Software Development Restful APIs Code Restructuring Web Api

Job description

Wir sind Pradtke.

Wir bei Pradtke sind MarktfĂŒhrer fĂŒr Personaleinsatzsoftware in KrankenhĂ€usern, Feuerwehren und anderen Einrichtungen der Daseinsvorsorge. In der Software-Branche besonders ist, dass wir diese Position als selbstbestimmtes Familienunternehmen innehaben.

Unsere App »TIMEOFFICE« sorgt mit kollaborativer Einsatzplanung, umfassenden Compliance-Checks, raschem Engpass-Management und prĂ€ziser Lohnabrechnung dafĂŒr, dass unsere Kunden optimal arbeiten und Bestmögliches fĂŒr uns alle leisten können.

Technologisch ist TIMEOFFICE eine moderne Web-App, die wir mit TIMEOFFICE Air auch als Software as a Service aus der eigenen Cloud anbieten.

Aktuell sind wir rund 60 Menschen, organisiert in dezentralen und selbstorganisierten Teams. Klassische FĂŒhrungskrĂ€fte gibt es bei uns nicht - FĂŒhrung ist inhaltlich, nicht disziplinarisch.

Wir wachsen stetig weiter - in Köpfen wie Könnerschaften. Deswegen suchen wir Dich.

Dein Aufgabenfeld.

Du denkst Architektur, nicht nur Code. Du konzipierst und verantwortest tragfĂ€hige Lösungen fĂŒr TIMEOFFICE - eigenstĂ€ndig und im selbstorganisierten Team.

Wild auf Wirksamkeit?

Als Senior-Entwickler:in gestaltest Du bei uns Produkt ,Architektur und Kundenbeziehungen aktiv mit, bist in TrĂ€gerschaft fĂŒr wichtige Prozesse wie Projekte und sorgst dafĂŒr, dass unsere Lösungen auch fĂŒr die grĂ¶ĂŸten Kunden sauber, skalierbar und sicher funktionieren.

Konkret heißt das:

  • Du entwickelst Frontend- und Backend-Komponenten von TIMEOFFICE weiter und ĂŒbernimmst Verantwortung ĂŒber den eigenen Code hinaus.
  • Du entwirfst Architekturen, Schnittstellen und technische Konzepte und setzt sie auch um.
  • Du stellst Code-QualitĂ€t, Wartbarkeit und Testabdeckung ĂŒber den gesamten Entwicklungsprozess hinweg sicher.
  • Du gestaltest unsere technologische Ausrichtung, Toolchains und Entwicklungsprozesse aktiv mit.
  • Du arbeitest eng und kollegial mit Kolleg:innen aus anderen Disziplinen zusammen und stehst im direkten Austausch mit unseren Kund:innen.
  • Du befĂ€higst Kolleg:innen durch Deine Expertise, teilst Dein Wissen und unterstĂŒtzt andere in ihrer professionellen Entwicklung.

Unser gemeinsames Ziel: Wirksamkeit und Arbeitsfreude in Kliniken, Feuerwehren und anderen Kundenorganisationen stÀrken - und dabei selbst mit viel Freude und hohem Eigenanspruch arbeiten.

Was wir uns wĂŒnschen


  • Du bist erfahrene:r Full-Stack-Entwickler:in mit ausgeprĂ€gtem Allrounder-Profil. Du arbeitest strukturiert, selbstorganisiert und mit hohem QualitĂ€tsanspruch - und weißt zugleich, wie man pragmatisch Strecke macht.
  • Im Frontend setzen wir Vue.js und TypeScript ein. Du bringst fundierte Erfahrung mit modernen SPA-Frameworks mit - vergleichbare Praxis mit React oder Angular ist ebenso relevant.
  • Im Backend verfĂŒgst Du ĂŒber tiefe Praxis mit ASP.NET Core Web APIs und Microsoft SQL Server oder PostgreSQL. REST-basierte Architekturen, saubere API-Schnitte sowie ein solides VerstĂ€ndnis fĂŒr Datenmodelle und Performance sind fĂŒr Dich selbstverstĂ€ndlich.
  • Teile unserer Cloud-Services betreiben wir in Azure. Du hast idealerweise produktive Erfahrung mit Microsoft Azure und verstehst Cloud-Infrastruktur im Allgemeinen. Nicht nur als Deployment-Ziel, sondern, im Sinne von DevOps, als Teil der Architektur, die Du mit gestaltest und betreibst.
  • QualitĂ€tssicherung ist fester Bestandteil Deiner Arbeit: testgetriebene Entwicklung, Komponenten-, Integrations- und End-to-End-Tests sind fĂŒr Dich gute und geĂŒbte Praxis.
  • Boilerplate-Code lĂ€sst Du gerne von AI erledigen, z.B. von GitHub Copilot oder Claude Code - mit klarem Blick auf CodequalitĂ€t, Wartbarkeit und Verantwortung.
  • Du kommunizierst offen und zugewandt, gibst konstruktiven Rat und forderst aktiv Hilfe ein, wenn es mal schwierig wird.
  • Stillstand ist nichts fĂŒr Dich. Du hast Lust auf Neues - in Technologien, fachlichen DomĂ€nen und Denkweisen.

Dein Fundament:

  • Dein Background: Du hast ein abgeschlossenes Hochschulstudium (Informatik oder vergleichbar) in der Tasche.
  • Dein Track-Record: Du blickst auf mindestens 4 Jahre echte Berufserfahrung in der Softwareentwicklung zurĂŒck.
  • Deine Base: Da wir eng im Team und direkt mit unseren Kunden zusammenarbeiten, kommunizierst Du sicher und fließend auf Deutsch und Englisch.
  • Deine Location: Du wohnst in der NĂ€he von Bochum oder bist umzugsbereit, denn PrĂ€senz an mindestens 3 Tagen pro Woche bei uns im BĂŒro ist fĂŒr unser Miteinander essenziell.

Dein Tech-Stack & Mindset:

  • Full-Stack aus Überzeugung: Du bewegst dich im gesamten Stack sicher und bringst ein tiefes analytisches Denken mit.
  • Architektur & Konzepte: RESTful APIs, relationale Datenbanken und gĂ€ngige Design Patterns sind Dein tĂ€gliches Handwerkszeug. Dein klarer Fokus liegt auf zukunftsfĂ€higer Software-Architektur.
  • QualitĂ€ts-Enthusiast: Clean Code ist fĂŒr Dich kein Buzzword, sondern Lebenseinstellung. Code-Audits und Refactorings gehören fĂŒr Dich ganz natĂŒrlich dazu.
  • Cloud & Mobile: Du hast Erfahrung mit den Architekturen von SaaS-Lösungen und mobilen Anwendungen, idealerweise im CNCF-Kontext (Cloud Native Computing Foundation).
  • Performance-Profi: Du weißt genau, wie man Systeme skalierbar baut. Exponentielles Wachstum schreckt Dich nicht ab, weil Du fundiertes Wissen ĂŒber Performance-Optimierungen und ETL-Prozesse besitzt.
  • AI-Ready: Du weißt KI-Tools in der Softwareentwicklung nicht nur zu schĂ€tzen, sondern setzt sie bereits gezielt und sinnvoll ein, um Workflows zu optimieren.
  • Mentor & Lerner: Du hast Bock auf lebenslanges Lernen und teilst Dein Wissen genauso gerne. Mentoring von Kolleginnen und Kollegen ist fĂŒr Dich Ehrensache.

Was Dich erwartet


Bei uns weißt Du, wofĂŒr Du morgens aufstehst: Du arbeitest an sinnstiftenden Aufgaben fĂŒr und mit Organisationen aus der DaseinsfĂŒrsorge. Unser Tun hat direkten Einfluss auf den Arbeitsalltag von 300.000 Menschen, die uns als Gesellschaft den RĂŒcken stĂ€rken.

Sicherheit ist Dir wichtig? Uns auch. Deshalb schließen wir unbefristete ArbeitsvertrĂ€ge.

Wir könnten Dir jetzt erzĂ€hlen, dass wir Benefits wie eine betriebliche private Krankenversicherung, vermögenswirksame Leistungen und betriebliche Altersvorsorge, Firmenfitness und Dienstfahrradprogramm bieten. Stimmt auch alles. Aber was uns wirklich ausmacht, ist unser Anspruch daran, wie wir miteinander-fĂŒreinander arbeiten und wie wir dabei gut miteinander umgehen.

Aber das erlebst Du am besten selbst.

Wat nu?

Wenn Du nicht nur Code, sondern vor allem Architektur denkst - und Spaß wie Ehrgeiz daran hast, tragfĂ€hige Lösungen fĂŒr die Menschen zu konzipieren und zu verantworten, die uns allen helfen -, dann bist Du bei uns genau richtig.

Wir freuen uns auf Dich!

Pradtke GmbH

Kirchharpener Straße 46 44805 Bochum http://www.pradtke.de

Requirements

  • Dein Background: Du hast ein abgeschlossenes Hochschulstudium (Informatik oder vergleichbar) in der Tasche.
  • Dein Track-Record: Du blickst auf mindestens 4 Jahre echte Berufserfahrung in der Softwareentwicklung zurĂŒck.
  • Deine Base: Da wir eng im Team und direkt mit unseren Kunden zusammenarbeiten, kommunizierst Du sicher und fließend auf Deutsch und Englisch.
  • Deine Location: Du wohnst in der NĂ€he von Bochum oder bist umzugsbereit, denn PrĂ€senz an mindestens 3 Tagen pro Woche bei uns im BĂŒro ist fĂŒr unser Miteinander essenziell.

About the company

Wir bei Pradtke sind MarktfĂŒhrer fĂŒr Personaleinsatzsoftware in KrankenhĂ€usern, Feuerwehren und anderen Einrichtungen der Daseinsvorsorge. In der Software-Branche besonders ist, dass wir diese Position als selbstbestimmtes Familienunternehmen innehaben.

Unsere App »TIMEOFFICE« sorgt mit kollaborativer Einsatzplanung, umfassenden Compliance-Checks, raschem Engpass-Management und prĂ€ziser Lohnabrechnung dafĂŒr, dass unsere Kunden optimal arbeiten und Bestmögliches fĂŒr uns alle leisten können.

Technologisch ist TIMEOFFICE eine moderne Web-App, die wir mit TIMEOFFICE Air auch als Software as a Service aus der eigenen Cloud anbieten.

Aktuell sind wir rund 60 Menschen, organisiert in dezentralen und selbstorganisierten Teams. Klassische FĂŒhrungskrĂ€fte gibt es bei uns nicht - FĂŒhrung ist inhaltlich, nicht disziplinarisch.

Wir wachsen stetig weiter - in Köpfen wie Könnerschaften. Deswegen suchen wir Dich.

Dein Aufgabenfeld.

Du denkst Architektur, nicht nur Code. Du konzipierst und verantwortest tragfĂ€hige Lösungen fĂŒr TIMEOFFICE - eigenstĂ€ndig und im selbstorganisierten Team.

Wild auf Wirksamkeit?

Als Senior-Entwickler:in gestaltest Du bei uns Produkt ,Architektur und Kundenbeziehungen aktiv mit, bist in TrĂ€gerschaft fĂŒr wichtige Prozesse wie Projekte und sorgst dafĂŒr, dass unsere Lösungen auch fĂŒr die grĂ¶ĂŸten Kunden sauber, skalierbar und sicher funktionieren.

Apply for this position

This job is hosted externally. Click below to view the full posting and apply.

Apply on www.stepstone.de
Prepare application

Inside Pradtke GmbH

Culture, engineering, and team stories

7 months ago

KI-gestĂŒtzte Softwareentwicklung braucht Zeitorientierung - statt neuer Frameworks

Die Software-Entwicklung als Disziplin steht, methodisch wie technologisch, vor großen Herausforderungen. Viele Frameworks fĂŒr die Organisation der Software-Entwicklung, allen voran Scrum, haben letztlich nie die Wirkung entfaltet, die sich viele erhofft haben. Darauf deuten auch die wenigen belastbaren Studien hin. Es ergibt sich ein „Organizational Drifting“: Prozessuale Anpassungen fĂŒhren dazu, dass sich die Frage stellt, ob das, was praktiziert wird, ĂŒberhaupt noch Scrum ist. Der Einsatz von KI-gestĂŒtzter Codegenerierung wiederum verĂ€ndert derzeit die Software-Entwicklung nicht nur als Disziplin, sondern auch als Job. Ein viel beobachtetes PhĂ€nomen: Mit KI entsteht zwar mehr Code, aber es wird nicht mehr Software ausgeliefert. All das haben wir auch bei Pradke in den letzten Jahren er- und durchlebt. Mit immer wieder einer Konsequenz: Uns ist weniger gelungen, als wir uns vorgenommen haben. Das hat uns dazu gebracht, grundsĂ€tzlich zu hinterfragen, wie wir Software-Entwicklung organisieren.Seit Herbst 2025 haben wir, in enger Zusammenarbeit zwischen Niels PflĂ€ging von Red42 und unserem CTO Sebastian Kubsch, Software-Entwicklung neu gedacht und neu gemacht: Mit Zeit- statt KapazitĂ€tsorientierung, als Single-Piece-Flow-System statt im Batch-Processing. Die Resultate sind bereits in der Zwischenbilanz ziemlich beeindruckend: Im VerhĂ€ltnis zur vorherigen Vorgehensweise – Scrum-ish in Verbindung mit OKR – hat sich der Output vervielfacht: Ein Entwicklungsprojekt, dessen Umsetzungszeit zuvor auf mindestens vier Jahre geschĂ€tzt wurde, haben wir in sechs Monaten realisiert. Bei gleicher TeamgrĂ¶ĂŸe und ohne Abstriche. Wir haben KI in unsere Arbeitsprozesse integriert, ohne mit den systemischen „Slopware“-Schattenseiten leben zu mĂŒssen. Alle bei Pradtke wissen genau, wo wir in der Entwicklung gerade stehen und welche nĂ€chsten Features wann ausgeliefert werden. Überschaubare Tagwerke erzeugen fĂŒr EntwicklerInnen das Erleben von Wirksamkeit und Sicherheit. Das ist toll – und das ist TOSD: Timeoriented Software-Development Dazu haben Niels PflĂ€ging und AndrĂ© Pradke bei Pure Quhr sprechen dĂŒrfen. Den Teilnehmenden gebĂŒhrt unser Dank fĂŒr das Interesse und die lebhafte Debatte. Wenn Du Lust hat, mit uns gemeinsam entlang von TOSD zu arbeiten, laden wir Dich herzlich ein, uns kennenzulernen und Dich zu bewerben!

KI-gestĂŒtzte Softwareentwicklung braucht Zeitorientierung - statt neuer Frameworks
7 months ago

TIME IS THE NEW FRAMEWORK

Wie TOSD die Softwareentwicklung revolutioniertInterview mit Sebastian Kubsch, CTO der Pradtke GmbHSebastian, du bist CTO der Pradtke GmbH und hast gemeinsam mit Niels PflĂ€ging den Entwicklungsprozess TOSD »erfunden.« Was steckt hinter »Time-Oriented Software Development?«Sebastian: TOSD ist ein radikal neuer Ansatz fĂŒr Softwareentwicklung, der Zeit als zentrale Ressource betrachtet – nicht im Sinne von Deadlines, sondern als integralen Bestandteil der Zusammenarbeit, Planung und Umsetzung. Statt klassischer ProjektplĂ€ne oder Sprint-Zyklen setzen wir auf konsequente Zeitorientierung, die den natĂŒrlichen Rhythmus von Arbeit, Teams und Organisationen berĂŒcksichtigt. Das fĂŒhrt zu mehr Klarheit, weniger Overhead und einer deutlichhöheren AnpassungsfĂ€higkeit.Wie kam es zur Zusammenarbeit mit Nils PflĂ€ging und zur Entwicklung von TOSD?Sebastian: Niels und ich haben uns im Sommer 2024 im Rahmen unserer der Beta-Transformation bei Pradtke kennen und mögen gelernt. Wir teilen die Leidenschaft fĂŒr dezentrale, agile Organisationsformen. In vielen GesprĂ€chen haben wir festgestellt, dass »klassische« Softwareprozesse – auch so genannte »agile« Formen der Softwareentwicklung – oft nicht zu modernen, dynamischen Unternehmen passen. Aus dieser Erkenntnis heraus haben wir TOSD entwickelt – als Antwort auf die Herausforderungen, die wir selbst erlebt haben. Es war ein intensiver, kreativer Prozess, der Theorie und Praxis miteinander verbunden hat.Du bist als CTO bei Pradtke der Allererste, der jemals TOSD eingefĂŒhrt hat. Wie verlief die Implementierung und was waren die grĂ¶ĂŸten Learnings dabei?Sebastian: Die EinfĂŒhrung war ein spannender Schritt. Wir haben TOSD nicht einfach »ausgerollt«, sondern gemeinsam mit unseren Teams erarbeitet und angepasst. Das hat enorm geholfen, hohe Akzeptanz zu schaffen und zĂŒgig echte Wirkung zu erzielen. Besonders beeindruckt hat mich, wie schnell sich die Kommunikation verbessert hat – weniger Meetings, klarere Entscheidungen, mehr Fokus.Gleichzeitig hat sich die Geschwindigkeit der Entwicklung sofort drastisch erhöht. Ein zentrales Learning war: Wenn man den Menschen vertraut und ihnen die Zeit als Gestaltungsmittel bewusst macht, entstehen großartige Ergebnisse.Welche konkreten Vorteile hat TOSD schon jetzt fĂŒr eure Kunden gebracht?Sebastian: Unsere Kunden profitieren direkt von der höheren Reaktionsgeschwindigkeit und der besseren QualitĂ€t unserer Software. Durch die zeitbasierte Orientierung können wir schneller auf neue Anforderungen reagieren, ohne in Hektik zu verfallen. Das schafft Vertrauen und ermöglicht eine partnerschaftliche Zusammenarbeit auf Augenhöhe.Wie geht es mit TOSD weiter – intern bei Pradtke und darĂŒber hinaus?Sebastian: Wir entwickeln TOSD kontinuierlich weiter, gemeinsam mit unseren Teams –wir lernen immer noch jeden Tag, jede Woche dazu. Gleichzeitig möchten wir den Ansatz auch anderen Organisationen zugĂ€nglich machen – durch konkrete Angebote, Veröffentlichungen und vielleicht sogar ein Buch. Wir haben ein Forschungspapier zu TOSD veröffentlicht, außerdem haben wir die 1. Bochumer Konferenz fĂŒr Zeitorientierte Softwareentwicklung organisiert, die am 21. Mai stattfinden wird.Gleichzeitig arbeiten wir daran, ein internationales Team rund um TOSD zu formen und mehr Teams und Organisationen fĂŒr die Zeitorientierung zu gewinnen. So haben wir bereits Andreas Schlegel aus Baden-WĂŒrttemberg und Ernesto Corona aus Argentinien als Mitstreiter fĂŒr TOSD gewinnen können – unser Ansatz kommt noch in diesem Jahr nach SĂŒdamerika.Es ist viel los rund um die Zeitorientierung, aber es macht auch unglaublich viel Spaß.Was wĂŒrdest du anderen CTOs oder Softwareverantwortlichen raten, die sich fĂŒr TOSD interessieren?Sebastian: Mein Rat: Denkt Zeit neu. Betrachtet sie nicht als Gegner, sondern als VerbĂŒndete. TOSD ist kein starres Framework, sondern ein Denkansatz, der zur sich an eure RealitĂ€t der Wertschöpfung anpasst und viele Probleme von Steuerung, Arbeitsorganisation, QualitĂ€t und Kosten auflöst oder bearbeitbar macht.Wer bereit ist, die ĂŒbliche Illusion der Planbarkeit und Steuerbarkeit loszulassen und Entwickler:innen Vertrauen zu schenken, wird ĂŒberrascht sein, wie viel Potenzial in den eigenen Entwicklungsteams steckt.Mehr zur Zeitorientierten Softwareentwicklung (TOSD): www.timeoriented.devTickets fĂŒr die 1. Bochumer Konferenz fĂŒr Zeitorientierte Softwareentwicklung: 1. Bochumer TOSD Konferenz - Pradtke GmbH

TIME IS THE NEW FRAMEWORK
4 months ago

Auf den Schultern von Riesen

Ernst Weichselbaum starb am 27. Dezember 2024, zwei Tage nach Weihnachten. Er wurde 80 Jahre alt. Der österreichische Berater, Philosoph und Pionier zeitorientierter Arbeitssysteme hinterließ ein Werk, das fast niemand in der Softwareentwicklung gelesen hat. Er hinterließ zudem den OK-Punkt – ein Konzept, das mehr als sieben Jahrzehnte nach Taiichi Ohnos ersten Experimenten bei Toyota endlich den Weg in den Bereich gefunden hat, in dem es am dringendsten benötigt wird.In diesem Artikel geht es um die Linie, die von Toyota City in den 1950er Jahren ĂŒber Wien in den 1980er Jahren bis hin zum OK Point fĂŒhrt, wie wir ihn heute kennen: den tĂ€glichen Austausch zwischen Konzeptentwicklern und Umsetzern im Herzen der zeitorientierten Softwareentwicklung. Es geht auch darum, warum diese Linie 70 Jahre gebraucht hat, um uns zu erreichen, und warum es wichtig ist, dass wir anerkennen, auf wessen Schultern wir stehen.Die Entdeckung in Toyota CityTaiichi Ohno wurde 1912 in Dalian an der mandschurischen KĂŒste geboren. Er trat als junger Ingenieur bei Toyota Spinning and Weaving ein und wechselte 1943 zur Toyota Motor Company. In den folgenden drei Jahrzehnten entwickelte er – fast im Verborgenen – das, was spĂ€ter als „Toyota-Produktionssystem“ bekannt werden sollte: eine Reihe von Methoden, die so radikal waren, dass westliche FĂŒhrungskrĂ€fte, die Toyotas Fabriken besichtigten, jahrelang mit dem Eindruck zurĂŒckkehrten, ihnen entginge etwas. Und das tat es auch.Das, was ihnen fehlte, war einfach zu beschreiben, aber fast unmöglich zu verinnerlichen. Ohno hatte die grundlegende Annahme der industriellen Produktion auf den Kopf gestellt. Im Westen ging man davon aus, dass die KapazitĂ€t feststeht – man hat seine Maschinen, seine Arbeiter, seine Arbeitszeiten – und die Lieferzeit schwankt um diese herum. Steigt die Nachfrage, werden die Warteschlangen lĂ€nger, die Kunden warten. Sinkt die Nachfrage, stehen die Maschinen still, werden Arbeiter entlassen. Die KapazitĂ€t ist die Konstante; die Zeit ist die Variable.Ohno tat das Gegenteil. Er legte die Zeit fest und ließ die KapazitĂ€t schwanken. Er konzipierte Toyota so, dass die Produktion mit gleichmĂ€ĂŸigen, zuverlĂ€ssigen Lieferungen – der berĂŒhmten Taktzeit – auf die Kundennachfrage reagierte und sich die KapazitĂ€t des Systems selbst anpasste, um diesen Rhythmus aufrechtzuerhalten. Wo sich die KapazitĂ€t nicht anpassen ließ, gestaltete Ohno sie so, dass sie umgestaltet werden konnte. Multifunktionale Mitarbeiter. Schnellwechselwerkzeuge. Kleine LosgrĂ¶ĂŸen. Pull statt Push. Das Ergebnis war in den 1970er Jahren ein Fertigungssystem, das Autos in einer QualitĂ€t und zu Kosten produzieren konnte, mit denen westliche Autohersteller nicht mithalten konnten, ohne die zugrunde liegende Philosophie zu kopieren. Die meisten von ihnen versuchten, nur die Ă€ußeren Merkmale zu kopieren – die Kanban-Karten, die Andon-SchnĂŒre – und scheiterten.Ohno hat die grundlegende Erkenntnis aller Zeitorientierung erkannt: Die Welt schwingt. Die Nachfrage schwingt. Die Jahreszeiten schwingen. Die Erde schwingt. Arbeitssysteme aufzubauen, die so tun, als wĂ€re dies nicht der Fall, bedeutet, gegen die Physik zu arbeiten. Arbeitssysteme aufzubauen, die mit der Welt schwingen, bedeutet, mit ihr zu arbeiten.Der Philosoph, der die Fackel trugOhno war ein Praktiker. Er war zudem, allen Berichten zufolge, ein schwieriger Mensch – direkt, unverblĂŒmt und intolerant gegenĂŒber der ausweichenden Sprache, die den Großteil des Managementdenkens umgibt. Er verfasste drei BĂŒcher, von denen eines ins Englische ĂŒbersetzt wurde. Er starb 1990, nachdem er miterlebt hatte, wie das Toyota-Produktionssystem weltberĂŒhmt und fast ĂŒberall missverstanden wurde.Etwa zur gleichen Zeit, als westliche Berater damit beschĂ€ftigt waren, TPS in „Lean Manufacturing“ umzuwandeln – eine freundliche, vermarktbare, etwas entschĂ€rfte Version von Ohno’s Werk –, war in Österreich ein Denker ganz anderer Art am Werk. Ernst Weichselbaum war ein Berater, der Jahrzehnte in produzierenden Unternehmen verbracht hatte, wo er mit den von Ohno entwickelten Systemen arbeitete, dabei aber andere Fragen zu ihnen stellte. Weichselbaum war ein Philosoph im Ă€lteren Sinne des Wortes: jemand, der versuchte, die Prinzipien hinter der Praxis zu verstehen, und nicht jemand, der diese Praktiken in Schulungen verpacken wollte.Weichselbaums einzigartiger Beitrag, auf den wir bei TOSD tĂ€glich zurĂŒckgreifen, war der „OK-Punkt“. In seiner ursprĂŒnglichen Formulierung befand sich der OK-Punkt an der Schnittstelle zwischen Kunde und Lieferant. Es war der Moment der Einigung – konkret, bezeugt, oft physisch –, in dem ein Projekt von der Konzeptphase, in der die Anforderungen noch verhandelbar waren, in die Umsetzungsphase ĂŒberging, in der dies nicht mehr der Fall war. Vor dem OK-Punkt konnten beide Seiten noch darĂŒber sprechen, wie die Arbeit aussehen sollte. Danach verlagerte sich das GesprĂ€ch darauf, ob die Arbeit wie vereinbart ausgefĂŒhrt wurde. Der OK-Punkt war der Moment, in dem Transparenz unvermeidlich wurde: nicht, weil jemand sie erzwang, sondern weil das Überschreiten dieses Punktes beide Parteien an dieselbe gemeinsame Definition von „fertig“ band.Weichselbaum erkannte, was Ohno erkannt hatte – dass der Wert der Zeitorientierung nicht in der Geschwindigkeit liegt, sondern in der Disziplin, die die Zeitorientierung schafft. Doch er dehnte Ohnos Erkenntnis nach innen aus, vom Fließband hin zum GesprĂ€chsgeschehen. Der OK-Punkt ist eine zeitliche Struktur, die in einer Beziehung zwischen zwei Parteien existiert. Das ist auch der Grund, warum sich Zeitorientierung anders anfĂŒhlt als Lean: Lean versucht, Verschwendung zu beseitigen, Zeitorientierung versucht, Rhythmus zu gestalten.Weichselbaum widmete seine Karriere der EinfĂŒhrung von Zeitorientierung in Unternehmen, die noch nie von Toyota gehört hatten. Er arbeitete mit produzierenden Unternehmen zusammen, aber auch mit Organisationen im Bereich der Wissensarbeit. Er verfasste nur wenige Schriften. Das meiste, was wir ĂŒber sein Denken wissen, stammt von den Menschen, die er beeinflusst hat – darunter Niels Pflaeging, der den kĂŒrzlich erschienenen Band „What would Ernst Weichselbaum do?“ herausgegeben hat und der mehr als jeder andere dafĂŒr gesorgt hat, dass Weichselbaums Name nicht in derselben AnonymitĂ€t verschwindet, die so viele von Ohno’s tatsĂ€chlichen Mitarbeitern umgab.Die 70-jĂ€hrige LĂŒckeHier ist die Frage, die uns beschĂ€ftigt hat, wĂ€hrend wir TOSD aus diesem Erbe aufgebaut haben: Warum hat es 70 Jahre gedauert, bis die Zeitorientierung die Softwareentwicklung erreicht hat?Die ehrliche Antwort lautet: Die Softwareentwicklung hat sich dagegen gewehrt. Sie hat sich aus GrĂŒnden gewehrt, die bei nĂŒchterner Betrachtung wenig schmeichelhaft sind. Der erste und am weitesten verbreitete Grund war die Überzeugung, dass Software Kunst sei. Durch diese Einordnung in den Kunstkontext fĂŒhlte sich jeder Versuch, der Entwicklung eine zeitliche Struktur zu geben, wie ein Verstoß gegen die kreative IntegritĂ€t an. Außerdem entband sie die Branche bequemerweise von der Disziplin, die andere Bereiche des Ingenieurwesens lĂ€ngst akzeptiert hatten. Die kapazitĂ€tsorientierte Herangehensweise mit ihren langen Planungshorizonten und ihrer Toleranz gegenĂŒber TerminĂŒberschreitungen passte perfekt zu einer Praxis, die im Kunstkontext verortet war. Die zeitorientierte Herangehensweise tat dies nicht.Der zweite Grund war, dass die frĂŒhe Agile-Bewegung um das Jahr 2001 herum die eine HĂ€lfte von Ohno’s Erkenntnis aufgriff und die andere HĂ€lfte verwarf. Das Agile Manifest und die Methoden, die sich darum herum entwickelten – Scrum, dann Kanban, dann die Skalierungs-Frameworks – ĂŒbernahmen den „Small-Batch“-Ansatz aus Lean und nannten ihn „Iteration“. Aber sie behielten die KapazitĂ€tsorientierung als zugrunde liegenden Rahmen bei. Ein Scrum-Team hat eine feste KapazitĂ€t, ausgedrĂŒckt in Story-Points, von der angenommen wird, dass sie stabil ist. Sprints kommen und gehen; was schwankt, ist das, was in sie hineinpasst. Das ist die Wand, die mit einer anderen Farbe gestrichen wurde. Ohno hĂ€tte darin keine Zeitorientierung erkannt.Der dritte Grund war soziologischer Natur. Zeitorientierung fĂŒhrt zu einer Dezentralisierung der Macht. Sie lĂ€sst sich nicht mit der dichten Schicht von Vermittlerrollen – Product Owner, Scrum Master, Agile Coaches, Projektmanager, Architekten im Titel – vereinbaren, die sich in den letzten zwei Jahrzehnten rund um die Softwareentwicklung gebildet hat. Eine ganze Branche hat sich um die Aufrechterhaltung dieser Rollen herum organisiert. Zeitorientierung bedeutet unter anderem das Verschwinden dieser Branche. Wie zu erwarten war, hat die Branche diese Entwicklung nicht gerade begeistert aufgenommen.Der vierte und vielleicht entscheidende Grund war, dass KI die Rechnung verĂ€ndert hat. Bevor KI-Assistenten ins Spiel kamen, war der Aufwand beim Tippen von Code so groß, dass die KapazitĂ€tsorientierung vorgeben konnte, das richtige Modell zu sein. Sobald die KI den Aufwand fĂŒr das Tippen auf nahezu null senkte, verlagerte sich der Engpass. Er verlagerte sich zum Denken – zur PrĂ€zision dessen, was gebaut wird, bevor es gebaut wird. Ein Bereich, in dem der Engpass die PrĂ€zision ist, ist ein Bereich, der einen OK-Punkt benötigt. Die Software hatte schließlich keinen Ort mehr, an dem sie sich verstecken konnte.Die Übertragung auf TOSDIm White Paper Nr. 26 beschreiben wir den „OK-Punkt“ in der Softwareentwicklung. Die Übertragung von Weichselbaums „Kunde-Lieferant-Nahtstelle“ ist nicht metaphorisch gemeint: Die Struktur ist dieselbe, nur die Parteien sind andere. In TOSD ist der „OK-Punkt“ die Nahtstelle zwischen Konzeption und Realisierung. Der Konzeptionist ĂŒbernimmt die Rolle der konzeptionellen Seite; der Realisierer ĂŒbernimmt die Rolle der realisierenden Seite. Der Handschlag ist ein tĂ€gliches Ritual, kein vertragliches, aber der zugrunde liegende Mechanismus – es wird eine Einigung erzielt, die Einigung wird bezeugt, die Arbeit ĂŒberschreitet eine Schwelle – entspricht dem, was Weichselbaum beschrieben hat.Wir haben auch den von Ohno entdeckten Rhythmus fast unverĂ€ndert ĂŒbernommen. TĂ€gliche Portionen sind die Kadenz des Fließbandes in der Softwareentwicklung. Die Zeitbox der Realisierung (ein, zwei oder drei Tage) ist die kleine Charge. Das TTEO-Prinzip – „Talk To Each Other“ (Miteinander reden) – ist die Andon-Schnur, an der jederzeit gezogen wird, wenn etwas nicht stimmt. Das Zellstruktur-Design ist in vielerlei Hinsicht die Philosophie der vielseitig qualifizierten ArbeitskrĂ€fte, angewandt auf eine gesamte Organisation. Das sind keine ZufĂ€lle. Es sind die strukturellen GrundsĂ€tze jedes zeitorientierten Arbeitssystems, ĂŒbertragen auf einen Bereich, den Ohno nie gesehen hat und den Weichselbaum sich erst zu erahnen begann.Warum die Tradition wichtig istEs wĂ€re einfach und verlockend, TOSD als etwas Neues darzustellen. Aus marketingtechnischer Sicht ist es das auch. Aus intellektueller Sicht ist es jedoch der jĂŒngste Ausdruck eines 70-jĂ€hrigen Projekts. Ich halte diese Unterscheidung aus mindestens drei GrĂŒnden fĂŒr wichtig.Erstens verschafft die Tradition jedem, der TOSD anwendet, Zugang zur umfassenderen Fachliteratur. Wenn Sie sich damit schwertun, wie die KapazitĂ€t in Ihrer Organisation schwanken sollte, mĂŒssen Sie die Antwort nicht von Grund auf neu erfinden – Ohno hat diese Frage bereits ausfĂŒhrlich fĂŒr einen Bereich beantwortet, der schwieriger ist als der Ihre. Wenn Sie sich damit schwertun, wie sich der „OK-Punkt“ in der Praxis anfĂŒhlt, können Sie Weichselbaum lesen und seine ursprĂŒngliche Formulierung nachschlagen. Die Menschen von diesem Erbe abzuschneiden, indem man so tut, als sei TOSD im Oktober 2025 erfunden worden, wĂŒrde die Praxis verarmen lassen.Zweitens schĂŒtzt die Herkunft vor der hĂ€ufigsten Fehlerquelle neuer Methoden, nĂ€mlich der stillschweigenden WiedereinfĂŒhrung alter Annahmen. Die Zeitorientierung wurde sieben Jahrzehnte lang kontinuierlich abgelehnt, neu interpretiert und wieder vereinnahmt. Die Kenntnis der Geschichte hilft Ihnen, die Muster zu erkennen, wenn sie bei TOSD auftreten. Und das werden sie.Drittens, und das ist das Wichtigste: Diese Tradition mahnt uns zur Demut. Ohno starb, bevor er erleben konnte, dass seine Arbeit richtig verstanden wurde. Weichselbaum starb, bevor er erleben konnte, dass seine Arbeit in Software Einzug hielt. Das Mindeste, was wir tun können, um diese Linie um ein weiteres Segment zu verlĂ€ngern, ist, die Menschen zu nennen, deren Erkenntnisse wir in die Praxis umsetzen. Das Whitepaper Nr. 26 ist Weichselbaum gewidmet. Das Whitepaper Nr. 27 ist Ohno gewidmet. Jeder, der TOSD nutzt, hĂ€lt – ob er es weiß oder nicht – diese Linie ebenfalls am Leben.Wir hoffen, dass zukĂŒnftige Praktiker sie weiter ausbauen werden. Ich hoffe, dass jemand im Jahr 2050 auf unsere heutige Darstellung zurĂŒckblicken und sie als primitiv empfinden wird – nicht, weil sie falsch war, sondern weil sieben Jahrzehnte weiterer Arbeit sie so erscheinen lassen. So funktionieren schließlich Traditionen.Erfahren Sie mehr ĂŒber TOSD: https://timeoriented.dev

Auf den Schultern von Riesen

Good distractions

Loading talks and stories from around this role