״צמיחה-חריגה״ (HyperGrowth) הוא מצב בו חברה צומחת בקצב לא שגרתי. הצמיחה יכולה להיות במכירות, שווי, מספר עובדים, מספר לקוחות וכו׳.
על איזה מדד אנחנו מדברים?
המדדים לרוב קשורים זה בזה. על אף שתאורטית ״שווי החברה״ הוא המדד המוביל - אני חושב שלקוראי הבלוג רלוונטי הרבה יותר להתמקד ב״מספר-העובדים״. זה מה שמשנה לנו את היום-יום - ובזה אעסוק.
מתי צמיחה נחשבת ל״חריגה״?
אין הגדרה חד-משמעית, אך מקובל להתייחס לצמיחה של 40-50% בשנה ומעלה, לאחר שהחברה התבססה - כצמיחה-חריגה.
המודל של חברות סטארט-אפ הוא: ״תנו לנו עוד כסף - ונצמח מהר יותר״. ברגע שיש שוק טוב ומוצר טוב - יש תמריץ ברור לייצר ערך גדול - מהר יותר, ו״לתפוס״ נתח שוק לפני המתחרים, שעוד יבואו.
(בואו נתעלם לרגע מ Bootstraps - שקיימים, וחברות שמגייסות הון - עוד לפני שהוכיחו Product Market-fit - שגם אלו קיימות).
האם צמיחה של 40% בשנה היא צמיחה-חריגה להייטק הישראלי? כלומר ארגון של 40 עובדים המגייס במהלך השנה עוד 16 עובדים?
זה אכן נשמע לא כל-כך חריג בשוק של היום.
כדאי לשים לב, שהשוק הולך ומקצין עם השנים האחרונות.
אם בשנת 2010 היו כ 20 חדי-קרן בעולם (חברות פרטיות בשווי של מעל מיליארד דולר), ב 2015 כבר היו כ 100 חדי-קרן, ובעת כתיבת הפוסט יש כ 500 (ע״פ CBInsights). יותר כסף זורם לחברות סטארט-אפ => צמיחה מהירה יותר.
המונח ״חד-קרן״ נבחר בכדי לתאר ייצור נדיר וייחודי - והיום כבר מתחילים לדבר על Decacorn (חברה פרטית בשווי 10 מיליארד או יותר) ואפילו Hectocorn (אשאיר לכם לבדוק...) - על מנת לבדל את הייחודי ויוצא-דופן.
זווית נוספת:
אני זוכר שהצטרפתי ל Gett לאחר ״הגיוס הגדול בהייטק הישראלי״ בסך 150$ מיליון דולר. מאז עברו חמש שנים - ו Gett גייסה עוד 720$ מיליון דולר (!!!).
סך ה״גיוס הגדול ביותר בהייטק הישראלי״ נשבר מאז עוד מספר פעמים - וגיוס בסך 150$ מיליון דולר הוא כבר לא אירוע ״בלתי-נתפס״. למשל: החברה שאני עובד בה כיום, Next-Insurance, גייסה פעמיים $250 מיליון דולר בארבע ומשהו שנות-פעילות. זה נתון חריג בהחלט - אבל לסתות כבר לא נופלות על הרצפה למשמע כאלו סכומים.
בפן אישי: ארבע מתוך חמש השנים האחרונות, אני נמצא בארגונים שצומחים יותר מ 100% בשנה. זו בהחלט צמיחה-חריגה, ולא מובנת.
לקבל פי 2 Traffic בשנה - זה לרוב לא אתגר כל-כך גדול.
שיכנס לחשבון הבנק סכום כסף גדול פי 2 משנה שעברה - גם אין בעיה.
להכפיל את מספר העובדים - זה אתגר משמעותי, שלא ניתן להתעלם ממנו. אני לא מדבר על מכירה/מיזוג - זה אתגר בפני עצמו - אך זה סיפור אחר. אני מדבר על צמיחה בבודדים, בקצב כזה.
חשבו על עיירה ההופכת למטרופולין (״גוש דן״) תוך 6-7 שנים: יש כאן אתגר ארגוני-ניהולי-חברתי-טכנולוגי ממשי ומשמעותי!
מה ״הבעיה״ בצמיחה-חריגה?
להצליח זה טוב. סטארט-אפים רוצים להצליח. להצליח משמע לגדול. לחברה גדולה יותר יש יתרונות וכוחות רבים - שאין לחברה קטנה. היא יכולה להשקיע מאמצים בסדר גודל אחר.
אז מה הבעיה בצמיחה-חריגה? למה לא רק לחגוג אותה?
בכל פעם שאני שומע על צמיחה-חריגה אני נזכר במשפט ״Success Killed The Punk״ (נדמה לי שהוא מהסרט The Filth and the Fury): הפאנק, הזרם החתרני כל-כך הצליח - שהוא הפך למיינסטרים, וכבר לא היה מקום לחתרנים אמיתיים.
צמיחה-חריגה מאיצה תהליכים ושינוי בארגון בצורה חריגה - הארגון משתנה בקצב מואץ, מה שלא קל לרבים. נוהגים ליפות את זה ולקרוא לזה ״כאבי גדילה״, ולהסביר שזה ״כאב טוב״.
כאבי לידה (לא חוויתי) - הם כנראה ״כאב טוב״. מניסיוני, ״כאבי גדילה״ הם כאבים עמוקים ואמיתיים - של מציאות משתנה תדיר שדורשת הסתגלות מהירה שוב ושוב, עם פשרות שכרוכות בכך.
לכאורה אם נוספו כ 20 מפתחים חדשים לחברה בחודש בודד - יש רק מה לשמוח על כך. זה לא יפה לעקם את האף - לא קוליגיאלי.
בפועל - תוספת של כל-כך הרבה אנשים משנה את אופן העבודה, וזה לא דבר קל לרבים. יותר גרוע: אם אופן העבודה ישתנה בצורה שגויה - ייגרם הרבה נזק לארגון ותפקודו.
הנה כמה סיכונים ממשיים בצמיחה-חריגה. אני מתייחס אליהם רק מנקודת המבט של ארגון תוכנה:
- רוב מהעובדים בחברה הם עובדים חדשים, עד הודעה חדשה!
- בהנחה שעובד הוא ״חדש״ בשנה-שנה וחצי הראשונה שלו בחברה, עד שהוא מכיר היטב את הארגון והמערכת - אנו הולכים לחוות תקופה בה רוב העובדים הם חדשים, וזה לא עתיד להשתנות עד קצת אחרי שקצב הצמיחה יתמתן.
- עובדים חדשים = פחות היכרות עם המערכת, הארגון, וההיסטוריה.
- עובד חדש מכיר פחות, ולכן הוא צריך יותר עזרה ויותר זמן בכדי להגיע לתוצאות דומות.
- לעובד חדש יש אינטואיציה פחות מפותחת מה מסוכן ו/או מה הגיוני, הוא מועד יותר לטעויות ופספוסים.
- כאשר הארגון מלא בעובדים חדשים, במי יתייעץ העובד שהגיע לפני שבוע? בעובד שהגיע לפני חודשיים, או בעובד שכבר נמצא ארבע חודשים?
- בסופו של דברים, עובדים חדשים יתייעצו עם עובדים חדשים אחרים - שהרבה פעמים לא יספקו תשובות מספיק טובות.
- הידע הממוצע במערכת / ביזנס / ארגון - ימשיך ויפחת ככל שהצמיחה החריגה ממשיכה. פחות ידע = הנדסה פחות טובה.
- טשטוש התרבות הארגונית (ו/או Engineering Culture)
- תרבות ארגונית היא נרכשת - ויכולה להתקיים בלי מייסדיה (כפי שניסוי חמשת הקופים מדגים).
- כאשר קצב ההצטרפות גדל - ההקניה נפגעת:
- כאשר עובד חדש מצטרף - הוא מגיע עם ״שק של הרגלים״. למשל, אם הוא ״לא מאמין בבדיקות יחידה״ - אך התרבות היא להקפיד על בדיקות יחידה - הוא יתיישר מהר מאוד. אם כולם עושים זאת - גם הוא יעשה.
- כאשר הרבה עובדים חדשים מצטרפים בזמן קצר - היישור הוא כבר פחות אוטומטי. אם קבוצה של עובדים הגיעה עם הרגל שנוגד את התרבות - גדלים הסיכויים שהם יצליחו לערער את העיקרון התרבותי.
- עכשיו: שינוי בתרבות הוא לא בהכרח רע. ייתכן והתרבות כוללת כמה הרגלים מזיקים. למשל: ארגון שלא עבד עם בדיקות יחידה - ועובדים חדשים שמגיעים עם ״שק הרגלים״ ומשנים את התרבות - הם כנראה דבר טוב. אבל:
- הנטייה של עובד חדש היא להיצמד ל״שק ההרגלים״ שלו כפי שהוא, ללא הבנת הצרכים הייחודים של הארגון שאליו הוא יצטרף. הסיכוי שההתנגדויות יהיו במקומות הנכונים - קטנים ככל שהארגון עובד היטב.
- יש יתרון גדול לתרבות ארגונית משותפת/אחידה. האחידות בטכנולוגיות / שיטות הרבה פעמים עדיפה על חצי-מעבר לטכנולוגיה / שיטה טובה יותר.
- האצת וריבוי תהליכי-שינוי
- אנחנו יודעים שמה ש״עובד״ עבור 10 עובדים עלול כבר לא לעבוד עבור 20-30 עובדים, ואז לא להתאים כבר ל 50-60 עובדים וכן הלאה: בעקבות צמיחה מספר העובדים - יש לשנות תהליכים והרגלים.
- כאשר הארגון גדל מהר - גם השינויים צריכים להעשות מהר יותר.
- שינוי כולל מאמץ וסיכון, אך צמיחה-חריגה לא מספקת הנחות*: את השינויים יש לעשות, וכל טעות - תהיה כואבת ומזיקה באותה המידה לו לא הייתה צמיחה-חריגה.
- * לעיתים ארגונים בצמיחה-חריגה מדלגים על שלבים: במקום להיערך למצב של 100 עובדים - מתכוננים כבר מיד למצב של 300 עובדים.
- ה Tradeoff: חוסכים איטרציה של שינוי - אך מתפקדים זמן מה במודל ״גדול/כבד״ יותר מהנדרש. הרבה פעמים ה Tradeoff הזה משתלם.
- אפשר לחשוב על צמיחה-חריגה כ״מגבר״ לשינויים ארגוניים:
- כאשר/היכן שהתרבות הארגונית / קבלת ההחלטות שלכם היא טובה - היא תשרת אתכם היטב בצמיחה-חריגה.
- כאשר/היכן שהתרבות הארגונית / קבלת ההחלטות שלכם לקויה - היא תזיק לכם שוב ושוב בצמיחה-חריגה.
- יצא לי באופן אישי, לחוות כניסה לצמיחה-חריגה בארגון פיתוח אחד עם יסודות הנדסיים רעועים (אין בדיקות אוטומטיות, אין לוגים, אין תרבות של שיפור קוד תמידי) ואחד עם יסודות יציבים (בדיקות אוטומטיות הן דבר מובן מאליו, יש כלי ניטור טובים, יש תרבות של שיפור קוד) - וההבדלים בתוצאות בין שני המצבים היה דרמטי. אני מתאפק שלא לומר: ״הבדלים של שמייים וארץ״.
- מעט סובלנות לקושי ב Scalability ארגוני
- כאשר שוררים תנאים עסקיים (מודל עסקי/שוק/הזדמנויות) לצמחה מהירה - המשקיעים => ה Board => המנכ״ל => המנהלים הבכירים => המנהלים הזוטרים ילחצו לאפשר אותה. זו הדרך להצליח - וזה תפקידם.
- הסובלנות לדחיית הצמיחה תהיה נמוכה, ומה שצריך לזוז בכדי לאפשר את המשך הצמיחה המהירה - יזוז:
- מנהלים יאלצו להאציל ולפזר סמכויות - גם כאשר הקצב מהיר מדי לטעמם.
- אם מחלקת הפיתוח מתקשה לגייס עובדים בקצב של מחלקת המכירות - היא תאלץ לגייס מהר יותר, ולעשות את הפשרות הנחוצות.
- תהליכים ידניים - יאלצו לעבור אוטומציה, גם אם כרוכות בכך פשרות באיכות.
- כל ״ניצחון״ (איכותי, צודק, נכון) שיגביל את הצמיחה - יצור לחץ הולך וגובר לאפשר חזרה את הצמיחה בחזרה. לא סביר שקבוצה קטנה של אנשים בארגון תחסום את הארגון מצמיחה-חריגה: הלחץ לצמיחה מהירה בסוף ינצח כל שיקול/טיעון. אם הצלחתם לעכב את הצמיחה - דעו שזה רק עניין של זמן, עד שתאלצו לסור מהדרך (לא משנה כמה הוגנת וטובה התרבות הארגונית).
- ארגון תוכנה - הוא מורכב יותר לצמיחה מארגון מכירות (אני מאמין). מערכת תוכנה - הולכת ומסתבכת עם הזמן - ולכן צריכה יותר עבודה על כל שינוי ככל שהזמן עובר. כל זה לא משנה - כל עוד ארגון התוכנה הוא צוואר בקבוק לצמיחת החברה (וכנראה שפעמים רבות זה יהיה המצב) -יהיה עליו לצמוח. אם הגדילה לא תעשה אורגנית - היא יכולה להיעשות ברכישה של ארגון תוכנה נוסף (ולא בהכרח הכי טובה). ארגון התוכנה הוא לא זה שיעצור את הצמיחה-החריגה של החברה.
אפשר לסכם את זה בפשטות: לצמיחה-חריגה חשוב מאוד להיכנס עם יסודות יציבים, וחשוב לקבל המון החלטות בצורה נכונה וטובה. הלוואי והיישום היה קל כמו לתת את העצה...
 |
| מקור: https://lethain.com/productivity-in-the-age-of-hypergrowth |
מה הדרכים להתמודד עם צמיחה-חריגה?
טוב. אם הייתי יודע מה הדרך הטובה ביותר - כבר הייתי כנראה עובד (בביקוש ושכר מטורף) כיועץ לארגונים בצמיחה-חריגה.
אני זוכר שעברתי לעבוד ב SAP בשנת 2005, אחת מנקודות המכירה של הארגון הייתה ״פה תעבוד ב Scale מטורף. יש לנו לקוחות עם עד 120 אלף משתמשים (!!!) למערכות שלנו. לא תמצא כזה Scale בשום מקום אחר״.
120 אלף משתמשים? היום לחצי מהסטארט-אפים הקיקיוניים - יש מספר דומה של מתשמשים (במיוחד בתחום הפרסום). ב Next-Insurance אנחנו מגדירים את עצמנו כ״חברה ש Scale הוא לא עניין שלה״ - ולא מזמן עברנו את 120 אלף הלקוחות.
מה שאני מנסה לומר שהוא שצמיחה-חריגה - הוא עניין מתפתח, שאין בו המון ניסיון. התעשייה לומדת כיצד מתנהלים במצבים שכאלו - וכרגע נראה שהעניין בנושא הזה רק ילך ויגבר עם הזמן.
אז אלו כלים ידועים להתמודדות עם צמיחה-חריגה (מלבד: ״להיות מוכנים, ולקחת המון החלטות בצורה נכונה וטובה״)?
רשימה לא מלאה:
מיקרו-שירותים
אני פותח ב microservices (פוסט בנושא) לא מכיוון שזה האמצעי החשוב ביותר, או היעיל ביותר - אלא כי זה אחד הרעיונות הראשונים שעולים מאנשי-תוכנה ברגע שמדברים על צמיחה-חריגה (וגם כאשר מדברים על דברים אחרים - זה פשוט באזז).
אנשים נוטים להתאים מיקרו-שירותים למגוון בעיות, אך דווקא צמיחה-חריגה היא בעיה עיקרית שמיקרו-שירותים נועדו באמת לפתור. ההנחה היא שאם נשבור את המערכת המורכבת שלנו ל״חתיכות מופרדות״ (Isolated) - יהיה קל יותר לנהל אותה ולשנות אותה לאורך זמן. מהות העבודה של ארגון פיתוח הוא לשנות את המערכת - וקל יותר לשנות 10 תתי-מערכות מופרדות מאשר אותה כמות קוד במערכת אחת בה הכל קשור להכל.
ההפרדה לשירותים שונים יוצרת גבולות ברורים של אחריות, ומקשה על עבודה מעבר לגבולות הללו (יש לפתוח API חדש - זה לא עוד קריאה באותו מרחב-זיכרון). השירותים גם מתעדכנים באופן בלתי-תלוי בפרודקשיין - מה שמגביר את העצמאות/פריון של הצוותים הבודדים, ומציב עוד קושי בפני מי שינסה ליצור תלויות עמוקות במערכת (שאנו רוצים לגדוע).
העיקרון אומר שהשירותים צריכים להישאר קטנים: כאשר שירת אחד גדל / מסתבך מעל למידה כלשהי - הפתרון הוא לחלק אותו שוב לעוד שירותים קטנים יותר. ככל שהמערכת גדלה - נוספים בה עוד שירותים, בגודל המירבי שאנו מרשים לעצמנו - במקום שירותים הולכים וגדלים. פיסות קוד קטנות יותר - מקשות על הצטברות חריגה של סיבוכיות, ושומרות על המערכת נשלטת יותר.
בסה״כ אני חושב שמיקרו-שירותים היא גישה מעשית ומועילה להתמודדות עם צמיחה-חריגה. כלומר: בהחלט לא פתרון קסם, אך עוד צעד בכיוון הנכון.
Companies
וריאציה נוספת של חלוקת ארגון הפיתוח הגדול (סבוך, קשה לניהול) לתתי-ארגונים היא חלוקת הארגון ל״חברות עצמאיות״ (להלן Companies). במידה והארגון מפתח מספר מוצרים / מערכות ללא קשר, או עם קשר רופף ביניהן - ניתן להגדיל ולחלק אותו לתתי ארגונים ש״רק מדי פעם נפגשים זה עם זה״. כל ארגון כזה יכול לקבל עצמאות גדולה יותר בסגנון הפיתוח / כלים / פרקטיקות / דרכי ניהול / וכו׳ - מה שדי יוצר בעיה כאשר מדובר במיקרו-שירותים שביניהם יש תקשורת רצופה ותדירה.
העיקרון זהה - ניהול של כמה ארגונים קטנים, קל ופשוט יותר מניהול ארגון גדול יותר. הסיבוכיות של ארגון פיתוח גדלה בקצב גדול מיחס ישר למספר העובדים (ידע,תקשורת, קונצנזוס) - ולכן לחלוקה שכזו יש היגיון.
וריאציה שראיתי פעם היא Companies בעלי בסיס קוד קדמון משותף. בחברת Nice שבה עבדתי מזמן, לקחו מוצר שעליו עבדו כ 50-60 מהנדסים (מערכת להקלטה של תכנים) ופיצלו אותה ל2 חטיבות עצמאיות: הקלטת וידאו והקלטת אודיו. עשו פשוט Fork לקוד, ושכפלו את המחלה ל-2 מחלקות שעבדו על בסיס אותו קוד שהיה עד כה.
עם הזמן הקוד השתנה, ועבר אופטימיזציה לשוק ולצרכים הספציפיים. ברור היה שלנהל מערכת ״גנרית״ שמטפלת ב-2 הצרכים - מסובך יותר. כמו כן, יכלו כך לתכנן את ה Releases - לצרכים השונים של כל שוק. זה היה בזמנו שיקול עיקרי.
אני מניח שזה מודל ישים כאשר יש ביזנס חזק שיכול להצדיק חופש בגיוס מספר רב יותר של עובדים. לצערי לא יצא לי לשמוע יותר על מערכת השיקולים מאחורי המהלך.
Lean Startup
שבירת הצרכים העסקיים ל״חתיכות קטנות״ ובחינת כל יכולת מהר-ככל-שניתן מול השוק / לקוחות אמיתיים - במקום להניח הנחות.
המודל של Lean Startup (פוסט בנושא) הוא מהפכני, נהדר, חשוב, ושימושי הרבה מעבר לחברות שחוות צמיחה-חריגה. אם זאת - כאשר יש צמיחה-חריגה, יש הרבה שינויים והסתגלויות, והרבה פחות זמן לטעויות. מחזור מהיר של Build-Measure-Learn הוא כלי נהדר על מנת לשפר את קבלת ההחלטות.
שמירה על מיקוד / WIP
עוד עיקרון מדובר הוא שמירה על מיקוד-חד, והגבלת ה Work In Process (בקיצר: WIP).
שוב, העקרונות הללו נכונים בכלל - אך חשובים יותר בצמיחה-חריגה.
בעת צמיחה-חריגה - יש לנו לרוב כסף, יש שוק מבטיח, אך יש לחץ באנשים ובזמן. גם שאנחנו מגייסים אנשים בקצב מוגזם (חוויה: 16 עובדים חדשים מתחילים לעבוד באותו היום) - ייקח זמן רב עד שהם יהפכו ליעילים, והרעב תמיד גדול יותר: ״תנו לאיש מוצר שבוע, והוא יגדיר עבודה ל 20 מהנדסים לכמה חודשים...״
טעות נפוצה, היא להתרשם ממספר האנשים (Head Count) ולהשתמש בהם להתחיל יוזמות נוספות / חדשות. תמיד יש רעיונות לכל מיני דברים ״חיוביים״.
״זוכרים שרצינו פעם לעשות XYZ ולא הספקנו? בואו ניתן לשלושת החבר׳ה החדשים לנסות - יצליח-יצליח, לא יצליח - לא נורא״ - הוא סוג החשיבה המזיק הזה.
התוצאה של ההתפזרות הזו היא: ״סתם״. יוזמות רבות, הגוזלות תשומת-לב מיוזמות חשובות יותר, מייצרות תחושה משמחת של ״עשייה״ אך ללא משמעות אמיתית, ללא Impact.
צוואר הבקבוק האמיתי של הארגון, הוא האנשים שיכולים להוביל בהבנה מאמצים שיגרמו ל Impact אמיתי. אם האנשים הללו ידרשו להתייחסות ליוזמות צדדיות - הם יתעכבו בעשייה המשמעותית.
על כן, עצה שחוזרת שוב ושוב מאלו שהיו שם היא: ״דבקו במיקוד״. ״אל תתרגמו כמות גבוהה יותר של עובדים, שאתם לא רגילים לה - למספר רב של יוזמות ללא בקרה/ניהול מספיק״.
עדיף להציב עובדים חדשים ביוזמות חשובות, גם כאשר אינם יעילים - מאשר לשלוח אותם לנסות יוזמות שוליות / יוזמות חשובית שהסיכוי שלהם לעשות Impact אמיתי הוא שולי.
זו גם דרך - להגדיל את מאגר האנשים שיכולים להוביל בהבנה מאמצים שיגרמו ל Impact - שזה הנתיב הקריטי.
וריאציה נוספת: אם מספר יוזמות בארגון מתקדם בצורה נרעשת (Frantic) / מלאת מהמורות - זה הזמן לצמצם את היוזמות. אתם תצטערו אם תמשיכו כך לאורך זמן.
וריאציה נוספת: ״The key to scaling - is to say no״.
ערכים ומדיניות
איך מכוונים עם שלם שצועד במדבר? - בעזרת עמוד האש: גדול, ברור, חד-משמעי.
איך משתיתים תורה על עם חסר-סדר? בעזרת עשרת הדברות. לו היו חמישים - התוצאה בוודאי הייתה פחות טובה. מספר מצומצם של הכללים החשובים ביותר.
כאשר הארגון גדל - הוא הופך לעדר: לא ניתן ״לכוון״ אותו בעזרת דיבורים שקטים ומנומקים. יש מקום לשקט והמנומק - אך חשוב להתחיל במסרים פשוטים וברורים.
הרעיון של חזון ארגוני ככלי ניהולי - אינו חדש (כנראה התפרסם בעיקר בספר לנצח נבנו). יש תורה שלמה כיצד לעשות זאת נכון. ראיתי יישומים של הרעיונות הללו בכל חברה שעבדתי בה ב 18 שנות הקריירה שלי.
ברמה המחלקתית, מסר פשוט וברור לגבי היעדים וסדרי העדיפויות - הוא ההכוונה. המודל הפופולארי בשנים האחרונות הוא ה OKR (פוסט בנושא).
ברמה של ארגון הפיתוח, ערכים ומתחת להם כמה כללים עיקריים של מדיניות - יעזרו להכווין את העדר לכדי קבוצה הומוגנית. למשל:
- Dare to Simplify (ערך של Next-Insurance) - הוא ערך שאני מאוד אוהב. המילה החזקה היא ״Dare״: ״קח סיכון על מנת לפשט, זה מספיק חשוב!״. עצם הצבת הערך הזה ברמת החברה - עזר למקד דיונים ולשכנע את המשתתפים לחתור לפשוטת, גם כאשר זה לא היה קל.
- Don't just identify a problem - fix it (מתוך מאמר על AirBnb) - במיוחד בארגון בצמיחה-חריגה - דברים יתקלקלו כל הזמן. חשוב לנצל את מאגר הכוחות/מוחות/תשומת-הלב כדי לשפר ולתקן כל הזמן תקלות. לתקן בעיות שלא אני גרמתי (כמובן) ולתקן בעיות שמפריעות לאחרים יותר מאשר לי (גם זה).
- Everything changes all the time. Get over it - זו יותר מדיניות מאשר ערך. אם לאנשים משתבשות שוב ושוב תוכניות, והם מתרכזים בדיוק על ״אסור להזיז לנו דברים - זה הורס את התוכניות״, התמודדות נגד היא להגדיר את המדיניות הזו. לחדד לאנשים שיהיה עליהם להמשיך ולהתמודד עם שינוי מהיר-תמידי. זה מה שמצופה מהעובדים, למרות שזה לא קל.
- הערה אישית: אני מקווה שזה בא עם הכרה כנה בקשיים. מנהלת HR שמצהירה ״אלו כאבי גדילה - זה טבעי״, מניסיוני, לא מספיק עזר. אני רוצה להאמין שמסר כמו - ״שמע, זה מזופת. זה יכול פעמים לשגע אותך - אבל זו המציאות שלנו. נסה לקחת את זה כאתגר - ולא להתייאש, כולנו עוברים את זה״ - היה עובד טוב יותר.
On-Boarding and Education
בחברת Gett (לשעבר GetTaxi) חוויתי לראשונה צמיחה-חריגה אמיתית.
בסאפ פעם הוספו לנו לפרויקט מהיום-למחר כמה עשרות עובדים, אבל הכרנו חלק מהם, והם הכירו היטב את הארגון. היו לנו כבר הרגלים משותפים. זה, יחסית, היה ״בקטנה״.
קליטה לארגון ב Gett היה תהליך קשה:
עובדים חדשים היו צריכים להכיר ביזנס חדש (מוניות, On-Demand Transportation), טכנולוגיה חדש (רובי, Go), שוק חדש (Consumer), רבים היו חדשים ל SaaS, טיפול בפרוקדשיין ו AWS ואפילו רבים היו חדשים למק. כל זה עוד לפני שהגענו למערכת חדשה ומורכבת, שעברה הרבה שינויים מהירים וגם היה בה הרבה Legacy להיזהר ממנו, ארגון שפועל ב - 4 מדינות, כל אחת עם כללים וצרכים משלה. ארגון וצוותים, בעלי תפקידים שונים ומשונים.
פלא שזו לא הסתגלות קלה?
מה עשינו לעזור לעובדים?
בהתחלה - את הדברים הרגילים: הצמדנו לכל עובד חדש Buddy (עובד אחר) שילווה אותו בכמה שבועות הראשונים (freestyle), ועשינו כמה סשנים להכרת המערכת.
הייתה תקופה שהזמנו קורס חיצוני של שבוע לשפת רובי, שלמרות ניסיונות שיפור, לא השיג שביעות רצון גבוהה - ולא הרגשנו שלאחריו אנשים יודעים ממש את השפה.
זה לא היה מספיק טוב. ההרגשה הכללית הייתה שעובדים שנמצאים כמה חודשים בחברה עדיין חסרים המון - ואינם עצמאים כמעט בשום משימה משמעותית. הם הרבו לתקן באגים קטנים או לכתוב שירותים צדדים - שלא נוגעים בליבת המערכת.
בהמשך לקחנו את היוזמה, והשקענו פנימית בהכנת בתכנים ממוקדים יותר לגבי רובי, ו Go אך גם AWS ו SQL. יותר מזה - סשנים יותר מבוקרים ומוקפדים על הכרת המערכת.
זה היה תהליך: בהתחלה זה צלע - אך אם הזמן היה יותר ויותר טוב.
עצם היותו תהליך פנימי - יכולנו להתאים תכנים בדיוק לארגון. למשל: לדבר על הספריות המשותפות הפנימיות של הקוד. על הבעיות הנפוצות שצצו אצלנו.
בסופו של דבר, הצלחנו לעשות את המעבר, ולחבר עובדים חדשים לטכנולוגיה והסביבה שלנו בצורה יעילה - כך שלאחר כמה חודשים, גם העובדים החדשים, וגם המנהלים בארגון - הרגישו הרבה יותר טוב לגבי היכולת של עובדים חדשים להתמצא במערכת. תהליך ה On-Boarding היה אחד הצעדים היותר פוריים שעשינו להשתלט על הבלאגן בקליטת כמות משמעותית של עובדים.
היום ב Next-Insurance יש לנו תהליך On-Boarding של הימים הראשונים, של השבועות הראשונים, ושל החודשים הראשונים. משם והלאה יש מבחר של סשנים (מוקלטים) במגוון נושאים רלוונטים - זמינים לרגע שבו העובד יזדקק להם. יש גם StackOverflow פנימי ווויקי - מהם אפשר להמשיך ללמוד.
תהליך ה On-Boarding מתחבר באופן טבעי לתיעוד וחומר לימודי להמשך תקופת העבודה. לפעמים עובד לא נתקל בנושא במערכת גם במשך שנתיים-שלוש. טוב שכאשר הוא נתקל בנושא - יש לו מקור יעיל להשלים לגביו ידע.
עוד גישה שיש לגבי קליטת עובדים במצב של צמיחה-חריגה היא לעשות ״תורנות״ בין הצוותים בגיוס העובדים. במקום לגייס לכל הצוותים כל הזמן, יש כל פרק זמן (נניח: רבעון) צוותים שמגייסים - וצוותים ש״מתאוששים״ מגיוס.
ההנחה היא שבניגוד למרתון (או התמודדות שוודית עם קורונה) בו שומרים על קצב קבוע כל הזמן, בקליטת עובדים יש הרבה הפרעה לצוות בביצוע ראיונות וקליטת עובדים חדשים.
לכן עדיף שתקופה הצוות יעסוק בגיוס, ותקופה הצוות יעסוק בקליטה ו״גידול״ העובדים החדשים - ולא לנסות למקד צוות בשני המאמצים בו-זמנית.
 |
| צמיחה-חריגה, בה רוב העובדים הם עובדים חדשים. |
אחת הגישות שהתנסתי בהן היא התמודדות עם צמיחה-חריגה ע״י גיוס של אנשים מצוינים בלבד (על בסיס הספר
Scaling Up).
המחשבה הייתה שעובדים ״סבירים״ - רק יעכבו אותנו, וידרשו המון תשומת לב. זו בעיה קשה, כאשר צומחים מאוד מהר (להזכיר: +100% בשנה) ורוב העובדים הם חדשים. במקום זאת, ניסינו להתמקד רק בעובדים ״מעולים״ שהם אלו שיהיו עצמאים הרבה יותר, ידרשו פחות תמיכה, וישפרו כל הזמן תהליכים - במקום רק לצרוך אותם (או להתלונן שהם חסרים).
לצורך העניין נעזרנו בחברת ייעוץ מלונדון (שהתבססה על הספר
Who. חלק מאיתנו גם טסו לשם להדרכה) - ולקחנו את העניין בסופר-רצינות. מהמנכ״ל - עד אחרון המראיינים.
ההחלטה הייתה לגייס פחות, לשלם יותר - אבל להביא רק אנשים מצוינים ״A players״. היו חודשים רבים שהקדשנו לנושא הגיוס יותר זמן מכל נושא אחר.
איך זיהינו אנשים מצוינים? אנשים שיצאנו מהראיון איתם ללא ספקות. שהרשימו את כל המראיינים מאוד. לא חששנו לפסול אנשים שיש לגביהם ספקות, והרבה כאלה.
זוכרים את העיקרון של אי-עצירת הצמיחה? היוזמה לגיוס אנשים מצוינים בלבד הגיעה מהמנכ״ל - וכדי לעמוד ביעדי הגיוס היינו צריכים לראיין בלי סוף. 3-5 ראיונות בשבוע היה קצב שגרתי למראיין, ואני זוכר מקרה של מנהל הפיתוח שסיפר שקיים 15 ראיונות בשבוע בודד.
את התוצאה ראינו רק לאחר חודשים - היא לא הייתה טובה. למרות מאמץ אדיר, פשוט אדיר - זה לא עבד כפי שציפינו.
בהבנה לאחור, הייתה תפיסה בארגון (שקדמה לכל התהליך) שחשוב לנו מאוד לגייס אנשים עם ״אש בעיניים״ עם מוטיבציית-שיא. בכדי להשיג מוטיבציית שיא גייסנו אנשים שהתפקיד שהוצע להם - היה עבורם קפיצת מדרגה משמעותית (כלל האצבע היה: ״30% יותר ממה שעשו בתפקיד הקודם״). למשל: מנהל בחברת פרויקטים, שבא לנהל קבוצת פיתוח Consumer/SasS בחברת סאטראט-אפ מבוקשת. בחור מאוד מוכשר - עם טונה של מוטיבציה להצליח. החיסרון שהבנו בדיעבד: לרבים מאלו שגייסנו לא היה ניסיון קודם במה שהם עומדים להתמודד איתו. הם עברו טבילת-אש ראשונה אצלנו, בתנאים לא אופטימליים, בלשון המעטה.
בסיבוב השני (לאחר חודשים), התמקדנו באנשים עם ניסיון ברור במה שהם עומדים לעשות. אנשים שכבר עשו את זה, ועשו את זה טוב. למשל: מפתחים - העדפנו שכבר עבדו בסביבת SaaS ופרודקשיין. ה״אש בעיניים״ כבר הייתה פחות שכיחה.
לאחר חודשים הבנו את התוצאות - והן היו טובות יותר, אבל לא עמדו בציפייה. יחסית למאמץ האדיר שהשקענו - עדיין קיבלנו עובדים שלרבים מהם לקח זמן להסתגל - והם היו זקוקים לכמות נכבדת של תמיכה לאורך זמן.
תאוריה (מרשימה), וניסיון - לחוד. זה הניסיון שלי.
הייתי ממליץ להתמקד באנשים שכבר התמודדו עם סוג האתגרים שעומדים בפניהם, ואולי קצת הלאה - ונמנע מלנסות ו״להצמיח אנשים מוכשרים ומלאי מוטיבציה״ לתפקיד. עדיין - הגיוס נראה לי כשלב הכרחי, אך לא מספיק על מנת להתמודד עם צמיחה-חריגה.
Guidelines and Standardization
הנה משהו מפחיד. רואים את המילים הללו למעלה? אלו מילים של Enterprise, של Coroporate.
אחד החששות בחברה קטנה הצומחת בקצב חריג - הוא ההפיכה ל Corporate במהירות ובלי לשים לב, ולכן הסממנים והסמלים של ה Corporate מעוררים בחלק מהעובדים תחושת חוסר-נעימות ברורה (Myself Included).
מצד שני, כאשר חצי מהעובדים הם חדשים, איך משמרים תרבות הנדסית? ידע? פרקטיקות וניסיון? כנראה ש Guidelines וסטנדרטיזציה הם כלים חשובים ומשמעותיים.
קחו את הפרקטיקות העיקריות שעברו עד עתה מפה-לאוזן, ונסחו אותם בכתב. הפנו אליהם עובדים חדשים - ובקשו מהם לאמץ אותם כמיטב יכולתם.
אני רוצה להמליץ בחום על כמה עקרונות בניסוח Guidelines שכאלו, בכדי לא לקחת מה "Corporate״ גם את הצדדים השליליים שלו:
- נסו לקצר כמה שיותר. אם יש ספק - קצרו. מקסימום השלימו אח״כ.
- נסו להצמיח את ה Guidelines מתוך השטח, בסיוע המפתחים הותיקים, הותיקים למחצה, וגם הצעירים - שמעוניינים בזה. התהליך נועד לתעד את הקיים והמוצלח, אבל גם אפשר לשפר אותו ״על הדרך״.
- אמצו גישה של ״Fail Open״: במקרים בהם לא ברור מה Guidelines כיצד יש לפעול, אפשרו חופש פעולה. אם המקרה חוזר על עצמו - תקננו את זה. אל תעכבו אף אחד כי ״זה לא מכוסה ע״י ה Guideline״.
את הגישה הזו התחלנו לאחרונה ב Next-Insurance. סה״כ אנשים תומכים בכיוון, ומספר עובדים חדשים הצהירו שזה מה שהם היו מצפים לו. אני מניח שעוד כחצי שנה - אוכל לתת הערכה יותר משמעותית על הגישה הזו, ספציפית, בהתמודדות עם צמיחה-חריגה.
סיכום
עם השנים יותר ויותר כסף זורם לחברות סאטראט-אפ מה שמאפשר להן (ומאלץ אותן) לצמוח בקצבים שהתעשייה עדיין לא רגילה בהם ככלל.
אלו פרקטיקות ותהליכים המגמה הזו תפתח?
האם ימשיכו לצמוך בקצבים יותר ויותר מהירים?
אני מקווה שהפוסט הצליח לשתף כמה תובנות על התהליך, וכמה כלים נפוצים - להתמודדות עם מצב של צמיחה-חריגה.
שיהיה בהצלחה!
