משבר זהות: ממפתח לראש צוות
#culture#leadership#career#team-lead#engineering

משבר זהות: ממפתח לראש צוות

הקפיצה מ-developer לראש צוות — עידן דגן על משבר הזהות שמגיע עם הפרומושן ומה שאף אחד לא מכין אתכם.

שחר פולק מארח את עידן דגן, שביצע את המעבר ממפתח בכיר לראש צוות ב-Imagen AI. מה קורה לזהות המקצועית כשהלו”ז מתמלא בפגישות במקום בשורות קוד? עידן לא מסתיר — היה שם “כאפה” אמיתית, וגם כמה תגליות שמישהו היה צריך לספר לו הרבה קודם.

מה תקחו מהפרק הזה?

”הכאפה” של המנהל החדש

הרגע שמבינים שהיום-יום השתנה מקצה לקצה. כשהלו”ז מתמלא בפגישות 1:1, קוד-ריוויוס וסינכרונים — אין כבר מקום לשעתיים של Coding שהכי אהבת. עידן מספר איך ציפה שהפרומושן ירגיש כמו שדרוג, אבל גילה שהוא קפץ למקצוע אחר לגמרי. ההכרה הזו לא מגיעה ביום הראשון — לפעמים לוקח שבועות עד שמבינים שצריך לשחרר את הזהות הישנה.

שריר אי-ההתערבות

הכישרון הכי קשה לפתח כמנהל: לדעת מתי לא להתערב. הדחף לקפוץ ולתקן את הקוד “כמו שצריך” הוא בדיוק מה שמונע מהצוות להתפתח. עידן מסביר שאי-ההתערבות הוא שריר שחייבים לאמן — לא מתוך אדישות, אלא מתוך הבנה שהטעות של המפתח Junior היא ההשקעה הכי טובה שאפשר לעשות בצוות. מי שמנהל על-ידי כך שהוא פותר את כל הבעיות — לא מנהל, הוא חוסם.

שיטת 1-3-1

הכלי שהפך את הצוות של עידן לעצמאי. כשמפתח מגיע עם בעיה, הוא צריך להגיע עם: תיאור הבעיה (1), שלוש אפשרויות לפתרון (3), וההמלצה שלו (1). כך הצוות מפסיק לבוא למנהל לקבל תשובות ומתחיל לבוא לשם לאשרר החלטות. ההבדל הוא עצום: האחד מייצר תלות, השני מייצר אחריות.

סיפור האימה: חשבון ה-AWS

טעות של 5 דולר שכמעט שרפה את חשבון המאסטר של AWS. זה לא סיפור על כשל טכני — זה סיפור על מה קורה כשמפתח לא מבין את הסביבה שהוא עובד בה. עידן מפרק מה קרה, מה הייתה תגובתו הראשונית כמנהל, ולמה בסוף הבחירה לא להעניש אלא לחנך הייתה ההחלטה הנכונה. הפרק הזה שינה איך הצוות שלו מתייחס לפרודקשן.

נקודות מפתח

  • הפרומושן לראש צוות הוא לא שדרוג — זה מקצוע אחר לגמרי, והלו"ז שמתמלא בפגישות במקום קוד הוא רק הסימפטום הראשון.
  • אי-התערבות היא שריר: הדחף לתקן את הקוד בעצמך הוא בדיוק מה שמונע מהצוות להתפתח.
  • שיטת 1-3-1 הופכת צוות לעצמאי: מגיעים עם תיאור הבעיה, שלוש אפשרויות לפתרון והמלצה — לא עם שאלה פתוחה.
  • כשמפתח עושה טעות יקרה, הבחירה לחנך במקום להעניש קובעת איך הצוות כולו יתייחס לפרודקשן מעכשיו.

שאלות נפוצות

מה משתנה במעבר ממפתח לראש צוות?

הכל — זה קפיצה למקצוע אחר, לא שדרוג של הקודם. הלו"ז מתמלא בפגישות 1:1, קוד ריוויוס וסינכרונים, ולא נשאר מקום לשעתיים של כתיבת קוד. ההכרה שצריך לשחרר את הזהות המקצועית הישנה לוקחת לפעמים שבועות, והיא החלק הקשה באמת.

מה זאת שיטת 1-3-1 בניהול צוות פיתוח?

כשמפתח מגיע עם בעיה, הוא מביא: תיאור אחד של הבעיה, שלוש אפשרויות לפתרון, והמלצה אחת שלו. כך הצוות מפסיק לבוא למנהל לקבל תשובות ומתחיל לבוא לאשרר החלטות — האחד מייצר תלות, השני מייצר אחריות ועצמאות.

מתי מנהל צריך להתאפק ולא להתערב בעבודת הצוות?

כמעט תמיד כשהדחף הוא לתקן את הקוד כמו-שצריך בעצמך. הטעות של מפתח ג'וניור היא ההשקעה הטובה ביותר בצוות, ומי שמנהל על ידי פתרון כל הבעיות בעצמו לא מנהל אלא חוסם. אי-התערבות היא שריר שמאמנים במודע.

איך מגיבים נכון לטעות יקרה של מפתח בצוות?

בפרק מסופר על טעות שכמעט שרפה את חשבון המאסטר של AWS. התגובה הנכונה הייתה לחנך ולא להעניש: להבין מה בסביבת העבודה אפשר את הטעות, לתקן את התהליך, ולתת למפתח להוביל את הלקחים. ההחלטה הזו שינתה את היחס של כל הצוות לפרודקשן.

הקטעים הכי שווים מהפרק