حالت بنیانگذار در اصل یک مسئله طراحی سازمانی است
عبارت founder mode خیلی سریع فراگیر شد چون شبیه یک نظریه شخصیتی به نظر میرسد. انگار شرکتها به دو گروه تقسیم میشوند: بنیانگذارانی که نزدیک محصول میمانند و مدیرانی که فاصله، جلسه و فرایند اضافه میکنند. اما این تصویر برای استفاده عملی خیلی سطحی است. موضوع واقعی، طراحی سازمانی است.
چیزی که بنیانگذاران معمولاً به آن واکنش نشان میدهند، صرفاً وجود مدیریت نیست. آنها به حلقههای بازخورد خراب، تصمیمگیری کند و لایههای ترجمه بین مشتری، محصول و افراد دارای اختیار واکنش نشان میدهند. از این منظر، بحث founder mode در اصل درباره این است که استارتاپها چگونه باید ارتباطات و کنترل را در زمان رشد ساختاربندی کنند و چه زمانی بدون کشتن سرعت محصول، فرایند اضافه کنند.
Founder mode معمولاً شکایتی درباره تأخیر است
در یک استارتاپ اولیه، بنیانگذار اغلب در کوتاهترین حلقه ممکن قرار دارد. مشتری میگوید onboarding گیجکننده است، پشتیبانی همان روز آن را میشنود، بنیانگذار همان شب میبیند و تیم همان هفته اصلاح میکند. این حلقه شاید شلوغ و احساسی باشد، اما سریع است. با رشد شرکت، همان سیگنال ممکن است از پشتیبانی، عملیات، مدیریت محصول، بازبینی طراحی، برنامهریزی و گزارشدهی اجرایی عبور کند تا تغییری رخ دهد.
به همین دلیل بسیاری از بحثهای founder mode اینقدر احساسی هستند. بنیانگذار کندی را میبیند و آن را بهعنوان انحراف سازمانی تجربه میکند. تیمها بهجای یادگیری از مشتری، شروع میکنند به بهینهسازی برای تأیید، اسلایدهای همراستاسازی و مرزهای نقش.
سؤال اصلی بنیانگذار در برابر مدیر نیست
نسخه اینترنتی این بحث اشتباه میکند چون بنیانگذاران و مدیران را دو تیپ متضاد میبیند. در واقع مدیران خوب معمولاً کسانی هستند که سیستم را قابل فهم نگه میدارند. آنها اولویتها را روشن میکنند، سربار هماهنگی را جذب میکنند و به متخصصان کمک میکنند سریعتر حرکت کنند. مدیریت بد کار را کند میکند، اما آشفتگی بنیانگذار هم همینطور.
سؤال بهتر این است: چه کسی به واقعیت نزدیکتر است، واقعیت با چه سرعتی در شرکت حرکت میکند و چه کسی میتواند بدون تأخیر غیرضروری بر اساس آن عمل کند؟
حلقههای بازخورد از خطوط گزارشدهی مهمترند
بهترین استارتاپها حول حلقهها طراحی میکنند، نه فقط عنوانها. آنها مطمئن میشوند افرادی که محصول را میسازند درد مشتری را مستقیم میشنوند. معیارها را نزدیک تیمهایی نگه میدارند که میتوانند آنها را تغییر دهند. تعداد handoffها را بین مشاهده و اقدام کم میکنند.
مثلاً یک استارتاپ B2B SaaS که از 25 نفر به 120 نفر میرسد، دیگر نمیتواند انتظار داشته باشد بنیانگذار در همه تماسهای فروش و همه تصمیمهای محصول باشد. پاسخ اشتباه این است که بنیانگذار کاملاً حذف شود و فقط به داشبورد و مرورهای فصلی تکیه شود. پاسخ درست، ساختن exposure ساختاریافته است: مرور هفتگی مشتری، نمونهبرداری مستقیم از تیکتها، دموهای کوتاه محصول با داده واقعی استفاده و مسیرهای escalation روشن.
فرایند زمانی مفید است که هماهنگی را فشرده کند
استارتاپها گاهی طوری درباره فرایند حرف میزنند که انگار ذاتاً بد است. اینطور نیست. فرایند خوب، سردرگمی تکراری را کم میکند. مشخص میکند چه کسی تصمیم میگیرد، چه شواهدی مهم است و تیمها چگونه بدون escalation دائمی هماهنگ شوند. اشتباه زمانی رخ میدهد که فرایند، مسیر بین سیگنال و اقدام را طولانیتر کند.
چکلیست ساده لانچ میتواند جلوی خطاهای قابل پیشگیری را بگیرد. اما ritual برنامهریزی که برای یک تست کوچک قیمتگذاری شش تأیید میخواهد، احتمالاً مفید نیست.
استارتاپها چه زمانی باید لایههای مدیریتی اضافه کنند
لایههای مدیریتی وقتی ارزشمند میشوند که بیش از آنکه latency اضافه کنند، کیفیت تصمیم و ظرفیت اجرا را بالا ببرند. این معمولاً وقتی رخ میدهد که بنیانگذار دیگر نتواند بین تعداد زیادی حوزه context switch مؤثر انجام دهد، یا وقتی چند تیم باید حول سیستمها و وابستگیهای مشترک هماهنگ شوند.
اما اضافه کردن هر لایه باید با یک آزمون طراحی همراه باشد. این لایه چه تصمیمهایی میگیرد؟ چه اطلاعاتی را مستقیم دریافت میکند؟ کدام جلسهها یا تأییدها را حذف میکند؟ اگر یک لایه جدید فقط برای انتقال اطلاعات به بالا و پایین وجود دارد، احتمالاً بهجای اهرم، اصطکاک میسازد.
سه نشانه هشدار که سازمان خودش را کند کرده است
اول، تیمها برای بازیابی context به جلسههای بیشتری نیاز دارند، در حالی که اهداف، داشبوردها یا شواهد مشتری باید کافی میبود. دوم، تصمیمهای مهم محصول منتظر بازبینی ارشد میمانند چون مالکیت روشن نیست. سوم، سیگنالهای خط مقدم هنگام حرکت به بالا ضعیف میشوند و رهبری بهجای الگوهای خام، خلاصههای تمیزشده میبیند.
Founder mode چه چیزی را درست میبیند
غریزه مفید در founder mode این است که استارتاپها با سریعتر یاد گرفتن از incumbents برنده میشوند. اگر رشد باعث فاصله گرفتن شرکت از واقعیت شود، شرکت زودتر از سنش پیر عمل میکند. بنیانگذاران حق دارند نگران شوند وقتی رهبران محصول با کاربران صحبت نمیکنند، وقتی مدیران بیشتر reportها را مدیریت میکنند تا outcomeها، یا وقتی تیمها از گرفتن تصمیمهای کوچک بدون تأیید اجرایی میترسند.
شرکتها حالا باید چه کار کنند
latency تصمیمگیری خود را audit کنید. پنج تغییر اخیر محصول یا عملیات را انتخاب کنید و ببینید از اولین سیگنال تا رسیدن به تیمی که میتوانست اقدام کند چقدر طول کشیده است. سپس منشأ تأخیر را پیدا کنید: داده ناکافی، مالکیت مبهم، تأییدهای زیاد یا لایههای مدیریتی که بهجای تصمیمگیری فقط ترجمه میکنند. جلسههایی را که فقط اطلاعات موجود را تکرار میکنند حذف کنید. فقط جایی فرایند اضافه کنید که از خطاهای تکراری جلوگیری کند یا اجرای مستقلتر را ممکن سازد.