Как стать автором
Обновить

Что происходит с разработчиками, которые не хотят управлять командой

Время на прочтение6 мин
Количество просмотров33K
Всего голосов 52: ↑48 и ↓4+53
Комментарии45

Комментарии 45

«На собеседовании в Google Джеффа спросили, что следовало бы из равенства P=NP. Он ответил: «P = 0 или N = 1». Затем, пока собеседующий ещё не перестал смеяться, Джефф присмотрелся к публичному сертификату Google и выписал приватный ключ на доску»

Долго смеялся над этим приколом, но мне кажется его очень мало кто поймет, по крайней мере вторую часть...

Полагаю, в айтишной среде всем известно, что подобрать приватный ключ - это NP

No Problem? :)

Если это будут так легко подбирать, то это уже Nam Piz**ts :)

Но это полная противоположность тому, что нужно в решении технических задач. Хард-скиллы требуют строго обратного:

...
- игнорировать мнения и советы от некомпетентных коллег;
- действовать смело и решительно.

Игнорировать мнения - вы здесь прям токсичный антипаттерн привели :)
Нужно не игнорировать, а наставлять и обучать, чтобы потом самому легче жилось.

Можно сказать, что в современном мире, особенно на удалёнке, коммуникативные навыки должны быть адекватно развиты. И они постепенно переходят в hard-skills, особенно при росте грейда, и особенно при работе в команде.

Нормальная коммуникация сэкономит много времени и сил всех и каждого.

И не стоит забывать, что все люди и все ошибаются. И надменное "да я лучше знаю, да у меня Х лет опыта!" как мысленный ответ джуну может выйти боком.
И джуны бывают правы :)

Так что стоит разделить ситуации, когда надо действовать решительно и смело (при тушении пожаров), а когда нужно подумать и по-человечески договориться (при нормальной работе).

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

Зачастую, технические задачи переплетены с коммуникацией, если они касаются межкомандного взаимодействия (работа с чужим сервисом, доработка общей библиотеки).
И отсутствие софт-скиллов в этом случае совершенно точно не ускорит принятие общих договорённостей ;)

И не стоит забывать, что все люди и все ошибаются. И надменное "да я лучше знаю, да у меня Х лет опыта!" как мысленный ответ джуну может выйти боком.
И джуны бывают правы :)

Кстати, от такого поведения лично меня очень хорошо спасает синдром самозванца (или что-то ему подобное). Ну, то есть, официально по бумагам и по всем характеристикам (опыт работы и т.д.) я уже давно синиор. Но по внутреннему ощущению я не сильно далеко ушел от джуна, которым был много лет назад. Не во всём, конечно: где-то я объективно чувствую личный прогресс и силу опыта. Но во многих аспектах это ощущение постоянно даёт о себе знать. И постоянно есть подозрение, что эта страшная тайна вот-вот раскроется. Именно поэтому я никогда не позволяю себе надменно говорить с джунами/мидлами, потому что, они легко могут быть правы, а я легко могу быть не прав :)

Уже писал в другом топике — лет 6-7 назад я себя уверенно называл Senior (на тот момент 4 года опыта работы было).

Потом подучился ещё, поработал с разными людьми, и теперь сильно не уверен, что могу себя так называть =)

Так что стоит разделить ситуации, когда надо действовать решительно и смело (при тушении пожаров), а когда нужно подумать и по-человечески договориться (при нормальной работе).

Вот в этом вопросе я с вами категорически не согласен. Команда без сильного лидера, это не команда, а стадо. Причем важно, чтобы лидер сочетал в себе одновременно как сильную техническую экспертизу так и развитые коммуникационные навыки. И важно, чтобы "лидер" по своей природе был альфа-самцом. В IT конечно работают умные, интеллигентные и эмоционально зрелые люди... Но... Тот факт, что мы произошли от обезьяны, никуда не денешь. Поэтому в любом коллективе идет подковерная борьба за место главного самца - нравится нам это или нет.

Альтернативы следующие:

  1. В команде отсутствует отсутствует альфа-самцы с технической экспертизой. Кучка бета-самцов до бесконечности между собой договаривается "по-человечески" и команда по сути бегает по кругу. До тех пор, пока у бизнеса не заканчивается терпение, и он не закрывает проект. Классический паттерн "лебедь, рак и щука".

  2. В команде есть альфа-самец со слабой технической экспертизой. Результат - команда с разбегу пытается проломить лбом бетонную стену, несмотря на то, что в двух шагах рядом находится широко распахнутая дверь. Результат - команда таки расшибает себе лоб.

  3. В команде есть люди с сильной технической экспертизой, не желающие или не способные взять на себя роль вожака стаи. Если другого альфа самца в команде не находится - то см. пункт первый. Если есть - то второй :)

Мы не сделали скандала —
Нам вождя недоставало:
Настоящих буйных мало —
Вот и нету вожаков.

Есть еще вариант, когда альфа самец со слабой технической экспертизой образует что то вроде симбиота с сильным бета-технарем. Такие комбинации зачастую тоже очень неплохо работают. При условии, что у альфа-самца хватает ума признать для самого себя превосходство бета-технаря в технических вопросах, и воспользоваться его советами.

Альфа самец? Симбиоз с технарём? Человеческое стадо?

Взаимоотношения внутри коллектива, на самом деле, не далеко ушли от пещерных времен. Вы присмотритесь получше :)

Еще такой парадоксальный момент. Для бизнеса пункт 2 обычно выгоднее, чем пункт 1. Во втором случае фейл происходит гораздо быстрее и "нагляднее", чем в первом. Соответственно бизнес раньше принимает решение о закрытии неудачного проекта, и теряет меньше денег :)

Браво!!!

Стоит также заметить, что лидеры это не альфа-самцы, но бета-самцы. Хотя само деление на альфа-бета-...-омега это не более чем кундштюк (редукция, практически до шаманско-астрологической чуши и стои́т с ними в одном ряду). Альфы это вожди. Вождей много не бывает и командами они не управляют. Управляют солдаты-охотники среднего звена (лейтенанты,капитаны, командиры рот и взводов), алиментаторы, инженеры от рождения. Это беты. Да-да, те самые, которые очень хотят быть как альфы, но не могут и поэтому часто стараются нацепить на себя модную серёжку в ухо, кольцо в нос, котлы диковенные (золотые или с экранчиком -- не важно), девушками лицом и силиконом лепыми и т.д. Это называется подражание (или имитация). Это беты. Лидеры с постоянным зудом по всему туловищу о том как причинить что-то полезное для себя и возможно для других (для группы). А альфы это совсем, совсем другой тип. Незаслуженно оболганный и забытый, кстати. ))) но это уже тема для отдельной лекции.

Просто им нужны хард-скилы в прямом их понимании)

Мне кажется, первый кто создаст вакансию "ищем бездарных программистов" сорвет джек-пот просто выбившись из общей социально-ожидаемой массы

Про софт и хард скиллы прям очень хорошо: и просто, и содержательно

игнорировать мнения и советы от некомпетентных коллег

Во, сразу видно, автор - "наш человек" из "нашей компании". Аз есьм, окружен некомпетентными людьми, идиотами. Только я, родимый, никто другой не способен.

Скромнее нужно быть, один в поле не воин.

Автор дело говорит, не все люди одинаково во всем разбираются. Надо уметь отсеивать дичь даже если ее советует коллега, особенно если у него специализация другая

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

Я лично некомпетентен в сфере 3д проектирования или UX дизайна, а так же агрокультуре и машинном производства. И я не вижу никаких проблем в том, чтобы меня называли некомпетентным в этой области, потому что это правда.

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

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

Хорошим примером будет ситуация, когда я подойду и скажу специалисту по информационной безопасности, и посоветую хранить пароли в базе данных в незашифрованном виде, и он отмахнеться от меня сказав, что я некомпетентен в этом вопросе и он не нуждается в моих советах в этой сфере.

То есть ваше недовольство заключено не в том, что вас назвали некомпетентным, а в том, что вас назвали так не заслужено. И такое недовольство оправдано

Не перекручивайте. Речи об этом не было ни в словах автора статьи, ни в моих словах.

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

Автор же говорит о взаимоотношениях между программистами А и В.

Но это полная противоположность тому, что нужно в решении технических задач. Хард-скиллы требуют строго обратного:

Тех задачи у работников отдела ИТ безопасности и отдела разработки ПО в 99% случаев совершенно разные.

Но это полная противоположность тому, что нужно в решении технических задач. Хард-скиллы требуют строго обратного:

...
- игнорировать мнения и советы от некомпетентных коллег;
- действовать смело и решительно.

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

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

- игнорировать мнения и советы от некомпетентных коллег;

То о чем мы говорим это не совсем хард-скиллы, я бы отнес это к софт скиллам, все же это взаимодействие с другими людьми. Тем не менее, я не думаю, что корректно рассматривать работу программиста в вакууме, лишь в кругу тех же программистов. Как я и сказал, коллеги это не только лишь программисты, а и другие люди, с которыми вы работаете бок о бок. Поэтому все мои слова сказанные о некомпетентности, и автора думаю тоже (по крайней мере я так понял), касаются тех людей, у которых действительно нет компетенции в вашей области

То о чем мы говорим это не совсем хард-скиллы ... и автора думаю тоже (по крайней мере я так понял)

Данное указание стоит подпунктом для hard-skills. Я думаю неслучайно. Мне кажется здесь речь идет о таком токсичном гуру программисте(деде от программирования, рок-старе), из некоего мвидео или ватэвэер, которые тыкает "рыльцем" своих некомпетентных коллег в их программистские некомпетентности. У нас на просторах бывшего сесер такое поведение, это прям нац спорт.

Если же речь заходит о soft-skills, даже если автор и не об этом, то тут тоже самое. Есть разница между фразой "ты некомпетентный специалист и в программировании ничего не понимаешь, так что знай свое место" и "мне кажется предложенный вами подход не очень оптимален, но спасибо за предложение". Даже если разговор имеет место между PM и разработчиком. Но это, еще раз, не из hard-skills.

Чаще вижу как человек, которому "неприятно командовать коллегами" получает серьёзный внутренний конфликт, когда сталкиваются его большие амбиции и естественные ограничения при работе только своими руками.
Да и "командовать" в IT - довольно дурацкое занятие/слово.

Прокачать целый пласт новых навыков - довольно интересный челлендж, интересней, чем освоить новый фреймворк. Ну и что уж, опцион - штука хорошая.

Скажите, пожалуйста, вот вы в конце выкатываете список вакансий.
Пошёл посмотреть IT.

Есть ожидаемый уровень (это хорошо и понятно).
Есть города (зачем это в IT?).
Вилка зарплат - ну, у вас действительно почти нигде нет представления о том, сколько вы готовы платить кандидату определённого уровня?

Не знаю, кого это может привлечь, только отталкивает. Всякие загадочные фразы от рекрутёра, типа, "по результатом собеседования" не принимаются. А потом вопрос "вы нам понравились, но какие ваши зарплатные ожидания?".

Такой процесс найма может быть интересен только новичкам, но мне вас вряд ли удасться в этом убедить. Я на вакансии без вилок зарплат давно нешил не тратить своё и ваше время.

У FAANG, да и вообще у 99% вакансий в силиконовой долине в вакансиях нет вилки ЗП, приходится прикидывать по всяким посторонним сайтам, стоит ли подаваться на какую-то вакансию, или нет. Вилка чаще всего бывает у всяких мелких стартапов, ну или у рекрутера при первом созвоне можно иногда выпытать, если скилла хватит.

Где Амазон и где М.Видео? Это риторический вопрос

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

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

Звучит как диалог из первого терминатора

Джефф Дин сделал мой день!

«Когда Джефф Дин разрабатывает программу, то сначала создаёт бинарник, а потом пишет исходный код как документацию».

«На клавиатуре Джеффа Дина две клавиши: 1 и 0».

Исходный код нулями-единицами писать это вам не мелочь... )

Вообще-то программисту тоже нужно "договариваться" с памятью и процессором, смотря что где важнее, идти на компромиссы.

Что происходит с разработчиками, которые не хотят управлять командой

.. они начинают управлять командой

НЛО прилетело и опубликовало эту надпись здесь

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

Спасибо за то, что подняли интересную тему! К моему удивлению, я не знал раньше про Джеффа Дина!

Хочу предложить своей взгляд на некоторые моменты из статьи:

Ему самому неприятно командовать коллегами

Руководить - не значит командовать. Есть ещё такое понятие как "лидерство", и в инженерных командах компетентным людям проще и правильнее именно быть лидером, вести команду за собой, показывать на своём примере, делиться своими знаниями и экспертизой. Люди, заинтересованные в профессиональном развитии, с удовольствием будут работать с таким человеком, и всем в этой схеме будет комфортно и продуктивно.

- избегать конфликтов

- говорить обтекаемо, чтобы никого не обидеть

Это необязательно должно быть так. Есть ситуации, где такие навыки нужны, но в целом люди нормально реагируют на критику, если она конструктивна, actionable (как это будет по-русски?) и подана в уважительной манере. Последнему несложно научиться; более того, по моему опыту самые сильные инженеры обычно общаются именно так, потому что им на самом деле не надо демонстрировать или защищать свой ранг в группе, все вокруг и так знают, что они компетентные и к их словам надо автоматически прислушиваться.

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

игнорировать мнения и советы от некомпетентных коллег

И снова: уважительная манера коммуникации диктует нам не игнорировать коллег, а разъяснять им их неправоту, что, опять же, опытному инженеру не составит труда.

Я за свою трудовую биографию запромоутил в тимлидов нескольких очень толковых ребят. И каждый раз говорю им: руководство командой - это горизонтальное масштабирование тебя как инженера, чтобы достигнуть уровня производительности, недостижимой при вертикальном профессиональном росте. Конечно, становиться руководителем - это сильное изменение, но в этом нет ничего невозможного, если человек это интересно и есть желание развиваться в эту сторону.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий