Team Lead · Softwarearchitekt · .NET-Entwickler
Ich führe ein Team und bleibe bewusst im Code.
Bei der WBS GRUPPE führe ich mehrere verteilte Teams mit zusammen 14 Leuten und verantworte die Migration einer gewachsenen .NET-Landschaft nach Azure. Architektur ist für mich die Sprache, in der ein Team entscheidet. Was dabei hält und was nicht, erzähle ich in Vorträgen und schreibe es hier auf.
Antwort in zwei Werktagen · Deutsch und Englisch · remote oder Region Hannover
- rolle
- Team Lead Enterprise Engineering, WBS GRUPPE
- team
- 14 Leute in mehreren Teams, remote
- migration
- .NET Framework → ASP.NET Core auf Azure
- zertifikat
- iSAQB CPSA-FL
- ausbilder
- IHK, seit 2019
Sichtbar machen, wer entscheidet
Ich führe fachlich und disziplinarisch und verantworte die Architekturentscheidungen. Ein Vorschlag von mir kommt im Team deshalb leicht als Anweisung an. Trennen lassen sich die beiden Rollen nicht, sichtbar machen schon: Für jede Entscheidungsklasse steht fest, wer entscheidet und welche Rolle ich habe.
| Klasse | Beispiel | Wer entscheidet | Meine Rolle |
|---|---|---|---|
| operativ | kleines Refactoring | wer die Änderung macht, die statische Analyse prüft | keine |
| strukturell | neues Feld an einer Entity, geänderter Datenzugriff | Autorin und Reviewer im Pull Request | Rat, wenn gefragt |
| schwer revidierbar | Ereignisse, die andere Teams konsumieren | die Teamleitung per Freigabe | Freigabe, offen als Entscheidung |
- Idee„Nur eine Idee, entscheidet ihr: …“entscheidet: das Team
- Rat„Mein Rat, mit Gründen: …“entscheidet: das Team
- Entscheidung„Das entscheide ich, weil …“entscheidet: ich
Entscheidungen, die man in zwei Jahren noch versteht
Schwer revidierbare Entscheidungen landen als ADR im Repo. Meine eigene Option steht dort als eine unter mehreren, mit Herkunft, und durchläuft dieselbe Prüfung wie die anderen.
---
status: proposed
date: 2026-09-18
decision-makers: Teamleitung (Freigabe), Autorin des ADR
consulted: zwei Entwickler aus dem Bestellservice, ein konsumierendes Team, Betrieb
informed: alle Teams, die die Ereignisse konsumieren
---
# Ereignisse des Bestellservice zuverlässig veröffentlichen
## Considered Options
* Transactional Outbox (Vorschlag der Teamleitung)
* Change Data Capture auf der Datenbank
* Direkt nach dem Commit veröffentlichen, mit Retry
Grenzen gehören in den Build
Ich komme aus dem Code und bleibe in Reviews und Architekturentscheidungen. Eine Modulgrenze, die nur im Review existiert, existiert nicht. Sie gehört in die Projektstruktur und in die Pipeline.
// Eine Modulgrenze, die nur im Review existiert, existiert nicht.
[Fact]
public void Abrechnung_kennt_Kurse_nur_ueber_Contracts()
{
var ergebnis = Types.InAssembly(typeof(AbrechnungModul).Assembly)
.That().ResideInNamespace("Abrechnung")
.ShouldNot().HaveDependencyOn("Kurse.Domain")
.GetResult();
Assert.True(ergebnis.IsSuccessful);
}$ dotnet test --filter Abrechnung_kennt_Kurse_nur_ueber_Contracts
Bestanden! Fehler: 0, erfolgreich: 1, übersprungen: 0, gesamt: 1Ein Beispiel mit NetArchTest, die Modulnamen sind ausgedacht. So sehen die Tests aus, mit denen bei uns Modulgrenzen im Build stehen statt im Review.
Erzählt, was bei uns passiert ist
Ich spreche und schreibe als Praktiker, mit Folien und Code aus dem Alltag. Was ich erzähle, ist in unseren Teams passiert.
Jetzt gerade
Was ich lese ↗Zweite Phase der Azure-Migration: die WebForms-Schnittstellen hinter ein .NET-Core-Gateway ziehen.
Ein schriftliches Entscheidungsregister im Team etablieren – kurz, verlinkt, ohne Template-Overhead.
Eigene KI-Gateways für Modelle aus Azure AI Foundry und IONOS – und wie viel Verantwortung ein Coding-Agent übernehmen kann, ohne das Review zur Fassade zu machen.