Всем привет!

Я Максим Слепов, менеджер в сфере ИТ. Это мой канал, где я пишу о своей работе и мыслях по поводу неё. Изредка разбавляю заметками о джазе.

Мой карьерный путь в ИТ: разработчик 10+ лет, тимлид, руководитель проектов. Девиз на работе: мне больше всех надо!

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

Добро пожаловать!

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

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

1) Социализация, для многих важно видеть хоть кого-то, люди сами это говорят на 1:1, удалёнка и релокация делают людей счастливее не во всех аспектах

2) Быстрое решение острых проблем, когда все на месте

3) Рождение новых идей, когда ты "об кого-то подумал", и слышишь 2-3 новых мнения, до которых не додумался бы сам

4) Согласование действий: Вася думает, что Вова уже сделал что-то, а Вова думает, что это надо делать после Васи, и они оба вместе об этом молчат в чатах своих, пока их не спросит кто-то третий

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

6) Элемент синхронизации. Всё-таки все уже проснулись к 10 и готовы работать. Часто нужна совместная работа.

7) Заочное знакомство с продуктом. Кто-то рассказал про микросервис N, а тебе потом с ним работать. Какая-то информация да всплывёт в голове, потому что уже обсуждали.

⭐️ А вы как думаете? Сильно страдаете от 20-минутных созвонов в начале рабочего дня?

https://habr.com/ru/articles/866176/

Кстати, вот только сегодня случай на дэйлике. Практически дословно. Разработчик:

"В задаче в условиях написано подумать. Я не знаю, что я должен сделать".

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

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

И всё же, моё заключение такое: иногда нужно думать над способами и даже предлагать что-то стороне заказчика, например, в виде 2-3 вариантов заранее. В нашем случае этот путь максимально короткий, заказчиком выступает бизнес-аналитик, более того, он здесь на дэйлике с нами.

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

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

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

НЕФОРМАЛЫ НА СЛУЖБЕ

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

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

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

Обычно, когда менеджер начинает работать с командой, отделом или компанией, он понимает, что в книгах, обычно тех, которые запакованы в целлофан и стоят больше 3000 рублей каждая, описывают скорее идеальный мир, а в жизни всё устроено сложнее. Но и становиться ещё одним дедком-старожилом и заниматься эскапизмом в свои 25-30-40 лет не очень хочется: на руководящие позиции обычно стремятся люди, которым больше других надо.

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

Света иногда выдавала сумасшедшие комбинации. Но иногда месяц не выдавала результат. Иногда приносила очень крупную добычу, но иногда закатывала позорные истерики в офисе. В итоге она ушла от нас. Часть её клиентов не хотели работать ни с кем, кроме Светы, и пришлось вложиться в их удержание. Часть поняла, что купили через неё много лишнего, и теперь они переплачивают. Но к моменту своего ухода Света была лучшим моим сотрудником, и принесла единиц KPI в копилку команды больше других, это объективно!

Другой случай, вот совсем недавно. Был у нас работник, назовём его Вася (имя изменено). Хороший без иронии программист с лидерскими амбициями, глубоким знанием технологий вокруг, с богатым опытом. Работоспособный. Даже на время сделали ему мини-команду (он и второй программист), они пилили новые сервисы.

Вот только у Васи был минус: никак не хотел уживаться с другими. То открываешь его проект - а у него прямо в master коммиты типа "fix one", "fix after mr", просто "fix". То, наплевав на чёткую постановку в задаче, он сделает сервис совершенно по-своему, займёт на это в два раза больше времени, а потом ещё будет мочить рога на заказчиков, мол, они сами не понимают, как правильно. Формально он был даже вежлив, но каждый раз строил диалог со мной примерно так: "Максим, да, ты совершенно прав, что так считаешь, и поэтому я... (и далее говорил ровно обратное моей позиции)". В итоге мы с Василием расстались, не по злому, просто удачно подвернулись обстоятельства.

(продолжение https://t.me/playingjazz/10)

(окончание, начало тут https://t.me/playingjazz/9)

Что же делать с такими крутыми, но ершистыми специалистами? Мой опыт и наблюдения говорят однозначно: брать их под что-то конкретное, а потом без сожаления расставаться либо ротировать, если позволяет размер компании. Если у вас есть отдел R&D или спецпроектов - отлично, запускать их туда. Но только ни в коем случае не начинать строить работу "обычных" команд вокруг них, уповая на то, что они прямо сейчас приносят большую пользу. На долгосроке вред от некорректной коммуникации всегда перевесит пользу прямо сейчас.

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

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

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

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

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

Надо сказать, Маки я посещал в разных странах и городах: в Индии, в Париже, в Турции, в Гонконге и много где ещё. Везде всё было хорошо. Ведь McDonalds продаёт по всему миру две вещи: безопасную понятную еду всегда одинакового качества и её быстрое потребление.

К большому сожалению, "Вкусно и точка" скатилась по обеим метрикам. Про отравление уже сказал. Вообще, кажется, что вкус стал хуже, но это ещё можно списать на субъективный фактор. А вот когда ты занимаешься спринтерским бегом по лестнице после посещения заведения - уже нет. По времени тоже: для ВиТ стало нормой создавать очереди, заказ могут нести и 10, и 15, и 20 минут. Мой личный рекорд 28 минут! В MC дэдлайн 10 минут, и я помню лишь один раз, когда они его сорвали, с извинениями и заверениями.

У меня нет инсайда, почему так пошло. Однако можно заключить следующее: даже вся готовая инфраструктура и отточенные технологии не дают вам преимущества без регулярного менеджмента. Фокус в разговорах об управлении сейчас смещён на поиск "золотых таблеток", "вдохновения", "поиск лучших умов" и тому подобное. Фундамент, рутина, то, что даёт 99% результата, остаётся в тени.

У ВиТ были идеальные условия: MC открыл своё первое заведение в 90 году, то есть пробыл тут 32 года. Выросли поколения сотрудников и менеджеров, проработавших в этой системе. Остались поставщики продуктов, осталось оборудование. Думаю, остались многочисленные наставления от головной компании. Также остался огромный спрос со стороны рынка: на любом фудкорте очереди в Мак всегда самые большие. Казалось бы, что может пойти не так?

И самое главное, совершенно невозможно списать неудачу на сотрудников, персонал. В этом главный успех McDonalds как системы: они делают суперуспешный продукт много лет с самыми обычными людьми. Кто идёт работать в Мак на кассу, лучшие выпускники лучших вузов? - Нет, конечно. Во многих странах это вообще одна из самых низкооплачиваемых работ. В России тоже зарплаты не ахти. Вопреки всем мифам о русской лени, особенной "нетаковости", "вороватости" наших работников, они и в России показали, что система работает. И по моим ощущениям, в России вообще были самые вышколенные, самые чистые и быстрые Маки среди всех, которые я лично посещал по миру.

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

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

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

С Ольгой всё необычно с самого начала. Ну например, ей 50 лет, и она решила войти в IT. Очень неплохо показала себя на интервью, лучше, чем ещё десяток претендентов на место, понравилась и мне, и IT-директору, и мы её приняли. Первый месяц-полтора Ольга работала непосредственно в нашем офисе. И вот тут мы с директором начали понимать...

Например, с её стороны следовали такие вопросы: "А зачем у мышки правая кнопка, как это использовать?". Или "как сделать ещё одну вкладку в браузере?". Стало понятно, что опыт в резюме Ольги явно липовый (там было нарисовано полтора года работы в QA), и что человек вот прямо на моих глазах начал осваивать компьютер. Как, каким образом она смогла убедить меня и гораздо более опытного директора на интервью, непонятно, магия.

Спустя 2 месяца после такой работы, воспользовавшись случаем, я прямо сказал Ольге: "Слушай, или ты всему быстро учишься сама, или мы расстаёмся". У меня было 90% уверенности, что она уволится, и мы спокойно найдём профессионала с реальным опытом, а этот случай забудем как недоразумение. Но на моё удивление на том конце Zoom я увидел спокойное лицо и услышал слова: "Нет, я останусь работать тут, я подтяну свои знания". Честно, это даже было нагло с её стороны. Но твёрдость ответа подкупила, дал ей шанс.

И вот с момента разговора прошёл год. Ольга стала хорошим специалистом QA, прошла внутренний экзамен, который мы с Lead QA устроили ей. Зачем экзамен? - Ольга сказала спустя несколько месяцев после прохождения испытательного срока: мол, слушай, я мало зарабатываю и хочу больше. Я ответил, что нужно предъявить более высокую квалификацию, и тогда будет разговор. Ольга предъявила, я со спокойной душой пошёл выбивать для неё больший бюджет, и вот буквально следующая её зарплата будет ощутимо солиднее. А теперь я смотрю на итоги года, где она намолотила задач больше всех.

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

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

Начались длинные новогодние каникулы, и это отличный повод упомянуть о проблеме, которая почти всегда в тени. Сейчас её начал педалить Александр Сертаков. Например, тут https://t.me/truefinance/1443 и тут https://t.me/truefinance/1444 (больше читайте в его ТГ-канале).

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

Первая: демотивация сотрудников. Я слышал о российских (не японских) компаниях, где уходить с работы раньше начальника не принято. При этом странно: вроде как всеми разделяется мнение, что сотрудники должны достаточно отдыхать, чтобы выполнять свою работу качественно. Отпуска, новогодние каникулы. И тут же из "сотрудников" исключаются люди на верху иерархии в компании. Так что, парень, ты можешь отдыхать, но смотри, в кабинете начальника твоего Департамента свет горит...

Вторая: снижение работоспособности самих директоров. Да, на эти должности как правило попадают люди способные, мотивированные. Им зачем-то больше всех надо, они долго стремятся наверх, строят карьеры. Но всё же общие законы никто не отменял. Сертаков ссылается на исследования, согласно которым регулярные переработки и стресс дают снижение IQ аж на 15-20%!

Только вдумайтесь! Человек, решение которого стоит дороже всех, намеренно тупеет, чтобы в итоге принимать не самое лучшее решение. Грубо, но дело обстоит примерно так.

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

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

В канале "Тимлид очевидность" нашёл ссылку на интересную запись разговора: сам автор канала со своим коллегой беседуют с организационным психологом на тему групп и команд https://t.me/general_it_talks/758

У Дмитрия Болдырева https://t.me/dmiboldyrev достаточно радикальный взгляд. То, что обычно принято называть командой в IT, в его понимании полноценной командой не является. Основной признак команды - это то, что она сама внутри себя делит "добычу". К командам в таком понимании можно называть бригаду строителей, артель старателей на добыче золота или взвод спецназа на задании. А то, что обычно называется "IT-командой", является рабочей группой: мы можем работать вместе, но цели у каждого по сути персональные. Да, не секрет, что одна из самых больших коммерческих тайн, которую берегут практически во всех компаниях, является ведомость зарплат сотрудников: коллеги не должны догадываться, кому сколько достаётся.

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

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

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

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

ЦЕЛИ НА ГОД

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

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

Получилось конкретных 11 пунктов. Сначала 1-2 слова - название цели, потом немного подробнее, как это должно в итоге выглядеть и, где это уместно, 1-2-3 шага, как я к этому приду. Не стал делать талмуд с подробным описанием каждого чиха, но и не ограничился запиской "хочу, чтобы было хорошо". К записям возвращался в течение года несколько раз, но не часто. Так или иначе, желания были в моей памяти, тем более что я осознанно их сформулировал в начале года.

Что имеем спустя год. Прямо сказать, в некоторых аспектах вышла настоящая магия. Заключается она в том, что те вещи, которые были написаны ручкой, случились буквально. Причём иногда не в том контексте, который подразумевался при написании. Условно, я сначала видел, что будет A, потом B и как результат C. А получилось A, потом D и F, а потом вдруг неожиданно C. Делаю вывод, что подсознание так или иначе приведёт тебя к тому, куда ты хотел прийти, найдёт пути. Главное захотеть что-то конкретное.

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

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

Как говорили древние, medice, cura te ipsum! А главный инструмент по преобразованию окружающего мира - это я сам!

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

Прослушал выпуск подкаста Кода-Кода про инцидент-менеджмент https://t.me/kodakodacast/373 . Гостем был Андрей Чупейкин, CTO блока платформы в Ozon. Есть много интересных вещей, которые можно было бы приложить к работе в компании, где я сейчас тружусь. Но одно сильно бросилось в глаза, об этом хотел чуть порассуждать.

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

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

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

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

Хотя Андрей очень здраво говорит о необходимости элементарной координации. Я сам с этим сталкивался не раз и не два в своей работе: вот есть 2-3-4 взрослых человека, хороших профессионала, которые точно могли бы без меня разобраться и быстро починить прод. Но нужен именно какой-то дядя, который скажет элементарные вещи: Васенька, делай хорошо, а нехорошо не делай. И - о чудо! - буквально за 15 минут всё починили. Надо легонько подтолкнуть, но без этого легонько всё лежит очень долго. Я уже даже не переживаю по этому поводу - иногда странной безынициативности коллег - а просто принимаю как должное.

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

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

А вы даёте своим сотрудниками право ошибиться? Я даю, не часто, но заставляю себя убирать руки от штурвала. Конечно, понимая пределы.

Нашёл отличный канал с подкастами - "Бреслав и Ложечкин". Два спикера очень интересно и глубоко раскрывают темы, о которых рассуждают. И не в последнюю очередь потому, что есть реальный опыт работы в крупных компаниях: один из них создавал язык Kotlin, руководил командами в JetBrains, второй долго работал в Microsoft и Amazon, а теперь CIO в банке.

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

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

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

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

Ложечкин рассказывает реальный случай, когда в немецком подразделении Microsoft увольняли сотрудника то ли год, то ли два. Наконец добились увольнения, а он пошёл в суд и вернулся на работу, где продолжал бездельничать (со слов его руководителя). Теперь мне стало более понятно, зачем крупные корпорации выстраивают такое длинное сито отбора, и весь процесс затягивается на месяца. В другом выпуске подкаста, кстати, рассказывают, что в Amazon найм - это всего лишь 15% (!) проверка hard- и soft-скиллов, а 85% - проверка жизненных установок и соответствия культуре компании.

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

https://t.me/breslavandlozhechkin/13

Прочитал сегодня "Чёрную книгу менеджера". Кто-то из авторов каналов, на которые я подписан, рекомендовал её как "книгу, перевернувшую жизнь".

Мягко говоря, не впечатлён. Вообще не люблю хамского стиля и топорных истин. Наверное, лет до 25 такое заходило, потом перестало.

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

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

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

https://stratoplan-school.com/Storage/books/pdf/stratoplan_black_book.pdf

Сегодня у меня первый день участия в Марафоне от Стратоплана. Бесплатное мероприятие, 10 дней, из которых 5 дней - потреблять статьи, 5 дней - семинары в Zoom. И вот на какой мысли себя поймал.

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

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

Проблема только в том, что получает от этого человек? Вот если я сам лично ещё раз не окину взглядом статью, не посижу 10 минут не подумаю, что является самым ценным для меня, а поручу это всё ChatGPT, что останется в моей голове? Есть лёгкое подозрение, что меньше, чем после самостоятельной интеллектуальной работы. Как там в советском мультике про двоих из ларца, "Вы и есть за меня будете? - Ага!"

Это всё серьёзно, и кажется, мы ещё не очень понимаем, какую яму для себя роем. Любой навык без тренировки падает, умственный в том числе. Быстрые помощники лишают нас не только нудной рутины, но и со временем способности выдавать вообще какую-то работу. Во всяком случае, на прежнем уровне.

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

Занялись поиском разработчика в свою команду. Сделали резюме, воронку подбора, с HR отработали взаимодействие. Пошёл поток кандидатов. Назначаем интервью.

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

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

Очень дорогая оценка, надо сказать.