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

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

רבים מאמינים שאם צוות אחד יריץ פיילוט 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.