Статистики под рукой нет, но с моей колокольни — сейчас не хватает, нужно больше. Я думаю, что в компании число стафф (и выше) специалистов должно превышать число тимлидов.
А касаемо попробовать — если желание есть, пробовать надо обязательно
Про «попросить» — скорее это договоренности. Обе крайности плохи: и прошение, и требование. С продуктом нужно быть в одной лодке.
У нас ещё при найме сообщают, что нянькаться не будут и никто не нянькается. К людям относятся по-взрослому и они в ответ (внезапно!) тоже ведут себя по-взрослому
Требовательность (по-взрослому) — это хорошо и правильно. Любовь к людям не должна ей мешать. Хороший руководитель совмещает и эмпатию, и требовательность.
Я таких почти не видел :) Тимлид — это мидл-менеджмент, без которого некому будет исполнять планы топ-менеджмента. Можно написать какую угодно хорошую стратегию, но доносить до людей ее будет мидл-менеджмент.
Так их и пришлось сначала учить жать кнопку. Потому что ни мыши, ни собаки — не рождаются с этим навыком. Так что таки да :)
https://pmc.ncbi.nlm.nih.gov/articles/PMC4920136/ исследование. Текст "The mechanism of learned helplessness is now very well-charted biologically and the original theory got it backwards." прямо в абстракте.
The dorsal raphe nucleus sends 5-HT projections to both the dorsal periaqueductal gray and to the amygdala, with 5-HT released in the dorsal periaqueductal gray inhibiting its function and 5-HT in the amygdala potentiating its function.
Второе исследование именно об этом и говорит: реакция мозга на стресс одинаковая. Если активные действия ведут к изменению влияния стресса, мозг посылает сигналы и отключает пассивность. Если активные действия не ведут (или их нельзя совершать), мозг не включает активное поведение.
И это важная деталь, которая меняет правила игры. В изначальной концепции проактивное поведение было как будто бы "дано", а последующее исследование показало, что этот навык обретается путем совершения активных действий с откликом. Это разница между "просто не мешать" и "активно учить". Если смотреть только на итог — да, одинаковый. Но предпосылки совершенно разные, о чем и говорят сами авторы.
В общем — да, если руководитель наказывает инициативы, команда тоже отучится проявлять эти инициативы. Но жизнь слишком коротка, чтобы работать с такими руководителями.
Абсолютно согласен. Кроме одного: людям может быть тяжело воспринять "бизнес" как некую абстракцию, для них и подойдут фреймворки или ментальные модели.
Я никогда не рассматривал выступления как обязанность :) Это интересно мне самому, потому что я люблю делиться знаниями и мне приносит искреннее удовольствие выступать перед аудиторией. Доклады — точно не часть моей ежедневной работы.
Стресс бывает хорошим стимулом, зависит от степени влияния и продолжительности влияния на организм.
По поводу заучивания: если информация засела достаточно глубоко, то в момент стресса она никуда из головы не денется. Пропадают навыки, связанные с эксплицитной памятью и все такое. План это хорошо, но сухо, надо ж будет развернуть в моменте.
Привычно — не значит правильно :) Я конкретной ситуации не знаю и бросаться словами "у вас неправильно настроены процессы" как будто бы не с руки. Но я бы к ним присмотрелся на месте руководителей.
О правильность процесса можно сломать много копий. Мой взгляд: эффективнее наладить взаимодействие между командами и отделами, чем любое взаимодействие вести через руководителя.
Если у разработчика возникла необходимость получить помощь другой команды, например, допилить API их сервиса, то он может пойти и к тимлиду другой команды, и к линейному сотруднику. Оба могут на следующем PBR'е, груминге или даже дейлике внести таску в бэклог спринта (некоторые команды закладывают время на непредвиденные задачи в спринт) или заложить капасити на следующий спринт. Мы живем в мире распределенных систем, и сервисы взаимодействуют друг с другом — поэтому взаимодействие людей неизбежно. Как бы программист не продумал API сервиса, доработки и фиксы будут.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Такой подход снижает басфактор, потому что не все упирается в тимлида. Что если тимлид заболеет? Команда будет отрезана от внешнего мира, потому что контакты не налажены.
Такой подход расширяет знание самой команды о сервисах вне ее скоупа. Это полезно и для архитектуры, и в случае инцидента.
Такой подход поможет вырастить людей, которым интересен дальнейший рост в менеджмент.
Тогда, если задача оказалсь просрочена, то ответственный за это тимлид/менеджер другой команды, он не выполнил свои обязанности.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я. Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти. Так что даже если часть моей задачи лежит в бэклоге другой команды, убедиться, что по ней есть прогресс должен тоже я. Главное, не возводить это в чайка-менеджмент и микро-контроль. Важна умеренность.
Не видите проблем в своей логике?
Искренне — нет. Не троллю :) Если более явно подсветите, будет здорово.
можно выстроить процессы так, чтобы этого не происходило.
Соглашусь, но только в определенных условиях. В реальной жизни команды меняются, компания может нанять целые отделы, которые еще не влились в выстроенные процессы. Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы. Как бы не был крут онбординг, он займет время.
Я люблю повторять, что hope — is not a strategy (спер у гугла) и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу. Тем более, если процессы хорошие, для этого достаточно просто зайти на доску команды и увидеть свою задачу в To Do и потом в In Progress. Это не займет более одной минуты. Тем более, что у любого процесса есть свои точки роста и абсолютного идеала, где все работает как часы, даже условная Toyota не достигла.
А вот тут мы подбираемся к вопросу о хорошем процессе поставки ценности. Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим. Можно выставить WIP-лимит или ограничить поток входящих задач, потому что незавершенная работа — это яд, который постепенно разъедает проект.
И разводить руками менеджеру тут нельзя, его прямая задача — не допустить подобных ситуаций. Хорошего руководителя отличает понимание, что процессные проблемы — это именно его проблемы, и решать их надо ему. Но не любой блокер является процессной проблемой.
На интервью кампания смотрит кандидата, а кандидат — компанию. Если так получается, что в компании не принято брать ответственность за ошибки, а к самим ошибкам относятся как к чему-то непростительному и пытаются замести под ковер, для меня это стало бы красным флагом :)
Ошибка — это шанс стать лучше. Главное, чтобы одни и те же ошибки не повторялись из раза в раз, вот это действительно печально.
В общем, в этом и различие. Самонаводимый человек считает, что его работа — это доставить ценность клиенту.
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство, то это приведет к росту сроков и тонне лишней коммуникации на ровном месте.
Все так :) Но у разработчика всё колоситься гораздо быстрее, и начинающему тимлиду с непривычки сложно.
Статистики под рукой нет, но с моей колокольни — сейчас не хватает, нужно больше. Я думаю, что в компании число стафф (и выше) специалистов должно превышать число тимлидов.
А касаемо попробовать — если желание есть, пробовать надо обязательно
Отличный комментарий :) Есть нюансы:
Про «попросить» — скорее это договоренности. Обе крайности плохи: и прошение, и требование. С продуктом нужно быть в одной лодке.
Требовательность (по-взрослому) — это хорошо и правильно. Любовь к людям не должна ей мешать. Хороший руководитель совмещает и эмпатию, и требовательность.
Скорее, взгляд на то, почему и как принцип Питера «достанет» новоиспеченного тимлида.
Я таких почти не видел :) Тимлид — это мидл-менеджмент, без которого некому будет исполнять планы топ-менеджмента. Можно написать какую угодно хорошую стратегию, но доносить до людей ее будет мидл-менеджмент.
Так их и пришлось сначала учить жать кнопку. Потому что ни мыши, ни собаки — не рождаются с этим навыком. Так что таки да :)
https://pmc.ncbi.nlm.nih.gov/articles/PMC4920136/ исследование. Текст "The mechanism of learned helplessness is now very well-charted biologically and the original theory got it backwards." прямо в абстракте.
https://pmc.ncbi.nlm.nih.gov/articles/PMC4920136/
Второе исследование именно об этом и говорит: реакция мозга на стресс одинаковая. Если активные действия ведут к изменению влияния стресса, мозг посылает сигналы и отключает пассивность. Если активные действия не ведут (или их нельзя совершать), мозг не включает активное поведение.
И это важная деталь, которая меняет правила игры. В изначальной концепции проактивное поведение было как будто бы "дано", а последующее исследование показало, что этот навык обретается путем совершения активных действий с откликом. Это разница между "просто не мешать" и "активно учить". Если смотреть только на итог — да, одинаковый. Но предпосылки совершенно разные, о чем и говорят сами авторы.
В общем — да, если руководитель наказывает инициативы, команда тоже отучится проявлять эти инициативы. Но жизнь слишком коротка, чтобы работать с такими руководителями.
Абсолютно согласен. Кроме одного: людям может быть тяжело воспринять "бизнес" как некую абстракцию, для них и подойдут фреймворки или ментальные модели.
Я никогда не рассматривал выступления как обязанность :) Это интересно мне самому, потому что я люблю делиться знаниями и мне приносит искреннее удовольствие выступать перед аудиторией. Доклады — точно не часть моей ежедневной работы.
Стресс бывает хорошим стимулом, зависит от степени влияния и продолжительности влияния на организм.
По поводу заучивания: если информация засела достаточно глубоко, то в момент стресса она никуда из головы не денется. Пропадают навыки, связанные с эксплицитной памятью и все такое. План это хорошо, но сухо, надо ж будет развернуть в моменте.
Привычно — не значит правильно :) Я конкретной ситуации не знаю и бросаться словами "у вас неправильно настроены процессы" как будто бы не с руки. Но я бы к ним присмотрелся на месте руководителей.
О правильность процесса можно сломать много копий. Мой взгляд: эффективнее наладить взаимодействие между командами и отделами, чем любое взаимодействие вести через руководителя.
Если у разработчика возникла необходимость получить помощь другой команды, например, допилить API их сервиса, то он может пойти и к тимлиду другой команды, и к линейному сотруднику. Оба могут на следующем PBR'е, груминге или даже дейлике внести таску в бэклог спринта (некоторые команды закладывают время на непредвиденные задачи в спринт) или заложить капасити на следующий спринт. Мы живем в мире распределенных систем, и сервисы взаимодействуют друг с другом — поэтому взаимодействие людей неизбежно. Как бы программист не продумал API сервиса, доработки и фиксы будут.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Такой подход снижает басфактор, потому что не все упирается в тимлида. Что если тимлид заболеет? Команда будет отрезана от внешнего мира, потому что контакты не налажены.
Такой подход расширяет знание самой команды о сервисах вне ее скоупа. Это полезно и для архитектуры, и в случае инцидента.
Такой подход поможет вырастить людей, которым интересен дальнейший рост в менеджмент.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я. Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти. Так что даже если часть моей задачи лежит в бэклоге другой команды, убедиться, что по ней есть прогресс должен тоже я. Главное, не возводить это в чайка-менеджмент и микро-контроль. Важна умеренность.
Искренне — нет. Не троллю :) Если более явно подсветите, будет здорово.
Соглашусь, но только в определенных условиях. В реальной жизни команды меняются, компания может нанять целые отделы, которые еще не влились в выстроенные процессы. Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы. Как бы не был крут онбординг, он займет время.
Я люблю повторять, что hope — is not a strategy (спер у гугла) и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу. Тем более, если процессы хорошие, для этого достаточно просто зайти на доску команды и увидеть свою задачу в To Do и потом в In Progress. Это не займет более одной минуты. Тем более, что у любого процесса есть свои точки роста и абсолютного идеала, где все работает как часы, даже условная Toyota не достигла.
А вот тут мы подбираемся к вопросу о хорошем процессе поставки ценности. Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим. Можно выставить WIP-лимит или ограничить поток входящих задач, потому что незавершенная работа — это яд, который постепенно разъедает проект.
И разводить руками менеджеру тут нельзя, его прямая задача — не допустить подобных ситуаций. Хорошего руководителя отличает понимание, что процессные проблемы — это именно его проблемы, и решать их надо ему. Но не любой блокер является процессной проблемой.
На интервью кампания смотрит кандидата, а кандидат — компанию. Если так получается, что в компании не принято брать ответственность за ошибки, а к самим ошибкам относятся как к чему-то непростительному и пытаются замести под ковер, для меня это стало бы красным флагом :)
Ошибка — это шанс стать лучше. Главное, чтобы одни и те же ошибки не повторялись из раза в раз, вот это действительно печально.
В общем, в этом и различие. Самонаводимый человек считает, что его работа — это доставить ценность клиенту.
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство, то это приведет к росту сроков и тонне лишней коммуникации на ровном месте.
За весь Купер не отвечу, у меня из ста человек в год уходило по 2-3 в среднем.
У вас, вероятно, очень большой опыт, судя по тону решений. Если не секрет, где вы его приобрели и на каких успешных проектах?