کمتر سازمانی را می‌شناسیم که با رشد، ساختارش هم سالم بماند. معمولاً ماجرا از جایی شروع می‌شود که کسی می‌گوید کار زیاد شده و باید یک نفر دیگر هم بیاید. بعد یک مدیر جدید وارد می‌شود، یک سرپرست اضافه می‌شود و جلسه‌ای برای هماهنگی بین دو واحد تعریف می‌شود. مدتی بعد، کاری که قبلاً با یک گفت‌وگوی کوتاه انجام می‌شد، حالا باید از سه جلسه، دو تأیید و یک فرم هماهنگی بین واحدها عبور کند.
هیچ‌کدام از این تصمیم‌ها در لحظه‌ی خودشان بی‌منطق نیستند. هرکدام دلیلی دارند. اما وقتی همه‌ی آن‌ها کنار هم جمع می‌شوند، نتیجه‌ای پیش می‌آید که کمتر کسی قصدش را داشته: نمودار سازمانی بزرگ‌تر شده، ولی توان سازمان برای تصمیم‌گیری سریع کوچک‌تر شده است. هر بار که حجم کار بالا می‌رود، بخشی از ساختار هم بزرگ‌تر می‌شود، تا جایی که خود ساختار مانع رشد می‌شود.
پرسش اصلی این است: آیا رشد سازمان حتماً باید به معنای افزودن لایه و پیچیده‌تر شدن ساختار باشد؟ پاسخ کوتاه این است که نه. ساختار سازمانی توسعه‌پذیر، ساختاری نیست که از اول برای همه‌ی احتمالات آینده طراحی شده باشد. ساختاری است که بتواند بر اساس نیاز واقعی کسب‌وکار، در زمان مناسب و بدون بازطراحی گسترده، رشد کند.
چنین ساختاری قرار نیست امروز همه‌ی ظرفیت آینده را به شکل پست‌های خالی و واحدهای بی‌کار در خودش نگه دارد. قرار است طوری طراحی شود که وقتی حجم فعالیت، تنوع محصولات، تعداد مشتریان یا گستره‌ی جغرافیایی تغییر کرد، بتوان با کمترین اختلال، ظرفیت موردنیاز را به آن اضافه کرد. این تفاوت، نگاه به طراحی ساختار را از پیش‌بینی همه‌ی نیازهای آینده، به آماده‌سازی سازمان برای پاسخ‌گویی به تغییرات آینده می‌برد.
وقتی رشد کسب‌وکار، ساختار را دنبال خود می‌کشد
فرض کنید شرکتی خدماتی با ۴۰ نفر نیرو فعالیت می‌کند. مدیرعامل مستقیماً با چند مدیر و مسئول اصلی در ارتباط است و تصمیم‌های مهم بدون عبور از مسیرهای طولانی گرفته می‌شوند. این وضعیت ساده و چابک است، اما دوام زیادی ندارد.
با رشد شرکت، تعداد مشتریان بیشتر می‌شود. تیم عملیات بزرگ‌تر می‌شود، فروش به چند بخش تقسیم می‌شود و سازمان وارد خدمات تازه‌ای می‌شود. در ابتدا مدیرعامل بخشی از مسئولیت‌ها را به مدیران واگذار می‌کند. بعد هر مدیر برای اداره‌ی تیم خودش به یک سرپرست نیاز پیدا می‌کند. سرپرست‌ها هم برای هماهنگی با یکدیگر به جلسات مشترک و سازوکارهای تازه احتیاج پیدا می‌کنند. وقتی اختلاف‌نظرها بیشتر می‌شود و تصمیم‌ها معطل می‌مانند، یک لایه‌ی تازه برای نظارت یا هماهنگی ساخته می‌شود.
از بیرون، سازمان حرفه‌ای‌تر به نظر می‌رسد. اما شاید چیز دیگری در حال رخ دادن باشد: ساختار، به جای آنکه رشد کسب‌وکار را آسان کند، دارد برای مدیریت پیچیدگی‌هایی که خودش ساخته، پیچیده‌تر می‌شود.
البته ساختن لایه‌ی مدیریتی همیشه اشتباه نیست. با افزایش تعداد نیروها، گسترده‌تر شدن عملیات یا بالا رفتن ریسک تصمیم‌ها، گاهی واقعاً به مدیر جدید و تفکیک روشن‌تر مسئولیت‌ها نیاز است. مشکل از جایی شروع می‌شود که هر افزایش حجم کار، به‌طور خودکار به ساخته شدن یک پست مدیریتی یا یک واحد مستقل منجر شود.
ساختار توسعه‌پذیر باید بتواند بین افزایش ظرفیت اجرایی و افزایش پیچیدگی مدیریتی فرق بگذارد. گاهی سازمان به نیروی اجرایی بیشتر نیاز دارد، نه به مدیر جدید. گاهی به تخصصی نیاز دارد که باید میان چند تیم به اشتراک گذاشته شود، نه اینکه واحدی مستقل با همه‌ی هزینه‌های مدیریتی‌اش ساخته شود. و گاهی هم واقعاً زمان ساختن یک واحد یا لایه‌ی جدید فرا رسیده است. تشخیص این تفاوت‌ها، قلب کار طراحی ساختار است.
طراحی برای امروز، قابلیت تغییر برای فردا
یکی از خطاهای رایج، تلاش برای ساختن سازمانی است که از همین امروز، همه‌ی نیازهای چند سال آینده را پوشش دهد. شرکتی را در نظر بگیرید که قصد ورود به دو بازار جدید دارد. ممکن است همین حالا برای هر بازار یک مدیر، چند زیرمجموعه و مجموعه‌ای از پست‌های تخصصی تعریف کند، در حالی که هنوز حجم فعالیت، درآمد، تعداد مشتری و پیچیدگی عملیاتی آن بازارها روشن نیست. نتیجه این است که سازمان پیش از آنکه نیاز واقعی شکل بگیرد، هزینه و پیچیدگی ساخته است.
رویکرد توسعه‌پذیر متفاوت است. ساختار باید بر اساس نیازهای واقعی امروز طراحی شود، اما مسیرهای توسعه‌ی آینده هم در طراحی دیده شوند. به جای ساختن سه واحد مستقل برای سه بازار احتمالی، می‌شود یک ساختار متمرکز با مسئولیت‌های روشن طراحی کرد که اگر حجم فعالیت بالا رفت، قابلیت تفکیک به چند واحد را داشته باشد. در این حالت، سازمان از اول می‌داند چه زمانی و بر اساس چه معیارهایی باید ساختار را بزرگ کند، اما تا وقتی نیاز واقعی شکل نگرفته، منابع و هزینه‌های مدیریتی را روی ساختار سنگینی نمی‌کند.
این یعنی آینده نادیده گرفته نمی‌شود. آینده در طراحی حاضر است، فقط نه به شکل پست‌های زودهنگام، بلکه به شکل مسیرهای مشخص برای توسعه.
منطق کسب‌وکار، نه تعداد آدم‌ها، مبنای تفکیک است
یکی از مهم‌ترین تصمیم‌ها در طراحی ساختار توسعه‌پذیر، تعیین مبنای تفکیک واحدهاست. آیا باید آدم‌ها را بر اساس تخصص‌شان سازمان داد؟ بر اساس محصول، مشتری، منطقه‌ی جغرافیایی یا فرآیند؟ هیچ‌کدام از این گزینه‌ها به‌تنهایی جواب همیشگی نیستند. انتخاب درست به مدل کسب‌وکار، مزیت رقابتی، تنوع محصولات و خدمات، نیاز مشتری و میزان وابستگی فعالیت‌ها بستگی دارد.
یک شرکت با چند محصول شبیه و مشتریان مشترک، احتمالاً از ساختار تخصص‌محور و متمرکز سود می‌برد. اما اگر هر محصول بازار، مشتری و مدل عملیاتی متفاوتی داشته باشد، تفکیک مسئولیت‌ها بر اساس محصول می‌تواند تصمیم‌گیری و پاسخ‌گویی را بهتر کند.
مثلاً یک تولیدی با سه خط تولید را در نظر بگیرید که هر سه از یک انبار و یک واحد کنترل کیفیت استفاده می‌کنند. اگر این تولیدی هر خط را به واحدی مستقل با مدیر، حسابدار و برنامه‌ریز اختصاصی تبدیل کند، پیش از آنکه ترتیب کار را بفهمد، دو برابر هزینه‌ی هماهنگی پرداخته است. اما اگر مشتریان هر خط نیازهای کاملاً متفاوتی داشته باشند و زمان‌بندی‌ها با هم تداخل نداشته باشند، همان تفکیک می‌تواند کیفیت و سرعت را بالا ببرد. تصمیم درست، به منطق کار بستگی دارد، نه به اینکه چند نفر روی هر خط کار می‌کنند.
اشتباه وقتی رخ می‌دهد که ساختار فقط بر اساس تعداد فعلی افراد شکل بگیرد. مثلاً چون یک تیم به ۱۲ نفر رسیده، یک مدیر جدید برای تقسیم آن به دو گروه ساخته می‌شود، بدون اینکه تفاوتی در مأموریت، نوع فعالیت، خروجی یا نیاز به تصمیم مستقل وجود داشته باشد. در چنین شرایطی، سازمان به جای حل یک مسئله‌ی واقعی، فقط یک لایه‌ی مدیریتی تازه اضافه کرده است.
در طراحی توسعه‌پذیر، هر واحد باید ماموریت مشخص، خروجی قابل تعریف و مرز مسئولیت روشن داشته باشد. اگر دو واحد عملاً خروجی مشابهی تولید می‌کنند، دائماً بر سر منابع مشترک رقابت دارند یا تصمیم‌های هم را تکرار می‌کنند، احتمالاً مشکل در منطق تفکیک ساختار است، نه در کمبود آدم.
واحدهای متمرکز یا تیم‌های مستقل؟
تصمیم دیگر این است که کدام قابلیت‌ها باید در واحدهای تخصصی متمرکز بمانند و کدام‌ها باید در اختیار تیم‌های مستقل قرار بگیرند. فرض کنید سازمان به تحلیل داده، طراحی تجربه‌ی مشتری و مدیریت پروژه نیاز دارد. آیا باید برای هرکدام واحدی مستقل بسازد و در صورت رشد، همان واحدها را بزرگ‌تر کند؟ یا بهتر است در مرحله‌ی اول این قابلیت‌ها را به شکل متمرکز بسازد تا چند تیم از آن‌ها استفاده کنند؟
پاسخ به میزان تقاضا، اهمیت استراتژیک قابلیت، نیاز به تخصص، سرعت موردنیاز و هزینه‌ی هماهنگی بستگی دارد. گاهی متمرکز نگه داشتن یک تخصص باعث می‌شود منابع بهتر استفاده شوند و کیفیت حفظ شود. گاهی هم فاصله گرفتن آن تخصص از تیم‌های اجرایی، سرعت تصمیم‌گیری را پایین می‌آورد و ناچار باید ظرفیت اختصاصی در تیم‌ها ایجاد شود. ساختار توسعه‌پذیر باید بتواند این تغییر را مدیریت کند.
مثلاً ممکن است تحلیل داده در ابتدای مسیر، یک تیم متمرکز باشد. اما با افزایش تعداد محصولات و پیچیده‌تر شدن تصمیم‌ها، بخشی از ظرفیت تحلیلی به تیم‌های محصول منتقل شود، در حالی که استانداردها، معماری داده و برخی تخصص‌های کمیاب همچنان متمرکز بمانند. در این حالت، سازمان لازم نیست کل ساختارش را از اول طراحی کند. فقط نحوه‌ی توزیع یک قابلیت را متناسب با نیاز جدید تغییر می‌دهد.
مرز مسئولیت‌ها؛ زیرساختی که رشد را ممکن می‌کند
وقتی سازمان کوچک است، آدم‌ها معمولاً با یک گفت‌وگوی مستقیم ابهام‌ها را برطرف می‌کنند. اما با زیاد شدن تیم‌ها، اتکا به روابط شخصی و هماهنگی‌های غیررسمی سخت‌تر می‌شود. اگر مرز مسئولیت‌ها روشن نباشد، توسعه‌ی سازمان به افزایش تعارض‌ها ختم می‌شود.
دو مدیر ممکن است هرکدام فکر کند تصمیمی در اختیار دیگری است. یک فعالیت ممکن است بین دو واحد بی‌صاحب بماند. یا چند تیم هم‌زمان برای حل یک مسئله وارد عمل شوند، بی‌آنکه معلوم باشد مسئولیت نهایی با کیست. در چنین وضعیتی، سازمان اغلب با ساختن نقش هماهنگ‌کننده یا لایه‌ی مدیریتی تازه جواب می‌دهد، در حالی که مشکل اصلی شاید کمبود مدیر نباشد، بلکه ابهام در مسئولیت و اختیار باشد.
تصور کنید فروش برای مشتری تعهد تحویل دو هفته‌ای می‌دهد، اما واحد عملیات برنامه‌ی تولید خودش را دارد و کسی هم اختیار تغییر اولویت‌ها را ندارد. هر دو واحد درست کار می‌کنند، اما نتیجه‌ی نهایی یک نارضایتی تکراری است. تشکیل یک کمیته‌ی هماهنگی یا گذاشتن یک مدیر میانی شاید این مشکل را موقتاً بپوشاند، ولی ریشه‌ی آن در این است که چه کسی حق دارد برای تحویل تصمیم بگیرد.
ساختار توسعه‌پذیر باید برای هر نقش و واحد، مأموریت، خروجی، اختیارات و روابط کاری مشخصی تعریف کند. این شفافیت باعث می‌شود سازمان بتواند تیم تازه اضافه کند، یک واحد را به دو بخش تقسیم کند یا بخشی از فعالیت‌ها را به واحد دیگری بسپارد، بدون اینکه همه‌ی روابط سازمانی از نو تعریف شوند. ساختاری که مسئولیت‌هایش روشن است، راحت‌تر رشد می‌کند، چون تغییر در تعداد افراد لزوماً به تغییر در همه‌ی روابط منجر نمی‌شود.
چه زمانی واقعاً باید ساختار را توسعه داد؟
اگر قرار است ساختار بر اساس نیاز واقعی رشد کند، باید روشن باشد این نیاز چطور تشخیص داده می‌شود. افزایش تعداد کارکنان به‌تنهایی معیار کافی نیست. گاهی یک تیم پانزده نفره به خاطر تنوع فعالیت‌ها، پراکندگی جغرافیایی یا ریسک بالای تصمیم‌ها به تفکیک نیاز دارد، در حالی که تیم دیگری با سی نفر هنوز می‌تواند با یک مدیر و فرآیندهای روشن کار کند.
برای تصمیم‌گیری درباره‌ی توسعه‌ی ساختار، می‌توان چند دسته شاخص را بررسی کرد. اول حجم و تنوع کار است: آیا فعالیت‌ها از ظرفیت قابل مدیریت تیم بیرون زده‌اند؟ آیا آن‌قدر متفاوت شده‌اند که مدیریت مستقل بخواهند؟ دوم کیفیت و سرعت تصمیم‌گیری است: آیا تصمیم‌ها به خاطر دامنه‌ی بیش‌ازحد مسئولیت مدیران معطل می‌مانند؟ آیا مدیر فرصت کافی برای هدایت تیم و حل مسائل مهم دارد؟ سوم کیفیت خروجی است: آیا افزایش حجم کار، خطا، تأخیر در تحویل یا نارضایتی مشتری را بالا برده است؟ چهارم وابستگی‌های بین‌واحدی است: آیا هماهنگی بین فعالیت‌ها آن‌قدر پیچیده شده که ساختار فعلی جوابگو نیست؟ و در آخر هزینه و ارزش افزوده‌ی مدیریتی: آیا ساختن نقش یا واحد جدید مسئله‌ی واقعی را حل می‌کند و ارزشش از هزینه‌ی مستقیم و غیرمستقیم بیشتر است؟
بررسی این شاخص‌ها نباید یک‌باره و در شرایط بحرانی انجام شود. بهتر است هر سه یا شش ماه، با داده‌های ثابت و مقایسه‌ی روند، بازبینی شوند. اگر تأخیر تحویل سه دوره‌ی پشت سر هم بالا رفته و علتش در فرآیند نیست، آن موقع است که توسعه‌ی ساختار معنا پیدا می‌کند. اما اگر فشار فقط در یک هفته‌ی پرکار دیده شده، شاید بهتر باشد اول همان هفته‌ی شلوغ با جابه‌جایی موقت منابع مدیریت شود.
این شاخص‌ها کمک می‌کنند توسعه‌ی ساختار به تصمیمی قابل دفاع تبدیل شود، نه نتیجه‌ی فشارهای روزمره یا ترجیح شخصی یک مدیر. البته آستانه‌های عددی این شاخص‌ها باید با توجه به ماهیت کسب‌وکار تعیین شوند. تعداد افرادی که یک مدیر می‌تواند اداره کند، در محیطی با کارهای تکراری و استاندارد با محیطی تخصصی، پرریسک و وابسته به تصمیم‌های پیچیده یکسان نیست.
رشد مرحله‌ای، سیستم مدیریتی و هزینه‌ی پنهان
یکی از ویژگی‌های مهم ساختار توسعه‌پذیر، امکان توسعه‌ی مرحله‌ای آن است. فرض کنید یک کسب‌وکار تجارت الکترونیک تصمیم بگیرد فعالیت‌هایش را در چند گروه محصول گسترش دهد. در مرحله‌ی اول، یک تیم محصول شاید بتواند همه‌ی گروه‌ها را اداره کند. با بالا رفتن حجم کار، برای هر گروه یک مسئول تخصصی گذاشته می‌شود. بعدتر، اگر استقلال عملیاتی و نیاز به تصمیم‌گیری متفاوت زیاد شد، هر گروه می‌تواند به یک تیم محصول مستقل تبدیل شود.
مزیت این مسیر آن است که سازمان مجبور نیست ساختار نهایی را از اول حدس بزند. مسیر توسعه را مشخص می‌کند و در هر مرحله بر اساس شواهد تصمیم می‌گیرد. این موضوع به‌ویژه برای کسب‌وکارهایی مهم است که سرعت رشد یا مدل درآمدی‌شان هنوز تثبیت نشده است.
حالا اگر این ترتیب رعایت نشود چه پیش می‌آید؟ کسب‌وکاری که از روز اول چهار مدیر محصول مستقل می‌گذارد، معمولاً با دو مشکل روبه‌رو می‌شود. اول اینکه مدیرها برای جذب فروش و بودجه‌ی مشترک با هم رقابت می‌کنند. دوم اینکه وقتی حجم فروش یکی از محصولات کم است، آن مدیر هم برای خودش کار می‌سازد تا توجیه پست خودش باقی بماند. ساختاری که قرار بود کارها را سریع‌تر کند، حالا خودش به کندی و هزینه‌ی اضافی تبدیل شده است.
اما حتی بهترین طراحی ساختاری، اگر به فرآیندهای مدیریتی متصل نباشد، کم‌کم از شکل اولیه‌اش خارج می‌شود. اگر اولویت‌های سازمان روشن نباشند، هر واحد برای افزایش منابع و اختیار خودش استدلال مستقل دارد. اگر عملکرد و خروجی‌ها اندازه‌گیری نشوند، تشخیص نیاز واقعی به توسعه سخت می‌شود. و اگر مسئولیت‌ها شفاف نباشند، سازمان برای جبران ابهام، نقش‌های تازه‌ای می‌سازد. به همین دلیل، ساختار توسعه‌پذیر باید کنار چند سازوکار مدیریتی قرار بگیرد: هدف‌گذاری روشن و قابل پیگیری برای واحدها، تعریف خروجی و مسئولیت هر نقش، مدیریت عملکرد و ارزیابی ظرفیت واقعی تیم‌ها، فرآیندی مشخص برای تصویب پست و واحد جدید، بازبینی دوره‌ای ساختار با تغییر استراتژی و مدل کسب‌وکار، و شفافیت در اختیارات تصمیم‌گیری و روابط بین واحدها.
این یعنی تصمیم درباره‌ی ساختن یک پست جدید، فقط به این دلیل گرفته نمی‌شود که مدیر یک واحد درخواست نیروی بیشتر کرده است. اول باید بررسی شود مسئله چیست، چه گزینه‌هایی برای حلش وجود دارد و آیا ساختن نقش جدید بهترین پاسخ است یا نه. گاهی مسئله با حذف کارهای کم‌ارزش، بازطراحی فرآیند، اتوماسیون، توزیع بهتر کار یا روشن شدن مسئولیت‌ها حل می‌شود. در موارد دیگر، ساختن نقش یا واحد جدید کاملاً ضروری است. ساختار باید نتیجه‌ی تحلیل نیاز کسب‌وکار باشد، نه جایگزین آن.
پیامد ساختار نامناسب هم فقط افزایش هزینه‌ی حقوق و مزایا نیست. لایه‌های غیرضروری زمان تصمیم‌گیری را بالا می‌برند. یک تصمیم ساده که باید در یک روز گرفته شود، با عبور از سه لایه‌ی تأیید، یک هفته طول می‌کشد و در این فاصله، فرصت یا مشتری از دست می‌رود. این هزینه در صورت‌حساب‌ها دیده نمی‌شود، اما در عملکرد سازمان کاملاً محسوس است. علاوه بر این، فاصله‌ی مدیران ارشد از واقعیت عملیات بیشتر می‌شود و مسئولیت نهایی تصمیم‌ها مبهم می‌ماند.
از طرف دیگر، ساختاری که بیش‌ازحد فشرده باشد هم هزینه‌ی خودش را دارد. مدیران بیش از ظرفیتشان درگیر عملیات می‌شوند، تصمیم‌ها روی تعداد محدودی آدم متمرکز می‌ماند و سازمان برای توسعه‌ی فعالیت‌های تازه، به افراد کلیدی وابسته می‌شود. اگر یک نفر که همه‌ی قراردادهای مهم را می‌شناسد برود، کل سازمان لنگ می‌زند. پس هدف رسیدن به کمترین تعداد پست یا لایه نیست. هدف پیدا کردن تعادل میان سادگی، ظرفیت مدیریتی، تخصص و پاسخ‌گویی است. ساختار توسعه‌پذیر باید آن‌قدر ساده باشد که تصمیم‌ها سریع بمانند و مسئولیت‌ها روشن باشند، و آن‌قدر منعطف باشد که با پیچیده‌تر شدن واقعی کسب‌وکار، قابلیت‌های تازه را جذب کند.
از نمودار سازمانی تا معماری رشد
در نگاه سنتی، طراحی ساختار معمولاً با کشیدن نمودار سازمانی شروع می‌شود: مدیرعامل در بالا، مدیران در لایه‌ی بعد و واحدها و تیم‌ها پایین‌تر. اما در رویکرد توسعه‌پذیر، نمودار سازمانی فقط خروجی طراحی است. نقطه‌ی شروع، شناخت استراتژی، مدل کسب‌وکار، فعالیت‌های اصلی، خروجی‌های لازم، روابط بین واحدها و ظرفیت‌های لازم برای اجرای آن‌هاست.
بعد از آن، سازمان تصمیم می‌گیرد کدام مسئولیت‌ها کنار هم قرار بگیرند، کدام قابلیت‌ها متمرکز بمانند، چه اختیاراتی در هر سطح وجود داشته باشد و چه شرایطی توسعه‌ی ساختار را توجیه کند. در این نگاه، سازمان فقط نمی‌گوید امروز چه واحدهایی دارد. تعیین می‌کند اگر کسب‌وکار بزرگ‌تر شد، کدام بخش‌ها باید رشد کنند، کدام‌ها به استقلال نیاز پیدا می‌کنند و کدام‌ها بهتر است همچنان متمرکز بمانند. تفاوت یک نمودار سازمانی با یک معماری سازمانی توسعه‌پذیر دقیقاً همین است.
سازمانی که برای رشد مجبور نیست از نو ساخته شود
ساختار سازمانی توسعه‌پذیر قرار نیست همه‌ی تغییرات آینده را پیش‌بینی کند. چنین چیزی نه ممکن است و نه اقتصادی. هدف این است که سازمان بتواند بدون بازطراحی گسترده و بدون ساختن لایه‌های غیرضروری، به نیازهای تازه جواب بدهد.
برای رسیدن به این هدف، باید ساختار را بر اساس منطق کسب‌وکار طراحی کرد، مسئولیت‌ها و اختیارات را روشن نگه داشت، معیارهای توسعه را از قبل مشخص کرد و تصمیم‌های ساختاری را به داده‌های واقعی درباره‌ی حجم کار، عملکرد، ظرفیت و پیچیدگی فعالیت‌ها وصل کرد. در این نگاه، رشد سازمان لزوماً با افزایش تعداد مدیران یا طولانی‌تر شدن مسیر تصمیم‌گیری همراه نیست. گاهی توسعه یعنی اضافه کردن ظرفیت اجرایی، گاهی یعنی تخصصی‌تر کردن یک تیم، گاهی یعنی مستقل کردن یک واحد و گاهی هم یعنی حذف لایه‌ای که دیگر ارزش افزوده‌ای ندارد.
پرسش اصلی مدیرعامل هم نباید فقط این باشد که ساختار فعلی برای اندازه‌ی امروز سازمان مناسب است یا نه. پرسش مهم‌تر این است: اگر کسب‌وکار ما دو برابر شود، باید ساختار را از نو طراحی کنیم یا ساختاری داریم که بتواند متناسب با نیاز واقعی و مرحله‌به‌مرحله رشد کند؟ اگر جواب این سؤال روشن باشد، ساختار سازمانی از یک تصویر ثابت از جایگاه‌ها فراتر می‌رود و به ابزاری برای مدیریت رشد تبدیل می‌شود. ابزاری که نه سازمان را پیش از موعد سنگین می‌کند و نه در زمان توسعه، آن را با محدودیت‌های ساختاری روبه‌رو می‌سازد.
چنین سازمانی لزوماً کوچک نمی‌ماند. اما هر بار که بزرگ‌تر می‌شود، مجبور نیست پیچیده‌تر از چیزی شود که کسب‌وکار واقعاً به آن نیاز دارد.