Про хороших технических менеджеров
Возникло тут 'https://t.me/productodud/9?comment=55' rel='nofollow'>обсуждение с вопросом насчет того, а что же это за зверь такой - хороший технический менеджер?
Чаще всего ответ технарей сводится к тому, чтобы "просто не мешал работать", на что всегда хочется ответить - "да у вас просто нормального менеджера не было", но мы тут не за этим :)
Такая точка зрения обычно основывается на том, что, дескать, менеджер, не прошедший через код, гит и литкод, не способен адекватно управлять разработчиками.
Попробую рассказать, какими, с т.з. разработчика, качествами должен обладать технический менеджер (который при этом не обязан быть технарём):
* отлично знать предметную область, обладать как знанием продукта, так и насмотренностью по рынку;
* осознавать границы применимости технологий;
* не принимать импульсивных решений и не быть их проводником - как тут не вспомнить "медленное мышление" по Канеману и нестареющую классику из "Фитиля";
* защищать команду от внешних потрясений и не быть самому белкой-истеричкой, попугаем-микроменеджером, чайка-менеджером и прочими нервными животными :)
* максимизировать полезное общение на единицу времени - ёмкие нечастые звонки, понятный и структурированный текст, полнота передаваемого контекста, внимательность к деталям;
* не навязывать технических решений - этим часто грешат бывшие технари, у каждого из которых свой уникальный набор бабаек-динозавров из его технической молодости. Куда лучше итеративно промптить людей на поиск подходящего решения;
* иметь цельное видение и уметь его передавать - куда приятнее работать над функционалом, когда понимаешь, какое место он занимает в системе, насколько важен и как связан с бизнесом и пользователями, и гораздо проще воспринимаются какие-то изменения в проекте;
* уметь принимать информированные решения с учетом того, что какие-то вещи могут выпасть из головы, не попасть в документацию, пропасть вместе с носителем знаний из проекта - и нужно собирать информацию из сильно разных источников;
* уметь принимать взвешенные решения - учитывая как внешние хотелки, так и мнения и возможности команды;
* осознавать свои ограничения и слушать и слышать людей - команда запросто может быть как опытнее, так и умнее, так и богаче;
* уметь действовать на нескольких уровнях абстракции - от обсуждения стратегических планов развития продукта до участия в отлове бага на проде;
* выстраивать процессы, создавать структуры, уметь их поддерживать и ломать адаптировать под ситуацию;
* иметь высокий эмоциональный интеллект и софт-скиллы;
* быть умным. В принципе, всё остальное можно было бы и не писать :)
* в любой непонятной ситуации - думать!
Фуф, эти, пожалуй, самые важные :)
Сразу всеми перечисленными качествами ни один из менеджеров, с кем довелось работать, увы, не обладал, но некоторые были весьма близки (и при этом лучший из них всё ещё не был технарём).
Но даже обладающий хотя бы 2/3 из этого списка уже будет настолько хорош, чтобы стать технарям другом, товарищем и sibling'ом :)
И уж точно никто не скажет, что менеджер мешает или вообще не нужен. Наоборот, без него будет сложно обойтись.
Возникло тут 'https://t.me/productodud/9?comment=55' rel='nofollow'>обсуждение с вопросом насчет того, а что же это за зверь такой - хороший технический менеджер?
Чаще всего ответ технарей сводится к тому, чтобы "просто не мешал работать", на что всегда хочется ответить - "да у вас просто нормального менеджера не было", но мы тут не за этим :)
Такая точка зрения обычно основывается на том, что, дескать, менеджер, не прошедший через код, гит и литкод, не способен адекватно управлять разработчиками.
Попробую рассказать, какими, с т.з. разработчика, качествами должен обладать технический менеджер (который при этом не обязан быть технарём):
* отлично знать предметную область, обладать как знанием продукта, так и насмотренностью по рынку;
* осознавать границы применимости технологий;
* не принимать импульсивных решений и не быть их проводником - как тут не вспомнить "медленное мышление" по Канеману и нестареющую классику из "Фитиля";
* защищать команду от внешних потрясений и не быть самому белкой-истеричкой, попугаем-микроменеджером, чайка-менеджером и прочими нервными животными :)
* максимизировать полезное общение на единицу времени - ёмкие нечастые звонки, понятный и структурированный текст, полнота передаваемого контекста, внимательность к деталям;
* не навязывать технических решений - этим часто грешат бывшие технари, у каждого из которых свой уникальный набор бабаек-динозавров из его технической молодости. Куда лучше итеративно промптить людей на поиск подходящего решения;
* иметь цельное видение и уметь его передавать - куда приятнее работать над функционалом, когда понимаешь, какое место он занимает в системе, насколько важен и как связан с бизнесом и пользователями, и гораздо проще воспринимаются какие-то изменения в проекте;
* уметь принимать информированные решения с учетом того, что какие-то вещи могут выпасть из головы, не попасть в документацию, пропасть вместе с носителем знаний из проекта - и нужно собирать информацию из сильно разных источников;
* уметь принимать взвешенные решения - учитывая как внешние хотелки, так и мнения и возможности команды;
* осознавать свои ограничения и слушать и слышать людей - команда запросто может быть как опытнее, так и умнее, так и богаче;
* уметь действовать на нескольких уровнях абстракции - от обсуждения стратегических планов развития продукта до участия в отлове бага на проде;
* выстраивать процессы, создавать структуры, уметь их поддерживать и ломать адаптировать под ситуацию;
* иметь высокий эмоциональный интеллект и софт-скиллы;
* быть умным. В принципе, всё остальное можно было бы и не писать :)
* в любой непонятной ситуации - думать!
Фуф, эти, пожалуй, самые важные :)
Сразу всеми перечисленными качествами ни один из менеджеров, с кем довелось работать, увы, не обладал, но некоторые были весьма близки (и при этом лучший из них всё ещё не был технарём).
Но даже обладающий хотя бы 2/3 из этого списка уже будет настолько хорош, чтобы стать технарям другом, товарищем и sibling'ом :)
И уж точно никто не скажет, что менеджер мешает или вообще не нужен. Наоборот, без него будет сложно обойтись.