Структура компании привычным образом формируется в виде иерархического дерева.
Однако такая структура приводит ко множествам явных и неявных проблем. Одна из проблем в том, что теряются связи между смежными отделами, а коммуникация идёт через верха. Вместе с тем верха имеют лишь общее представление о ситуации, тем самым принятые решения часто оказываются не адекватными ситуации.
Между тем в IT разработке активно используется методология Scrum суть которой в том, что у нас нет начальников, но есть внутренние заказчики.
Например, у Вас есть отдел продаж (холодные и горячие звонки, ведение клиентов) и отдел рекламы, который организует акции на сайте и других площадках.
Так вот, отдел продаж может выступить заказчиком к отделу рекламы и заявить, что нам для продаж не хватает информационного сопровождения.
Далее отдел рекламы должен или выполнить данное задание или пойти наверх, говоря, что у нас нет ресурсов.
К кому наверх? Допустим к тому, кто координирует реализацию продукции. Этим человеком может оказаться коммерческий или генеральный. Но коммерекий не будет заниматься рекламой. Если ункция лишь в том, чтобы обеспечть ресурсами.
Конечно, продажники и реклама могут вообще сидеть в одной комнате и не иметь формального разделения. Но какие компетенции будут у руководителя? Он будет больше продажник или рекамщик?
Но когда отделы разрастаются, нет смысла решать всё через верха, ибо можно напрямую, оставляя для верха лишь роль координатора.
В таком случае решения будут принимать эксперты. В противном будут управленческие ошибки.
Например, что я постоянно сталкиваюсь с ситуацией, когда начальник говорит, что я в этом не ничего не понимаю. Но всё равно принимает решения. Начальник, конечно, нахватается что-то по верхам, но дьявол в деталях. Чего-то человек явно не учтёт.
Самому мне довелось несколько раз реализовывать проекты, в которых мой начальник, плохо разбираясь в теме, доверял мне техническую сторону проекта. За начальником оставалась финансовая составляющая, да и та в качестве стратегической кнопки.
При этом я напрямую решал все вопросы со смежными отделами. И проект шёл.
Во всех иных случаях проект заваливался.