Comments 18
Всё уже придумано за нас:
надо выпускать львов.
В НИИ стали приводить львов и выпускать в рабочее время в коридоры, чтобы сотрудники работали, а не болтались. Потом случилось ЧП, и львов убрали. Один лев — другому:
— И нужна была тебе эта уборщица! Я двадцать два научных сотрудника съел, и никто не заметил!
Потому что в 21-ом веке, в индустрии где ВСЁ это R&D, манагёры всё ещё живут принципами фабричного производства из 19-ого века.
Пока не понял, хочу я с вами согласиться или спорить) Можете деталей добавить? О каких принципах 19 века идет речь?
У Вас название: "Как “заставить” сотрудников работать". Возможно поэтому и отсылка к 19-му веку.
На трех проектах в моей карьере у меня были руководители с примерно похожим подходом: вода про "мотивацию", "типы", флоу "сроки-контроль" и проч.
Все три накрылись медным тазом, причем в двух из них были хорошие программисты, а в одном из этих двух я еще и поработал сам в качестве СТО.
На четвертом мне повезло больше: мой тимлид вообще не понимает в мотивации, зато "сечет" в тех задачах, которые я делаю.
И поверьте, разница между тем, когда ты объясняешь какому-то "левому хмырю", почему тут выросли сторики, а ему до фонаря вообще, он же такие красивые картинки нарисовал про мотивацию, ему НЕКОГДА вникать в то, что происходит, "программировай давай", и между тем, кто говорит с тобой на одном языке, но ЕЩЕ и ставит задачи по своему положению это разница между Теслой и индийской машиной за 1000$. Обе машины: на какую сами сядете, на какую подчиненных посадите?
У меня обратный опыт. И тимлидам, которые выезжали исключительно на своей технической грамотности, не удавалось делать проекты командами серьезных размеров.
То, что вы описываете - также пример плохого управления. Руководитель операционного уровня, коим тимлид является, обязан хорошо разбираться в предметной области. В нашем случае - быть технически грамотным. Но это не отменяет и не перекрывает всего остального.
И тимлид без техники, и тимлид без понимания базовых основ управления людьми - две крайности плохого менеджера.
100% согласен. когда тимлид пытается выехать только на софт скиллах и не шарит в матчасти - это тупиковый путь
Есть такой подход, называется Servant leadership. Идея в том, что умные люди работают, а ты, как руководитель, им помогаешь чем можешь, и не мешаешь.
Так вот, с технарями такое работать не может. Здесь лидерство и уважение, во многом, определяются через экспертность. И потому нормальному тимлиду надо быть классным технарем.
А чтобы быть ХОРОШИМ тимлидом, нужно и то, и другое.
Вы говорите про четыре проекта, а опыт индустрии - это "сто тысяч миллионов" проектов. Означает ли это, что опыт индустрии однозначно подойдёт конкретно вашему проекту? Нет. Но ваш личный опыт совершенно точно не перечёркивает опыт индустрии. Т.к. в её масштабах это отклонение - это даже не песчинка на берегу океана.
Но в целом соглашусь со мнением, высказанным выше. Взгляд на менеджмент немного отдаёт нафталином.
Все правильно: эти "сто тысяч" и есть машина из страны рупий. Она возит, в ней есть крыша и двери и даже стекла из пластика.
Огромная "индус-трия" компании Microsoft год за годом выдаёт на гора шлак вместо продукта и выглядит молодцом именно в тех небольших сегментах, которые менее коммерциализированы, а, значит(как мне кажется), ещё не успели привлечь к себе внимание стаи очередных сияющих уверенностью выпускников мва-курсов.
Телега едет, куда ей деться-то...
А как надо, чтобы не было нафталина?
Только не пишите, пожалуйста, про самоорганизованные команды без лидов, и про осознанных инженеров, которые сами все делают превосходно. Не работает так, к сожалению.
Между классическим менеджментом и самоорганизованными командами есть еще множество промежуточных вариантов. Лично я, как тимлид, придерживаюсь подхода "Manager as a service" и принципа "Не управляй, а направляй".
Может, вам покажется сказкой, но моя команда прекрасно справляется с работой без меня, когда я, например, ухожу в отпуск. При этом они сами анализируют входящие задачи, грумят, приоритизируют, сами договариваются, кто будет делать ту или иную задачу. И это команда, состоящая из джунов и мидлов. В командах с прожженными сеньорами создать пусть и не самоорганизованную, но близко к этому, команду, гораздо проще.
Но, конечно, такой подход будет работать не во всех компаниях и не во всех профессиях
Спасибо за комментарий. Сказкой не покажется, очень даже верю :)
"Направлять" - это также история про мотивацию и поиск индивидуального подхода. Поэтому ваш пример никак не противоречит тому, что я описал. Даже наоборот, лишний раз может подтверждать.
А по поводу басфактора и возможности уйти в отпуск - здесь это немного другая тема, про организацию работы и, возможно, процессы в команде. Делегирование через бизнес-процесс. И это классная схема, можно уйти в отпуск или спокойно поболеть, если понадобится, но недолго. Такая структура работоспособна в определенных условиях, которые вы создали. И если вводные будут меняться, она сама не адаптируется, и все рассыпется. А в нашей сфере вводные меняются, даже на стабильных долги и однообразных проектах. К сожалению. Поэтому и без лида/руководителя - никуда.
Как “заставить” сотрудников работать