Использование грейдов: частые ошибки

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

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

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

Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.

По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.

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

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

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

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

Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.

Максим Шаламов

#сто #тимлиду #руководителю

Как развлечься на работе

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

Зона комфорта
Скука выплывает обычно в контексте того, что работа по ведению проекта устаканилась и идет своим чередом, соответственно больше не дает дополнительных вызовов и роста. На самом деле это самообман и вы просто вошли в зону комфорта, из которой сами себя вытаскивать не хотите, а смена работа естественным образом решит эту проблему на время, но именно на время. Почему я в уверен, что скука идет от зоны комфорта? Потому что идеальных ситуаций/проектов/команд/технологий/... не бывает. Просто со временем вы принимаете некоторые вещи как данность и перестаете пытаться их улучшить. Дальнейшие упражнения имеют смысл, если вас в целом все устраивает и нет других серьезных причин для увольнения. Так же оставим в стороне случаи, когда вы хотите других позиций в целом.

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

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

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

Максим Шаламов
#советы #разработчику #тимлиду

План по приведению отдела в порядок, разбираем предновогодний кейс
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.

С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.

Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.

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

Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.

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

#сто #тимлиду
Максим Шаламов

Как подпитывать драйв в команде

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

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

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

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

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

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

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

Максим Шаламов
#тимлиду #разработчику

Фокусировка - держим команду в фокусе

Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.

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

Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).

Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.

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


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

Максим Шаламов
#тимлиду #agile_который_работает

Кто должен быть лидером в команде разработки

Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.

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

Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.

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

А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.

Максим Шаламов
#тимлиду #разработчику

Как правильно принимать решение

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

Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.

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

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

Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:

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

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

- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.

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

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

Максим Шаламов
#разработчику #тимлиду

Как не погрязнуть в ручных правках

Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.

Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?

К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.

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

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

Максима Шаламов
#тимлиду #разработчику

Нужны ли руководителю технические знания?

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

Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.

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

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

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

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

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

Максим Шаламов
#тимлиду #разработчику

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

#тимлиду #разработчику

Офис или удаленка? Личный опыт.

Сейчас очень много идет споров и обсуждений на тему “офис против удаленки”. Крупные компании пытаются вернуть сотрудников в офис, в то время, как большинству сотрудников хорошо работается удаленно. Расскажу свою историю и к какому выводу я в итоге пришел.

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

Дак как так случилось, если эксперимент получился удачным? Начну лично с моих проблем, а потом перейду к общим для команды.

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

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

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

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

А какой у вас был опыт удаленной работы? Какие были проблемы, а что понравилось больше, чем в офисе?

Максима Шаламов
#разработчику #тимлиду

Плюсы и минусы продолжительной работы на одном месте
Плюсы:

- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.

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

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

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

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

Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.

Максим Шаламов
#советы #разработчику #тимлиду

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

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

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

Максим Шаламов
#тимлиду #разработчику

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

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

Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.

Максим Шаламов
#тимлиду #разработчику

Выгорание у джунов до старта работы - миф или реальность?

У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.

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

Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.

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

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

Александра Шаламова
#разработчику #тимлиду

Многоэтапные собеседования - зачем?

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

Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.

Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.

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

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

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

Максим Шаламов
#тимлиду #разработчику

Должен ли руководитель уметь сам проверить работу каждого?

В очередной раз получил вопрос: “Если ты ничего не делаешь руками, то тебе сложно становится проверять чужую работу, а со временем вообще разучишься это делать. Что делать? А если ты не можешь проверять, то зачем ты тогда нужен? Просто ходить задачи раздавать?”. Нюансы бывают разные, но это волнует многих начинающих лидов, которых я знаю и которых растил. Давайте сегодня без общих рассуждений чисто к моему мнению.

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

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

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

Еще статьи по теме задач руководителя, которые уже есть на канале:

Нужны ли руководителю технические знания

Чем занят руководитель

Чем отличается руководитель от разработчика

Задачи тимлида и техлида

Мой путь от разработчика к СТО


Максим Шаламов
#тимлиду #руководителю

Что делать, если тебя не уважают

Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?

Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.

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

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

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

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

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

Александра Шаламова
#разработчику #тимлиду

Как руководителю заставить подчинённых и коллег себя уважать

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

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

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

Подача
Подача себя. На встречах и в общении вы должны быть уверены в себе и последовательны. Высказывайте свое мнение, убеждайте в своей правоте, не бойтесь спорить (но не переходите на грубость и споры ради спора). Если вы не можете высказать и отстоять свое мнение (а для подчиненных и их в большинстве случаев тоже), то доверие и уважение внушать вы не сможете.

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

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

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

Максим Шаламов
#тимлиду #руководителю