Norveon Blog

Workalitic gibt es jetzt für Android, gebaut für die Person mit dem Schraubenschlüssel in der Hand

Norveon doo — Fri, 16 Oct 2026 00:00:00 GMT

*Beim Bau dieser App wurden keine Dashboards auf einen Sechs-Zoll-Bildschirm gequetscht.* [Workalitic](https://workalitic.com) ist unsere Plattform für Arbeitsaufträge und Lagerbestand für kleine Außendienstteams. Zum Beispiel HVAC-Trupps, Wartungsfirmen, Hausverwaltungen, Elektriker. Wenn sie zu uns kommen, laufen die meisten über eine WhatsApp-Gruppe und eine Tabelle, die genau eine Person versteht. Ab heute ist die Workalitic-App bei [Google Play](https://play.google.com/store/apps/details?id=com.norveon.workalitic&hl=en) verfügbar. iOS folgt als Nächstes. ## Die Web-App lief bereits auf dem Handy Workalitic läuft seit dem ersten Tag im mobilen Browser. Sie können sie auf den Startbildschirm legen, und sie funktioniert weiter, wenn die Verbindung abbricht. Für einen Manager, der zwischen zwei Meetings einen Blick auf den Tag wirft, reicht das völlig. Stellen Sie sich jetzt einen Techniker im Heizungskeller vor, Handschuhe an, Taschenlampe in der einen Hand, der in einem vollen Web-Layout den richtigen Arbeitsauftrag sucht. Er wird sich sagen, dass er das „später ausfüllt“. Später heißt meistens nie. Genau darum ging es uns. Alles, was Workalitic für einen Manager tut (Berichte, Kosten, Lagerbestände), hängt davon ab, dass die Person im Feld erfasst, was sie getan hat. Wenn das zu viele Taps braucht, lässt sie es weg, und die Zahlen des Managers stimmen still und leise nicht mehr. Also haben wir die Web-App nicht portiert. Wir haben gefragt, was ein Techniker bei einem Auftrag tatsächlich tut, in welcher Reihenfolge, und die App darum herum gebaut. ## Was drin ist Die App deckt zwei Workalitic-Rollen ab. Mitarbeiter erledigen die Arbeit. Betrachter müssen sehen, was los ist, können aber nichts ändern. Admins und Manager bleiben im Web, wo Planung und Disposition auf einem großen Bildschirm ohnehin mehr Sinn ergeben. Ein Techniker öffnet die App und sieht zuerst die ihm zugewiesenen Aufträge. Suche und Filter sind für alles andere da. Im Auftrag kann er sich mit einem Tap ein- und ausstempeln, und diese Stunden fließen direkt in die Berichte, die sein Manager ohnehin liest. Er kann einen Auftrag auf „In Bearbeitung“ setzen oder als „Blockiert“ markieren, wenn er auf ein Teil wartet oder jemand vergessen hat, die Schlüssel zu hinterlegen. Blockiert war der Status, der uns am wichtigsten war. Manager sehen ihn sofort, statt am Freitag davon zu hören. Checklisten werden vor Ort abgehakt. Kommentare bleiben am Auftrag, für den, der ihn als Nächstes übernimmt. Material wird lückenlos nachverfolgt: im Lager abgeholt, vor Ort verbraucht, der Rest zurückgebracht. Der Bestand aktualisiert sich in Echtzeit, was wichtiger ist, als es klingt. Niemand will für ein Teil quer durch die Stadt fahren, das jemand anderes vor einer Stunde mitgenommen hat. Sie können außerdem mit der Kamera Vorher-Nachher-Fotos machen und an den Auftrag anhängen, und Push-Benachrichtigungen sagen Ihnen, wenn Ihnen etwas zugewiesen wurde. Welche Benachrichtigungen Sie bekommen, wählen Sie selbst. Betrachter sehen dieselben Bildschirme, nur ohne die Buttons. Wir wollten niemandem einen Button zeigen, der nur dazu da ist, ihm zu sagen, dass er ihn nicht drücken darf. ## Die langweilige Arbeit Die Feature-Liste schreibt sich leicht. Der Großteil der Arbeit floss in Dinge, die man nur bemerkt, wenn sie kaputt sind. Schlechter Empfang war das große Thema. Viel Außendienstarbeit findet in Kellern und auf Dächern statt, wo ein Balken Empfang ein guter Tag ist. Die App weiß, wenn sie offline ist, sagt das klar und tut nicht so, als wäre etwas gespeichert, wenn es das nicht ist. Ein Techniker, der glaubt, drei Ventile erfasst zu haben, und es nicht hat, ist schlechter dran als einer, der weiß, dass er es noch einmal versuchen muss. Berechtigungen kommen von der Plattform, nicht vom Handy. Wenn ein Manager im Web die Rolle von jemandem ändert, zieht die App nach. Wenn App und Server jeweils ihre eigene Liste führen, wer was darf, geraten sie früher oder später in Widerspruch, und jemand tippt auf einen Button, den der Server dann ablehnt. Anmeldungen bleiben unauffällig. Tokens liegen im sicheren Speicher des Handys und erneuern sich im Hintergrund, sodass ein Techniker an einem gemeinsam genutzten Diensthandy nicht jeden Tag um 7 Uhr morgens ein Passwort eintippt. Apps, die das verlangen, werden gern deinstalliert. Gebaut ist sie mit Expo und React Native, demselben Stack, den wir für Mobile-Projekte unserer Kunden einsetzen. Das war Absicht. Wir empfehlen lieber einen Stack, den wir selbst ausgeliefert und betreut haben, mit echten Nutzern, die sich beschweren, wenn er kaputtgeht. Über ein Android-spezifisches Kopfzerbrechen damit haben wir in [unseren Notizen zur Migration auf 16 KB Page Size](/de/blog/android-16kb-page-size-migration-challenges) geschrieben. ## Warum wir uns die Mühe machen Workalitic ist neben [Arheev](https://arheev.com) und [Omnotic](/de/blog/introducing-omnotic-our-pos-hardware-brand) eines der Produkte, die wir selbst betreiben. Jedes davon hat uns etwas beigebracht, das wir später in Kundenprojekten genutzt haben, und die Kunden mussten die Lektion nicht bezahlen. Dieses hier hat uns daran erinnert, dass eine Web-App, die „auf dem Handy funktioniert“, für jemanden im Heizungskeller trotzdem eine Qual sein kann. Responsives CSS bringt das Layout in Ordnung. An der Zahl der Taps ändert es nichts. ## Probieren Sie es aus Wenn Sie ein Außendienstteam führen, bietet [Workalitic](https://workalitic.com) eine kostenlose 30-Tage-Testphase mit allen Funktionen und ohne Kreditkarte. Legen Sie im Web ein paar Arbeitsaufträge an, dann installieren Sie die [Android-App](https://play.google.com/store/apps/details?id=com.norveon.workalitic&hl=en) auf den Handys Ihrer Techniker. Wenn Sie darüber nachdenken, eine eigene Mobile-App zu bauen, für Ihr Team oder Ihre Kunden, [sprechen Sie mit uns](/de/#contact). Genau das machen wir. *Kein Techniker musste ein Formular zweimal ausfüllen. Darum ging es ja.*

Warum wir weiterhin in Mentoring investieren

Norveon doo — Wed, 23 Sep 2026 00:00:00 GMT

*Beim Schreiben dieses Beitrags wurde keinem Junior-Entwickler eine Leseliste zugeteilt.* Einer unserer Entwickler kämpfte seit Monaten mit derselben Sorte Bug. Flaky Integrationstests, immer ein anderer Test, immer irgendein Timing-Problem. Er war richtig gut darin geworden, sie zu beheben. Schnell, und die PR-Beschreibung erklärte jedes Mal genau, was schiefgelaufen war. Dann saß ein Senior zwanzig Minuten in einem Screenshare dabei und sagte: Das sind keine flaky Tests, das ist eine gemeinsam genutzte Fixture, in die alles hineinschreibt. Das war's, mehr Eingreifen brauchte es nicht. Zwanzig Minuten, ein Satz, und ein Problem, das jeden Monat still und leise die Aufmerksamkeit eines ganzen Sprints verschlungen hatte, existierte nicht mehr. Der Entwickler hätte ein Modell zu jedem einzelnen dieser Fehler befragen und eine gute Antwort bekommen können. Hat er auch, oft, und die Antworten waren korrekt. Was niemand von sich aus gesagt hätte: dass alle Antworten auf die falsche Frage gingen, weil sonst niemand das Muster über Monate hinweg beobachtet hatte. ## Produktiv sein und besser werden sind zwei verschiedene Dinge Diese Unterscheidung ist in den letzten zwei Jahren verschwommen, und das kommt teuer zu stehen, glauben wir. Ein Entwickler mit gutem Tooling kann heute echte Arbeit abliefern, ohne viel davon zu verstehen, warum sie funktioniert. Das ist keine Kritik, dafür sind Werkzeuge da. Aber Ausliefern und Wachsen haben sich still voneinander entkoppelt, und ein Team kann beim Output ziemlich lange gesund aussehen, bevor jemandem auffällt, dass sich bei niemandem das Urteilsvermögen weiterentwickelt. Am deutlichsten sehen wir es in Reviews. Der Code von jemandem ist in Ordnung. Er ist seit einem Jahr in Ordnung. Aber es ist immer dieselbe Art von „in Ordnung“: dieselbe Sorte Problem, auf dieselbe Weise gelöst. Ändert sich das Problem, steckt die Person auf eine Art fest, die ihre PR-Historie nie hätte vermuten lassen. Output sagt Ihnen, was jemand produziert hat. Er sagt Ihnen fast nichts darüber, was diese Person nächstes Quartal produzieren könnte. ## Code-Review ist kein Mentoring Wir haben das länger geglaubt, als gut war, auch weil es bequem ist, das zu glauben. Review steht ohnehin im Kalender. Ein Senior schaut sich ohnehin die Arbeit eines Juniors an. Nah genug dran, sollte man meinen. Ist es nicht, aus einem strukturellen Grund: Review sieht das Artefakt, nicht das Denken, das es hervorgebracht hat. Wenn ein PR existiert, sind die interessanten Entscheidungen längst gefallen. Die drei Ansätze, die in der ersten Stunde verworfen wurden, das falsche mentale Modell, das Ansatz zwei attraktiv aussehen ließ, die Annahme über das Verhalten der Datenbank, die sich als falsch herausstellte, aber diesmal zufällig nichts kaputt gemacht hat. Nichts davon steht im Diff. Sie können nur reviewen, was überlebt hat. Dabei lohnt es sich gerade, das fehlerhafte Denken zu erwischen, denn es produziert nächsten Monat einen anderen Bug, in einer Datei, die niemand damit in Verbindung gebracht hätte. Wir reviewen immer noch alles, wir haben nur aufgehört zu erwarten, dass es eine Aufgabe erfüllt, für die es nie gemacht war. ## Nach einem blinden Fleck kann man nicht fragen Der naheliegende Einwand gegen all das ist 2026, dass ein Modell um 2 Uhr nachts verfügbar ist, nie müde, nie herablassend, und mehr über Ihr Framework weiß als irgendjemand in Ihrem Team. Alles wahr. Wir nutzen diese Werkzeuge ständig. Sie haben den Teil des Lernens, der aus Fragen besteht, nahezu kostenlos gemacht, und das ist ein echter Gewinn. Der Entwickler, der früher bis Montag wartete, um etwas zu fragen, fragt jetzt einfach. Aber jede einzelne dieser Interaktionen beginnt damit, dass Sie wissen, was Sie fragen müssen. Diese Grenze ist nicht vorübergehend. Ein Modell kann eine Annahme hinterfragen, die Sie ihm vorlegen. Es kann nicht, metaphorisch gesprochen, an Ihrem Schreibtisch vorbeigehen und bemerken, dass Sie seit sechs Monaten etwas Seltsames tun. Es sieht Sie nicht über längere Zeit. Jedes Gespräch beginnt bei null. Was Entwickler wirklich zurückhält, sind selten Wissenslücken. Es sind Gewohnheiten. Jedes Mal zur selben Abstraktion greifen. Eine bestimmte Art von Aufgabe chronisch unterschätzen. Verstummen, wenn man feststeckt, statt zu fragen, was in einem [vollständig remote arbeitenden Team](/de/blog/why-we-went-fully-remote) ein viel größeres Problem ist, weil niemand sieht, wie man verstummt. Nichts davon ist eine Frage, und genau das ist das Problem. Jemand anderes muss es für Sie bemerken. ## Alle anderen haben das längst verstanden Es ist ein wenig seltsam, dass Software Coaching als Nachhilfemaßnahme behandelt. Kein ernsthafter Sportler hört auf, einen Trainer zu haben, sobald er gut geworden ist. Musiker, die seit dreißig Jahren auf der Bühne stehen, nehmen immer noch Unterricht. In beiden Fällen ist der Coach häufig weniger fähig als die Person, die er coacht, und das ist in Ordnung, denn der Coach muss nicht besser sein. Er muss von außen hinschauen. Nur die Softwarebranche tanzt hier aus der Reihe. Wir haben eine Kultur gebaut, in der die Bitte um einen Mentor wie ein Eingeständnis wirkt und in der Seniorität stillschweigend bedeutet, dass man so etwas nicht mehr braucht. Unsere erfahrensten Leute schreiben seit 1997 Produktionscode, und sie ziehen aus einer Stunde, in der ihnen jemand bei der Arbeit zusieht, immer noch mehr als aus den meisten Konferenzen. Innerhalb des Teams ist das inzwischen weitgehend unspektakulär. Es hat eine Weile gedauert, dorthin zu kommen. ## Das Feedback von Software ist schlecht kalibriert Dass das in unserem Feld mehr zählt als in den meisten anderen, liegt auch daran: Die Zeit zwischen einer Entscheidung und ihrer Folge schwankt enorm. Machen Sie einen Syntaxfehler, wissen Sie es in unter einer Sekunde. Machen Sie einen Architekturfehler, kompiliert er, besteht die Tests, segelt durchs Review, geht live und kostet Sie dann achtzehn Monate später ein Quartal, wenn eine Anforderung kommt, die das Modell nicht aufnehmen kann. Bis dahin hat derjenige, der die Entscheidung getroffen hat, vergessen, dass er sie getroffen hat, und die Verbindung zwischen Ursache und Wirkung ist nicht mehr herzustellen. Aus Feedback auf dieser Zeitskala kann man nicht lernen. Niemand kann das. Die Schleife ist zu lang und zu verrauscht. Ein Mentor verkürzt sie künstlich. Er hat die achtzehn Monate schon durchlebt, mehrmals, und kann Ihnen am Dienstag sagen, was Sie sonst erst 2028 herausfinden würden. Mit Weisheit hat das wenig zu tun. Es ist Erfahrung, für die schon jemand anderes bezahlt hat, und es ist so ziemlich das Nützlichste, was ein erfahrener Entwickler weitergeben kann. Wir haben über [die Velocity-Metrik eines Kunden geschrieben, die sein Team kaputt gemacht hat](/de/blog/the-velocity-metric-that-quietly-broke-our-client), und das ist derselbe Fehler auf Organisationsebene. Die Konsequenz kam viel zu spät, um noch mit der Entscheidung in Verbindung gebracht zu werden. ## Reibung hat eine Funktion Hier sind wir vorsichtig, denn in die andere Richtung kann man es genauso leicht falsch machen. Tut sich ein Entwickler schwer, will man ihm instinktiv das Hindernis aus dem Weg räumen. Das geht schneller, es ist nett, und es ist meist der falsche Schritt, denn im Ringen steckt das Lernen. Wer jemandem die Antwort vorsagt, bekommt ein funktionierendes Feature, aber keine neue Fähigkeit. Die nützliche Variante ist also enger, als sie klingt. Lassen Sie Leute feststecken. Lassen Sie sie nur nicht an etwas hängen bleiben, in dem keine Lektion steckt, oder in einer Richtung, die strukturell aussichtslos ist. Entscheidend ist, ob die Reibung etwas lehrt, und das richtig einzuschätzen ist der größte Teil der Kunst. Genau hier versagt ein jederzeit verfügbarer Assistent. Er beseitigt Reibung wahllos. Er kann nicht unterscheiden zwischen einem Kampf, der sich lohnt, und einem Yak, das gerade rasiert werden will, weil er nicht weiß, was Sie dieses Jahr lernen sollen. ## Braucht das jeder? Nein, und das sagen wir lieber, als es zu verkaufen. Wenn Sie gerade erst anfangen, bringen ein gutes Buch und eine Community Sie weiter als ein Mentor, weil die Grundlagen gut dokumentiert sind und Sie noch nicht die spezifischen Lücken haben, die Einzelbetreuung lohnend machen. Wenn Sie eine klar umrissene Frage haben, lesen Sie die Doku. Wenn Sie ein Code-Review wollen, holen Sie sich ein Code-Review. Mentoring lohnt sich, wenn der Ertrag ein Vielfaches der investierten Zeit ist, und das trifft meist in genau einer Situation zu: Sie machen das beruflich, Sie sind über das Anfängerstadium hinaus, und Sie sind an eine Decke gestoßen, deren Form Sie nicht erkennen können. Der letzte Teil ist das Erkennungszeichen. Wenn Sie benennen können, was Ihnen fehlt, lernen Sie es einfach. Wenn Sie es nicht können und seit einem Jahr auf demselben Niveau feststecken, dann zahlt sich jemand, der von außen zuschaut, an einem einzigen Nachmittag aus. ## Was wir tatsächlich tun Wir haben das bewusst unstrukturiert gehalten, denn jedes formale Mentoring-Programm, das wir von innen gesehen haben, wurde innerhalb von zwei Quartalen zur Kalenderpflicht. Was es bei Norveon gibt: Niemand arbeitet lange allein an etwas, Pairing passiert standardmäßig statt auf Anfrage, und [unser Stand-up](/de/blog/how-we-run-standup-meetings) ist ausdrücklich kein Status-Meeting, deshalb hört man, wenn jemand zögert. Dieses Zögern ist meist das Signal, dass jemand auf eine Weise feststeckt, die er noch nicht in Worte gefasst hat. Die andere Hälfte ist, dass wir [danach einstellen](/de/blog/how-we-hire-engineers). Wir sind 14 Leute. Eine einzige Person, die Fragen als Störung behandelt, kann das Lernen im ganzen Team abwürgen, und das überlebt kein Programm. Nichts in einem Prozessdokument wiegt schwerer als die Frage, ob die erfahrenste Person im Raum sichtbar noch dazulernt. Wir sind übrigens nicht ganz sicher, ob das trägt. Es informell zu halten bedeutet, dass die, die fragen, Mentoring bekommen, und die Stillen lange unbemerkt bleiben können. Ungefähr zweimal im Jahr spricht das jemand an, und wir haben nie eine Lösung gefunden, die nicht zu genau der Kalenderpflicht wird, die wir vermeiden wollten. Bei 14 Leuten fängt man das auf, weil man alle kennt. Wir gehen davon aus, dass das ab einer gewissen Größe nicht mehr funktioniert, und wir wissen nicht, ab welcher. Das meiste davon ist uns bei der Arbeit an [Arheev](/de/#products) aufgefallen. Wenn dasselbe Team über einen langen Zeitraum dasselbe Produkt ausliefert, sieht man genau, wer besser wird und wer ein Plateau erreicht hat, während er vollkommen produktiv bleibt. Auf einem Sprint-Board sehen die beiden identisch aus. Zwei Jahre später sehen sie sich überhaupt nicht mehr ähnlich. *Kein Mentor wurde per Ticket zugewiesen. Ein paar Gespräche dauerten länger als geplant.*

Ein Produkt, viele Lieferanten, viele Kanäle

Norveon doo — Tue, 01 Sep 2026 00:00:00 GMT

*Keine Tabellenkalkulation kam zu Schaden. Einige wurden in den Ruhestand geschickt.* Fast jedes E-Commerce-System geht davon aus, dass ein Produkt einen Preis hat. Die Annahme ist so vernünftig, dass man gar nicht merkt, sie getroffen zu haben, bis man auf ein Geschäft trifft, in dem sie nicht stimmt. Die Distribution ist so ein Geschäft. Sie kaufen denselben Artikel bei mehreren Distributoren, jeder nennt einen anderen Einkaufspreis und hat einen anderen Lagerbestand. Sie verkaufen ihn über die Shops anderer Leute, jeder will einen anderen Preis und behält eine andere Provision ein. Das Produkt in der Mitte ist ein einziges Produkt. Fast nichts, was daran hängt, gibt es nur einmal. Wir haben dieses Jahr damit verbracht, für [Inovio doo](/de/case-studies/inovio-hub) ein System für genau diese Struktur zu bauen. Folgendes würden wir ins nächste Projekt mitnehmen. ## Beide Richtungen sind Adapter Der Import von einem Lieferanten und der Export in einen Kanal sehen nach unterschiedlichen Problemen aus. Eingehend ist es XML von einem Distributor, eine abgelegte CSV-Datei von einem zweiten, eine REST-API von einem dritten. Ausgehend sind es Marktplätze, von denen jeder sein eigenes Feed-Format will. Strukturell sind sie identisch: etwas Externes, Veränderliches, das auf einer Seite einer Grenze sitzt, die Sie kontrollieren. Also ist jeder Lieferant ein Adapter, der Angebote in einer internen Form erzeugt, und jeder Kanal ein Adapter, der den Katalog in einer internen Form konsumiert. Was sich unterscheidet, gehört in den Adapter. Was zählt, gehört in die Mitte. Das zahlt sich spätestens beim nächsten Lieferanten aus: Ihn hinzuzufügen heißt, einen Adapter zu schreiben. Preisberechnung, Lagerbestand und alle anderen Kanäle bleiben unberührt. Eine Regel hat sich früh bewährt: An einer Grenze wird nichts stillschweigend verworfen. Eine Zeile, die wir nicht zuordnen können, verschwindet nicht in einer Logzeile. Wenn sie aktiv ist und einen Namen hat, wird daraus ein Produktentwurf, der auf einen Menschen wartet, markiert mit dem Grund, warum er nicht eingeordnet werden konnte, und bei jedem späteren Lauf über seinen Code wiedererkannt, statt erneut als Duplikat angelegt zu werden. Eingehende Feeds sitzen außerdem hinter einem Circuit Breaker: Ein Lieferant, der einen schlechten Morgen hat, wird ausgebremst und gemeldet, statt bis zum Umfallen erneut abgefragt zu werden. ## Den Preis einmal berechnen Die Regel, die wir am liebsten behalten würden: Nichts berechnet beim Export einen Preis neu. Vorgefunden haben wir etwas anderes. Einige Kanäle wendeten auf dem Weg nach draußen ihre eigene Margenformel an, sodass der Preis im System und der Preis auf dem Marktplatz zwei verschiedene Zahlen waren. Die echte existierte nur in dem Code, der diesen einen Feed erzeugte. Fragen Sie, warum ein Artikel auf einem Marktplatz billiger ist, und niemand kann antworten, ohne zwei Feed-Generatoren zu lesen. Heute ist die Preisberechnung eine einzige Engine, die die Konditionen je Kanal kennt und die Zahl erzeugt, die tatsächlich veröffentlicht wird. Der Export formatiert. Er rechnet nicht. Der Lagerbestand funktioniert genauso, abgeleitet in genau einer Funktion aus interner Verfügbarkeit und der des Lieferanten. Eine zweite Implementierung gilt als Bug, denn die zweite ist immer die, die auseinanderdriftet. ## Ihre Kennungen gehören anderen Leuten Das ist der Punkt, der am meisten Nachdenken gekostet hat, und der, auf den wir jeden hinweisen würden, der einen Katalog ablöst. Bei einer Migration will man natürlich saubere neue interne Kennungen. Das Problem: Jeder Marktplatz, über den Sie verkaufen, kennt Ihre Produkte bereits unter der Kennung, die das alte System erzeugt hat. Dieser Code steht in deren Datenbank, verknüpft mit der Historie Ihres Angebots und seinem Ranking. Wenn Sie ihn ändern, ist das keine Migration mehr: Sie listen neu und werfen alles weg, was diese Angebote sich erarbeitet haben. Ein migriertes Produkt hört also auf Kanälen, die es schon kannten, weiter auf seinen alten Code, während es für alles andere eine neue interne Kennung trägt. Unglamouröse Modellierung, aber genau sie unterscheidet eine Migration, die außerhalb des Unternehmens niemand bemerkt, von einer, die ein Quartal Marktplatz-Performance kostet. Die allgemeine Fassung: Wenn Sie ein System ablösen, sind seine Kennungen womöglich der Teil, von dem andere abhängen. Und die haben Ihrer Migration nicht zugestimmt. ## Das Backoffice ist keine Website Ziemlich früh haben wir aufgehört, die Admin-Oberfläche wie eine Website zu behandeln. Die Anwender machen hier den Großteil des Tages nur eines: lange Tabellen mit Produkten, Angeboten und Preisen durchgehen, auf der Jagd nach der Zeile, die falsch ist. Alles, was Sie beim Bau von Marketing-Websites verinnerlicht haben, arbeitet hier gegen Sie. Großzügiger Weißraum bedeutet weniger Zeilen auf dem Bildschirm. Ein bequemer 16px-Fließtext bedeutet weniger Zeilen auf dem Bildschirm. Jedes bisschen Luft, das Sie hinzufügen, kostet die Nutzer genau das, wofür sie gekommen sind. Also ist der Fließtext 12px groß, die Abstände sind bewusst eng, und Zeilen pro Bildschirm ist die Zahl, die wir optimieren. Wir sind so weit gegangen, den alternativen Glyphensatz der Schrift für l, 1 und I einzuschalten, weil die drei in einer schmalen Spalte voller SKUs bei 12px wirklich schwer auseinanderzuhalten sind, und ein falsch gelesener Code kostet jemanden zehn Minuten und eine falsche Änderung. In einem Design-Review wirkt das gedrängt, und wir haben dieses Gespräch mehr als einmal geführt, meist untereinander. Niemand, der den ganzen Tag damit arbeitet, hat uns gebeten, es aufzulockern. ## KI schlägt vor, ein Mensch entscheidet Ein Katalog, der aus vielen Distributoren zusammengesetzt ist, ist von Natur aus uneinheitlich. Ein Lieferant schickt eine vollständige Beschreibung und saubere Attribute. Der nächste schickt einen Namen, einen Preis und ein Foto. Beide müssen gut genug sein für einen Marktplatz, der ein Angebot wegen einer fehlenden Abmessung ablehnt. Diese Lücke zu schließen war früher ein Personalproblem, was die Katalogqualität auf so viele Stunden deckelte, wie man dafür aufbringen konnte. Also behandeln wir KI als Anreicherungsdienst über dem Datenbestand, aus derselben Familie wie jeder andere Datenanbieter, den die Plattform aufruft: Sie nimmt das Produkt, das wir haben, füllt die Felder, die die Feeds nicht geliefert haben, und gibt sie zurück. Sie schlägt eine Kategorie mit Konfidenzwert vor, ergänzt fehlende Attribute, leitet die Logistikfelder ab und liest die Produktbilder, wenn der Text allein nicht reicht, um es zu erkennen. Einen KI-Endpunkt aufrufen kann jeder. Spannend wird es bei der Frage, wo seine Ausgabe landen darf. Nichts, was der Dienst zurückliefert, wird auf das Produkt geschrieben. Es wird daneben als offener Vorschlag gespeichert, und ein Anwender nimmt ihn im Vergleich zum aktuellen Wert an oder lehnt ihn ab. Die Annahme wird protokolliert, sodass Sie ein Jahr später noch sagen können, welche Felder ein Mensch eingegeben und welche ein Mensch freigegeben hat. Diese Eigenschaft ist wichtiger, als sie klingt. Gefährlich ist weniger der offensichtliche Schnitzer, den jemand bemerkt, als der plausible, aber falsche Wert, der stillschweigend in einen Datensatz geschrieben wird, sich auf jeden Kanal ausbreitet und von Daten, die ein Mensch eingegeben hat, nicht zu unterscheiden ist. Sobald Sie nicht mehr sagen können, was was ist, können Sie es weder prüfen noch bereinigen, ohne alles noch einmal zu kontrollieren. Eine Ausnahme haben wir zugelassen: Physische Abmessungen füllen leere Logistikfelder direkt, denn in der Breite eines Kartons steckt kein redaktionelles Urteil. Die Herkunft wird trotzdem protokolliert. Der ehrliche Preis für all das ist eine Prüfwarteschlange. Jemand muss sich damit hinsetzen, und in einer schlechten Woche ist das ein ordentlicher Teil des Arbeitstags eines Anwenders. Man könnte einwenden, wir seien zu vorsichtig, und viele Teams würden die Werte einfach hineinschreiben und Beschwerden später beheben. Uns ist die Warteschlange lieber als ein Katalog, für den wir nicht geradestehen können. Es bleibt ein Tausch, und wir sind ihn bewusst eingegangen. ## Was sich verallgemeinern lässt Behandeln Sie jede externe Partei als Adapter, eingehend wie ausgehend. Leiten Sie jede bedeutsame Zahl an genau einer Stelle ab. Fragen Sie, bevor Sie irgendetwas migrieren, welche Ihrer Kennungen sich andere Leute bereits notiert haben. Und wo KI Ihre Daten anreichert: Halten Sie, was der Dienst vorschlägt, getrennt von dem, was Ihr System für wahr hält, und protokollieren Sie den Übergang dazwischen. Sonst sitzen Sie am Ende auf einem Datenbestand, den Sie nie prüfen können. Nichts davon ist raffiniert, aber es entscheidet darüber, ob der nächste Lieferant Sie einen Nachmittag oder ein Quartal kostet, und ob KI-Anreicherung Ihnen einen besseren Datenbestand hinterlässt oder einen Datenqualitätsvorfall in Zeitlupe. *Viele Kanäle. Eine Preis-Engine. Und ein Anreicherungsdienst, der nie das letzte Wort hat.*

Wie Engineering-Leadership in einem Team von 14 wirklich aussieht

Norveon doo — Wed, 29 Jul 2026 00:00:00 GMT

*Bei der Entstehung dieses Beitrags wurde kein Organigramm neu gezeichnet.* Es gibt einen Beitrag aus dem Software-Leads-Newsletter über [die täglichen Aktivitäten von Engineering-Leads](https://softwareleads.substack.com/p/engineering-leaders-day-to-day-activities), den wir intern herumgereicht haben. Seine These: Managementarbeit wirkt neben dem Schreiben von Code unsichtbar, ist aber nicht formlos. Sie ist ein Zyklus aus sechs Aktivitäten, der sich den ganzen Tag wiederholt: Informationen sammeln, sie teilen, Entscheidungen treffen, Entscheidungen beeinflussen, die man nicht selbst verantwortet, Richtung vorgeben und planen. Wir haben jede einzelne davon wiedererkannt. Uns ist aber auch aufgefallen, dass wir fast keine davon so machen, wie das Framework es stillschweigend voraussetzt, denn das Framework ist für eine Führungskraft in einer größeren Organisation geschrieben. Wir sind 14 Entwickler und Designer, seit 2023 vollständig remote, und wir liefern neben Kundenprojekten eigene Produkte aus. Im Folgenden also dieselben sechs Aktivitäten und wie sie in unserer Größe tatsächlich aussehen. Einige werden leichter. Ein paar werden auf eine Weise schwerer, vor der Sie niemand warnt. ## Informationen sammeln Einen Punkt aus dem Artikel würden wir doppelt unterstreichen: Alles Weitere ist nur so gut wie das, was Sie zuerst sammeln. Schlechte Eingaben, schlechte Entscheidungen – und Sie merken es wochenlang nicht. In einem größeren Unternehmen ist das eine echte Aufgabe. Sie ziehen Kontext aus Skip-Level-Gesprächen, Dashboards, Incident-Reviews und drei Teams, die dasselbe Problem jeweils anders beschreiben. In unserer Größe kommt das meiste von allein. Wir haben darüber geschrieben, [wie wir unsere Stand-ups halten](/de/blog/how-we-run-standup-meetings), und dieses Meeting leistet hier mehr als alles andere, was wir tun. Fünfzehn Minuten am Tag, in denen Leute teilen, was interessant ist, statt Status zu berichten. Daraus entsteht ein laufendes Bild vom Team, das Ihnen kein Dashboard liefert. Sie hören das Zögern, bevor jemand sagt: „Passt schon.“ Der Haken: Das funktioniert nur, weil wir klein genug für einen Raum sind. Es skaliert nicht, und das wissen wir. Wir haben Kunden dabei zugesehen, wie sie die Größe erreichten, ab der informeller Kontext nicht mehr von allein ankommt, und ein Quartal lang merkt es niemand, weil sich das Fehlen von Information nicht ankündigt. Wenn in Ihrem Stand-up 25 Leute sitzen, haben Sie das nicht mehr. Sie haben ein Statusmeeting, das sich Stand-up nennt. ## Informationen teilen Hier hört Kleinsein auf zu helfen und fängt an, Sie aktiv zu belügen. Wenn alle alles hören, gehen Sie davon aus, dass alle alles wissen. Tun sie nicht. Jemand war im Urlaub. Jemand steckte zwei Wochen lang bis über beide Ohren in einer Migration. Jemand ist letzten Monat dazugekommen und hat keine Ahnung, dass das, was Sie alle „das alte Abrechnungsding“ nennen, eine bewusste Entscheidung war und kein Unfall. Unsere Regel aus dem Stand-up-Beitrag deckt das ab: Es ist flüchtig, und alles Kritische muss schriftlich wiederholt werden. Diese Regel gibt es, weil wir es falsch gemacht haben. Wir hatten Entscheidungen, auf die sich alle Anwesenden geeinigt hatten, die niemand aufschrieb und die einen Monat später von Leuten neu aufgerollt wurden, die schlicht nicht im Raum waren. Zweimal. Mehr Meetings helfen nicht. Was hilft: akzeptieren, dass mündlicher Kontext nach etwa einer Woche verfällt, und die wenigen Dinge aufschreiben, die länger halten müssen. ## Entscheidungen treffen Der schärfste Satz des Artikels: Auf Gewissheit zu warten ist selbst eine Entscheidung, und sie hat ihren eigenen Preis. Wir würden die Kleinteam-Version ergänzen. Mit 14 Leuten sind die Kosten einer falschen, umkehrbaren Entscheidung wirklich gering. Sie können etwas ausprobieren, es hassen und innerhalb eines Sprints rückgängig machen. Die Kosten einer *langsamen* Entscheidung sind viel höher, als sie aussehen, weil das ganze Team davon blockiert ist und es keinen anderen Arbeitsstrang gibt, der die Verzögerung auffängt. Also neigen wir stark dazu, alles Umkehrbare schnell zu entscheiden und alles andere langsam. Datenbankschema, Framework-Wahl, alles, was Kundendaten berührt: langsam, schriftlich, ausdiskutiert. Welche Library, welche Ordnerstruktur, wie wir Dinge benennen: im Stand-up entscheiden, weitermachen, neu ansehen, wenn es wehtut. Wir liegen nicht immer richtig damit, in welche Schublade etwas gehört. Das Warnsignal ist meist, dass eine „kleine“ Entscheidung immer wieder zurückkommt. Wenn etwas Umkehrbares dreimal neu aufgerollt wird, war es nicht umkehrbar, und wir haben es falsch eingeschätzt. ## Entscheidungen beeinflussen, die man nicht selbst verantwortet Für eine Führungskraft innerhalb eines Unternehmens heißt das: Nachbarteams. Für uns heißt es meist: der Kunde. Das ist die Aktivität, in die wir die meiste Zeit stecken, und die, in der wir anfangs am schlechtesten waren. Wir gaben eine technisch korrekte Empfehlung ab, sahen zu, wie sie abgelehnt wurde, und schlossen daraus, der Kunde habe es nicht verstanden. Was tatsächlich passierte: Wir beantworteten eine Frage, die niemand gestellt hatte. Den CTO trieb nicht die technische Qualität um, sondern ein Board-Meeting in fünf Wochen. Der Artikel nennt das: verstehen, welche Ziele, Zwänge und Anreize Ihr Gegenüber hat. Genau darum geht es. Eine Empfehlung, die jemandes tatsächliche Einschränkung ignoriert, ist keine Empfehlung, sondern eine Beschwerde mit angehängtem Diagramm. Was sich für uns geändert hat: Wir knüpfen das technische Argument an das, woran die Person tatsächlich gemessen wird. „Das fällt uns später auf die Füße“ bewegt niemanden. „Das kostet jetzt zwei Wochen oder etwa sechs Wochen im Q4, wenn Sie gerade die Finanzierungsrunde abschließen wollen“ ist ein Satz, mit dem jemand etwas anfangen kann. Wie eine Variante davon schiefgehen kann, haben wir in [der Velocity-Metrik, die unseren Kunden leise kaputtgemacht hat](/de/blog/the-velocity-metric-that-quietly-broke-our-client) beschrieben. ## Richtung vorgeben Das Framework beschreibt, wie man organisatorische Prioritäten in etwas übersetzt, womit das Team arbeiten kann, und wie man die Standards vorlebt, die man erwartet. Die erste Hälfte bekommen wir fast geschenkt. Es gibt keine Schicht zwischen denen, die entscheiden, was gebaut wird, und denen, die es bauen, also müssen Prioritäten kaum übersetzt werden. Das ist ein echter Vorteil des Kleinbleibens, und wir haben nicht vor, ihn aufzugeben. Bei der zweiten Hälfte spielt die Größe keine Rolle. Wenn wir sagen, Zeitpläne seien ehrlich, und dann stillschweigend jede Schätzung aufpolstern, lernen alle die tatsächliche Regel in etwa zwei Wochen. Wenn wir sagen, das Stand-up sei kein Berichtsmeeting, und dann nutzt ein Gründer es, um den Fortschritt zu prüfen, dann ist es jetzt ein Berichtsmeeting, egal, was in der Doku steht. [Arheev](/de/#products) zu bauen erwies sich als die direkteste Form davon. Wenn Sie Ihr eigenes Produkt mit Ihrem eigenen Prozess betreiben, wird die Lücke zwischen dem, was Sie behaupten, und dem, was Sie tun, sehr konkret. Wir fanden mehrere Stellen, an denen unser Rat an Kunden besser war als unsere eigene Praxis. ## Planen Von dort, wo Sie stehen, dorthin kommen, wo Sie hinwollen, in konkreten Schritten. Unsere Version ist bewusst kurzfristig: zweiwöchige Sprints mit funktionierender Software am Ende und eine erste funktionierende Demo nach zwei bis vier Wochen. Nicht, weil langfristige Planung wertlos wäre, sondern weil in unserer Größe die Genauigkeit eines Plans nach etwa einem Monat ins Bodenlose fällt. Wer etwas anderes vorgibt, erzeugt nur ein Dokument, mit dem sich alle organisiert fühlen. Das Einzige, was wir langfristig planen, sind Menschen. Wer woran arbeitet, wer sich zu langweilen beginnt, wer seit sechs Monaten nichts Neues angefasst hat. Das hat eine viel längere Vorlaufzeit als jede technische Entscheidung, und hier wird Zuspätkommen wirklich teuer. ## Was wir daraus mitnehmen würden Die sechs Aktivitäten halten stand. Wir würden sagen, das Framework beschreibt etwas Reales und weitgehend Unsichtbares, und allein das macht es lesenswert. Was es nicht sagt und was wir ergänzen würden: In einem kleinen Team werden drei davon von selbst leichter, und Sie sollten das nicht damit verwechseln, sie gelöst zu haben. Informationen kommen von allein – bis sie es nicht mehr tun. Richtung braucht keine Übersetzung – bis es eine Schicht gibt, die sie braucht. Die beiden, die nie leichter werden, egal wie groß das Team ist, sind Entscheidungen zu beeinflussen, die man nicht selbst verantwortet, und den Standard vorzuleben, den man zu halten behauptet. Das sind auch die beiden, in denen Sie schon morgen besser werden können, ohne irgendetwas umzustrukturieren. *Keine Frameworks kamen zu Schaden. Einigen wurde sanft widersprochen.*

Wir haben eine Hardware-Marke gelauncht (ja, ausgerechnet ein Softwareunternehmen)

Norveon doo — Mon, 20 Jul 2026 00:00:00 GMT

*Bei dieser Ankündigung kam kein Lötkolben zu Schaden.* Wir sind ein Softwareunternehmen. Wir schreiben React, wir liefern Mobile-Apps aus, wir betreiben eine HR-Plattform. Und jetzt verkaufen wir Point-of-Sale-Hardware. Das ist [Omnotic](https://omnotic.com): unsere POS-Hardware-Marke für den serbischen Markt. Zwei Produkte zum Start, der Thermo-Bondrucker THP-803 und das Touchscreen-POS-Terminal MPOS-M6-150, gemacht für die Orte, die dieses Land am Laufen halten: Cafés, Restaurants, Läden und Lager. Warum macht ein Softwareunternehmen so etwas? Und was haben wir dabei gelernt? ## Die Lücke war nicht die Hardware Wenn Sie in Serbien ein Café oder ein Einzelhandelsgeschäft betreiben und Ihr Bondrucker mitten in der Schicht den Geist aufgibt, sieht es düster aus. Ersatz im Ausland bestellen und wochenlang warten. Bei einem Händler kaufen, für den beim Support immer jemand anderes zuständig ist. Sich durch Garantiefälle kämpfen, die zwischen Importeur, Distributor und einem Hersteller auf einem anderen Kontinent hin- und hergeschoben werden. Die Hardware selbst ist ein gelöstes Problem. Thermodrucker und Touchscreen-Terminals sind ausgereifte, zuverlässige Technik. Kaputt ist alles *um* die Hardware herum: Verfügbarkeit, Support, Rechnungsstellung und jemand vor Ort, der ans Telefon geht. Um diese Lücke zu schließen, braucht es weniger Engineering als eine Marke, einen Vertriebskanal, lokalen Lagerbestand und einen Support, der tatsächlich antwortet. Und so etwas können wir bauen. ## Was Omnotic eigentlich ist Unsere Rolle sollten wir genau beschreiben, denn „wir haben eine Hardware-Marke gelauncht“ kann vieles bedeuten. Wir entwerfen keine Platinen. Wir haben bewährte Geräte ausgewählt, die Marke Omnotic darum herum aufgebaut und alles übernommen, was ein Unternehmen braucht, um mit gutem Gefühl zu kaufen: - **Lokaler Lagerbestand.** Geräte in Serbien auf Lager. Kein Warten auf den Zoll. - **Inländische Rechnungsstellung.** Ein lokales Unternehmen auf der Rechnung, in Dinar, mit ordentlicher Dokumentation. - **Serbischer Support.** Wenn samstags um 11 Uhr etwas kaputtgeht, sprechen Sie mit uns, nicht mit einem Callcenter im Ausland. - **Ehrliche Produkte.** Der THP-803 druckt mit 260 mm/s, mit einem Schneidwerk, das für 1,5 Millionen Schnitte ausgelegt ist. Der MPOS-M6-150 ist ein lüfterloses 15-Zoll-Terminal mit IP65-Schutz und aufrüstbaren Modulen, damit es nicht schon im Jahr nach dem Kauf veraltet ist. ## Der Teil, der für uns wirklich neu war Die Website zu bauen war der einfache Teil. Das machen wir beruflich. Neu war alles andere: eine Marke für ein Publikum positionieren, das sich nicht für Tech-Stacks interessiert; einen Vertriebskanal vom Angebot bis zur Lieferung aufsetzen; Produkttexte auf Serbisch schreiben, für Leute, die Wert in überstandenen Schichten messen statt in ausgelieferten Features; und Support rund um eine Theke gestalten, die nicht stillstehen darf. Das ist dieselbe Arbeit, die wir für Kunden machen (Marke, Web, E-Commerce, Go-to-Market), nur dass das Marktfeedback diesmal direkt bei uns landet. Wenn ein Verkaufsargument nicht zieht oder ein Support-Ablauf jemanden frustriert, steht kein Kunde dazwischen, der die Lektion abfedert. Damit betreiben wir jetzt zwei eigene Produkte. [Arheev](https://arheev.com) hat uns gelehrt, was es braucht, um Software zu bauen und im Produktivbetrieb zu betreiben. Omnotic lehrt uns, was es braucht, um ein physisches Produkt auf den Markt zu bringen. Beides fließt direkt in unsere Arbeit mit Kunden zurück. ## Wie es weitergeht Omnotic startet bewusst mit zwei Produkten. Ein Drucker und ein Terminal decken die Theke ab; alles Weitere wäre Ablenkung, solange wir nicht bewiesen haben, dass wir für das, was wir verkaufen, auch den Support stemmen. Wenn Sie in Serbien in Gastronomie, Einzelhandel oder Logistik tätig sind und Ihre Thekenausstattung nur noch von Hoffnung zusammengehalten wird, schauen Sie bei [omnotic.com](https://omnotic.com) vorbei. Und wenn Sie neugierig sind, was wir für Sie bauen würden (die Marke, den Shop, den ganzen Kanal): Das ist buchstäblich unser Job. [Sprechen Sie mit uns](/de/#contact).

Die Velocity-Metrik, die unseren Kunden leise kaputtgemacht hat

Norveon doo — Tue, 07 Apr 2026 00:00:00 GMT

*Bei der Entstehung dieses Beitrags kamen keine Story Points zu Schaden. Sie waren schon tot.* Ein Gründer, mit dem wir arbeiten, holte uns letzten Sommer in ein Meeting. Auf seinem Bildschirm war ein Diagramm. Abgeschlossene Story Points pro Sprint, zwei Jahre zurück. Die Kurve zeigte steil nach oben. „Sehen Sie sich das an“, sagte er. „Wir sind 40 % produktiver als vor achtzehn Monaten. Warum fühlt es sich dann an, als würde alles auseinanderfallen?“ Wir sahen uns das Diagramm an. Dann seinen Bugtracker. Dann die Kundenabwanderung der letzten sechs Monate. Das Diagramm log. Nicht mit Absicht. Es maß das Falsche. ## Wie eine Zahl zum Evangelium wird Dieser Kunde begann Anfang 2024, die Velocity zu messen. An sich vernünftig. Die meisten Teams, die irgendetwas Scrum-Artiges betreiben, tun das. Ihr VP of Engineering richtete es ein, präsentierte es im monatlichen Board-Meeting, und dem Board gefiel es. Zahl geht hoch, Board glücklich. Sobald eine Zahl einem Board gezeigt wird, hört sie auf, eine Zahl zu sein. Sie wird zur Zielvorgabe. Der VP ging sechs Monate später. Die Zahl blieb. Sein Nachfolger erbte das Dashboard, die Erwartung des Boards und die unausgesprochene Regel, dass die Velocity weiter steigen muss. Was in diesem Team niemand laut aussprechen würde: Jeder Entwickler wusste genau, wie man die Zahl nach oben treibt. Großzügig schätzen. Arbeit in kleinere Tickets zerlegen. Die Aufräumaufgabe auslassen. Sich nicht freiwillig für den fiesen Bug melden, weil er den Sprint-Durchschnitt ruiniert. Das Diagramm stieg weiter. Alle wussten, was passierte. Niemand konnte es stoppen, weil das Board zusah. ## Was wir fanden, als wir wirklich hinsahen Wir verbrachten zwei Tage damit, ihre Codebasis und ihre Tickets durchzugehen. Nicht das Dashboard. Die tatsächliche Arbeit. Die Test-Suite brauchte 47 Minuten. Vor achtzehn Monaten waren es 9. Niemand hatte Zeit, das zu beheben, weil es keine Story Points wert war. Drei ihrer fünf Kerndienste liefen auf einer Node-Version, deren Support acht Monate zuvor ausgelaufen war. Das Upgrade-Ticket existierte. Lag seit über einem Jahr im Backlog. Elf Story Points. Nie angefasst. Elf Punkte für drei kleine Features bewegten das Diagramm weiter als elf Punkte dafür, den Produktivbetrieb nicht kaputtzumachen. Die Zahl der Bugs war im Jahresvergleich um das 3-Fache gestiegen. Aber Bug-Tickets wurden mit ein oder zwei Punkten geschätzt, Features mit fünf oder acht. Technisch gesehen „leistete“ das Team also mehr, während es ein schlechteres Produkt an weniger zufriedene Kunden auslieferte. Die Zahl im Diagramm und der Zustand des Produkts hatten nichts miteinander zu tun. Schlimmer noch: Sie entwickelten sich in entgegengesetzte Richtungen. ## Warum wir ihnen nicht einfach sagen konnten, sie sollen aufhören Wir sagten dem Gründer: Weg mit der Metrik. Er sah uns an, als hätten wir vorgeschlagen, das Büro anzuzünden. „Das Board sieht diese Zahl jeden Monat. Ich kann nicht einfach aufhören, sie zu zeigen. Womit soll ich sie ersetzen?“ Darüber spricht niemand, der Ihnen erklärt, eine Metrik sei schlecht: Sie können keine Metrik abschaffen, an die sich ein Führungsgremium gewöhnt hat. Sie müssen sie durch etwas ersetzen, dem es mehr vertraut. Und wenn Sie das nicht parat haben, stecken Sie fest. In dieselbe Falle haben wir Senior-Entwickler tappen sehen, wenn sie gegen Velocity-Tracking argumentieren. Sie haben recht, aber nichts, was sie an die Stelle der Zahl setzen könnten. Nichts ändert sich, die Zahl steigt weiter und das Produkt wird weiter schlechter. Wir mussten den Ersatz bauen, bevor wir das Original anfassen konnten. ## Womit wir sie ersetzt haben Wir haben nicht eine Zahl gewählt, sondern vier. Keine davon ist perfekt. Alle lassen sich schwerer manipulieren als Story Points. Erstens: die Zeit von „Bug gemeldet“ bis „Bug im Produktivbetrieb geschlossen“ für die schlimmsten 10 % der Bugs. Nicht der Durchschnitt. Der Durchschnitt lügt. Im Long Tail sitzt der Schmerz. Wenn Ihre schlimmsten Bugs drei Monate brauchen, bis sie geschlossen sind, sagt Ihnen das, ob Ihr Team wirklich Qualität liefert. Zweitens: die Zahl der pro Woche ausgelieferten Änderungen, die Code anfassen, der älter als ein Jahr ist. Das haben wir uns von einer Gewohnheit abgeschaut, die wir intern entwickelt hatten. Wenn niemand alten Code anfasst, meidet Ihr Team ihn entweder oder versteht ihn nicht. Beides ist schlecht. Ein gesundes Team kehrt immer wieder zu altem Code zurück, verbessert Kleinigkeiten, löscht Dinge, refaktoriert nebenbei. Drittens: von Kunden gemeldete Probleme pro aktivem Nutzer und Monat. Nicht die rohe Bug-Zahl. Die Bug-Zahl steigt, wenn Sie mehr Features ausliefern. Probleme pro Nutzer rechnen das Wachstum heraus. Wenn diese Zahl steigt, während Ihre Nutzerbasis wächst, haben Sie ein Problem, das die Velocity nie sichtbar machen wird. Viertens: das Vertrauen der Entwickler in die Codebasis, von ihnen selbst berichtet. Einmal im Monat abgefragt. Eine einzige Frage: „Wie viel Vertrauen haben Sie in den Code, den Sie diesen Monat ausliefern, auf einer Skala von 1 bis 5?“ Anonym. Wir zählen aus und zeigen den Trend. Wenn das Vertrauen sinkt, stimmt etwas nicht, und das zeigt sich meist Wochen früher als in jeder anderen Metrik. Wir präsentierten diese Zahlen dem Board drei Monate lang neben dem alten Velocity-Diagramm. Dann ließen wir die Velocity weg. Niemand im Board fragte, wo sie geblieben war. ## Der Teil, in dem wir uns selbst ertappt haben Wir schreiben das nicht aus der sicheren Warte des externen Experten. Etwa vier Monate nach Beginn dieses Auftrags fiel uns etwas Unangenehmes an unserem eigenen Tracking bei Norveon auf. Wir hatten pro Woche gemergte PRs gezählt, als groben Pulsmesser für den Output des Teams. Nicht für ein Board, nicht für irgendjemanden von außen, nur für uns selbst. Der Fall des Kunden brachte uns dazu, uns unsere eigene Zahl anzusehen. Zwei Entwickler mergten konstant die meisten PRs. Sie waren auch diejenigen, bei denen am ehesten ein kleiner Fix zwei Wochen später etwas anderes kaputtmachte. Ein Entwickler mergte die wenigsten PRs. Er war zugleich der, dessen Code nie als Bug zurückkam, dem die anderen ihre Reviews anvertrauten und der im Jahr davor still und leise drei der schlimmsten Stellen unserer Codebasis in Ordnung gebracht hatte. Unsere interne Zahl belohnte die falschen Leute. Viel stand dabei nicht auf dem Spiel. Niemand wurde deswegen gefeuert oder befördert. Aber sie prägte, wie wir in Retros übereinander sprachen, und die Leute, die mehr Anerkennung verdient hätten, bekamen weniger. Wir haben sie abgeschafft. Zwei Monate lang durch nichts ersetzt, während wir herausfanden, was wir eigentlich wissen wollten. Heute erfassen wir die PR-Zahl überhaupt nicht mehr. Stattdessen gibt es eine monatliche Runde, in der jeder Entwickler eine Sache teilt, die er ausgeliefert hat und auf die er stolz ist, und eine Sache in der Codebasis, für deren Behebung er gern Zeit gehabt hätte. Weniger präzise. Ehrlicher. ## Der Teil, der schwer zu akzeptieren ist Eine schlechte Metrik ist schlimmer als keine Metrik. Keine Metrik heißt, Sie müssen urteilen, mit Leuten reden, sich die tatsächliche Arbeit ansehen. Das ist langsam und passt auf keine Folie. Eine schlechte Metrik heißt, Sie haben eine Zahl, die Zahl fühlt sich objektiv an, und die Zahl steuert Sie leise auf Entscheidungen zu, die Ihnen schaden. Story Points pro Sprint sind nicht der einzige Übeltäter. Wir haben erlebt, wie die Testabdeckung in Prozent dasselbe anrichtet. Codezeilen. Deployment-Frequenz. Sogar Uptime, wenn sie isoliert gemessen wird. Jede Zahl, die leicht zu manipulieren und leicht zu präsentieren ist, wird irgendwann manipuliert und präsentiert. Bevor wir heute irgendetwas messen, stellen wir uns eine Frage: Wenn wir sechs Monate lang hart auf diese Zahl hin optimieren würden, wäre das Produkt dann wirklich besser? Oder wären wir nur besser darin, die Zahl zu produzieren? Wenn wir das nicht ehrlich beantworten können, messen wir es nicht. ## Wo dieser Kunde heute steht Sie arbeiten noch immer mit den vier Metriken. Ihr Bug-Long-Tail ist über acht Monate um etwa 60 % gesunken. Die von Kunden gemeldeten Probleme pro Nutzer ebenfalls. Die Vertrauenszahl erholte sich am langsamsten. Es dauerte fast ein Jahr, bis sie wieder dort war, wo sie vor der Ära der Velocity-Jagd gestanden hatte. Diese Verzögerung ist aufschlussreich. Das Vertrauen eines Teams in die eigene Arbeit wächst über Jahre und ist in Monaten beschädigt. Keine Metrik warnt Sie in Echtzeit davor. Bis das Dashboard es erfasst, haben Sie die Leute, die es behoben hätten, schon verloren. Wir helfen ihnen weiterhin. Sie sind noch nicht fertig. *Derzeit helfen wir einem anderen Kunden, sich von seiner Fixierung auf die „Deployment-Frequenz“ zu lösen. Fragen Sie uns in sechs Monaten, ob das neue Dashboard den Kontakt mit dem Board überlebt hat.*

Wie wir Engineers einstellen

Norveon doo — Tue, 24 Feb 2026 00:00:00 GMT

*Für dieses Bewerbungsgespräch musste kein Algorithmus ans Whiteboard.* Wir haben Engineers mehr als einmal auf die falsche Art eingestellt. In den frühen Norveon-Tagen haben wir gemacht, was alle machen. Stelle ausschreiben, Lebensläufe sammeln, Take-Home-Aufgabe verschicken, technisches Interview führen, Angebot machen. Standardprozess. Fühlte sich professionell an. Und dann stellten wir jemanden ein und merkten innerhalb eines Monats, dass es nicht passte. Oder wir verloren einen guten Kandidaten, der woanders zugesagt hatte, weil wir zu langsam waren. Also haben wir einiges geändert. So machen wir es heute. ## Warum wir keine Take-Home-Aufgaben mehr verschicken Die Kandidaten, die wir am liebsten eingestellt hätten, hatten am wenigsten Zeit dafür. Senior Engineers mit Job, Familie, Nebenprojekten. Sie bekamen unsere Aufgabe und wogen sie gegen drei andere ab, die sie in derselben Woche erhalten hatten. Wir stellten außerdem fest, dass die Qualität der Abgaben nichts mit der späteren Leistung im Job zu tun hatte. Wir stellten Leute ein, die polierte Arbeit ablieferten und ins Straucheln kamen, sobald es unübersichtlich wurde. Wir sagten Leuten ab, deren Abgaben grob waren, die sich aber als hervorragend herausstellten, als wir ihnen später anderswo wieder begegneten. Die Aussagekraft war gering, der Aufwand für die Kandidaten hoch. Wir haben sie gestrichen. ## Was wir stattdessen tun Drei Schritte. **Ein kurzes Gespräch.** Dreißig Minuten. Wir wollen wissen, was die Person gebaut hat, was sie sucht und ob es ein offensichtliches Missverhältnis gibt. Gleichzeitig werben wir für uns selbst: Gute Kandidaten haben meist die Wahl und gehen den nächsten Schritt nicht, wenn sie uns nach dreißig Minuten nicht mögen. **Eine Arbeitssession.** Zwei Stunden. Wir nehmen etwas Echtes: einen tatsächlichen Bug aus unserer Codebasis, einen langsamen Endpoint, den wir schon länger beheben wollten, oder unordentlichen Code, zu dem wir eine Zweitmeinung möchten. Wir arbeiten das gemeinsam durch, und einer von uns programmiert die ganze Zeit zusammen mit dem Kandidaten. Wir bezahlen dafür. Wir nehmen jemandem zwei Stunden seiner Zeit und verlangen echte Arbeit. **Ein kurzer Referenz-Check und das Angebot.** Wenn die Session gut lief, machen wir schnell. Wir haben Kandidaten verloren, weil wir nach einem guten Interview zwei Wochen lang abgetaucht sind. ## Wonach wir wirklich suchen Weder nach der richtigen Antwort noch nach einer sauberen Lösung. Wir beobachten, wie jemand laut denkt. Stellt die Person Fragen, bevor sie loslegt? Liest sie den Code, bevor sie ihn ändert? Gerät sie in Panik, wenn etwas nicht funktioniert, oder wird sie methodisch? Am meisten zählt, was jemand tut, wenn er auf etwas stößt, das er nicht kennt. Gute Engineers sagen „Das würde ich normalerweise googeln, ist das okay?“ oder „Diesen Teil des Stacks kenne ich nicht, können Sie mir Kontext geben?“ Das verrät uns mehr als die Frage, ob jemand einen Binärbaum umkehren kann. ## Der ehrliche Kompromiss Das kostet unser Team mehr Zeit, als eine Take-Home-Aufgabe zu verschicken. Zwei Stunden im Kalender eines Kollegen, plus Vorbereitung, plus Nachbereitung. Wir können nicht fünf davon in einer Woche machen, ohne dass andere Arbeit darunter leidet. Also sind wir wählerischer, wen wir zu einer Session einladen, und investieren mehr Zeit in dieses erste Gespräch, um sicherzugehen, dass sich eine Session lohnt. Wir sind vierzehn Leute. Wir stellen nicht oft ein. Und wenn, dann ist uns die richtige Entscheidung wichtiger als eine schnelle. Vier Engineers haben wir so eingestellt. Drei sind noch bei uns. Einer ist in eine andere Stadt gezogen, und Remote-Arbeit ließ sich in seinem Fall nicht einrichten. Keine dramatischen Fehlbesetzungsgeschichten, aber auch keine der „sah auf dem Papier großartig aus, in der Praxis völlig anders“-Geschichten, die es früher gab. Wenn Sie fünfzig Engineers im Jahr einstellen, skaliert das vermutlich nicht. Wenn Sie fünf einstellen, überlegen Sie, ob der Zeitaufwand wirklich so viel anders ist als das Durchsehen von zwanzig Take-Home-Aufgaben. *Diese Woche läuft gerade wieder eine dieser Sessions. Fragen Sie uns in einem Monat, ob wir ein Angebot gemacht haben.*

Wie wir Stand-up-Meetings führen (es ist kein Daily Scrum)

Norveon doo — Fri, 30 Jan 2026 00:00:00 GMT

*Für dieses Meeting wurde kein Board aktualisiert.* Wir arbeiten nicht gern mit Agile Frameworks™ wie Scrum. Wir wissen, wie es geht. Wir haben Teams geleitet, die mit Scrum und ähnlichen Methoden gearbeitet haben. In manchen Fällen passt es, und es kann gut funktionieren. Es ist nur nicht das, was wir im Alltag am effizientesten und angenehmsten finden. Das Konzept eines täglichen Stand-ups lieben wir dagegen. Es ist meist das Erste, was wir einführen, wenn wir zu einem neuen Kundenteam stoßen, das noch keins hat. Aber wir führen Stand-ups nicht wie Daily Scrums, und deshalb zeigen wir hier, wie wir es tatsächlich machen, intern bei Norveon genauso wie mit den Teams, mit denen wir arbeiten. ## Wie wir es heute aufsetzen würden So würden wir es einem neuen Team erklären: **Das Ziel ist, interessante Dinge zu teilen, die für Ihr Team relevant sind, und Blocker anzusprechen.** Was als „interessant“ gilt, hängt vom Kontext ab. Nutzen Sie Ihr Urteilsvermögen und zögern Sie nicht, die Gruppe zu fragen, ob etwas für sie interessant ist. **Wir treffen uns täglich um 12:03 vor dem Mittagessen für etwa 15 Minuten.** An manchen Tagen sind es 10, an anderen vielleicht 20. Bei Bedarf achtet jemand auf die Zeit, aber wir verlassen uns darauf, dass sich alle kurzfassen. **Das Ganze ist flüchtig.** Keine Boards, keine Notizen. Wenn etwas Kritisches geteilt wird, muss es asynchron schriftlich wiederholt werden. E-Mail, Slack, egal. **Das ist kein Reporting-Meeting.** Es ist völlig in Ordnung, an manchen Tagen nichts zu teilen. Es ist sogar erwünscht. Sie werden kaum jeden Tag etwas erleben, das sich zu erzählen lohnt. Ja, das meinen wir ernst. Sie werden sehen, dass wir es selbst so machen. **Sie werden Updates hören, die Sie nicht direkt betreffen.** Vielleicht Dinge, die Sie nicht vollständig verstehen. Das ist normal und so gewollt. Ihre Aufgabe ist es, aufmerksam zu sein, neugierig zu bleiben und zu versuchen, zu folgen, was alle teilen. Stellen Sie danach Fragen. **Alle paar Monate stellen wir dieses Format infrage.** Dazu gehört auch die Frage, ob wir es abschaffen. Was wir hier vorschlagen, ist das Ergebnis jahrelanger kleiner Iterationen. Wir mögen es sehr, aber es passt nicht für alle gleich gut. Irgendwo müssen wir anfangen. ## Was als „interessant“ gilt Dieser Teil ist absichtlich vage. Was es wert ist, geteilt zu werden, hängt vom Team und vom Kontext ab. Etwas konkreter, das kommt bei uns häufig zur Sprache: - **Entdeckungen.** Neue Technologie, neuer Teil des Stacks, neue Geschäftschance. - **Feature-Fortschritt.** Etwas Begonnenes, ein wichtiger Meilenstein, ein Release, Feedback aus den Daten. - **Anstehende Projekte.** Discovery-Ergebnisse, Research-Erkenntnisse, geschäftliche oder rechtliche Anforderungen. - **Zuverlässigkeitsprobleme.** Bugs, Ausfälle, Post-Mortems, Performance-Änderungen. - **Organisatorische Änderungen.** Neuzugang, neues Team. - **Persönliche Ereignisse.** Babys, Umzüge. - **Blocker.** Ein Review wird gebraucht, Kommunikationsproblem, fehlende Klarheit. - **Büro-News.** Neue Richtlinien, anstehende Teambuilding-Events. ## Was dieses Meeting nicht ist Genauso wichtig ist, wofür dieses Meeting nicht gedacht ist: **Ein Board aktualisieren.** Das geht asynchron besser. **Aufgaben berichten oder nachverfolgen.** Dito. Vor allem, weil nicht jeder jeden Tag ein Update teilen wird. **Leute zur Rechenschaft ziehen.** Die Menschen hier sind Profis und sollten kein tägliches Meeting brauchen, um zu beweisen, dass sie vorankommen. Wenn jemand Schwierigkeiten hat, sollte das an anderer Stelle auffallen und dort besprochen werden. **Den Tag planen.** Tun Sie das in kleineren, fokussierten Gruppen. Nicht jeden Tag, und Teammitglieder sollten ihre Projekte so autonom wie möglich steuern dürfen. **Leute zwingen, früh am Morgen anwesend zu sein.** Ja, das haben wir erlebt. **Ein bestimmtes Ziel erreichen.** Da das kein Scrum ist, gibt es womöglich keinen Sprint und kein Sprint-Ziel. Ziele zu erreichen ist das Nebenprodukt eines eingespielten, effizienten Teams. ## Warum wir glauben, dass das funktioniert Die wichtigsten Vorteile eines kurzen täglichen Treffens: **Empathie aufbauen.** Bevor Sie einen großen PR zum Review bekommen, haben Sie den Engineer schon darüber sprechen hören. Sie kennen den Kontext der technischen Entscheidungen, die Schwierigkeiten, die Abwägungen. Sie wissen auch etwas über die Verfassung der Person. Ist sie spät dran? Gestresst? Sie können Ihre Kommunikation anpassen. Dasselbe gilt, wenn der PM vom Druck aus dem Geschäft erzählt. **Entdecken, was andere tun.** Über die Jahre haben wir so viel über die Arbeit von Engineers in Bereichen gelernt, die wir weniger kannten, einfach indem wir ihnen täglich zugehört haben, wie sie erklären, womit sie gerade ringen. Noch besser wird es, wenn Designer und PMs dabei sind und ebenfalls teilen. **Gelegenheiten für Diskussionen schaffen.** Wenn Sie nur auf Ihre Aufgaben und Tickets fixiert bleiben, sind Sie kurzfristig vielleicht produktiver, aber Ihr Fokus wird sehr eng. Damit schränken Sie auch ein, was Sie bewirken können. **Den Puls des Teams fühlen.** Fühlen sich die Leute gut, produktiv, positiv? Oder kämpfen alle? Für uns als verteiltes Team, in dem man nicht auf Gespräche an der Kaffeemaschine zählen kann, ist das besonders wichtig. **Ein Gespür dafür bekommen, wer woran arbeitet.** Wenn man jemanden monatelang über ein Thema sprechen hört, bleibt das hängen. Sie wissen, an wen Sie Fragen weiterleiten, wenn es so weit ist. **Teamdynamik verbessern.** So wie regelmäßige 1:1s mit der Führungskraft eine Arbeitsbeziehung aufbauen, ist regelmäßiger Austausch mit Teamkollegen weit effektiver als ein Workshop einmal im Quartal. Und ein kleiner Bonus für Teams vor Ort: Es vor dem Mittagessen zu machen, ist ein natürlicher Abschluss des Vormittags und bringt die Leute dazu, gemeinsam zu essen. Günstiges Teambuilding. Überraschend effektiv. ## Fragen, die wir immer bekommen Wir haben das über die Jahre in vielen Teams eingeführt. Unterm Strich war es positiv. Nicht 100 % der Leute haben 100 % des Nutzens bekommen, aber der ROI war gut genug, um weiterzumachen. Diese Fragen und Einwände hören wir immer wieder. ### „Das stört. Ich bin besser dran, wenn ich mich auf meinen Code konzentriere.“ Da es jeden Tag stattfindet, können Sie Ihren Tag darum herum planen. Zugegeben, es stört. Aber wie regelmäßige 1:1s ist es eine Investition. An einem einzelnen Tag lohnt es sich vielleicht nicht spürbar, der Nutzen zeigt sich erst mit der Zeit. Sie denken vielleicht, Ihre Rolle besteht nur darin, Code zu schreiben, Figma-Designs zu erstellen oder PRDs aufzusetzen. Sie umfasst mehr. Ihr Team zu verstehen, ist wichtiger, als Sie erwarten würden. Die Zeit macht die spätere Zusammenarbeit einfacher und erspart Ihnen Kopfschmerzen. ### „Das sollten wir asynchron machen.“ Es geht um Empathie und Nähe, und das schriftlich zu erledigen, halten wir für kontraproduktiv. Wir sind noch nicht überzeugt, dass das Lesen einer Slack-Nachricht dieselbe Wirkung hat wie zu sehen, wie jemand dasselbe mündlich teilt. Außerdem hinterlassen schriftliche Updates eine Spur und fühlen sich irgendwann wie Reporting an. Genau das wollen wir vermeiden. ### „Niemand wird verstehen, woran ich arbeite.“ Manchmal arbeiten Sie an etwas Kniffligem, das nur Sie vollständig verstehen. Das ist in Ordnung. Nehmen Sie sich etwas mehr Zeit, den Kontext zu erklären. Vielleicht müssen Sie ihn öfter wiederholen, was Mehrarbeit ist. Aber es hat einen doppelten Nutzen: Mehr Leute werden in Ihr Thema eingearbeitet, und Sie werden besser darin, tiefe technische Arbeit verständlich zu machen. Beides lohnt sich. ### „Ich bin Designer, mich interessiert nicht, was die Entwickler machen.“ Wir halten das für die falsche Sichtweise. Engineers zu verstehen, und von ihnen verstanden zu werden, entscheidet mit darüber, ob Sie beim Bauen von Software erfolgreich sind. Wenn Sie Entwicklung nur als Implementierungsdetail sehen, begrenzen Sie, welche Designs Sie tatsächlich vor Nutzer bringen können. Das wollen Sie vermutlich nicht, es sei denn, Ihr Job besteht nur aus Mockups und statischen Assets. ### „Ich bin Engineer, mich interessiert nichts außerhalb des Engineerings.“ Ebenfalls der falsche Ansatz. Wer Produkte baut, profitiert enorm davon, mehr als nur die Technik zu verstehen. Design mag nicht Ihr Thema sein, aber wenn Sie täglich ein paar Minuten davon mitbekommen, erkennen Sie Abkürzungen, Design-Debatten laufen reibungsloser, und Sie haben bessere Argumente gegen zu komplexe Lösungen. Wir möchten Sie ermutigen, Ihren Job als mehr als nur Programmieren zu verstehen. Dabei hilft es, sich für andere Bereiche zu öffnen, und hier lernen Sie mit ein paar Minuten Aufmerksamkeit am Tag dazu. Kein schlechter Tausch. ### „Wir haben schon zu viele Meetings.“ Wenn Sie viele andere Meetings haben, würden wir eher diese überprüfen und ausmisten. Das tägliche Stand-up senkt die Zahl der Meetings insgesamt, weil es Probleme und Missverständnisse früh abfängt. Es zu streichen, macht 15 Minuten frei, kostet aber später viele Stunden mehr. ### „Das ist nicht Scrum-konform.“ Richtig. Es ist kein Daily Scrum und hat nicht dieselben Ziele. ### „Sie sagen, es sei kein Reporting, aber genau das ist es.“ Wir verstehen, warum es sich so anfühlen kann. Aber wir halten nicht fest, was geteilt wird, und es verlässt das Team nicht. Sie sind eingeladen, zu teilen, was interessant ist, und das ist nicht immer direkter Fortschritt bei Ihren Aufgaben, was das Ganze zu einem miserablen Reporting-Tool macht. Da nutzen wir viel lieber unseren normalen Ticket-Tracker, um zu sehen, was läuft. ### „Ich traue mich nicht, nichts zu teilen.“ Wenn Sie neu im Team sind, ist das normal. Keine Sorge. Sie werden sehen, dass andere es tun, und mit der Zeit sollte es weniger einschüchternd wirken. ### „Kann man wirklich nichts teilen?“ Ja. „Nichts wirklich Interessantes seit dem letzten Mal“ funktioniert. „Immer noch an derselben Aufgabe, nichts Neues“ funktioniert auch. Wenn jemand mehrere Tage hintereinander nichts zu teilen hat, kann das ein Warnzeichen sein. Erfahrungsgemäß steckt meist einer von drei Gründen dahinter: - **Die Person hält ihre Themen nicht für interessant.** Dann hilft ein kurzer Hinweis, warum andere von einem bestimmten Teil ihrer Arbeit hören wollen könnten. - **Sie hat ein tieferliegendes Problem.** Mit dem Prozess, der Arbeit, dem Team, dem Unternehmen oder dem Leben im Allgemeinen. Das muss man sich im Einzelfall ansehen, und es zeigt sich meist auch außerhalb des Stand-ups. - **Sie steckt fest und fühlt sich nicht sicher genug, das zu sagen.** Das löst sich meist von selbst, sobald sie sieht, dass andere offen über Blocker sprechen. *Bei der Entwicklung dieses Stand-up-Formats kam kein Framework zu Schaden. Ihre Ergebnisse können abweichen.*

Jede Start-up-Teamstruktur, die wir ausprobiert haben (und warum sie alle gescheitert sind)

Norveon doo — Fri, 28 Nov 2025 00:00:00 GMT

[image1]: /images/blog/2025-11-28.jpg "Jede Start-up-Teamstruktur, die wir ausprobiert haben" ![Jede Start-up-Teamstruktur, die wir ausprobiert haben][image1] *Es gibt keine perfekte Teamstruktur, nur verschiedene Arten festzustecken.* Letzten Monat fragte uns ein Gründer: „Wie sollen wir unser Engineering-Team organisieren?“ Wir haben gelacht. Die Frage ist gut, aber wir haben Teams jede mögliche Antwort ausprobieren sehen, und irgendwann scheitern sie alle. Wir sind bei Norveon 14 Leute. Alle Generalisten. Funktioniert für uns. Aber wir haben mit einem Kunden gearbeitet, der in zwei Jahren von 8 auf 32 Entwickler gewachsen ist. Wir durften jede Umstrukturierung miterleben. So lief es tatsächlich. ## Aufteilung nach Tech-Stack Bei etwa 10 Leuten teilen sich die meisten Teams nach Technologie auf. Frontend zum Frontend, Backend zum Backend, Mobile zusammen. Dieser Kunde hat das im Juni 2023 gemacht. 18 Entwickler insgesamt. React-Web-App, Swift- und Kotlin-Mobile-Apps, Node.js-Backend. Drei Teams. Hat drei Monate funktioniert. ## Warum es gescheitert ist Jedes Feature brauchte alle drei Teams. Neuer Onboarding-Flow? Backend baut APIs, Frontend baut Formulare, Mobile aktualisiert die Apps. Drei Teams müssen sich für ein einziges Feature abstimmen. Frontend beschwerte sich, die APIs seien nicht fertig. Mobile beschwerte sich, die APIs seien fürs Web gebaut. Backend hatte keine Ahnung, warum es die Hälfte dieser Endpunkte überhaupt baute. Niemand war für irgendeinen Teil des Produkts verantwortlich. Alle fassten alles an, also verstand niemand wirklich, wie irgendetwas funktionierte. Ab Monat vier bestand jedes Stand-up aus „warten auf Backend“ oder „blockiert durch API-Änderungen“. ## Squads (wie bei Spotify) Nächster Versuch: Organisation nach Produktbereichen. Squad A: Nutzerverwaltung. Squad B: Kernfunktionen. Squad C: Abrechnung. Jede Squad bekam Frontend-, Backend- und Mobile-Leute. Fühlte sich deutlich besser an. Die Teams waren für ihren Bereich verantwortlich. Konnten liefern, ohne auf andere zu warten. Hielt ein Jahr. ## Woran die Squads gescheitert sind Niemand kümmerte sich um technische Themen. Das React-Router-Upgrade lag acht Monate im Backlog. Die Test-Suite wuchs von 3 Minuten auf 55 Minuten. Wessen Aufgabe war es, das zu beheben? Niemandes. Der iOS-Entwickler in Squad A hatte niemanden, mit dem er über iOS-Probleme reden konnte. Squad B wählte eine State-Library, Squad C eine andere. Technische Schulden häuften sich an. Jede Squad wurde an Features gemessen, nicht an Codequalität. In Monat 11 waren drei Entwickler ausgebrannt. ## Chapters kommen dazu Also kamen Chapters dazu. Alle Frontend-Leute in einem Frontend-Chapter. Alle Backend-Leute im Backend-Chapter. Die Chapter-Leads drängten auf 20 % Zeit für technische Arbeit. Framework-Updates, Wissensaustausch, Technologieentscheidungen. Die ersten zwei Monate waren großartig. Updates wurden erledigt. Tech-Talks fanden statt. Dann begann der Streit. ## Das Chapter-Problem Produktmanager gegen Chapter-Leads. Jeden Sprint. „Warum aktualisiert Alice Abhängigkeiten, statt Features zu bauen?“ „Warum hat Bob das Sprint-Planning für ein Chapter-Meeting geschwänzt?“ Sie fingen an, Prozentsätze zu erfassen. Alice: 23 % Chapter-Zeit. Bob: 11 %. Alle hassten es. Die Entwickler wurden in zwei Richtungen gezogen. Der Squad-PM will das Feature bis Freitag. Der Chapter-Lead will Sie im Workshop. Entscheiden Sie sich. Nach sechs Monaten begannen die ersten zu kündigen. ## Plattform-Team Als Nächstes: ein eigenes Team für technische Arbeit. Der Backend-Lead wechselte dorthin, dazu zwei Mobile-Entwickler und ein Frontend-Entwickler. Dadurch waren die Produkt-Squads unterbesetzt. Squad A hatte nur noch einen Backend-Entwickler. Squad B verlor die Hälfte seiner Mobile-Kapazität. Aber der Streit hörte auf. Das Plattform-Team machte die technische Arbeit. Die Produkt-Squads bauten Features. Allerdings. ## Neue Probleme Der Backend-Lead hatte nie Zeit, seiner alten Squad zu helfen. Squad A fiel zurück. Ihr einziger Backend-Entwickler ging unter. Die Mobile-Entwickler wurden ständig zurück in die Produktarbeit gezogen. Kunden beschwerten sich, dass iOS und Android nicht synchron waren. Der Frontend-Entwickler im Plattform-Team wollte nach drei Monaten kündigen. Libraries aktualisieren macht nicht so viel Spaß wie Features bauen. Das Schlimmste: Den anderen Entwicklern wurde Codequalität egal. „Das Plattform-Team richtet das schon“ wurde zur Ausrede für unordentlichen Code. Das Plattform-Team führte mehr Prozesse ein. Das sorgte für böses Blut zwischen den „Architekten“ und den „Leuten, die die echte Arbeit machen“. ## Temporäre Projektteams Plattform-Team aufgelöst. Neuer Plan: temporäre Teams für große Projekte. Projekt Alpha: React-Upgrade. Drei Frontend-Leute, zwei Monate. Projekt Beta: APIs für Mobile neu bauen. Zwei Backend, zwei Mobile, zwei Monate. Projekt Beta brauchte vier Monate statt zwei. Falscher Umfang. Zu spät zum Abbrechen. Projekt Alpha verlor nach einem Monat jemanden. Ersatz kam dazu. Das Onboarding dauerte drei Wochen. Das Projekt lief sieben Monate statt zwei. Der Entwickler, der alle sieben Monate dabeiblieb, brannte aus. Kündigte einen Monat nach Abschluss. Projekt Beta wurde in Monat drei abgebrochen. Zu komplex. Sechs Monate später mussten sie etwas aus Projekt Alpha ändern. Das Team war weg. Der ursprüngliche Entwickler hatte gekündigt. Niemand wusste, wie es funktionierte. ## Staff Engineers Aktuelle Aufstellung: Zwei Leute wurden zum Staff Engineer befördert. Einer Backend, einer Frontend. Sie sind frei beweglich. Helfen, wo es nötig ist. Die Chapters kamen zurück. 20-%-Regel. Aber diesmal ohne Erfassung. Nur Vertrauen. Läuft seit acht Monaten. Der Backend-Staff-Engineer half Squad A, bis jemand eingestellt war. Der Frontend-Staff-Engineer leitete das React-Update. Die Staff Engineers veranstalten monatliche „Update-Tage“. Ein paar Leute aus jeder Squad verbringen einen Tag damit, Abhängigkeiten zu aktualisieren und Tests zu ergänzen. Die Chapters treffen sich alle zwei Wochen. Wissensaustausch. Technologieentscheidungen. Keine Arbeitszuweisungen. Nicht perfekt. Die Staff Engineers sind auf zu viele Baustellen verteilt. Solche Leute einzustellen ist schwer. ## Was wir gelernt haben Jede Struktur scheitert irgendwann. Technologie-Teams scheitern am Koordinationsaufwand. Squads scheitern, wenn technische Arbeit ignoriert wird. Chapters erzeugen Konflikte. Plattform-Teams verlieren den Bezug zur Realität. Projektteams reißen Deadlines. Wir sind bei Norveon 14 Leute. Alle Generalisten. Funktioniert in unserer Größe. Würde bei 50 nicht funktionieren. Dieser Kunde hat jetzt 32 Entwickler. Im Staff-Engineer-Modell zeigen sich bereits erste Risse. ## Wenn Sie das gerade durchmachen Kopieren Sie nicht Spotify. Kopieren Sie nicht Google. Deren Kontext ist nicht Ihrer. Reparieren Sie, was jetzt kaputt ist. Nicht, was bei 100 Leuten kaputtgehen könnte. Wenn Koordination das Problem ist, teilen Sie nicht nach Tech-Stack auf. Wenn sich technische Schulden anhäufen, setzen Sie nicht auf reine Squads. Wenn Leute ausbrennen, lassen Sie das Chapter-Modell vielleicht lieber aus. Probieren Sie etwas aus. Geben Sie ihm sechs Monate. Achten Sie auf Probleme. Ändern Sie es, wenn es eindeutig nicht mehr funktioniert. Teamstruktur ist kein Problem, das man einmal löst. Es gibt nur unterschiedliche Kompromisse für unterschiedliche Größen. *Derzeit helfen wir einem anderen Kunden, genau das herauszufinden. Fragen Sie uns in sechs Monaten, ob es funktioniert hat.*

Android 16KB Page Sizes: Unsere Migrations-Achterbahnfahrt

Norveon doo — Fri, 21 Nov 2025 00:00:00 GMT

*Wir dachten, es dauert einen Vormittag. Es wurden drei Wochen.* Dann kam Googles Ankündigung: „Hallo zusammen, ab dem 1. November 2025 müssen Ihre Apps 16KB Page Sizes unterstützen. Sollte einfach sein!“ Wir waren gerade dabei, die Mobile-App von [Arheev](https://arheev.com), unserer intelligenten HR-Plattform, zu migrieren. Wir haben die Doku gelesen. Klang unkompliziert. Ein paar Build-Tools aktualisieren, ein paar Config-Flags setzen, vielleicht einen Kaffee holen, während es baut. Bis zum Mittagessen fertig, oder? Erzählerstimme: *Es war nicht bis zum Mittagessen fertig.* ## Was Google wollte (und warum) Die Grundidee ergibt Sinn. Android arbeitet seit jeher mit 4KB großen Speicherseiten, aber moderne Geräte mit jeder Menge RAM laufen mit 16KB-Seiten besser. Googles eigene Zahlen zeigen ein paar schöne Verbesserungen: - Apps starten 3 % schneller, wenn der Speicher des Telefons voll ist - 4,5 % weniger Akkuverbrauch beim Start - Kamera-Apps laufen 5–7 % schneller - Das Telefon bootet 8 % schneller Klingt gut. Wo ist der Haken? ## Das eigentliche Problem, vor dem uns niemand gewarnt hat Jetzt wird es heikel. Jede native Bibliothek (.so-Datei) in Ihrer App muss an 16KB-Grenzen „ausgerichtet“ sein, also aligned. Stellen Sie sich das wie Parken vor: Ihre Bibliothek muss sauber in Parkplätze von 16KB Größe passen. Wenn Sie eine reine Java/Kotlin-App schreiben, haben Sie Glück. Kein nativer Code, kein Problem. Aber die [Arheev-Mobile-App](https://arheev.com) ist mit React Native gebaut. Und React-Native-Apps sind im Grunde native Bibliotheken, verpackt in JavaScript, verpackt in weitere native Bibliotheken, verpackt in existenzielle Fragen, warum wir nicht einfach separate native Apps gebaut haben. Wenn Bibliotheken nicht richtig ausgerichtet sind, bekommen Sie: - Apps, die sich nicht installieren lassen - Kryptische Fehlermeldungen, die Ihnen nichts sagen - Abstürze, die nur auf bestimmten Geräten auftreten (meist auf denen, mit denen Ihr Chef testet) Ein Riesenspaß! ## Was tatsächlich passiert ist: eine Chronik ### Tag 1: „Das wird einfach“ Wir haben auf Android Gradle Plugin 8.5.1 und NDK r28 aktualisiert. Laut Doku kümmern sich diese Versionen automatisch um das 16KB-Alignment. Wir haben ein paar Flags in die AndroidManifest.xml eingetragen: ```xml ``` Build lief durch. Tests grün. High Fives in alle Richtungen. Zeit, unsere Migration in unter einer Stunde zu feiern! ### Tag 3: „Warum funktioniert das nicht?“ Wir haben einen Android-15-Emulator mit aktivierter 16KB-Unterstützung hochgefahren. App installiert. Sofort abgestürzt. Wie sich herausstellte, waren mehrere Bibliotheken, die sich in unserem Dependency-Tree versteckten, nicht 16KB-aligned: - Unsere Audioverarbeitungs-Bibliothek (libandroidlame.so) - Irgendein Bildkomprimierungs-Dings - Ein Drittanbieter-SDK, an dessen Einbau wir uns kaum noch erinnerten Die Fehlermeldung lautete: „Native module initialization failed.“ Danke, Android. Super hilfreich. Wir haben zwei Tage damit verbracht, mehr über ELF-Alignment zu lernen, als wir je wissen wollten. ### Tag 5: „Na gut, dann bauen wir drumherum“ Nach viel Googeln (und ein paar langen Abenden auf Stack Overflow mit sehr viel Kaffee) fanden wir das magische Flag: `android:extractNativeLibs="true"`. Es weist Android an, Bibliotheken bei der Installation der App zu extrahieren, statt sie direkt aus dem APK zu laden. Damit wird die Alignment-Anforderung im Grunde komplett umgangen. Ist das perfekt? Nein. Funktioniert es? Ja. Liefern wir es aus? Auf jeden Fall. **Das Gute:** - Hat unsere Abstürze sofort behoben - Funktioniert mit jeder Bibliothek, aligned oder nicht - Kein Warten darauf, dass Drittanbieter ihr Zeug aktualisieren **Das weniger Gute:** - Die Installation der App dauert etwas länger - Belegt mehr Speicherplatz auf dem Gerät - Google könnte das irgendwann abschaffen (aber das ist das Problem unseres zukünftigen Ichs) Wir behandeln das als vorübergehende Lösung, während wir mit den Maintainern der Bibliotheken an sauber 16KB-ausgerichteten Versionen arbeiten. ### Tag 7: „Automatisieren wir das, bevor wir es vergessen“ Das Letzte, was wir wollten, war, dass jemand `expo prebuild` ausführt und versehentlich all unsere hart erarbeiteten Konfigurationen wegputzt. Also haben wir ein Expo-Config-Plugin gebaut, das alles automatisch erledigt: **Änderungen an AndroidManifest.xml:** - Fügt die 16KB-Page-Size-Property hinzu - Aktiviert den Back-Gesture-Callback - Setzt das extractNativeLibs-Flag **Updates in build.gradle:** - Konfiguriert die NDK-ABI-Filter - Aktiviert Multidex-Unterstützung - Richtet das Release-Signing ein **Anpassungen in gradle.properties:** - Build-Tool-Einstellungen - Flags für die neue React-Native-Architektur - Ressourcenoptimierung Wenn jetzt jemand im Team prebuild ausführt, dann... funktionieren diese Einstellungen einfach. Keine „Moment, wo ist diese Config hin?“-Momente mehr. ## Was wir gern von Tag eins an gewusst hätten ### 1. Erst alles aktualisieren Denken Sie nicht einmal daran, diese Migration ohne Android Gradle Plugin 8.5.1+ und NDK r28+ anzufangen. Ältere Versionen bekommen das 16KB-Alignment schlicht nicht richtig hin. Aktualisieren Sie Ihre `android/build.gradle`: ```gradle dependencies { classpath('com.android.tools.build:gradle:8.5.1') } ``` Ja, Build-Tools zu aktualisieren nervt. Machen Sie es trotzdem. ### 2. Finden Sie heraus, ob Sie überhaupt nativen Code haben Bevor Sie in Panik geraten: Prüfen Sie, ob Ihre App tatsächlich native Bibliotheken verwendet. Am einfachsten geht das mit dem APK Analyzer in Android Studio: 1. Öffnen Sie Android Studio (jedes Projekt funktioniert) 2. Klicken Sie auf **Build > Analyze APK...** 3. Wählen Sie Ihre APK-Datei aus 4. Suchen Sie nach einem **lib**-Ordner Wenn Sie einen lib-Ordner mit .so-Dateien darin sehen: Glückwunsch, Sie haben nativen Code, um den Sie sich kümmern müssen. Prüfen Sie die Spalte „Alignment“ auf Warnmeldungen. [image2]: /images/blog/2025-11-21-1.jpg "APK-Analyzer-Menü in Android Studio" ![APK-Analyzer-Menü in Android Studio][image2] Kein lib-Ordner? Sie nutzen reines Java/Kotlin und können sich den Großteil dieser Kopfschmerzen vermutlich sparen. Glück gehabt. ### 3. Testen Sie tatsächlich auf einem 16KB-Emulator Erstellen Sie im AVD Manager einen Android-15-Emulator und aktivieren Sie in den erweiterten Einstellungen „16KB page size“. Ihr normales Gerät wird diese Probleme nicht aufdecken, weil es noch mit 4KB-Seiten arbeitet. Glauben Sie uns: Alignment-Probleme wollen Sie nicht erst nach dem Release im Produktivbetrieb entdecken. ### 4. Spüren Sie Ihre nativen Bibliotheken auf Finden Sie all die .so-Dateien, die in Ihrer App lauern: ```bash # List all native libraries in your APK unzip -l app-release.apk | grep '\.so$' ``` Oder nutzen Sie einfach wieder den APK Analyzer; das ist viel einfacher und hat eine schöne Oberfläche. Machen Sie eine Liste. Prüfen Sie, ob welche Probleme machen. Fluchen Sie über die, die es tun. ### 5. Behalten Sie Ihre Abhängigkeiten im Blick Nicht jeder Bibliotheks-Maintainer ist schon auf den 16KB-Zug aufgesprungen. Manche haben noch nie davon gehört. Für React Native: - Prüfen Sie, ob Ihre Expo-SDK-Version die Fixes enthält - Durchsuchen Sie die GitHub-Issues Ihrer nativen Module - Erwägen Sie einen Bibliothekswechsel, wenn der Maintainer spurlos verschwunden ist ### 6. Der extractNativeLibs-Trick ist nur vorübergehend Ja, `android:extractNativeLibs="true"` behebt gerade alles. Aber behandeln Sie es wie Panzertape: Es funktioniert, aber irgendwann wollen Sie eine richtige Lösung. Behalten Sie im Blick, welche Bibliotheken es brauchen, und achten Sie auf Updates. ## Ihre Migrations-Checkliste (damit Sie nichts vergessen) Das müssen Sie tatsächlich tun: - [ ] AGP auf 8.5.1+ und NDK auf r28+ aktualisieren - [ ] Gradle auf 8.14+ aktualisieren (wenn Sie schon dabei sind) - [ ] Mit dem APK Analyzer prüfen, ob Sie native Bibliotheken haben - [ ] Die 16KB-Page-Size-Flags in die AndroidManifest.xml eintragen - [ ] NDK-ABI-Filter in build.gradle einrichten - [ ] extractNativeLibs hinzufügen, wenn es zu Abstürzen kommt - [ ] Einen Android-15-Emulator mit aktiviertem 16KB-Modus erstellen - [ ] Wirklich alles testen (nicht einfach annehmen, dass es funktioniert) - [ ] Eine Liste problematischer Bibliotheken anlegen - [ ] Die Config automatisieren (Ihr zukünftiges Ich wird es Ihnen danken) ## Die Realität der Cross-Platform-Entwicklung Plattformanforderungen wie diese betreffen eben nicht bloß Ihren eigenen Code, sondern jede einzelne Bibliothek in Ihrem Dependency-Tree. Wenn Google sagt „unterstützt 16KB“, muss jeder Entwickler nativer Module, jeder SDK-Anbieter, jedes Community-Paket nachziehen. Und Ihre Migration ist erst dann abgeschlossen, wenn die langsamste Bibliothek endlich aufgeholt hat. Mit React Native wird es noch unterhaltsamer: Sie warten auf mehrere Ökosysteme gleichzeitig, bis sich iOS-, Android- und JavaScript-Entwickler untereinander abgestimmt haben. Es ist wie Katzen hüten, nur dass die Katzen nebenbei auch noch jonglieren. ## Hat es sich gelohnt? Haben wir nach all der Arbeit tatsächlich Verbesserungen gesehen? Ja, haben wir: - Weniger Speicherfragmentierung auf neueren Geräten - Etwas schnellere App-Starts (schwer exakt zu messen, aber es ist da) - Keine „Ihre App funktioniert auf meinem Handy nicht“-Bug-Reports mehr von Android-15-Nutzern Der extractNativeLibs-Workaround macht die Installation etwas langsamer, aber sobald die App läuft, fühlt sich alles gut an. ### Was noch nicht perfekt ist Wir verwenden immer noch `extractNativeLibs="true"` statt sauber ausgerichteter Bibliotheken. Das funktioniert, ist aber technisch gesehen ein Workaround, keine Lösung. Ein paar Abhängigkeiten haben noch keine 16KB-ausgerichteten Versionen veröffentlicht. Wir beobachten ihre GitHub-Issues, aber einige wurden seit Monaten nicht aktualisiert. Möglicherweise müssen wir sie irgendwann forken oder Alternativen finden. Und wir sind nicht 100 % sicher, wie sich das auf echten 16KB-Geräten verhält, sobald diese verbreitet sind. Emulatoren sind das eine, echte Hardware das andere. Wir werden es herausfinden. ## Wie geht es weiter? Vermutlich mehr vom Gleichen. Je leistungsfähiger Android-Telefone werden, desto mehr Plattformanforderungen werden sich durch die Dependency-Trees ziehen. Die Automatisierung, die wir für diese Migration gebaut haben, kommt bei der nächsten wieder zum Einsatz. ## Unterm Strich Die Migration auf 16KB Page Sizes ist nicht optional, wenn Sie über Google Play ausliefern wollen. Und sie ist definitiv aufwendiger, als die Dokumentation es klingen lässt. Aber wenn Sie einmal durch sind, sind Sie durch. Die Config läuft weitgehend von selbst, Ihre App läuft auf neueren Geräten schneller, und Sie haben eine Deadline weniger, über die Sie sich Sorgen machen müssen. Wenn Sie gerade mitten in dieser Migration stecken und auf seltsame Probleme stoßen: Sie sind nicht allein, uns ging es genauso. Melden Sie sich gern, wenn Sie über Bibliotheks-Alignment jammern oder Anekdoten über kryptische Android-Fehlermeldungen austauschen möchten. ## Nützliche Links, wenn Sie einsteigen - [Android-Dokumentation zu 16KB Page Sizes](https://developer.android.com/guide/practices/page-sizes): Die offizielle Dokumentation (die es deutlich einfacher klingen lässt, als es ist) - [Release Notes des Android Gradle Plugin](https://developer.android.com/studio/releases/gradle-plugin): Um zu prüfen, welche Version Sie brauchen - [Leitfaden zu Expo Config Plugins](https://docs.expo.dev/config-plugins/introduction/): Falls Sie Expo nutzen und dieses Chaos automatisieren wollen *Anders als die meisten Migrationen hat diese tatsächlich eine Deadline. Aber zumindest müssen Sie sie nicht allein durchstehen; jeder React-Native-Entwickler kämpft gerade mit denselben Alignment-Albträumen.* [image1]: /images/blog/2025-11-21.jpg "Android 16KB Page Sizes: Unsere Migrations-Achterbahnfahrt" ![Android 16KB Page Sizes: Unsere Migrations-Achterbahnfahrt][image1]

Wenn Ihr Team zu groß wird: Das hat bei uns wirklich funktioniert

Norveon doo — Tue, 24 Jun 2025 00:00:00 GMT

[image1]: /images/blog/2025-06-24.jpg "Wenn Ihr Team zu groß wird: Das hat bei uns wirklich funktioniert" ![Wenn Ihr Team zu groß wird: Das hat bei uns wirklich funktioniert][image1] *Sechs Monate gescheiterter Experimente. Das haben wir dabei tatsächlich herausgefunden.* Sommer 2024. Unser Team war auf vierzehn Leute gewachsen, und plötzlich fühlte sich alles falsch an. Stand-ups zogen sich über 45 Minuten hin. Die halbe Mannschaft starrte auf ihre Bildschirme und hörte offensichtlich nicht zu. Von ausgelieferten Features erfuhren wir im Nachhinein, meist wenn ein Kunde sie erwähnte. Irgendetwas war kaputtgegangen, und wir wussten nicht genau, wann. ## Als es anfing schiefzulaufen Diese täglichen Check-ins? Die reinste Folter. Marko erzählte von seiner API-Arbeit, während Miloš auf sein Handy starrte und ganz offensichtlich ans Mittagessen dachte. Darija erklärte derweil ihre CSS-Probleme einem Raum voller Backend-Entwickler, denen das herzlich egal war. Während wir uns in Meetings zu Tode langweilten, passierte die eigentliche Arbeit im Verborgenen. Jemand erwähnte beiläufig, er habe gerade ein Feature ausgeliefert, von dem keiner von uns je gehört hatte. Meist, weil Stefan aus dem Marketing um „einen kleinen Gefallen“ gebeten hatte und unsere hilfsbereiten Entwickler ihn einfach ... erledigt hatten. ## Unsere gescheiterten Experimente (alle) ### August 2024: Die Aufteilung Wir haben versucht, uns in ein Frontend- und ein Backend-Team aufzuteilen. Jedes Team mit eigenem Stand-up, eigenem Fokus. Hielt genau einen Sprint. Bei Arheev müssen beide Seiten nun mal ständig miteinander reden. Wer hätte das gedacht? ### September 2024: Asynchrone Updates „Machen wir statt Meetings einfach tägliche Slack-Updates!“ In der ersten Woche posteten alle ausführliche Updates. In der zweiten Woche wurden sie kürzer. In Woche drei waren wir bei „hab an Sachen gearbeitet“ angekommen, und gelesen hat sie ohnehin niemand. ### Oktober 2024: Rotierende Team-Leads Jede Woche leitet jemand anderes das Stand-up, mit Schwerpunkt auf seinem Bereich. Klang in der Theorie großartig. In der Praxis: Manche landeten in jedem Meeting (weil sie überall mitarbeiteten), andere tauchten gar nicht mehr auf. Am Ende hatten wir mehr Silos als vorher. ### November 2024: Fast hätten wir aufgegeben Wir versuchten es wieder mit „kein formaler Prozess, regelt das einfach selbst“. Nach zwei Wochen hatten wir dieselben Probleme wie zuvor. Sechs Monate Scheitern. Uns gingen die Ideen aus. ## Anfang 2025: Die zufällige Lösung Geplant war das nicht. Jemand schlug vor, für einen besonders hartnäckigen Bug in Arheev Mob Programming auszuprobieren. Fünf Leute, ein Bildschirm, ein Problem, das Frontend, Backend und Datenbank gleichzeitig betraf. Wir dachten, das bleibt eine einmalige Sache. Der Bug wurde behoben. Aber noch etwas anderes passierte: Die Leute lernten Teile der Codebasis kennen, die sie nie angefasst hatten. Die Frontend-Entwicklerin verstand, warum die Datenbankabfrage langsam war. Der Backend-Entwickler sah, warum der Ladezustand wichtig war. Wir fingen an, das wöchentlich zu machen. Nicht für alles, aber für komplexe Features oder harte Bugs. ## Was sich wirklich verändert hat **Wissen verbreitete sich schneller.** Wenn alle sehen, wie etwas funktioniert, gibt es am Ende nicht die eine Person, die als Einzige den Deployment-Prozess kennt. **Weniger „Das ist nicht mein Problem“-Momente.** Schwer zu behaupten, das Frontend gehe einen nichts an, wenn man gerade beim Debuggen des React-Rendering-Problems geholfen hat. **Code-Reviews wurden besser.** Wer Code reviewte, den er live hatte entstehen sehen, gab besseres Feedback als jemand, der ohne Vorwissen auf den Diff schaute. ## Was immer noch kaputt ist Seien wir ehrlich: Wir haben nicht alles gelöst. **Mob Programming skaliert nicht auf 14 Leute.** Meist sitzen 4 bis 6 in einer Session. Alle anderen arbeiten für sich weiter. Also haben wir weiterhin Koordinationsprobleme. **Manche hassen es.** Besonders Introvertierte. Zwei Stunden in einer Gruppen-Coding-Session zu sitzen, kann auslaugen. Wir haben noch nicht herausgefunden, wie es für alle funktioniert. **Silos gibt es immer noch.** Selbst mit Generalisten wird irgendwer zur „Person, die sich mit AWS auskennt“ oder zur „Person, die den Zahlungsablauf versteht“. Nur eben ... weniger als vorher. **KI-Tools helfen, aber sie sind keine Zauberei.** Klar, Sie können sich von Claude beim SQL-Schreiben helfen lassen, wenn Sie eigentlich Frontend-Entwickler sind. Aber Sie müssen trotzdem verstehen, was Sie tun. KI macht Lernen leichter, nicht überflüssig. ## Wo wir heute stehen (November 2025) Stand-ups dauern wieder 15 Minuten. Wir reden tatsächlich über das, was zählt, statt Statusberichte abzuliefern. Mob-Programming-Sessions finden 2- bis 3-mal pro Woche statt. Nicht alle machen jedes Mal mit. Das ist in Ordnung. Wir haben immer noch Koordinationsprobleme. Wir haben immer noch Wissenssilos. Aber sie sind kleiner und weniger schmerzhaft als vor sechs Monaten. ## Falls Sie gerade dasselbe durchmachen Wir haben sechs Monate mit verschiedenen Ansätzen verschwendet. Das würden wir unserem früheren Ich sagen: **Teilen Sie das Team nicht auf.** Solange Sie nicht wirklich groß genug sind (50+ Leute), schafft eine Aufteilung mehr Probleme, als sie löst. **Zwingen Sie nicht alle, über Nacht zu Generalisten zu werden.** Das geht nur schrittweise. Mob Programming oder Pair Programming hilft, aber es dauert Monate, nicht Wochen. **Akzeptieren Sie, dass es zu einer gewissen Spezialisierung kommen wird.** Das ist in Ordnung. Sorgen Sie nur dafür, dass nichts Kritisches an einer einzigen Person hängt. **Probieren Sie die 30-%-Regel.** Wenn Sie neben Kundenprojekten ein eigenes Produkt bauen, reservieren Sie Kapazität dafür. Sonst wird es nie gebaut. Ihre Erfahrung wird anders aussehen. Wir sind vierzehn Remote-Leute, die eine HR-Plattform bauen. Ihr Team, Ihr Produkt, Ihre Rahmenbedingungen sind andere. Aber wenn sich Ihre Stand-ups wie Zeitverschwendung anfühlen und Sie ständig erst von Arbeit erfahren, wenn sie schon erledigt ist, haben Sie vielleicht dieselben Probleme wie wir. *Anders als Ihre Lieblings-Büro-Sitcom hat diese Geschichte kein sauberes Ende. Wir probieren weiter, während wir wachsen.*

Warum Norveon vollständig remote arbeitet (und warum wir nicht zurückgehen)

Norveon doo — Wed, 02 Apr 2025 00:00:00 GMT

*Keine Büropolitik, wenn es kein Büro gibt.* Alle fragen uns, wann wir „zurück ins Büro“ gehen. Die Frage ergibt keinen Sinn: Wir hatten nie eines, in das wir zurückkönnten. Unser Team arbeitet seit November 2023 vollständig remote, lange bevor Norveon offiziell gegründet wurde. Nicht als Reaktion auf die Pandemie, nicht als Sparmaßnahme, sondern weil uns schlicht nicht einfiel, warum wir es anders machen sollten. Wir bauen Software. Unsere Werkzeuge sind online. Unsere Kunden sitzen weltweit. Warum sollten wir unseren Talentpool auf Leute in Pendeldistanz zu Belgrad beschränken? Zwei Jahre später sind wir immer noch remote. Eine Bilanz. ## Die Dinge, vor denen uns alle gewarnt haben (und die nicht eingetreten sind) ### „Kultur lässt sich remote nicht aufbauen“ Falsch. Man baut sie nur anders auf. Wir haben einen wöchentlichen Team-Call, in dem wir wirklich darüber reden, woran wir arbeiten. Keine Status-Updates, die gehören in Slack. Echte Diskussionen über technische Entscheidungen, Probleme, an denen wir hängen, Dinge, die wir gelernt haben. So ein Gespräch würde man sonst in der Büroküche führen, nur dass niemand so tun muss, als schmecke ihm der Kaffee. Alle paar Monate treffen wir uns für ein paar Tage persönlich. Nicht für verpflichtende „Teambuilding“-Aktivitäten, sondern weil man nach Monaten gemeinsamer Online-Arbeit seine Kollegen tatsächlich kennenlernen will. Diese Treffen gehören zu den produktivsten Tagen, die wir haben. ### „Die Kommunikation wird zusammenbrechen“ Sie wurde sogar besser. Im Büro unterbricht man die konzentrierte Arbeit eines Kollegen für eine kurze Frage. Remote zwingt einen zum Nachdenken: Ist das wirklich dringend, oder kann es warten? Kann ich es klar in Slack formulieren, oder brauchen wir einen kurzen Call? Wir sind richtig gut in asynchroner Kommunikation geworden. Ausführliche Slack-Threads, Bildschirmaufnahmen für Bug-Reports, ordentliche Dokumentation, weil man niemandem einfach auf die Schulter tippen und fragen kann, wie etwas funktioniert. Die Kehrseite: Wir mussten das lernen. Anfangs hatten wir wochenlange Slack-Threads, die besser ein 15-minütiger Call gewesen wären. Inzwischen wissen wir besser, wann wir das Medium wechseln müssen. ### „Die Leute werden weniger arbeiten“ An manchen Tagen, ja. An manchen Tagen hat man einen Arzttermin, muss eine Lieferung entgegennehmen oder kann sich einfach nicht konzentrieren und geht lieber spazieren, statt Arbeit vorzutäuschen. Aber wir haben auch das Gegenteil erlebt. Jemand pusht um 11 Uhr abends einen Fix, weil er gerade im Flow ist und fertig werden will. Jemand anderes fängt früh an, weil er sich dann am besten konzentrieren kann. Wir messen Output, nicht erfasste Stunden. Das klassische Büro tut so, als wären alle von 9 bis 17 Uhr produktiv. Remote-Arbeit gibt zu, dass das Unsinn ist, und optimiert auf die Zeiten, in denen Leute tatsächlich ihre beste Arbeit leisten. ## Was wirklich problematisch war ### Zeitzonen sind immer noch Physik Unser Team erstreckt sich über mehrere Zeitzonen. Für die Erreichbarkeit ist das großartig: Es ist immer jemand da, wenn ein Kunde etwas braucht. Für die Terminplanung ist es furchtbar. Wir haben uns auf ein Zwei-Stunden-Fenster geeinigt (10 bis 12 Uhr MEZ), in dem theoretisch alle für Meetings verfügbar sind. „Theoretisch“, weil immer jemand unterwegs ist oder etwas anderes hat. Ein Meeting mit dem ganzen Team zu planen, braucht weiterhin mehrere Anläufe und mindestens eine Person, die zu einer unchristlichen Uhrzeit dazukommt. ### Sie brauchen bessere Werkzeuge (und die Disziplin, sie zu nutzen) Büroarbeit verzeiht viele schlechte Gewohnheiten. Etwas nicht dokumentiert? Fragen Sie einfach Jim. Unsicher beim Deployment-Prozess? Schauen Sie jemandem dabei zu. Remote bestraft so etwas. Wir mussten ordentliche Dokumentation aufbauen, gutes Projektmanagement aufsetzen, klare Prozesse schaffen. Nicht, weil wir organisierte Menschen wären (sind wir nicht), sondern weil die Alternative Chaos war. Wir nutzen Slack, Linear, Notion, Figma, GitHub und vermutlich zu viele andere Tools. Jedes löst ein bestimmtes Problem. Jedes muss aber auch gepflegt werden, sonst wird es nutzlos. ### Burnout ist heimtückischer Im Büro merken Ihre Kollegen, wenn Sie erschöpft aussehen. Remote? Da können Sie wochenlang still untergehen, bevor es jemand bemerkt. Dafür haben wir keine perfekte Lösung. Wir fragen einander, wie es geht, achten auf Warnzeichen und legen einander freie Tage nahe. Aber es ist immer noch zu leicht, einfach ... weiterzuarbeiten, weil der Arbeitsplatz immer direkt da ist. ## Was wir jemandem sagen würden, der ein Remote-Unternehmen gründet Tun Sie es, wenn Ihre Arbeit tatsächlich remote erledigt werden kann, Sie bereit sind, Kommunikation bewusst zu gestalten, und Ihnen Output wichtiger ist als erfasste Stunden. Wenn Sie mit dem Durcheinander asynchroner Abstimmung umgehen können, ist es einen Versuch wert. Tun Sie es nicht, wenn Sie darin nur billigere Büroflächen sehen oder den ganzen Tag überwachen wollen, was die Leute tun. Und wenn Ihre Arbeit wirklich ständige physische Zusammenarbeit erfordert, wird Remote Ihnen an jeder Ecke Steine in den Weg legen. Dasselbe gilt, wenn Sie nicht bereit sind, in ordentliche Werkzeuge und Prozesse zu investieren: Dann sitzen Sie einfach in einem Büro mit schlechterer Kommunikation. ## Würden wir jemals ein Büro nehmen? Das fragen uns Leute. Die Antwort: wahrscheinlich nicht. Nicht, weil Büros böse wären oder Remote perfekt, sondern weil wir Systeme gebaut haben, die für uns funktionieren. Unser Recruiting ist nicht geografisch begrenzt. Unser Team arbeitet dann, wenn es am produktivsten ist. Wir sparen Geld für Büroflächen, und unsere Leute sparen Zeit beim Pendeln. Könnten wir mit einem Büro produktiver sein? Vielleicht. Aber wir würden auch die Flexibilität verlieren, die es jemandem in einer anderen Zeitzone erlaubt, in unser Team zu kommen, oder die es Leuten ermöglicht, ihren Tag um ihr Leben herum zu strukturieren statt um ihren Arbeitsweg. Den Zahlen nach stellen die meisten Unternehmen auf hybrid um. Für sie ist das wahrscheinlich richtig. Für uns ergibt vollständig remote weiterhin am meisten Sinn. ## Ehrlich gesagt Remote-Arbeit ist nicht per se besser oder schlechter als Büroarbeit. Sie ist anders, mit anderen Kompromissen. Für Norveon, das mit einem verteilten Team Software baut, funktioniert Remote. Damit es funktioniert, gestalten wir Kommunikation bewusst, investieren in gute Werkzeuge und akzeptieren, dass manches (wie die Terminplanung) immer schwieriger sein wird. Zwei Jahre später lernen wir immer noch dazu. Aber zurück ins Büro gehen wir ganz sicher nicht. [image1]: /images/blog/2025-04-02.jpg "Warum Norveon vollständig remote arbeitet (und warum wir nicht zurückgehen)" ![Warum Norveon vollständig remote arbeitet (und warum wir nicht zurückgehen)][image1]

Wir wurden das Start-up, mit dem wir selbst gern gearbeitet hätten

Norveon doo — Sat, 15 Mar 2025 00:00:00 GMT

*Bei der Entstehung dieses Produkts wurden keine Pivot-Tabellen konsultiert.* Seit unser Team Ende 2023 zusammengekommen ist, machen wir Kundenprojekte für Start-ups. Ihre MVPs bauen, ihre technischen Schulden abtragen, ihre Infrastruktur skalieren. Gute Arbeit, interessante Probleme, solider Umsatz. Dann begannen wir Anfang 2024, Arheev zu bauen – unsere eigene HR-Plattform – und plötzlich standen wir auf der anderen Seite jedes Gesprächs, das wir je mit Start-up-Kunden geführt hatten. Ein eigenes Produkt neben einem Dienstleistungsgeschäft zu bauen, ist viel schwerer, als wir es unseren Kunden erzählt hatten. ## Die klassische Agenturfalle So denken Dienstleistungsunternehmen meist über eigene Produkte: „Wir nutzen unsere freie Zeit, um ein internes Produkt zu bauen. Wenn es bei den Kundenprojekten ruhig ist, arbeiten wir daran. Das wird großartig!“ Wir wussten, dass das eine Falle ist. Wir hatten gesehen, wie es bei anderen Agenturen schiefging. Wir sagten uns, bei uns würde es anders laufen. Es lief nicht anders. Die ersten Monate sind alle begeistert. Leute melden sich freiwillig, am Wochenende an Arheev zu arbeiten. Es geht schnell voran. Wir bauen einen funktionierenden Prototyp, holen erstes Feedback ein, alles großartig. Dann kommt ein großes Kundenprojekt herein. „Nur zwei Wochen“, sagen wir uns. „Dann geht's zurück zu Arheev.“ Drei Monate später ist Arheev unangetastet und wir haben die Hälfte unserer Entscheidungen vergessen. ## Was wir geändert haben (und was tatsächlich funktioniert hat) Nachdem das zum zweiten Mal passiert war, führten wir eine Regel ein: **Arheev bekommt 30 % unserer Kapazität, jede Woche, egal was passiert.** Nicht „wenn wir Zeit haben“. Nicht „wenn es bei den Kunden ruhig ist“. Einfach … 30 % sind für unser Produkt reserviert. Immer. Das fühlte sich beängstigend an. Was, wenn wir Kundenaufträge ablehnen müssten? Was, wenn wir Deadlines nicht einhalten könnten? Wie sich zeigte, macht eine feste Grenze effizienter. Wir wurden besser darin, Kundenprojekte zu schätzen. Wir hörten auf, zu allem Ja zu sagen. Wir stellten eine weitere Person ein, damit wir Puffer hatten. Und bei Arheev kamen tatsächlich regelmäßig neue Features heraus. ### Das Mobile-App-Desaster Bei der Arheev-Mobile-App kamen auf der Android-Seite alle Probleme auf einmal. Google kündigte die 16KB-Page-Size-Anforderung an. React Native brauchte Updates. Die Hälfte unserer Abhängigkeiten war nicht kompatibel. Ein Albtraum aus technischen Schulden, wie wir ihn bei Kunden sonst zu Premium-Sätzen aufräumen. Nur war das unser Produkt, unser Problem, unsere Wochenenden. Wir verbrachten drei Wochen damit, Alignment-Probleme in nativen Libraries zu debuggen. Niemand bezahlte uns dafür. Wir konnten es niemandem in Rechnung stellen. Wir mussten es einfach tun, weil die Alternative gewesen wäre, nicht zu liefern. Das ist der Teil, den wir Start-up-Kunden nie wirklich erklärt hatten: Manchmal muss man die Kosten für Plattformanforderungen, kaputte Abhängigkeiten und technische Änderungen, die man nicht verursacht hat, einfach schlucken. ### Nutzern wirklich zuhören (mit Lehrgeld) Für Kundenprojekte haben wir einen Prozess. Nutzerforschung, Wireframes, Prototypen, Tests. Sehr professionell. Für Arheev? Wir bauten, was wir für sinnvoll hielten, lieferten es aus und sahen zu, wie die Leute verwirrt waren. Ein Feature, an dem wir drei Wochen gebaut hatten – dieser clevere automatisierte Genehmigungsworkflow – wurde buchstäblich von niemandem genutzt. Alle genehmigten einfach alles manuell, weil unser „cleveres“ System niemand verstand. Wir haben es entfernt und etwas Einfacheres gebaut. Dauerte vier Stunden. Die Leute nutzen es tatsächlich. Bei einem Kunden hätten wir unsere komplexe Lösung wahrscheinlich wochenlang verteidigt. Beim eigenen Produkt? Man behebt es einfach, weil es niemanden sonst gibt, dem man die Schuld geben könnte. ## Was das an unserer Kundenarbeit verändert hat Wenn ein Start-up-Kunde heute sagt: „Das Mobile-Deployment übernehmen wir selbst“, nicken wir nicht einfach. Wir erzählen ihm von den drei Wochen, die wir mit 16KB-Seitengrößen verbracht haben. Wenn er ein komplexes Feature bauen will, weil es cool wirkt, zeigen wir ihm unseren verworfenen Genehmigungsworkflow. Wenn er versucht, Produktarbeit „zwischendurch“ neben anderen Prioritäten unterzubringen, erklären wir, warum wir 30 % Kapazität reservieren mussten. Ohne diese Regel wäre Arheev nie erschienen. Wir sind besser in der Kundenarbeit, weil wir dieselben Probleme als internes Start-up durchlebt haben. Nicht als Berater, die darüber gelesen haben. Als Team, das um 23 Uhr Code ausgeliefert hat, weil ein Deployment kaputt war und Nutzer warteten. ## Die unbequeme Wahrheit Arheev zu bauen hat uns klargemacht, wie viel leichter es ist, Ratschläge zu geben, als sie zu befolgen. Wir sagten Kunden „einfach schnell liefern und iterieren“, während wir wochenlang Arheev-Features perfektionierten. Wir sagten „konzentrieren Sie sich zuerst auf die Kernnutzer“, während wir versuchten, jedes denkbare Feature für jeden denkbaren HR-Anwendungsfall zu bauen. Wir empfahlen „einfach schlägt komplex“, während wir komplexe Lösungen bauten, weil wir dachten, wir wüssten es besser. Auf der anderen Seite zu stehen zwang uns, tatsächlich zu praktizieren, was wir predigten. Oder es zumindest zu versuchen. ## Wo wir heute stehen Arheev ist live. Leute nutzen es. Wir bauen weiter Features, beheben Bugs und haben uns damit abgefunden, dass Software nie „fertig“ ist. Wir machen weiterhin Kundenprojekte, sie bringen nach wie vor den Großteil unseres Umsatzes. Aber wir betreiben jetzt auch unser eigenes Produkt. Es ist unordentlich. In manchen Wochen bekommt Arheev mehr als 30 %. In manchen weniger. Wir lernen noch dazu. Wir sind ein besseres Dienstleistungsunternehmen, weil wir dasselbe durchgemacht haben wie unsere Kunden. Den Druck, die Kompromisse, die langen Nächte beim Debuggen von etwas, das „eigentlich einfach sein sollte“. Wenn wir einem Kunden sagen, dass etwas schwer ist, weiß er, dass wir das nicht nur sagen, um mehr Stunden abzurechnen. Wir haben es selbst gemacht.

Wie ein kleines Team Produkte baut (ohne den Verstand zu verlieren)

Norveon doo — Mon, 03 Mar 2025 00:00:00 GMT

*Beim Schreiben dieses Beitrags kamen keine Corporate-Buzzwords zu Schaden.* Wir sind vierzehn Leute. Das ist klein genug, dass jeder weiß, woran alle anderen arbeiten, aber groß genug, dass es ganz ohne Prozess nicht mehr geht. Diese Größe ist seltsam. Zu groß für „Kurz alle in einen Call und das klären“, zu klein für Abteilungen, Manager und formale Hierarchien. Wir mussten herausfinden, wie man in dieser Größenordnung tatsächlich Produkte baut, und ehrlich gesagt sind wir immer noch dabei. ## Was wir eigentlich bauen Im Moment haben wir zwei große Baustellen: 1. **Arheev** - Unsere HR-Plattform für wachsende Unternehmen. Das Produkt, das wir für uns selbst bauen (und für andere, die es brauchen). 2. **Kundenprojekte** - Wir entwickeln Individualsoftware für Start-ups und Unternehmen, denen die technische Expertise im eigenen Haus fehlt. Beides zu jonglieren ist manchmal Chaos. Wir stecken tief in der Feature-Arbeit an Arheev, dann schlägt in einem Kundenprojekt ein kritischer Bug ein, und das halbe Team schwenkt um. Oder wir planen einen Kunden-Sprint und merken dann, dass Arheev dringend etwas für eine Demo nächste Woche braucht. Bei vierzehn Leuten gibt es keine Lösung namens „getrennte Teams“. Alle fassen alles an. ## Wie wir wirklich Entscheidungen treffen In einem großen Unternehmen gibt es Prozessdokumente und Genehmigungsketten. In unserer Größe ist das übertrieben. Stattdessen haben wir eine Regel: **Wer findet, dass etwas getan werden sollte, baut einen Prototyp.** Nicht „ein Meeting ansetzen, um das zu besprechen“. Nicht „einen Vorschlag zur Prüfung schreiben“. Einfach eine grobe Version bauen und dem Team zeigen. Das klingt chaotisch. Manchmal ist es das auch. Aber es bedeutet auch, dass wir schnell vorankommen und schlechte Ideen schnell beerdigen. Deutlich besser, als zwei Wochen lang in Meetings über etwas zu debattieren, es dann zu bauen und festzustellen, dass es nicht funktioniert. Marko (unser Head of Engineering) kam aus einem Umfeld, in dem jede Änderung drei Genehmigungsstufen brauchte. Er sagt, als ihm bei Norveon zum ersten Mal jemand sagte „einfach rausbringen und schauen, was passiert“, hielt er das für einen Test. War es nicht. Wir trauen einander wirklich zu, selbst abzuwägen und zu entscheiden. ## Der Freitags-Fehlerbericht Jeden Freitag haben wir ein festes Meeting, in dem alle erzählen, was in dieser Woche nicht funktioniert hat. Keine Erfolge. Fehlschläge. Das Azure-Deployment, das den Produktivbetrieb lahmgelegt hat. Das Feature, das wir gebaut haben und das die Nutzer hassen. Der Refactor, der die Performance verschlechtert statt verbessert hat. Das Kundenmeeting, das aus dem Ruder lief. Anfangs zögerten die Leute, Fehlschläge zu teilen. Heute ist es das nützlichste Meeting, das wir haben. Aus „Das habe ich kaputtgemacht, und so habe ich es repariert“ lernt man deutlich mehr als aus „Das ist gut gelaufen“. ## Als der Junior-Entwickler recht hatte Bei Arheev haben wir Wochen damit verbracht, das Dashboard-Layout zu entwerfen. Mehrere Iterationen, viele Diskussionen über Informationshierarchie und Nutzer-Workflows. Dann pushte jemand, der noch neu im Team war (und in den meisten Meetings still geblieben war), einen Prototyp auf Staging, der unseren gesamten Navigationsansatz über den Haufen warf. Einfach ... komplett anders. Die erste Reaktion war: „Das widerspricht all unseren Design-Patterns.“ Die zweite Reaktion, nachdem wir es tatsächlich benutzt hatten: „Moment, das funktioniert ja wirklich besser.“ Am Ende haben wir diese Version ausgeliefert. Es brauchte noch etwa zwei Wochen Feinschliff, aber die Kernidee (von jemandem, der bei all unseren früheren Diskussionen und Annahmen nicht dabei gewesen war) löste das Problem besser als unser „Experten“-Ansatz. Die Lektion: Manchmal bedeutet neu zu sein, dass man die falschen Muster noch nicht gelernt hat. ## Die Dinge, die nicht skalieren (und die wir trotzdem tun) Bei vierzehn Leuten können wir noch Dinge tun, die größere Unternehmen nicht können: **Alle reviewen den Code aller.** Nicht nur Senior-Entwickler, die Juniors reviewen. Alle sehen die Arbeit aller. Das heißt, Code-Reviews dauern manchmal länger, aber es heißt auch, dass sich Wissen schnell verbreitet. **Wir deployen direkt in den Produktivbetrieb.** Kein separates Deployment-Team, kein Change Approval Board. Sind die Tests grün, darf deployen, wer es gebaut hat. Leute aus größeren Unternehmen erschreckt das. Wir kommen gut damit klar. **Alle reden mit Kunden.** Es gibt kein „Account-Management-Team“, das die Entwickler von den Nutzern abschirmt. Wer das Feature gebaut hat, demonstriert es vielleicht auch oder debuggt es gemeinsam mit dem Kunden. Das ist ineffizient. So lernt man aber, was wirklich zählt. ## Was passiert, wenn das nicht funktioniert Nicht alles ist perfekt. Manche Dinge in unserer Größe sind einfach ... mies. **Wissenssilos bilden sich trotzdem.** Selbst mit Code-Reviews und gemeinsamen Projekten wird am Ende jemand zur „Person, die weiß, wie das Deployment funktioniert“ oder zur „Person, die den Zahlungsablauf versteht“. Ist sie im Urlaub, wird alles langsamer. **Politik gibt es trotzdem.** Ein kleineres Team heißt nicht, dass es keine Meinungsverschiedenheiten oder verletzten Gefühle gibt. Wir haben nur weniger Orte, an denen wir uns davor verstecken können. **Wachstum ist seltsam.** Wir sind zu klein für spezialisierte Rollen, aber zu groß, als dass alle alles machen könnten. Stellen wir noch einen Generalisten ein oder suchen wir einen spezialisierten Designer? Entscheiden wir falsch, sind wir monatelang aus dem Gleichgewicht. Für all das haben wir keine Lösungen. Wir wissen nur, dass es diese Probleme gibt, und versuchen, sie nicht schlimmer zu machen. ## Warum das für Produkte wichtig ist Wie wir arbeiten, wirkt sich direkt darauf aus, was wir bauen. In Arheev (unserer HR-Plattform) lässt sich praktisch alles anpassen. Workflows, Berechtigungen, Datenfelder, Reporting: alles konfigurierbar. Nicht, weil wir geplant hätten, „das flexibelste HR-System“ zu bauen, sondern weil wir intern genau so arbeiten. Wir hassen es, in starre Prozesse gezwängt zu werden, also haben wir ein Tool gebaut, das seine Nutzer nicht in starre Prozesse zwängt. Hätte ein größeres, strukturierteres Team etwas Ähnliches bauen können? Vielleicht. Aber es hätte mehr Meetings gebraucht, mehr Planung, mehr Genehmigungsebenen. Bis zur Auslieferung hätte sich der Markt weiterbewegt. Bei vierzehn Leuten können wir schnell sein, weil es keinen Ort gibt, an dem sich schlechte Ideen verstecken könnten. Sie fliegen im Code-Review auf, oder im Freitags-Fehlermeeting, oder wenn jemand das Feature tatsächlich benutzen will und merkt, dass es furchtbar ist. ## Wo wir stehen Wir haben nicht den perfekten Weg gefunden, Produkte zu bauen. Den hat niemand. Wir teilen nur, was für uns funktioniert, in dieser Größe, in dieser Phase. Einiges davon wird kaputtgehen, wenn wir wachsen. Einiges funktioniert schon jetzt nicht mehr so gut wie damals, als wir kleiner waren. Wir werden uns anpassen, oder auch nicht, und auch darüber werden wir schreiben. Fragen Sie uns in einem Jahr noch einmal, und die Antwort könnte anders ausfallen.

Wir haben eine HR-Plattform gebaut (weil uns die Spreadsheets umgebracht haben)

Norveon doo — Sat, 22 Feb 2025 00:00:00 GMT

*Für diese Ankündigung wurde kein einziges Spreadsheet konsultiert.* Wir haben Arheev gebaut, weil unser eigener HR-Prozess ein Desaster war. Vierzehn Leute. Abwesenheiten in Google Sheets erfasst. Mitarbeiterakten in Notion. Dokumente in Drive. Jemand fragt „Wie viele Urlaubstage habe ich noch?“, und Sie müssen drei Tabs öffnen und rechnen. Wir haben bestehende HR-Plattformen ausprobiert. Sie waren entweder zu simpel (im Grunde nur hübschere Spreadsheets) oder viel zu komplex (Enterprise-Systeme für 500+ Mitarbeiter, für deren Bedienung man eine Schulung brauchte). Also haben wir etwas dazwischen gebaut. Im Februar 2025 ausgeliefert. Das haben wir dabei gelernt. ## Das eigentliche Problem Unser HR-„Prozess“ sah so aus: **Jemand beantragt Urlaub:** 1. Nachricht in Slack schicken 2. Manager prüft im Google Sheet, ob in der Woche noch jemand frei hat 3. Manager aktualisiert die Tabelle von Hand 4. Jemand aktualisiert (hoffentlich) die Jahressummen 5. Vergessen, es zu aktualisieren, und zwei Monate später merken, wenn jemand fragt, warum seine Urlaubstage nicht stimmen **Neuer Mitarbeiter kommt dazu:** 1. In Slack, GitHub, E-Mail, Linear, Notion anlegen 2. Vergessen, ihn in die Urlaubstabelle einzutragen 3. Drei Wochen später daran erinnert werden, wenn er seinen ersten freien Tag beantragt 4. Hektisch versuchen, sich an sein Startdatum zu erinnern, um den angesammelten Urlaubsanspruch zu berechnen Das als Softwareunternehmen zuzugeben, ist peinlich. Wir bauen buchstäblich Systeme für andere und bekamen unser eigenes HR nicht in den Griff. ## Warum wir nicht einfach etwas kaufen konnten Wir haben es versucht. Wirklich. **BambooHR, Workday, SAP SuccessFactors**: gebaut für Unternehmen mit 200+ Mitarbeitern. Wir hätten für Module zu Leistungsbeurteilungen, Nachfolgeplanung und Vergütungsmanagement bezahlt, die wir nicht brauchen. **Gusto, Rippling**: großartig für US-Unternehmen. Weniger großartig, wenn Ihr Team über Europa verteilt ist und Sie keine Lohnabrechnung brauchen (dafür haben wir Steuerberater). **Einfache Tools wie Timetastic**: machen im Grunde nur das Spreadsheet hübscher. Immer noch von allem anderen abgekoppelt. Wir brauchten etwas, das mit uns wachsen konnte, ohne uns Funktionen aufzuzwingen, die wir noch nicht brauchten. ## Was wir tatsächlich gebaut haben [image1]: /images/blog/dashboard-interface-2.png "Arheev-Dashboard-Oberfläche" ![Arheev-Dashboard-Oberfläche][image1] Version 1.0 enthält das, was wir am dringendsten brauchten: - Abwesenheitsverwaltung: beantragen, genehmigen, Salden verfolgen. Der Spreadsheet-Ersatz. - Mitarbeiterakten: Basisdaten, Beschäftigungsdetails, Dokumente, alles an einem Ort. - Abteilungen und Positionen: Organisationsstruktur ohne Organigramm-Software. - Anwesenheitsübersicht: Wer arbeitet, wer hat frei, wer ist im Urlaub. - Ein „Pulse“-Dashboard: Sehen, was im Team passiert, ohne fünf Tabs zu öffnen. Das war's. Keine KI, die Entscheidungen trifft. Keine „intelligente Automatisierung“, nach der niemand gefragt hat. Nur die Grundlagen, die tatsächlich funktionieren. ### Die eine KI-Funktion (die wir wirklich nutzen) Eine KI-gestützte Sache haben wir doch eingebaut: Beim Prüfen von Urlaubsanträgen markiert das System potenzielle Konflikte. „Drei Leute aus dem Engineering haben in der Woche schon frei“ oder „Das überschneidet sich mit der Projekt-Deadline in Linear.“ Es genehmigt nicht automatisch und lehnt nicht automatisch ab. Es zeigt nur Informationen an, die Sie sonst von Hand nachschlagen müssten. Das hat sich als deutlich nützlicher erwiesen, als die eigentliche Entscheidung automatisieren zu wollen. ## Woran wir noch bauen Wir haben mit funktionierenden Kernfunktionen ausgeliefert. Aber vieles haben wir noch nicht gebaut: Ein Recruiting-Modul kommt später in diesem Jahr. Vielleicht. Wir suchen noch den richtigen Ansatz. Leistungsbeurteilungen sind geplant, aber ehrlich gesagt wissen wir noch nicht, wie das geht, ohne dass es sich nach Bürokratie anfühlt. Integrationen: Aktuell können Sie Daten exportieren. Wir wollen richtige API-Integrationen mit Slack und Linear. Steht auf der Liste. Die Android-App funktioniert, aber die Migration auf 16KB Page Sizes hat drei Wochen gedauert, und wir finden immer noch Grenzfälle. Version 1.0 löst unser unmittelbares Problem (raus aus der Spreadsheet-Hölle). Alles andere ist Roadmap. ## Die Migration war chaotischer als erwartet Wir waren selbst die ersten echten Nutzer. Ende Januar 2025 haben wir unsere eigenen HR-Daten aus den Spreadsheets nach Arheev migriert. Hat zwei volle Tage gedauert. Nicht, weil der Import schwierig war, sondern weil unsere Tabellen inkonsistent waren. Manche Urlaubstage standen als Dezimalzahlen drin, manche in Tagen. Manche Datumsangaben in einem Format, manche in einem anderen. Wir stellten fest, dass wir die Urlaubsansprüche monatelang falsch berechnet hatten. Wenn schon unsere eigenen Daten unordentlich waren, sind es die aller anderen vermutlich auch. Also haben wir Import-Werkzeuge gebaut, die versuchen, mit Inkonsistenzen umzugehen. Sie sind nicht perfekt, aber besser, als saubere Daten vorauszusetzen. ## Im echten Einsatz Wir nutzen Arheev seit Ende Januar intern. Es ist... überwiegend gut. Die Urlaubsanträge laufen bestens. Kein Spreadsheet-Chaos mehr. Die Dokumentenablage ist okay. Besser als Drive-Ordner, aber wir vergessen immer noch, Dinge hochzuladen. Die Anwesenheitsübersicht wird manchmal ignoriert, weil Remote-Arbeit „Anwesenheit“ zu einem seltsamen Begriff macht. Es funktioniert einfach besser als das, was wir vorher hatten. Für eine 1.0 reicht das. ## Wenn auch Sie in Spreadsheets ertrinken Arheev ist live. Sie können es ausprobieren, wenn Sie möchten. Es ist für Teams wie unseres gemacht: 10–50 Leute, wachsend, noch keine Enterprise-Funktionen nötig. Eine ehrliche Warnung: Es ist nicht so poliert wie die großen Anbieter. An einigen Stellen feilen wir noch an der UX. Die Mobile-App funktioniert, ist aber nicht überragend. Wir beheben Bugs, sobald sie gemeldet werden. Aber wenn Sie HR in Google Sheets verwalten und es Sie in den Wahnsinn treibt, könnte sich ein Versuch mit Arheev lohnen. Wir haben es gebaut, weil wir es brauchten. Wenn Sie dasselbe Problem haben, funktioniert es vielleicht auch für Sie.