Anwalt und Programmierer: warum ich beides mache

Zwei Welten, lange getrennt

Mein erstes Gewerbe habe ich 2001 als Schüler angemeldet. Programmieren hatte ich mir selbst beigebracht, HTML, CSS, PHP und MySQL, ohne Kurs und ohne Studium. Das erste Projekt verwandelte Leitzordner voller Audits in ein Intranet. Danach kamen Webprojekte für Kunden, ein Onlineshop, Intranetsysteme und eigenes Webhosting. Parallel dazu habe ich Jura studiert. Beide Welten liefen jahrelang nebeneinander her, ohne sich zu berühren.

Erst 2014, am Ende des Studiums, kam Legal Tech in Deutschland auf. Da hatte ich über zehn Jahre Digitalprojekte hinter mir und merkte, dass sich das Gelernte auf die Rechtswelt übertragen ließ. Seit 2015 bin ich Rechtsanwalt, inzwischen Fachanwalt für Arbeitsrecht. Und ich schreibe bis heute selbst Code. Der Grund ist einfach: Jede der beiden Seiten macht mich in der anderen besser.

Was der Code den Anwalt lehrt

Wer selbst programmiert, weiß, was in einem Projekt technisch realistisch ist und was nur gut klingt. Im Kanzleialltag ist das mehr wert, als es zunächst scheint. Softwareanbieter versprechen viel, und wer die Technik dahinter nicht kennt, kann die Versprechen schlecht einordnen. Ich sehe schneller, ob eine Funktion im Betrieb trägt oder nur auf der Präsentationsfolie.

Programmieren zwingt außerdem zu einer Denkweise, die Juristen selten üben. Jeder Schritt muss eindeutig sein, jede Ausnahme braucht eine Regel, und was nicht beschrieben ist, passiert nicht. Wer einen Ablauf einmal in Software gegossen hat, sieht auch die eigene Kanzleiarbeit anders. Er fragt, welche Schritte sich wiederholen und welche am Einzelfall hängen. Diese Frage stelle ich zu Beginn jedes Projekts, denn sie entscheidet über Aufwand und Erfolg.

Was der Anwalt den Code lehrt

Umgekehrt gilt: Ohne anwaltliche Praxis entsteht kein gutes Legal-Tech-Produkt. Ich habe deshalb 2015 zuerst in einer Wirtschaftskanzlei gearbeitet, mit eigenem Dezernat, eigenen Mandaten und eigener Unterschrift. Wer den Kanzleialltag nicht aus eigener Arbeit kennt, baut Software an den Menschen vorbei, die später damit arbeiten sollen.

Als Anwalt weiß ich auch, wo Software aufhören muss. Prozessführung, Verhandlungen und strategische Beratung hängen am einzelnen Sachverhalt und bleiben Sache des Anwalts. Standardisieren lässt sich, was sich wiederholt und für alle gleich gilt, etwa Datenschutzpflichten, Verträge nach Muster oder Fristen und Standardschreiben. Ein Programmierer ohne juristische Praxis erkennt diese Grenze kaum. Er baut dann zu viel oder das Falsche.

Die Lücke zwischen den Sprachen

In vielen Legal-Tech-Projekten arbeiten Juristen und Entwickler nebeneinander statt miteinander. Die einen denken in Paragraphen, die anderen in Datenmodellen. Dazwischen entsteht eine Lücke, in der Zeit, Geld und gute Ideen verloren gehen. Der Jurist beschreibt eine Prüfung so, wie er sie im Kopf hat. Der Entwickler hört etwas anderes und baut es so, wie er es verstanden hat. Beide merken den Unterschied erst, wenn die Software fertig ist.

Diese Lücke schließe ich, weil ich beide Sprachen spreche. Ich kann eine juristische Prüfung in Entscheidungslogik übersetzen und einem Entwickler erklären, warum eine Ausnahme ein eigener Fall ist. Und ich kann einem Anwalt erklären, warum sein Wunsch mehrere Wochen Arbeit bedeutet, obwohl er nur wie ein zusätzliches Feld aussieht. In meinen beiden Unternehmen habe ich Teams aus Juristen und Entwicklern geführt, und diese Übersetzung war jeden Tag nötig.

Warum ich weiter selbst programmiere

Man könnte einwenden, dass ein Anwalt mit Technikverständnis reicht und das Programmieren anderen überlassen kann. Ich sehe das anders. Wer den Code aus der Hand gibt, verliert das Gefühl dafür, was er kostet. Ich schreibe deshalb bis heute selbst, inzwischen KI-gestützt. Meine eigene Webseite habe ich so neu gebaut, samt einem schlanken Redaktionssystem für diesen Blog.

Dabei habe ich eine Lektion gelernt, die auch für Kanzleien gilt. Ein erster Textentwurf, den ich die KI zum Test schreiben ließ, war geschwollen, kaum verständlich, ein Unsinntext. Daraus entstand ein verbindlicher Schreibleitfaden: nichts erfinden, keine Floskeln, kurze Abschnitte, immer ein Fazit. Die KI arbeitet schnell, braucht aber klare Regeln, und jemand muss draufschauen. Das gilt beim Programmieren wie beim Schreiben, und in einer Kanzlei gilt es erst recht.

Was kleine Kanzleien daraus ziehen

Kaum ein Inhaber einer kleinen Kanzlei wird jetzt PHP lernen, und das muss auch niemand. Drei Dinge aus meiner Erfahrung lassen sich trotzdem übertragen. Erstens lohnt vor dem Kauf einer Software die Frage, welche Arbeit sich in der Kanzlei wirklich wiederholt. Nur dort zahlt sich Technik aus. Zweitens hilft es, die eigene Arbeit so genau zu beschreiben, wie ein Programmierer sie braucht: Schritt für Schritt, mit allen Ausnahmen. Die Lücke zwischen den Sprachen schließt sich nur, wenn sich eine Seite bewegt.

Drittens ist Software erst dann erfolgreich, wenn die Menschen in der Kanzlei sie verstehen, bedienen können und gern nutzen. Ich habe die Digitalisierung meines eigenen Dezernats in meiner damaligen Kanzlei selbst durchgezogen und darüber ein Buchkapitel geschrieben. Der wichtigste Teil davon war die Akzeptanz im Team.