בואו נסתכל על זה ביחד:

יוז קייס ראשון

ב-Shopify בנו משהו שנקרא River. סוכן AI שחי ב-Slack של החברה ועושה הכל: קורא קוד, מריץ טסטים, פותח pull requests, מגיע לנתוני הפרודקשן. ב-30 הימים האחרונים השתמשו בו 5,938 עובדים. אחד מכל שמונה pull requests שמורג'ג'ו נכתבו על River.

מרשים, אבל יותר מרשים זה מה שגורם לו להשתפר: אחוזי ה-merge עלו מ-36% ל-77% בחודשיים בלי שאימנו מחדש אף מודל. הסיבה: עובדים צפו ב-River עובד, ראו איפה הוא נתקע ועזרו לו עם הידע שחסר לו. כל צוות הכניס לתוכו את הסטנדרטים שלו, את הכלים שהוא עובד איתם, את האופן שבו הוא חושב על הבעיות שלו.

טובי לטקה, מנכ"ל שופיפיי, ניסח את זה ככה : "The agent gets better at being Shopify."

ב-River ידע שנשאר פרטי לא עוזר לאיש. טובי אמר את זה ישירות: "The company moves at the speed of its slowest secret."

יוז קייס שני

ב-Ramp, חברת פינטק אמריקאית, ראיתי את אותו הדבר מזווית שונה: החברה דיווחה שהגיעה ל-99% הטמעת AI בקרב כל העובדים. אחד הדברים שהם עשו כדי לגרום לזה לקרות הוא לבנות marketplace פנימי שנקרא Dojo.

הרעיון: כשמישהי בצוות הסיילס מגלה workflow מצוין לנתח שיחות לקוח ולייצר battlecards, – היא אורזת אותו כ-skill ומפרסמת. מאותו רגע כל עובד אחר בחברה יכול להשתמש בו. כל skill עובר code review ו-versioning כמו קוד רגיל, ומהרגע שעלה הוא הופך לסטנדרט מקצועי של הדומיין.

פייננס, דיזיין, אופריישן, סיילס, כל דומיין בונה את הבסיס המשותף שלו.

מה שני הסיפורים האלה מלמדים >

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

גילדה היא שכבה משותפת

גילדות הן לא פורמט חדש. מה שחדש הוא מה שה-AI דורש מהן להיות היום.

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

מה שקורה עכשיו הוא שיש לגילדה שני קהלים במקום אחד: אנשי המקצוע עצמם, והאיג'נטים שעובדים איתם.

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

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

ככל שתרצו יותר אוטונומיה, תצטרכו יותר תשתיות

זה הפרדוקס שלא כולם שמים לב אליו.

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

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

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

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

זה לא תהליך קצר. אבל זה ההבדל בין ארגון שמדבר על עתיד ה-builders לבין ארגון שבונה את התשתיות שמאפשרות אותו.

הפוסט הגילדה מייצרת תשתיות לאנשים ול-AI הופיע לראשונה ב-Glue.

מדובר בחברת פינטק אמריקאית ששווה 32 מיליארד דולר, עם כ-2,000 עובדים ומעל מיליארד דולר הכנסות בשנה, ואצלם כולם נקראים Builders. אין FE, דאטה או אנליסטים, כולם בילדרים.

כשחברה מדווחת על 99% הטמעת AI, הדבר הראשון שחושבים עליו הוא תרבות, מוטיבציה, אולי תוכניות לרנינג איכותיות. אבל הבעיה שRamp גילו הייתה פשוטה יותר: סביבת העבודה דרשה terminal windows, npm installs והגדרות MCP ידניות. עובדים שאינם טכניים פשוט לא יכלו להתחיל כי הכניסה הייתה טכנית מידי.

התובנה שלהם: הגורם המגביל בהטמעת AI הוא לא עוצמת המודל. הוא היכולת של העובד להתנסות ולעבוד בעצמו עם המודלים.

הדבר הראשון שהם בנו הוא סביבת עבודה בשם Glass. עובד נכנס דרך ה-SSO הרגיל של החברה, ומהרגע שהוא לוגד-אין הכל כבר מחובר: Gong, Salesforce וכל המערכות הפנימיות. אפס הגדרות, אפס טיקטים ל-IT.

מה שמעניין הוא מה שהם לא עשו: לא "דאמי-פרופד" את הסביבה. הם הורידו חיכוך בלי להוריד יכולת. Power users עדיין מקבלים multi-window workflows ואינטגרציות עמוקות. הכניסה קלה, אבל התקרה נשארת גבוהה. אנשי הסיילס יכולים לבקש מ-Glass למשוך הקשר משיחת Gong, להעשיר אותו בנתונים מ-Salesforce ולכתוב follow-up, הכל בלי לצאת מהסביבה.

הדבר השני הוא מנוע המלצות בשם Sensei. כדי להבין למה הוא נחוץ, צריך להבין קודם מה יש ב-Dojo.

Dojo הוא marketplace פנימי עם מעל 350 skills. לכאורה מרשים, בפועל יכול להיות בדיוק הבעיה: ספרייה של 350 פריטים שאף אחד לא מוצא בה כלום. Sensei הוא מה שמונע את זה. הוא לומד את התפקיד שלך, את הכלים שמחוברים אצלך, ואת מה שעסקת בו לאחרונה, ומתאים לך skills רלוונטיים באופן שוטף. לא רק ביום הראשון אלא כל יום מחדש. Account manager חדש לא מסתכל על 350 skills, הוא רואה את החמישה שרלוונטיים לשבוע הפתיחה שלו.

אבל הדבר השלישי הוא מה שבאמת תפס אותי.

הם בנו marketplace פנימי שנקרא Dojo. הרעיון פשוט: כשמישהי בצוות הסיילס מגלה workflow מצוין לנתח שיחות לקוח ולייצר battlecards, היא אורזת אותו כ-skill ומפרסמת. מאותו רגע כל עובד אחר בחברה יכול להשתמש בו, וכמובן גם לפרסם skills משלו. כל skill שעולה עובר code review ו-versioning כמו כל קוד אחר בחברה, ומאותו רגע הוא הופך לסטנדרט מקצועי של הדומיין.

פייננס, דיזיין, אופריישן, סיילס, כל דומיין בונה את הבסיס המשותף שלו.

מה שהם יצרו בפועל זו שכבה שלמה של סטנדרטים מקצועיים שנבנתה מלמטה, לפי דומיינים, על ידי האנשים שעושים את העבודה בפועל.

Glass הורידה את חסם הכניסה.

Sensei הפכה ספרייה גדולה לכלי שניתן לעבוד איתו.

Dojo הפך את הידע הפרטי לתשתית משותפת.

זה לא תהליך קצר. הוא גם לא פשוט. אבל זה ההבדל בין ארגון שמדבר AI לארגון שבונה את התשתיות שיאפשרו לעובדים באמת להשתמש ב-AI.

הפוסט הסיפור של Ramp: כשכל עובד/ת בפיתוח הוא Builder הופיע לראשונה ב-Glue.

מה לא עובד (ולמה כולנו עושים את זה)

מיתוס הדיפוזיה הטבעית

רבים מאמינים שאם צוות אחד יריץ פיילוט AI מוצלח, הידע "ידלוף" באופן טבעי לצוותים אחרים. המחקר מראה שזה פשוט לא קורה. ידע לא מתפשט בצורה אקראית בשיחות מסדרון. הוא דורש ערוצי הפצה מכוונים ומבניים.

המחקר מזהה את התופעה הזו כ"רשתות סגורות" – קהילות מומחים שמחזיקות את הידע בפנים ולא מעבירות אותו הלאה. הם לא עושים את זה בכוונה כמובן, זה קורה בעיקר כי אין תשתית לשיתוף.

כשל ה"מנדט מלמעלה"

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

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

מה כן עובד: כוח הקרבה הקוגניטיבית

המחקר מזהה מנגנון חזק אחד שכן מבטיח הפצת ידע: Peers בקרבה קוגניטיבית.

הכוונה לחיבורים אמיתיים בין Peers עם שפה מקצועית משותפת (טרמינולוגיה, מתודולוגיות, כלים), רקע טכנולוגי דומה, אמון והזדמנות לשיתוף בידע מעשי. שם הידע זורם, הופך לפרקטיקה ומשם גם יכול להתפשט הלאה.

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

גילדות מקצועיות הן ה-API האנושי הטוב ביותר

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

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

זו לא העברת מידע חד-כיוונית אלא רשת למידה מתפתחת שיוצרת knowledge base עשיר ורלוונטי לכל המשתתפים.

אז אמנם המחקר עצמו לא היה על גילדות או על קהילות מקצועיות, אבל התוצאות שלו מהדהדות את מה שאני רואה בשטח: אם אתם באמת רוצים שהידע על AI לא ייתקע במצגת או בפיילוט צדדי, תנו לגילדות שלכם לעבוד – הן ה־API האנושי הכי טוב שיש לארגון.

הפוסט איך באמת מטמיעים AI בארגונים ולמה גילדות הן המפתח להצלחה הופיע לראשונה ב-Glue.

בסדנת סרגל מעורבות אנחנו עושים סדר במה מודדים ומה לא, ובהתאם לזה בונים את הסרגל מעורבות הספציפי לכל קהילה. הכלי שבניתי ב base44 גמיש: הוא מאפשר למובילי קהילות להגדיר איך נראים ביטויים של מעורבות בקהילות שלהם. והוא גמיש כי מעורבות זה לא one size fits all, מה שאומר שהדרך למדוד מעורבות צריכה להתאים בדיוק בדיוק למאפיינים של קהילה ספציפית.

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

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

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

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

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

הפוסט כלי דיגיטלי למדידת מעורבות בקהילה הופיע לראשונה ב-Glue.

כמו בכל סיפור טוב, זה קרה אי שם במעבר מסטארטאפ קטן, לארגון גדול, וכל כאבי הגדילה הנלווים לזה.

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

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

• מפגישה נציגים מכל הצוותים כדי לשתף ידע, לפתור יחד אתגרים טכנולוגיים, ולעבוד על יוזמות חוצות-ארגון.
• מגדירה את עקרונות העבודה לכל המהנדסים והמהנדסות, ויוצרת שפה משותפת.
• נותנת לאנשים אפשרות להשקיע 20% מהזמן שלהם ב־Guild Task Pool כדי להוביל שיפורים בקוד ובתשתיות בלי לחכות שמישהו מלמעלה יאשר.
• שמה בפרונט את המצויינות של המהנדסים שלהם – סיגנל שהם שלחו לכל החברה כשהם התחילו להיפגש באופן-ספייס של המשרדים במקום בחדרי ישיבות קטנים ומרוחקים.

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

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

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

בסוף, גם מהנדסים צריכים קהילה – ובמקרה הזה HoneyBook בנו גילדה מצויינת שמאפשרת לארגון כולו לרוץ מהר יותר, ועוזרת למהנדסים להרגיש שהם הגיע לבית המקצועי שלהם.

הפוסט איך HoneyBook הקימו גילדת Engineering שעזרה להם ליצור סטנדרטים בלי לוותר על קצב עבודה גבוה הופיע לראשונה ב-Glue.