[{"data":1,"prerenderedAt":307},["ShallowReactive",2],{"page-\u002Fblog\u002Fleadership\u002Ferste-100-tage-als-tech-lead":3},{"id":4,"title":5,"author":6,"body":7,"canonicalPath":294,"category":13,"dateModified":295,"datePublished":295,"description":296,"extension":297,"image":294,"imageAlt":294,"layout":294,"locale":294,"meta":298,"navigation":301,"ogImage":302,"path":300,"published":301,"seo":303,"seoTitle":304,"stem":305,"twitterCard":294,"__hash__":306},"content\u002Fblog\u002Fleadership\u002Ferste-100-tage-als-tech-lead.md","Die ersten 100 Tage als Tech-Lead: Dein Fahrplan","Samuel Benjamin Schneider",{"type":8,"value":9,"toc":290},"minimark",[10,15,23,53,76,91,104,117,220,233,266],[11,12],"blog-breadcrumb",{"category-title":13,"current-title":14},"Leadership","Erste 100 Tage als Tech-Lead",[16,17],"blog-header",{"category":18,"date":19,"reading-time":20,"subtitle":21,"title":22},"LEADERSHIP","07. Jun 2026","10 Min Lesezeit","Der Wechsel vom Entwickler zur Führungskraft ist kein Skill-Upgrade, sondern ein Identitätswechsel.","Die ersten 100 Tage als Tech-Lead",[24,25,26,40],"blog-content-container",{},[27,28,31],"blog-highlight-box",{"title":29,"variant":30},"KURZ GESAGT","definition",[32,33,34,35,39],"p",{},"Die ersten 100 Tage entscheiden, ob dich dein Team als Führungskraft akzeptiert – oder weiter als „besten Entwickler, der jetzt auch Meetings hat\". Dein Erfolg misst sich ab jetzt am Output des ",[36,37,38],"strong",{},"Teams",", nicht an deinem eigenen. Dieser Fahrplan zeigt dir, was du in Woche 1 und den ersten 30, 60 und 90 Tagen konkret tust – und welche technikspezifischen Fallen du vermeidest.",[32,41,42,46,47,52],{},[43,44,45],"em",{},"Bevor du startest:"," Wo stehst du gerade? Der ",[48,49,51],"a",{"href":50},"\u002Freality-check","Leadership-Reality-Check"," gibt dir in ~3 Minuten eine ehrliche Standortbestimmung – ohne Anmeldung.",[54,55,60,66],"blog-section",{"background":56,"icon":57,"title":58,"variant":59},"white","ico:ear-compact","Was ist die wichtigste Aufgabe in den ersten 100 Tagen?","mechanic",[32,61,62,65],{},[36,63,64],{},"Beziehungen und Erwartungen klären – nicht Output liefern."," Verstehe, wie das Team arbeitet, was kaputt ist, und leg mit deinem Vorgesetzten in einem Satz fest, was nach 90 Tagen „sichtbar besser\" sein soll.",[32,67,68,69,75],{},"Dein größter Hebel ist nicht dein Code, sondern die psychologische Sicherheit im Team. In ",[48,70,74],{"href":71,"rel":72},"https:\u002F\u002Frework.withgoogle.com\u002Fintl\u002Fen\u002Fguides\u002Funderstand-team-effectiveness",[73],"nofollow","Googles Project Aristotle"," war sie der wichtigste einzelne Faktor für die Leistung eines Teams – wichtiger als die Zusammensetzung. Genau diese Sicherheit baust oder zerstörst du in den ersten Wochen.",[54,77,82,88],{"background":78,"icon":79,"title":80,"variant":81},"alt","ico:code-compact","Soll ich als Tech-Lead noch selbst programmieren – und wie viel?","warning",[32,83,84,87],{},[36,85,86],{},"Ja, aber nachgeordnet und nie auf dem kritischen Pfad."," Wie viel genau, hängt von Teamgröße und Personalverantwortung ab – je mehr Menschen du führst, desto weniger Code. Die Regel dahinter: Führung zuerst, Coding zweitens.",[32,89,90],{},"Behalte Arbeit, die mentort: Code-Reviews, Pairing, Spikes, Glue-Code. Gib Arbeit ab, die das Team blockiert, wenn du sie liegen lässt – also alles auf dem kritischen Pfad. Wer Critical-Path-Features übernimmt, wird zum Single Point of Failure und nimmt dem Team die Lernchancen, an denen es wächst.",[54,92,95,101],{"background":56,"icon":93,"title":94,"variant":59},"ico:users-three-compact","Wie führe ich plötzlich meine ehemaligen Kollegen?",[32,96,97,100],{},[36,98,99],{},"Den Rollenwechsel explizit ansprechen, nicht aussitzen."," Führe in Woche 1 ein ehrliches 1:1 mit jedem – besonders mit dem, der den Posten auch wollte.",[32,102,103],{},"Ändere bewusst Muster aus der Peer-Zeit („mach ich schnell für dich\") und sei in Entscheidungen transparent statt kumpelhaft-vage. Du musst nicht beliebt sein. Du musst berechenbar und fair sein – das schlägt Beliebtheit in jeder schwierigen Situation, die noch kommt.",[54,105,108,114],{"background":78,"icon":106,"title":107,"variant":81},"ico:git-branch-compact","Reviewe ich als Tech-Lead noch jeden Pull Request?",[32,109,110,113],{},[36,111,112],{},"Nein – das macht dich zum Bottleneck und signalisiert Misstrauen."," Wechsle von „Ich bin der Gatekeeper\" zu „Ich definiere Standards, die das Team selbst durchsetzt\".",[32,115,116],{},"Etabliere klare Review-Regeln (z. B. zwei Approvals, du nur bei Architektur und Risiko), und nutze deine Reviews gezielt als Mentoring statt als Kontrolle. Eine gute Review-Frage – „Was passiert hier, wenn die Liste leer ist?\" – lehrt mehr und entmachtet weniger als ein Befehl.",[54,118,121,126,148,153,173,178,198,203],{"background":56,"icon":119,"title":120,"variant":30},"ico:rocket-launch-compact","Dein 30\u002F60\u002F90-Tage-Fahrplan",[32,122,123],{},[36,124,125],{},"Woche 1 – Zuhören & Landschaft kartieren",[127,128,129],"blog-ordered-list",{},[130,131,132,136,139,142,145],"ol",{},[133,134,135],"li",{},"Buche mit jedem Teammitglied ein 45-Min-1:1. Drei Fragen: Was läuft gut? Was nervt dich täglich? Was würdest du als Erstes ändern? (Remote: lieber zwei kürzere Video-1:1s als ein langes – und kein Gruppen-Call als Ersatz.)",[133,137,138],{},"Führe das schwierigste 1:1 zuerst – mit dem Kollegen, der den Posten auch wollte. Benenne die Situation offen.",[133,140,141],{},"Lies dich in Architektur, CI\u002FCD und die letzten drei Incident-\u002FPostmortem-Dokumente ein. Nicht um zu urteilen – um Kontext zu bekommen.",[133,143,144],{},"Frag deinen Vorgesetzten konkret: „Woran misst du in 90 Tagen, dass ich diese Rolle gut mache?\" Notiere die Antwort in einem Satz.",[133,146,147],{},"Ändere noch nichts Strukturelles. Sag das auch laut – „die ersten Wochen höre ich zu.\" Laut sagen heißt nicht groß auftreten; eine kurze Nachricht im Team-Channel zählt genauso.",[32,149,150],{},[36,151,152],{},"Tag 1–30 – Verstehen & verankern",[127,154,155],{},[130,156,157,160,167,170],{},[133,158,159],{},"Verdichte die 1:1-Erkenntnisse zu einer Schmerz-Liste und teile sie transparent („das habe ich verstanden\").",[133,161,162,163,166],{},"Wähle ",[36,164,165],{},"einen"," Quick Win, der Dev-Schmerz senkt (was das heißt, siehe unten).",[133,168,169],{},"Mach Entscheidungsrechte sichtbar: Wer entscheidet Architektur, wer Tooling, wer Prioritäten?",[133,171,172],{},"Lege deinen Coding-Rahmen fest: Welche Tickets nimmst du (kein kritischer Pfad), welche nicht.",[32,174,175],{},[36,176,177],{},"Tag 31–60 – Erste Hebel ziehen",[127,179,180],{},[130,181,182,185,192,195],{},[133,183,184],{},"Liefere den Quick Win – sichtbar, dem Team zugeschrieben.",[133,186,187,188,191],{},"Justiere den Review-Prozess: Wann reviewst ",[43,189,190],{},"du"," (Risiko\u002FArchitektur), wann gibt das Team eigenverantwortlich frei?",[133,193,194],{},"Hol strukturiert Feedback zu deiner Führung ein: „Was sollte ich als Lead anders machen?\"",[133,196,197],{},"Prüfe ehrlich deinen Coding-Anteil. Über ~20 % und auf kritischem Pfad? Gib gezielt ab.",[32,199,200],{},[36,201,202],{},"Tag 61–90 – Rolle festigen",[127,204,205],{},[130,206,207,214,217],{},[133,208,209,210,213],{},"Setz eine sichtbare Verbesserung am ",[36,211,212],{},"Team","-Output um (Lead-Time, weniger Rework, klarere Done-Definition) – nicht an deinem eigenen.",[133,215,216],{},"Delegiere bewusst eine Aufgabe, die du „eigentlich besser selbst\" machen würdest – und halt dich raus.",[133,218,219],{},"Führe das 90-Tage-Review mit deinem Vorgesetzten gegen den Satz aus Woche 1.",[54,221,224,230],{"background":78,"icon":222,"title":223,"variant":59},"ico:lightning-compact","Was sind echte Quick Wins für ein Dev-Team?",[32,225,226,229],{},[36,227,228],{},"Dinge, die den täglichen Schmerz der Entwickler senken – nicht ein schneller geshipptes Feature fürs Management."," Beispiele: ein chronisch flaky Test gefixt, die CI-Build-Zeit halbiert, ein seit Monaten ignoriertes Tech-Debt-Ticket endlich priorisiert, ein nerviges manuelles Deploy-Ritual automatisiert.",[32,231,232],{},"Solche Wins zahlen sofort auf Vertrauen ein, weil sie zeigen: Du hörst zu und nimmst das ernst, was die Leute jeden Tag bremst.",[54,234,237,243,249,255],{"background":56,"icon":235,"title":236,"variant":30},"ico:chat-centered-text-compact","Häufige Fragen",[32,238,239,242],{},[36,240,241],{},"Muss ich der beste Entwickler im Team bleiben?","\nNein. Deine Autorität kommt aus guten Fragen, Kontext und Standards – nicht aus dem meisten Output. Erfolg heißt: Dein Team wird besser, auch in Bereichen, in denen du nicht der Beste bist.",[32,244,245,248],{},[36,246,247],{},"Wie gewinne ich Respekt, wenn ich jetzt meine ehemaligen Kollegen führe?","\nIndem du den Rollenwechsel offen ansprichst, in Entscheidungen berechenbar und fair bist und alte Peer-Muster bewusst neu rahmst. Fairness schlägt Beliebtheit.",[32,250,251,254],{},[36,252,253],{},"Was, wenn ich nach 100 Tagen das Gefühl habe, nichts geschafft zu haben?","\nDas ist normal – der Wechsel von Einzel-Output zu Team-Outcome fühlt sich anfangs „unproduktiv\" an, weil sich dein Erfolgsmaßstab verschoben hat. Genau diesen Shift einzuordnen, statt in alte Coding-Reflexe zurückzufallen, ist die eigentliche Arbeit.",[32,256,257,260,261,265],{},[36,258,259],{},"Was ist überhaupt der Unterschied zwischen Tech-Lead und Engineering Manager?","\nKurz: Der Tech-Lead führt über Technik, der Engineering Manager über Menschen. Ausführlich im Vergleich: ",[48,262,264],{"href":263},"\u002Fblog\u002Fleadership\u002Ftech-lead-vs-engineering-manager","Tech Lead vs. Engineering Manager",".",[24,267,268,280],{},[27,269,272],{"title":270,"variant":271},"DU WILLST EINEN SPARRINGSPARTNER FÜR DEINE ERSTEN 100 TAGE?","cta",[32,273,274,275,279],{},"Der Wechsel vom Entwickler zum Lead ist ein Identitätswechsel – den muss niemand allein durchziehen. Wenn du jemanden willst, der die Tech-Lead-Rolle aus der Praxis kennt und dir auch sagt, wenn ein Schritt zu früh kommt: ",[48,276,278],{"href":277},"\u002Ffit-check","mach den 15-Min Fit-Check",". Kein Verkaufstermin – ein ehrlicher Blick auf deine Situation.",[32,281,282,283,287,288],{},"Weiterlesen: ",[48,284,286],{"href":285},"\u002Fblog\u002Fleadership\u002Fdie-befoerderungs-falle","Die Beförderungs-Falle"," · ",[48,289,264],{"href":263},{"title":291,"searchDepth":292,"depth":292,"links":293},"",2,[],null,"2026-06-07","Frisch zum Tech-Lead befördert? Konkreter 30\u002F60\u002F90-Tage-Plan: Code-Review-Dilemma, Ex-Kollegen führen, wie viel selbst coden. Klartext statt Theorie.","md",{"sitemap":299},{"loc":300},"\u002Fblog\u002Fleadership\u002Ferste-100-tage-als-tech-lead",true,"\u002Fassets\u002Fimg\u002Fog\u002Fdefault-og-1200x630.webp",{"title":5,"description":296},"Erste 100 Tage als Tech-Lead – 30\u002F60\u002F90-Plan | UP&FINE","blog\u002Fleadership\u002Ferste-100-tage-als-tech-lead","6vLJcismYfWKKoYh78XUI5ICZDkAxyDSY-m_drurg_8",1784825000542]