Engineering Manager Tools und Tech-Stack: Der ehrliche Käufer-Leitfaden 2026

Sie haben das Team vor sechs Wochen übernommen. Sie haben jetzt Zeit gehabt, den "Tech-Stack" wirklich anzusehen, und das Bild ist nicht schön. Der Projekt-Tracker ist ein Jira-Board, dem niemand vertraut, weil vor drei sprints jemand 200 Tickets in einem Bulk-Edit und die Prioritäten gebrochen hat. Slack hat 47 Kanäle, die Hälfte davon archiviert-aber-nicht-wirklich. Notion ist ein Friedhof halbgeschriebener runbooks, zuletzt bearbeitet von einem Ingenieur, der 2024 gegangen ist. Es gibt ein Google Doc namens "Ziele_ENDGÜLTIG_v3", auf das alle verweisen und das niemand finden kann. Der vorherige EM ist gegangen, und so ist der Kontext.

Kommt Ihnen das bekannt vor? Das sollte es. Das erbt jeder neue EM, und der Drang, den "Stack zu reparieren", indem man ein weiteres glänzendes Tool kauft, ist genau, wie es so schlimm geworden ist.

Diese Anleitung ist das Gegenteil davon. Es ist ein Käufer-Leitfaden, der Ihnen meist sagt, was Sie kürzen, konsolidieren und welche sechs Kategorien wirklich wichtig sind. Reale Preise, reale Abwägungen und ein 30-Tage-Plan, den Sie ab Montag durchführen können.

Warum die meisten EM-Stacks kaputt sind

Der Stack, den Sie geerbt haben, wurde nicht entworfen. Er wurde angehäuft. Drei verschiedene Manager haben über drei Jahre Tools einzeln ausgewählt, jeder löste das Problem vor ihm, keiner dachte an das Ganze. Niemand besitzt den Stack jetzt. Das Team nutzt ungefähr 30% von dem, wofür Sie bezahlen. Kundenbugs leben an drei Stellen (Support-Tool, Slack-DM an den Ingenieur und eine persönliche Apple-Notiz auf dem Laptop von jemandem). 1:1-Notizen sind über persönliche Dokumente verstreut. Verlängerungsdaten? Unbekannt. Die jährliche automatische Verlängerung wird feuern, und Sie werden von einer 14.000-Euro-Abrechnung erfahren.

Die Lösung sind nicht mehr Tools. Es ist zu entscheiden, welche Aufgabe jedes Tool erledigen soll, ein Tool pro Aufgabe zu wählen und den Rest loszuwerden. Sechs Kategorien decken es ab. Das ist das gesamte Framework.

Die Kern-6: Was ein EM-Stack wirklich braucht

Vergessen Sie Tool-Listen. Denken Sie in Jobs-to-be-done. Es gibt sechs Dinge, mit denen Ihr Stack umgehen muss. Wählen Sie ein Tool pro Kategorie. Wenn Sie zwei haben, ist das das Duplikat, das Ihre "Wo finde ich das?"-Slack-Nachrichten verursacht.

1. Projektmanagement: Wo Arbeit lebt

Das ist das eine, dem niemand vertraut, was alles andere bricht.

• Linear ($10/Nutzer/Monat Standard, $14 Plus) ist schnell, meinungsstark und für Produktentwicklungsteams unter 50 gebaut. Zyklen statt sprints, Tastaturkürzel, die funktionieren, und ein meinungsstarker Workflow, der sich dem Werden eines Jira-Klons widersetzt. Es ist die Standardwahl, wenn Ihr Team Software liefert und das Liefern mag.
• Jira Cloud Standard ($7,75/Nutzer/Monat) bis Premium ($15,25/Nutzer/Monat) ist die sichere Wahl für Organisationen, die Compliance, komplexe Berechtigungsschemata oder Integration mit dem Rest der Atlassian-Welt benötigen. Es ist auch das Tool, das Ihr Team still hasst, wenn es ein 12-köpfiges Produktteam ist, das nichts davon braucht.
• Shortcut (~$8,50/Nutzer/Monat) ist die leichtere Alternative (früher Clubhouse), weniger starr als Jira, weniger meinungsstark als Linear. In Ordnung, wenn Linear zu startup-artig und Jira zu enterprise-artig wirkt.

Die Falle: Jira zu wählen, "weil das Unternehmen es bereits hat." Wenn Ihr Team das Tool hasst, sind Ihre Daten wertlos, Ihre Sprint-Reviews werden zu Theater, und Sie sind wieder bei der Wahrheit in Slack. Investieren Sie politisches Kapital in einen Wechsel, oder akzeptieren Sie, dass Jira-Hygiene jetzt ein realer Teil Ihrer Arbeit ist.

Entscheidungsregel: Unter 50 Ingenieuren, die Produkte liefern, Standard ist Linear. Über 50 mit Audit/Compliance-Anforderungen, Jira Premium. Irgendwo dazwischen, lassen Sie das Team eine einwöchige Testphase durchlaufen und abstimmen.

2. Code und Review: Wo Ingenieure den ganzen Tag leben

Das ist größtenteils geklärt, deshalb bin ich schnell.

• GitHub Team ($4/Nutzer/Monat) ist der Boden. GitHub Enterprise Cloud ($21/Nutzer/Monat) bietet SAML/SSO, Audit-Logs und die Dinge, die Ihr Sicherheitsteam irgendwann verlangen wird.
• GitLab Premium ($29/Nutzer/Monat) gewinnt genau ein Szenario: Sie wollen wirklich ein Tool für Repo, CI und Security Scanning, und Sie sind bereit, den Aufpreis zu zahlen und eine etwas umständlichere Review-UX im Austausch für weniger Anbieter zu akzeptieren.
• Bitbucket ist die richtige Antwort nur, wenn Sie bereits tief in Atlassian sind und Ihr Team mehr YAML als Markdown schreibt.

Die ehrliche Einschätzung: GitHub ist aus einem Grund der Standard. Die Netzwerkeffekte sind real (jeder Auftragnehmer und jede neue Einstellung hat bereits einen Account, jede OSS-Abhängigkeit ist dort), und die Review-UX ist immer noch die beste in der Kategorie. Wenn jemand in Ihrem Team einen Wechsel zu GitLab propagiert, fragen Sie, welches spezifische Problem er löst. "Ein Tool" ist kein Problem. Es ist eine Präferenz.

Wenn Sie einen staff engineer einstellen, der Infra besitzt, ist das die Person, die jede plattformbezogene Entscheidung hier vorantreiben sollte. Sehen Sie die Staff Software Engineer-Stellenausschreibung für das, wonach Sie suchen.

3. Incident und On-Call: Das 3-Uhr-morgens-Problem

Das ist die Kategorie, in der Sparsamkeit Sie am meisten kostet.

• PagerDuty Professional ($21/Nutzer/Monat) ist der etablierte Marktführer. Ausgereifte Integrationen, zuverlässiges Paging, die Bereitschaftsdienst-Rotations-Tooling, die andere Anbieter noch aufzuholen versuchen.
• Opsgenie Standard ($9/Nutzer/Monat) ist die Atlassian-Alternative. Günstiger, gut für kleinere Teams, und offensichtlich der Weg des geringsten Widerstands, wenn Sie bereits Atlassian bezahlen.
• Incident.io ($16-$24/Nutzer/Monat je nach Tier) ist der schnell wachsende Newcomer. Slack-nativ, unglaublich schnell einzurichten, und der Postmortem- und Incident-Komms-Workflow ist der beste in der Kategorie. Wenn Ihr Team in Slack lebt, ist das das erste, was evaluiert werden sollte.

Die Falle: die Rotation "vorläufig" in ein Google Sheet zu stecken. Sie werden um 3 Uhr morgens angepingt, die Rotation wird sechs Wochen zuvor still defekt gewesen sein, als jemand im PTO war, und Sie verbringen den Ausfall damit, herauszufinden, wer on-call ist, statt das Problem zu beheben. Zahlen Sie die $21/Seat. Es ist die günstigste Versicherung, die Sie je kaufen werden.

Entscheidungsregel: Unter 8 Ingenieuren in der Rotation und Slack-nativer Kultur, Incident.io. Größeres Team oder bereits auf Atlassian, Opsgenie. Stark reguliert oder 24/7 kundenorientierte Zuverlässigkeitsverpflichtungen, PagerDuty.

4. Leistung, 1:1s und Feedback: Wo die meisten EMs zu viel ausgeben

Seien Sie ehrlich darüber, was Sie wirklich brauchen.

• Lattice (~$11/Nutzer/Monat für das Talent Management-Bundle, mehr für die vollständige HRIS-Suite) ist die polierte Option. Ziele, Reviews, 1:1s, Feedback, alles in einem. Es lohnt sich, wenn Sie 30+ Ingenieure haben und HR eingebunden ist.
• 15Five ($10-$16/Nutzer/Monat je nach Bundle) ist die etwas stärker leistungsmanagement-orientierte Alternative. Stark bei wöchentlichen Check-ins und OKRs.
• Officevibe ($5/Nutzer/Monat) macht Puls-Umfragen gut und nicht viel anderes.

Die ehrliche Einschätzung: Wenn Sie weniger als 30 Ingenieure haben, brauchen Sie keins davon. Ein gemeinsames Notion-Template für 1:1-Notizen, ein vierteljährliches Review-Formular in Google Forms und eine Kalender-Erinnerung bringt Ihnen 80% des Wertes bei 0% der Kosten. Die restlichen 20% sind größtenteils die Dashboards, die Ihr VP möchte, und Ihr VP schaut wahrscheinlich gar nicht auf sie.

Die Falle ist, Lattice zu kaufen, um "unsere Feedback-Kultur zu verbessern". Lattice lässt Menschen kein ehrliches Feedback geben. Sie als Vorbild in Ihren 1:1s tut das. Tools verstärken Kultur; sie schaffen sie nicht. Wenn Ihr 1:1-Rhythmus kaputt ist, reparieren Sie Ihren 1:1-Rhythmus, bevor Sie irgendetwas kaufen.

5. Dokumente und Runbooks: Wählen Sie eines. Nur eines.

• Notion ($10/Nutzer/Monat Plus, $15 Business) ist der Team-Favorit für internes Wissen. Flexibel, schnell zu schreiben, blocks-Modell, das Ingenieure schnell verstehen.
• Confluence ($6,05/Nutzer/Monat Standard, $11,55 Premium) ist der Enterprise-Standard. Bessere Zugriffskontrollen, native Jira-Integration, weniger angenehm zu schreiben.
• GitBook ist gut für öffentlich zugängliche Engineering-Dokumente (Entwicklerdokumentation für eine externe API zum Beispiel), aber überdimensioniert für interne runbooks.

Die Falle: Notion UND Confluence gleichzeitig nutzen. Das ist die einzige größte Quelle für "Wo ist das runbook?"-Slack-Nachrichten, die ich in EM-Stacks sehe. Wählen Sie eines. Wenn Ihr Unternehmen eine Confluence-Lizenz hat und Sie nicht entkommen können, legen Sie runbooks dort ab und nutzen Sie Notion nur für persönliche Entwürfe. Wenn Sie frei wählen können, Notion für ein Produktteam, Confluence wenn Sie mit PMs und Finance zusammenarbeiten müssen, die bereits in Atlassian leben.

6. CRM und der Kunden-Bug-Feedback-Loop: Die Kategorie, die die meisten EM-Stacks ignorieren

Die meisten EM-Tech-Stack-Artikel enden bei fünf Kategorien. Das ist die Lücke.

Wenn Ihr Team Software für zahlende B2B-Kunden liefert, kommen Kundenbugs namentlich: "Acme Corp sagt, der Export-Button ist kaputt." Ohne ein CRM im Loop sterben diese Bugs in DMs an den Support, werden ohne Account-Kontext in Jira neu eingetippt, und Ihre Ingenieure beheben sie blind. Das Support-Team kann dem Kunden nicht sagen, wann es behoben ist, weil die Verbindung zwischen Ticket und Engineering-Arbeit das Gedächtnis einer Person ist.

Rework ($12/Nutzer/Monat für CRM/Sales Ops, $6/Nutzer/Monat für Work Ops; siehe rework.com/pricing) schließt diesen Loop. Support-Tickets, Kunden-Accounts und Engineering-Aufgaben leben im selben Workspace, sodass, wenn ein Ingenieur einen Bug behebt, er sehen kann, welche Accounts ihn gemeldet haben, und das Support-Team automatisch benachrichtigt wird. Es ist das einzige Kategorie-6-Tool, das ich in einem EM-Leitfaden namentlich erwähnen würde, weil die Alternative (Zendesk plus Jira plus Salesforce mit Zapier und Gebeten selbst verbinden) mehr als $12/Nutzer/Monat an verlorenem Engineering-Aufwand kostet, wenn zum ersten Mal eine P1-Kunden-Eskalation am Freitagnachmittag landet.

Ehrliche Einschätzung: Wenn Ihr Team nur interne Tools liefert, brauchen Sie diese Kategorie überhaupt nicht. Überspringen Sie sie. Wenn Sie an zahlende Kunden liefern und Bugs nach Firmenname gemeldet werden, brauchen Sie hier eine Antwort, und die Frage ist nur, ob Sie es bauen (Zendesk + Jira + Salesforce + Integrations-Klebemasse) oder kaufen (Rework, in einem Workspace).

Das 30-Tage-Stack-Audit

Das ist das eigentliche Liefergut dieser Anleitung. Blockieren Sie vier Wochen. Tun Sie eine Sache pro Woche. Versuchen Sie nicht, alles an einem einzelnen Nachmittag zu erledigen. Sie werden keine ehrlichen Antworten bekommen.

Woche 1: Inventar

Öffnen Sie eine Tabellenkalkulation. Eine Zeile pro Tool. Spalten:

Füllen Sie es für jedes bezahlte Tool aus, das das Team berührt. Ziehen Sie Seat-Zahlen aus jedem Admin-Panel. Der Prozentsatz aktiver Nutzer ist wichtiger als die Seat-Anzahl. Die meisten EMs finden in Woche eins mindestens 2-3 Zombie-Abonnements (die "Wir haben es vor 18 Monaten getestet und nie gekündigt"-Tools). Verlängerungsdaten kommen aus der Abrechnung oder dem Beschaffungsteam. Wenn niemand das Verlängerungsdatum kennt, ist das ein Befund.

Erwarten Sie, dass das ungefähr 4 Stunden dauert. Es wird sich wie Routinearbeit anfühlen. Tun Sie es trotzdem.

Woche 2: Den Kern-6 zuordnen

Gehen Sie durch Ihr Inventar und taggen Sie jedes Tool mit einer der sechs Kategorien. Die Duplikate springen ins Auge: Notion UND Confluence, Linear UND Jira, Slack-DMs UND ein echtes Ticket-System, drei verschiedene Feedback-Tools, eine "Engineering-Metriken"-Plattform, die sich mit dem überschneidet, was Ihr Projekt-Tracker bereits tut. Markieren Sie jedes Duplikat.

Alles, was nicht in die sechs Kategorien passt, ist ebenfalls ein Befund. Es könnte ein echtes siebtes Ding sein, das Ihr Team braucht (CI/CD, das nicht mit Ihrer Code-Plattform gebündelt ist, zum Beispiel, oder ein feature flag-Tool). Es könnte ein Tool sein, das ein Problem löst, das Sie nicht mehr haben.

Woche 3: Mit dem Team reden

Stellen Sie in Ihrer nächsten Runde von 1:1s eine Frage: "Welches Tool vermeiden Sie zu nutzen, und was nutzen Sie stattdessen?"

Der Schatten-Stack zeigt Ihnen, was wirklich kaputt ist. Wenn drei Ingenieure Ihnen sagen, dass sie Jira vermeiden und einen privaten Linear-Workspace nutzen, ist das keine Autonomie, das ist Datenfragmentierung, und Sie zahlen für beides. Wenn zwei Ingenieure Ihnen sagen, dass sie das Unternehmens-Notion vermeiden, weil die Suche kaputt ist, und Notizen in Obsidian machen, ist die Antwort, Notion zu reparieren, nicht Obsidian zum Stack hinzuzufügen.

Ein kurzes Skript, das funktioniert:

"Ich führe ein Stack-Audit durch. Kein Urteil, kein Verpetzen. Welches Tool vermeiden Sie zu nutzen, und wo erledigen Sie diese Arbeit wirklich? Ich möchte wissen, wo die Lücke zwischen dem, wofür wir bezahlen, und dem, was Sie wirklich nutzen, liegt."

Sie werden ehrlichere Antworten bekommen, als Sie erwarten. Ingenieure sagen Ihnen gerne, was kaputt ist, wenn sie vertrauen, dass Sie etwas dagegen tun.

Woche 4: Entscheiden und konsolidieren

Wählen Sie ein Tool pro Kategorie. Setzen Sie Erinnerungen für Verländerungskalender 60 Tage vor jeder Verlängerung, damit Sie Zeit haben, zu evaluieren, nicht nur automatisch zu zahlen. Kündigen Sie die Duplikate. Schreiben Sie ein einseitiges "Das ist unser Stack"-Dokument mit den sechs Kategorien, dem gewählten Tool für jede, wer die Verlängerung besitzt und was der Job-to-be-done ist. Pinnen Sie es. Verweisen Sie beim Einarbeiten neuer Mitarbeiter darauf.

Das ist auch die Woche, um die Kündigungs-E-Mails zu senden. Zögern Sie nicht. Anbieter werden Ihnen einen Rabatt anbieten, um zu bleiben; das ist ein Grund zu gehen, nicht zu bleiben.

Häufige Fehler

Eine kurze Liste der Fehler, die ich am häufigsten sehe:

• Tools kaufen, um Kulturprobleme zu lösen. Lattice lässt Ihr Team kein ehrliches Feedback geben. Ein 1:1-Dokumenten-Template macht Sie nicht zu einem besseren Zuhörer. Tools verstärken Kultur; sie schaffen sie nicht.
• Jeden Ingenieur sein eigenes Tool "für Autonomie" wählen lassen. Autonomie bei Bibliotheken und Editoren, ja. Autonomie beim Projekt-Tracker, nein. Die Kosten eines fragmentierten Stacks fallen auf den nächsten EM, den neuen Mitarbeiter und die on-call-Rotation.
• Jährlich erneuern ohne Nutzung zu prüfen. Sie werden für 12 Seats bezahlen, wenn Sie 7 Ingenieure haben. Auto-Verlängerung ist aus einem Grund der Standard: Sie wetten darauf, dass Sie nicht nachsehen. Sehen Sie nach.
• In jeder Kategorie das günstigste Tool wählen. Manchmal ist der $21/Seat PagerDuty es wert, weil die $9/Seat-Alternative eine Benachrichtigung fallen lässt. Die Kosten einer verpassten Benachrichtigung sind nicht "$12/Seat pro Monat gespart."
• Zu stark auf Integrationen setzen. Wenn Sie einen Zapier-Graph mit 14 Zaps brauchen, damit Ihr Stack funktioniert, ist Ihr Stack falsch. Wählen Sie Tools, die für sich alleine gut sind und nativ mit den anderen integrieren, die Sie gewählt haben.

Vorlagen und Tools

Drei Artefakte, die im runbook-Ordner des Teams aufbewahrt werden sollten:

1. Stack-Audit-Tabellenkalkulation (die Tabelle aus Woche 1). Vierteljährlich neu durchführen.
2. Einseitiges "Unser Engineering-Stack"-Dokument: die sechs Kategorien, das gewählte Tool für jede, die Kosten pro Seat, der Job-to-be-done, das Verlängerungsdatum, der Eigentümer. In Ihrem Dokumenten-Tool anpinnen.
3. 1:1-Schatten-Stack-Skript (die Frage aus Woche 3). Fügen Sie es Ihrer rotierenden 1:1-Fragenliste hinzu, damit Sie sie alle sechs Monate stellen.

Erfolgsmessung

Innerhalb von 90 Tagen nach diesem Audit gilt:

• Sie können jedes Tool, seine Kosten pro Seat, seinen Eigentümer und den Job-to-be-done auswendig benennen.
• Verlängerungsdaten stehen in einem gemeinsamen Kalender mit 60-Tage-Voraus-Erinnerungen.
• Jede der sechs Kategorien hat genau ein Tool. Der Schatten-Stack ist geschrumpft.
• Kundenbugs (wenn Sie an Kunden liefern) haben einen einzigen Eingangspfad.
• Ein neuer Mitarbeiter kann in unter einem Tag in den vollständigen Stack eingearbeitet werden.

Wenn auch nur drei dieser fünf zutreffen, sind Sie besser aufgestellt als 90% der EMs, mit denen ich spreche. Tools sind nicht die Arbeit. Die Arbeit ist das Liefern von Software mit einem Team, das Ihnen vertraut. Der Stack hält sich einfach aus dem Weg.

Mehr erfahren

• Engineering Manager 1:1 Cadence
• Sprint Planning for Small Eng Teams
• Hiring Your First Staff Engineer
• Engineering Manager Onboarding