Pull to refresh

Comments 15

Человеческое настроение, оно как герпес, заразно.

Вот только необоснованная уверенность заставляет людей сомневаться, что человек вообще понимает, что он делает.


обсуждать задержки зарплаты и переработки

Вот тут согласен на все 100%, лучше о таком узнать на пороге, чтобы время не терять. Ещё лучше, конечно, сразу в описании вакансии.


А так у вас конечно забавный портрет хорошего руководителя вырисовался — туповатый самоуверенный чувак, который не решает твоих проблем, а только задалбывает всех своей энергичной беготней с ободряющими речами с "прямой спиной", слава богу хоть иногда отстаёт, отвлекаясь на птичек и кофе.

Вы немного передернули. Наверное должно быть так:
Портрет хорошего руководителя — не вникающий в нюансы задачи, уверенно рисующий цель, который ничего не делает, а только ставит задачи и заряжает команду энергией. Говорит о проблемах честно и прямо, дает и выполняет свои обещания.

Мне зашло все. Буду трансформироваться в этом направлении.
Пункт первый даже не спорный, примерил на себя и действительно — когда ставлю задачу тут же прокручиваю риски.
В итоге вместо «иди и делай!» получается «ну вот попробуй, тут конечно есть нюансы, но вдруг получится». Так что даже первый пункт верен, хотя сформулирован конечно спорно :)
Хотелось бы поподробнее обсудить пункт 7… Понятна проблема, непонятно что же предлагается в качестве решения :)
Работаю в продуктовой компании 5000+ чел, у нас четкая установка «задача менеджера — по максимуму помогать подчиненным и коллегам».
Коллеги, подчиненные, начальство — у всех есть проблемы, все просят тебя помочь.
Хорошо когда есть в наличии достаточное количество сильных, независимых сотрудников которые и сами знают что делать, и на которых можно много делегировать, но обычно таких людей немного.
Растить «ответственных-инициативных» из тех кто есть? Это блин не натаскать джуниора на С++, сложная задача :)
Пока застрял в режиме «днем помогаю другим, вечером делаю свою работу», как и в прошлую свою попытку захода в менеджмент/тимлидство. Выгорание машет из-за угла :)
Помогать можно по-разному же. Кому-то просто нужно пнуть соседнего менеджера или подписать замену компа на более мощный или разобраться с приоритетом задач. Не всегда же помощь — это выполнение работы подчиненного.
Судя по тому, что статья про обезьян уже 46 лет в топе, эта проблема терзает многих. Вот несколько советов из самой статьи:

Следует изложить сотрудникам новые правила игры.

1) Пока я помогаю вам решить эту или какую-либо иную проблему, она ни на секунду не перестает быть вашей

2) Вы можете просить моей помощи в назначенное для этого время, и тогда мы вместе определим, каким должен быть следующий шаг и с чьей стороны

3) В тех редких случаях, когда следующий шаг буду обязан сделать я, решение мы примем совместно

Тут ниже в комментариях есть ссылка на бесплатно доступный полный текст.

Мне ещё помогает деление проблем на 2 части: те, что в компетенции человека и те, что за пределами его компетенции.

Если возникает проблема, которую сотрудник сам в теории и должен решить, то от руководителя может быть ответ в виде: «Подбери список курсов/литературы, которые помогут тебе понять проблему. Изучи их и сообщи, нашлось ли решение». То есть, мы не оставляем мяч на своей стороне, следующий шаг за сотрудником.

Если это что-то за пределами обязанностей человека, то лучше тратить время не на решение единичной проблемы, а на настройку процессов внутри компании. Часто такие проблемы связаны с тем, что какой-то другой сотрудник не выполнил свои обязанности.
UFO just landed and posted this here
интересно, что это за собственная работа у руководителя в статье про обезьяну? я всегда думал, что координация подчиненных это и есть работа руководителя и ей он должен посвещать все свое время. И если подчиненные рапортуют о возникающих проблемах, то это как раз работа руководителя решать подобные проблемы. Вы это видите по другому?
Помимо времени на решение задач своих подчинённых, можно разделить временной ресурс руководителя на три части:

* время менеджера, которым распоряжается его босс
* время, которое забирает система, — просьбы менеджеров других подразделений
* время, распределяемое на собственные инициативы

Поскольку требования, предъявляемые начальством и системой, обязательны к исполнению, эти составляющие менеджеру неподвластны.

Единственный компонент, который оставляет простор для манёвра, — это время, затрачиваемое на собственные инициативы. И тут основная задача менеджера — максимально увеличить время, расходуемое по собственному усмотрению, и минимизировать или даже свести к нулю ту часть, которую отнимают подчинённые.

— Это из статьи про обезьяну. Мне кажется полезным такой вариант трактовки: время, потраченное на сотрудников, лучше направлять не на прямую помощь им, а на то, чтобы они становились более самостоятельными. Или на то, чтобы сама система, в которой они находятся, была бы для них более понятна и лучше работала. А это в дальнейшем освободит время на свои инициативы
+1, работаю в сторону улучшения документации/вики (вместо email с инструкциями — сразу страницу в Confluence, а еще лучше Васю/Раджеша попросить ее написать), стараюсь больше давать общих рекомендаций а не лезть самому разбираться (пока тяжело дается, привычка «все сам, все сам» :))) С соседними менеджерами и начальством сложнее. Тут утонуть запросто можно — если начальство фонтанирует идеями, а downstream команды стремятся переложить побольше на твои плечи. Но это уже про копоративную борьбу, вне рамок статьи по сути.
я просил примеры. мой опыт как то сильно расходится с тем, что написано в статье. Ниже VFaland написал, что он человек-оркестр, который затыкает дыры, хотя это и плохой пример, но более жизненный и близкий мне.
пример придумал. есть отличный разработчик, который качественно и быстро разрабатывает, но отвратительно пишет формальные тексты, а на английском и того хуже. Но надо написать документацию к той функциональности, которую он несколько месяцев делал. Ваши действия?
Если бы мы писали симулятор работы начальника, я бы предложил вам попробовать свои силы в этом)

Вижу вашу проблему, но ответ, наверное, всё-равно прозвучит общим. В похожих гипотетических ситуациях всегда есть какой-то контекст, который нам не известен.

И в зависимости от этого контекста менеджер может решить, что:

1) Сотрудник не может или не хочет делать свою работу. Нужно разбираться с сотрудником.

2) Кто-то поручил ему работу, которую он заведомо не может или не должен делать. Нужно разбираться с поручившим.

3) В компании вообще не предусмотрено, что кто-то будет писать документацию. Нужно разбираться с процессами внутри компании.

4) А надо ли тратить силы на документацию? Может этот проект был тестовым и уже сейчас другой командой пилится новое решение.

В статье есть два посыла на эту тему:

1) Изначально нанимать лучше такого человека, который придёт с более конструктивной формулировкой. Например «Я не очень люблю писать документацию, но Вася любит. Я с ним поговорил, он не против. Мы можем с ним поменяться задачами?». И в текущих сотрудниках поощрять именно такой подход к проблемам

2) Каким бы ни было решение, оно не должно быть «Ну ок, документацию я сам напишу»
мы с вами очень по разному видим как все устроено, я уже задал контекст описав, что документация нужна и у вас есть очень хороший разработчик. Вам уже повезло, очень маловероятно найти такого же только с перламутровыми пуговицами. Я считаю, что в этом контексте нет «хорошего» решения при котором разработчик разрулит ситуацию сам. Когда вы обязываете его самого найти решение проблемы, вы теряете. А как раз задача руководителя минимизировать потери, повысить эффективность и далее по списку. Накину, вы плохой руководитель, т.к. рост производительности команды ограничен догмами, которые вы приняли на веру только потому что источник имеет громкое название.
Зачастую позиция тимлида подразумевает и управление людьми, презентации, встречи с клиентами, и некоторую техническую работу — архитектура, код ревью, некоторые сложные или специфические задачи, или наоборот — разгружаешь людей, даешь им возможность сосредоточится на важных фичах а сам прикрываешь на багах. Особенно если команда небольшая. У нас многие линейные менеджеры (не проджекты и продакты, которые сбоку) в development командах пишут код, и такое наблюдаю во всех американских компаниях где работал… Есть свои плюсы и минусы в этом подходе.
Спасибо за статью. Мне, как человеку, который только только попал в IT после госслужбы была удивительна атмосфера, когда начальник и подчиненный говорят на одном языке, когда тебя слушают и слышат, а не просто отдают указиловки. С таким руководителем хочется работать.

И вынес для себя некоторые моменты, которые нужно изменить в поведении, чтобы в перспективе самому стать руководителем. особая проблема — собрать всех обезьян в округе
-_-
Sign up to leave a comment.

Articles

Change theme settings