хочу поделиться с вами сборником айти канальчиков, который собирает крутой Дима Рыбалка. я сам в части каналов состою, а остальные ситуативно поглядываю сборник одобрен лучшими технарями, поэтому смело добавляйте)
на этой неделе сразу с несколькими коллегами, обсуждая разные темы, пришли к похожим мыслям.
у каждой организации есть определенный уровень развития (не путать со стадиями). как уровень зрелости или культуры.
если сотрудник приходит из компании с меньшим уровнем в большую, его ждет вызов и он будет круто (пусть и тяжело по началу) расти. либо, не справится и уйдет. но обычно, тянется к большинству.
а если человек идет на «понижение» — будет борьба за то, готова ли хотя бы его команда принять то новаторство и подходы, что он несет (а он может и не нести).
вряд ли компания сможет быстро вырасти с одного уровня на другой, а уж тем более, перескочить сразу несколько этапов развития. это значит лишь одно — нужно запастись терпением и желанием учить и слушать. корректируя путь свой и компании.
в командах все проще, но может обернуться расколом или нелояльностью части отличающихся уровнем зрелости людей.
может быть, есть известный способ определить уровень и как в них адаптироваться?
как театр начинается с вешалки (фу, клише!) так и работа в компании начинается с онбординга
я очень часто вижу, что на онбординг не выделяется должных сил и процесс превращается во что-то вроде "читай отсюда и до просветления" и "ну я когда пришел — тут даже звонка приветственного не было, онбординг не предусмотрен"
так вот, считаю что для работодателя критически важно сделать не просто хорошее приветствие, выдачу доступов и показать документацию (которой очень даже нет), но построить процесс онбординга таким, чтобы у новичка было ощущение нужности, долгожданности, чтобы он получил ответы на вопросы, которые даже не успел задать
прикольный онбординг был в сбермаркете — в джире автоматически создавались задачи на первый день, неделю, месяц и по ним легко можно было трекать что новичок сделал, где завис, где не получил доступ и что еще. прозрачно с обеих сторон.
альтернативный вариант — это страница вики с чеклистом, которую клонируют для каждого новичка и там он отмечает галочкой что сделал/получил.
очень клево, когда новичку выделяют ментора — человека, который от старта до завершения испыталки (может дальше) будет вести за ручку и помогать в спорных вопросах. при этом, почему-то, принятно такую опцию вешать на руководителя (что не есть правильно), тем самым сильно ограничивая скоуп знаний для новичка, а еще, в случае больших команд, расфокусировку или недостаточное погружение в технические процессы и детали (сам таким страдаю)
что ж, да) сейчас у нас онбординг очень хромает, но я знаю что сделать и как его сделать хорошим, а в будущем — даже лучшим.
в нелегкие времена задумываюсь вот о чем: сколько бы ни работал — всегда работаю с командой, а не с компанией.
возможно, поэтому мне не сильно важно в какой фирме работать (при прочих равных, см пост про пирамиду), а с какими людьми.
но ведь сложно понять что за люди и как они работают в конкретных условиях, не поработав с ними.
и тут есть варианты — работать со своими людьми (расширяя круг) и переходя с ними (или за ними) из компании в компанию, либо смотреть на компанию исходя из людей там и к ним притираться (или просто влиться как к себе домой)
я сторонник и того, и того подхода в зависимости от ситуации и конечно буду рад знакомым лицам, однако всегда когда поработаю в компании хотя бы чуть — начинаю работать с командой (или командами)
и вот, когда я перехожу к работе с командами — тогда уже лояльность работает в обе стороны полноценно — команда опирается на меня, я опираюсь на компанию и команду и служу связующим звеном между ними (если это требуется, конечно).
главное — найти свою команду, быть в ней полноценным участником — и тогда работа будет в кайф и тогда задачи будут интересные и всё получится. но не стоит питать иллюзий — если компания плохая — то и команде станет плохо, а там уже — смотри выше.
что вкладывается в понятие опыт? багаж знаний, который есть у человека по определенной теме? или практические навыки, полученные за годы работы с технологией или практикой?
мне кажется, опытный человек — это тот, который может сделать базовые вещи вообще не задумываясь, разобраться в контексте и необходимости сложных действий и спроектировать решение по необходимости изменений.
это касается не только айти или работы даже, в жизни же точно так же.
ну и да, невозможно стать сеньором за три года от старта. либо станешь только в своей узкой специализации, либо будешь дурачком, который считает что все знает и набивает себе этим цену. ни тех, ни других рынок не ценит.
обратная стороная — быть слишком широким универсалом без глубокой специализации в какой-то конкретной теме. всё вроде знает, но не может нигде нырнуть вглубь и дать экспертную оценку/совет.
бороться с этим? нет, просто надо понимать, что опыт — это штука, которая помогает, а не просто дает очков в резюме) а уж как она помогает — надо смотреть. кому-то может и мешает, потому что шоры глаза закрыли.
вот все кручу, кручу этого играющего тренера и не могу отделаться от мысли — те, кто ожидает играющего тренера — всегда получают и не тренера, и не игрока.
почему? потому что если инженер вырос в менеджера — ему нужно расти в менеджерстве, там много чего есть и обуять это быстро и качественно — невозможно
когда менеджер хочет инженерить — это круто, он может и будет это делать. но дальше нужно понимать какое соотношение инженерных задач к менеджерским будет и как к этому готов каждый конкретный лидер.
закладывать капаситет лида в командный — считаю точно неправильным. пусть это всегда будет приятный бонус и ускорение в моменте.
при этом, для компании получить "играющего тренера" на самом деле проблема — они не получат адекватной менеджерской поддержки и не получат полноценно инженера.
ни в коем случае не говорю, что становясь менеджером, нужно забыть инженерку и стать бумажкоперекладывателем. можно и нужно продолжать быть в тренде, понимать что происходит и держать контекст. самый простой способ — участие в код-ревью и архитектурном комитете на уровне полноценного участника, а не просто принимающего решения человека.
ну и да, будучи на высоких позициях (юнит-лид, head of, CTO) все эти вещи тоже работают.
ага, а если вы инженера грузите менеджерством — тоже может получиться вообще плохо (а может хорошо, но давайте об этом однажды еще поговорим)
да вряд ли сыча, просто хочется подумать над тем, что в работе для меня важнее всего. на днях обсуждали с коллегой эту историю, решил как-то формализовать критерии критичности условий на работе для меня
сверху-вниз (чем выше — тем важнее)
нулевой слой — не заставлять делать дичь: переступать мораль, законы, увольнять всех неугодных руководству, продавать в рабство инженеров, убивать людей, гемблинг, наркотики, железные сервера руками
дальше, в адекватную первую очередь идет, конечно же, оплата труда и сфера труда — айти. это какой-то базис, без которого я работать не буду)) а так — на что продал — на то и работаю) дальше уже перф-ревью или рынок решит
честность и открытость между мной и руководителем, а так же прямыми пирами — я это всегда делаю сам, но мне важно, чтобы со мной были честными во всем
степень известности — важно чтобы цели были понятны, куда они приведут и как их корректируют исходя из происходящего
удаленная работа — для меня теперь стала еще важнее, я умею, могу и буду работать удаленно
коллеги, а точнее — те, кого не хочется звать коллегами, а хочется назвать братаны/сестраны, капибарята, в общем — коллектив, который поддержит, поможет, сделает то, что нужно и как нужно сюда же добавлю кружки по интересам, которые можно открывать и лидировать + пушить в правильном русле
атмосфера правильной токсичности — кого надо облить, кого не надо — помочь, не стесняться критиковать и получать критику адекватно
интересные задачи — не однородный поток коричневых задач, а разнообразные задачи, в которых я могу решать и выбирать
обратная связь — 360/180 и прочие циферки, но лишь бы доносили что я делаю что-то не так (или так, тоже норм)
техника — либо работать на технике компании, либо без ограничений на собственной (типа ставить DLP на свою? нееее)
так уж повелось, что календарь менеджера — это сплошное полотно из созвонов и созвонов. я, разумеется, не являюсь исключением.
но работа менеджера — не только балакать, но и мешки ворочать. очевидным решением для себя я нашел столбление слотов в календаре под концентрацию. зачастую делаю их приватными, чтобы даже не лезли.
но вот минус — не всегда в эти отведенные промежутки в слотах ты будешь делать то, что нужно.
следующей генерацией от меня было сделать слот "задачи и цели" и в рамках слота точно иметь время на это.
однако, в это время почти всегда происходят форс-мажоры и важные событие вовне, которые отвлекают от этих дел.
соблюдать ворк-лайф беленс нужно. поэтому, не жертвуя личным временем, оптимизируем встречи — приходим готовыми, делаем на них ровно то, что нужно, делегируем встречи, на которых нам лично быть не нужно, а еще прямо во время встречи если понимаем что нет смысла на них быть — уходим (можно даже предлог написать в виде "я на инц")
главное — не сойти с ума и не потерять контексты между встречами, поэтому ставьте себе либо кратные 15 минутам встречи с зазором в эти самые 15 минут, либо ведите заметки по ходу встречи, а вечером — делайте разбор заметок. не откладыайте на утро, утром все изменится.
а еще — если откладывать на завтра — завтра наступит внезапно и там будет еще 10+ новых задач и встреч.
расшивка календаря круто, но реальность кусь за жопу.
https://ecom-tech.timepad.ru/event/3152566/ сыч будет рассказывать про ченджи) приходи понабрасывать! ну и Даша Джудис тоже будет рассказывать про взаимодействие подразделений) ееее го!
https://bit.ly/3CqvrQ2 го по моей ссылке на митап регистрироваться, посмотрим сколько нас? обсудим факапы, послушаем чужие, получим опыт, решим как жить дальше?
понял тут что знаю как минимум даа типа руководства.
кто-то любит решать за других, а кто-то хочет, чтобы люди были самостоятельнее и отдает решение другим.
не стоит воспринимать это как снятие ответственности. ведь в итоге, когда что-то случится — руководитель возьмет ответственность на себя. зато лавры победы будут точно отгружены тем, кто действительно сделал.
и нет, конечно, руководитель тоже многое делает и лавры ему тоже положены.
был у меня руководитель, который не принял ни одного решения и не подписал ни одного документа за 2 года совместной работы. это вообще за скобками) человек номинально существовал, влиял через манипуляции и получал свою выгоду.
а еще был у меня шеф, который лез во все, в чем даже не имел представления. выливалось это в длительные объяснения, ожидания. но все решения должен был принять он. иначе они нелегитимны.
а вообще — команда строится под руководителя, руководитель подстраивается под команду.
я за высокий уровень осознанности и ответственности. мне уже давно не хочется думать за других, но помогать им. я доверяю своим людям, они молодцы.
подумал вот: каждый раз на собеседованиях мы отбираем только лучших, классных и подходящих нам сотрудников
сотрудники, в свою очередь, выбирают самые крутые команды, технологии и компании.
потом эти два мира объединяются и после испытательного срока все становится обыденным и рабочим. всплывают разные нюансы и особенности.
и потом может начаться следующее: адаптация. не та, когда ты заонбордился и привык, а та, где сотрудник прощупывает компанию по нахождению "дна" (на самом деле — комфортной ниши), а компания — сотрудника, для нахождения тонкой струны (на самом деле — предела лояльности)
и идет танец: когда сотруднику комфортно, когда компанию все устраивает — все прекрасно, такт совпал и все счастливы, но стоит кому-то наступить на ногу — начнется аритмичная борьба.
не всегда она длится долго или вообще выходит за предел пожимания плечами (что с одной, что с другой стороны).
но если вы понимаете что явно что-то начинает расходиться — время задать вопрос "что не так? мы в одном контексте?". порой достаточно просто проговорить или написать где-то согласованные понятия, чтобы вновь войти в такт.
почему-то часто встречаю неразрывную связь performance review и salary review.
а еще, у нас сейчас, это две неразрывные процедуры одного процесса.
главным минусом такой связки стало отношение к процессу как к ежегодной (или ежеполугодовой) индексации. типа «мне обязательно накинут денежку, иначе я демотивируюсь»
однако, я же прожаренный хоппер и знаю, что далеко не в каждой фирме, даже по прямому запросу «поднимите мне уровень оплаты» HRD пойдет навстречу. зачастую, тебе нужно получить оффер, чтобы побороться за контр-оффер и удержание. это ужасная практика, которая подталкивает людей на уход из компании.
и тут вы спросите: так плохо, эдак не так. а как хорошо?
да все просто: performance review должен быть регулярным процессом, необратимым и объективным. для этого должны быть четко прописаны грейды и ожидания от них. кроме грейда, здесь еще играет роль целеполагание и достижение результатов. цели ставят обе стороны, достигает сотрудник, с помощью руководителя.
а salary review может быть нерегулярным и вызываться по запросу. в идеале — не дожидаясь просьб (многие даже не попросят), пересмотр в рамках вилки по грейду или даже самих вилок в грейдах. это процесс hrbp + cnb.
и, в итоге, сотрудник будет замотивирован выполнять цели чтобы иметь возможность получить грейд выше, пересмотр зарплаты. а работодатель должен быть чутким, чтобы сотрудник не дул на рынок при каждом чихе.
ну и да, премии — это отдельный разговор, как-нибудь в другой раз.