Unsere Kultur
Manifest fuer Wohlbefinden & Autonomie
Es ist uns egal, wie viele Stunden Sie arbeiten. Uns ist wichtig, dass das System laeuft, dass der Code wartbar ist und dass der Ingenieur, der ihn geschrieben hat, gut geschlafen hat.
Wir stellen keine Leute ein, um Plaetze zu fuellen. Wir stellen Ingenieure ein, um komplexe Probleme zu loesen. Und komplexe Probleme werden besser mit Autonomie, Fokus und Erholung geloest.
Vier Prinzipien, die nicht verhandelbar sind
Das sind keine angestrebten Ideale. Es sind operative Entscheidungen, die wir jeden Tag treffen und die definieren, wie bei Digital Axios gearbeitet wird.
Ergebnisse > Stunden Erfolgreiche Deployments und stabile Prozesse.
Wir messen Erfolg nicht in Stunden vor dem Bildschirm. Wir messen ihn in Deployments ohne Rollback, in Automatisierungspipelines, die Tausende Dokumente ohne Eingriff verarbeiten, und in Kunden, die ruhig schlafen, weil ihr System nicht ausfaellt.
Ein Ingenieur, der einen kritischen Bug in 45 Minuten behebt und spazieren geht, ist wertvoller als einer, der 8 Stunden Produktivitaet simuliert.Die KPIs, die zaehlen: System-Uptime, Fehlerrate in der Produktion, Incidentloesungszeit. Nicht die Stechuhr.Wenn Ihr Code die Tests besteht, das Code Review uebersteht und sich sauber in die CI/CD-Pipeline integriert, haben Sie Ihre Arbeit getan. Die Uhrzeit ist irrelevant.
Asynchrone Kultur Deep Work ohne Unterbrechungen.
Die Programmierung komplexer Systeme erfordert tiefe Konzentration. Ein Ingenieur, der alle 20 Minuten unterbrochen wird, schreibt keine solide Architektur: er schreibt Patches. Wir gestalten unseren Betrieb so, dass konzentrierte Arbeitsbloecke geschuetzt sind.
Schriftliche Kommunikation zuerst. Wenn etwas eine Slack-Nachricht mit Kontext sein kann, ist es kein 30-Minuten-Meeting.Meetings mit vorheriger Agenda und fester Dauer. Keine "schnellen Calls", die sich in eine Stunde Abschweifung verwandeln.Dokumentation als Quelle der Wahrheit. ADRs (Architecture Decision Records) und Runbooks ersetzen das "Frag mal den Kollegen, der weiss das."Wir respektieren "Nicht Stoeren"-Status. Wenn ein Ingenieur im Deep-Work-Modus ein Concurrency-Problem loest oder einen Microservices-Flow entwirft, ist diese Konzentration heilig.
Respekt vor dem Ingenieur Ihre berufliche Weiterentwicklung ist kein Hindernis.
Unsere Ingenieure absolvieren Studiengaenge an der UTN, erwerben AWS-Zertifizierungen und tragen zu Open-Source-Projekten bei. Das ist nichts, was wir trotz der Arbeit "tolerieren": wir foerdern es, weil es uns besser macht.
Flexible Arbeitszeiten, damit akademische Ausbildung nie mit der Arbeit konkurriert. Wenn Sie Vorlesungen haben, passt sich Ihr Zeitplan an.Jaehrliches Weiterbildungsbudget: Cloud-Zertifizierungen, technische Konferenzen, spezialisierte Kurse. Ohne Buerokratie bei der Beantragung.Geschuetzte Forschungszeit. Das ist kein dekoratives Benefit: Es ist der Grund, warum wir unseren Kunden Loesungen mit neuester KI und Dokumentenverarbeitung bieten koennen.Interne Mentorships zwischen Senior- und Junior-Ingenieuren. Geteiltes Wissen skaliert; Wissen, das bei einer einzigen Person angehaeuft ist, ist ein Single Point of Failure.
Mentale Gesundheit Sauberer Code erfordert ausgeruhte Koepfe.
Es gibt kein heroisches Engineering. Ein Ingenieur, der 14 Stunden arbeitet, um ein Deployment zu "retten", ist ein Symptom eines schlecht designten Systems, kein Akt der Hingabe. Wir gestalten unsere Prozesse so, dass Heldentum nicht noetig ist.
Produktionsincidents haben Blameless Postmortems. Wir suchen nach systemischen Ursachen, nicht nach Suendenboecken.On-Call-Rotation mit klaren Grenzen. Niemand ist "immer verfuegbar". Wenn Sie diese Woche Bereitschaft haben, ruhen Sie sich naechste Woche aus.Nachhaltige Arbeitsbelastung. Unmoeglich Sprints produzieren technische Schulden, die am Ende mehr kosten als die Deadline, die sie einzuhalten versuchten.Ein ausgeruhter Ingenieur erkennt Race Conditions, antizipiert Edge Cases und schreibt Tests, die Szenarien abdecken, die ein erschoepfter Ingenieur ignoriert.
Wie das in der Praxis aussieht
Das sind nicht nur Worte. So arbeiten wir jede Woche konkret.
Nachhaltige Sprints
Wir planen mit realer Kapazitaet, nicht mit Wunschdenken. Wir beruecksichtigen Puffer fuer Forschung, technische Schulden und Unerwartetes. Ein Sprint, der Heldentum erfordert, ist ein schlecht geplanter Sprint.
Dokumentation statt Meetings
Jede Architekturentscheidung wird in einem ADR dokumentiert. API-Spezifikationen sind in Swagger. Runbooks sind die erste Reaktionslinie bei Incidents. Wir verlassen uns nicht auf das Gedaechtnis einzelner Personen.
Code Reviews als Mentoring
Code Reviews sind keine buerokratische Formalitaet. Sie sind die Gelegenheit, Wissen zu teilen, Probleme zu erkennen, bevor sie die Produktion erreichen, und das technische Niveau des gesamten Teams zu erhoehen.
Blameless Postmortems
Wenn etwas in der Produktion fehlschlaegt, suchen wir nicht nach Schuldigen. Wir suchen, was dem Fehler erlaubt hat, so weit zu kommen. Fehlte ein Test? Hat das Monitoring nicht rechtzeitig alarmiert? War die Dokumentation mehrdeutig? Wir reparieren das System, nicht die Schuldigen.
Moechten Sie in einem Team arbeiten, das Ihre Zeit respektiert?
Wenn Sie Ingenieur/in sind und Autonomie, sauberen Code und echte technische Herausforderungen schaetzen, lassen Sie uns sprechen.
Kontaktieren Sie uns