Отвечай на добро

Есть очень простое правило сохранения и развития полезных контактов и связей: отвечай на добро. Если человек принес добро тебе – дай ему тоже что-то полезное. Не дожидаясь запроса.

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

Если ты хочешь, чтобы человек помогал тебе и в будущем – верни ему добро взамен. Это не обязательно деньги (хотя могут быть и они. Например, кто-то помог тебе получить клиента, порекомендовав знакомым – не грешно и отстегнуть за это часть). Это может быть встречный advisory с твоей стороны по другой теме. Это может быть сильный референс твоим знакомым, которым, как ты думаешь, услуги этого человека пригодятся. Это может быть "угостить ужином". Что угодно, в дополнение к "спасибо". Или предложение на будущее "если нужно будет X – обращайся в любой момент".

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

Если ты этого НЕ сделаешь – будет одно из двух. Либо человек ничего не подумает и в следующий раз поможет тебе только если его ОЧЕНЬ заинтересует задача по любым материальным/нематериальным причинам. Либо, что хуже (и что вероятнее, если его время стоит дорого), он при следующем твоем обращении подумает "блин, в прошлый раз час времени на этого парня потратил просто так, а теперь еще час потрачу. А зачем мне это?".

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

Трусость – смертный грех менеджера

Если ты НЕ делаешь чего-то (не проводишь сложный разговор / не запускаешь перестройку / не останавливаешь проект / не пробуешь новый стэк) потому, что ожидаешь конкретный негативный исход и можешь детально объяснить, почему он случится ("я отправлю Васю сделать X, в результате чего может сломаться сервис Y и мы потеряем деньги" / "я скажу Пете, что ему надо начать делать Z, ему это не понравится потому, что я точно знаю, что ему интересно X, и он уволится потому, что легко найдет оффер на рынке – я точно знаю, что он общался с конкурентами) – это нормально.

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

Опасаться неизвестности – нормально. Опасаться неизвестности и из-за этого стагнировать – плохо. И – да, чтобы что-то сделать, не обязательно быть абсолютно уверенным в этом. Если все же не получается – можно спросить у кого-то, кто уже такое делал 🙂

Кто-нибудь, сделайте курс по продажам для широких масс

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

––––

– Привет! Я из <X>, у меня есть такая-то вакансия и проект, обсудим?

<КАКАЯ ВАКАНСИЯ? ГДЕ ПРОЕКТ?>

– Привет! Расскажи подробнее? <пытаюсь помочь ситуации. Если ответ не придет сразу же, я его не увижу, тк сообщения читаю один-два раза в сутки и через два часа его смоет потоком>
– Можем перейти <в мессенджер X>?
– <вероятность того, что я все еще в чате и перейду в ДРУГОЙ мессенджер – сами посчитайте>

––––

Или вот еще:

– Привет! Мы делаем новое медиа-пространство, туда можно перенести твой контент, хочешь поучаствовать? Здесь можно узнать подробнее: <ссылка на презентацию из 12 слайдов>

<Разумеется, времени у меня есть посмотреть только первый слайд. Я вообще не был уверен, хочу ли кликать по ссылке>

– Привет! Свободного времени у меня только на то, чтобы поучаствовать, ничего не делая. У вас так можно, контент сами отзеркалите из канала?
– Да, напиши <контакт другого менеджера по привлечению>, там помогут

<Какого черта мне предлагает зарегаться на платформе не тот человек, который может сам меня туда сразу зарегать, если вдруг я соглашусь?>

– Окей..Пишу по новому контакту: Привет, мне тут рассказали, что вы новую медиа-площадку делаете. Я могу поучаствовать, если есть возможность легко туда мой контент перелить и посмотреть на трафик. Есть такая опция?
– Да. Тебе нужно зарегистрироваться <здесь>. Потом заполнить <вот это>. Потом адаптировать 5 своих постов под нашу площадку и...
– Понял, на связи...

––––

Думал привести ещё пример питч-дэка, но не буду, это было бы жестоко.

––––

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

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

Если ты супер-вовлечен и проактивен, очень стараешься, круглосуточно работаешь, но ничего не получается

Делай меньше разных вещей. Не прям одну, конечно, но и не 10, а, например, не больше, чем 5. Вот прямо сейчас пойди и найди способ передать/отказаться/быстро проебать половину.

Серьёзно, всё, это твоя карьерная консультация на сегодня, лучшей уже не будет. Измерь результат и качество жизни через квартал.

Дёшево и качественно не бывает

Помните несовместимый треугольник "быстро" — "дешево" — "качественно"?
Так вот, несовместимы не три вершины, а даже две: "дешево" и "качественно".

Мой опыт смещённый, субъективный, не соответствует твоему, но, закопав в разработку много лет на высоком уровне: я НИ РАЗУ не видел людей, которые берут мало денег и делают хорошо. Независимо от обстоятельств: друзья, "проект очень нравится", "миссия" и тд. Если "миссия" — бывает хорошо и бесплатно. Если за деньги, но маленькие — всегда какое-то говно.

Если, будучи линейным руководителем, ты управляешь командой "на метриках эффективности"

Ты делаешь что-то не то. Работу прямых подчинённых должно быть и так нормально видно. Если руководитель m1 крутой и реально понимает что делать — ему не нужно смотреть на метрику, чтобы ее улучшать, все и так перед глазами, достаточно знать, какое улучшение ожидают (в скорости/качестве/стабильности/всем сразу и тд).

Если, став руководителем 2+ уровня, ты управляешь командой без метрик эффективности

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

——————

Если после повышения у тебя что-то пошло не так — ОЧЕНЬ вероятно, что ты наступаешь на одно из двух)

Да, они МОГУТ этого не знать

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

Да, бывают разработчики, не умеющие пользоваться ide.
Да, бывают руководители, не подозревающие о том, что такое фидбек.
Да, бывают продакты, ни разу не проводившие А/Б.

Да чего далеко ходить — вот у меня канал, на который подписаны в значительной степени ребята, связанные с IT. И у меня, как и у всех, просел онлайн, когда для работы с telegram стал нужен VPN. Почему? Потому, что люди все еще не умеют пользоваться vpn. И — да, часть моих подписчиков, не умеющих пользоваться VPN, работает в IT. Так бывает :) Это, кстати, одна из причин, по которой некоторые разработчики в РФ (не из топ-тех, а обычные люди с земли) не адоптят нормально ллм-ки в работе — они тупо не открываются без vpn, а настраивать его самому — "сложно и лень".

Научившись так думать и начав проверять, ты сначала немного расстроишься, а потом станешь намного эффективнее коммуницировать и договариваться.

Иногда у меня спрашивают, как я развлекаюсь в свободное время

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

// Почему мои собственные посты при этом — такое говно с опечатками? Мои тексты не проходят никакого ревью, даже моего: если начну это делать, скорость выпуска замедлится в 5 раз.

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

Почему я решил написать об этом сейчас, а не утром? Потому что проклятое 362-е ревью я дописал только что, в 01:50 по местному времени. А вы как развлекаетесь?

Есть ровно один способ чему-то научить:

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

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

Других рабочих способов нет, пользуйся и не трать время на теорию.

Ребята, прекратите писать юнит-тесты!

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

Если ты делаешь не рокет-саенс, а туда-сюда crud и просто бизнес-логику — не надо дрочить покрытие методов и строчек кода. Покрой тестами сценарии использования целиком. Например, в случае с бэкендом, тест должен быть написан на "вызов http-хендлера + проверку того, что случилось с базой + проверку того, что вернулось", не, блин, на функцию, которая под капотом в этом пайплайне заголовок парсит. Гугли component testing, Фаулер, кажется, лет 10 назад название специальное придумал.

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

Работа с людьми — это отдельный набор навыков, которому можно обучить ТОЛЬКО человека, который этого хочет

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

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

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

Если сомневаешься, стоит ли делать человека руководителем, И ОН ТОЖЕ СОМНЕВАЕТСЯ — не надо этого делать. Скорее всего, он может приносить пользу иначе. Если уже сделал и понял, что, возможно, зря — звони :)

Кто я и зачем

Спустя пару лет существования канала я всё же сделаю интро:)

Мой бэкграунд без неожиданностей:

— stem, graduated with honors

— несколько лет разработки: движок репликации данных в большом и хайповом онлайн-банке (если кто-то из подписчиков встречал в своей жизни ods2, простите, ради бога, я был молод); софт для миграции тачек между облаками (из aws в azure, например, для желающих легко переместиться), другие околостартапные и неожиданно низкоуровневые начинания

— несколько лет tech startups в яндексе: mvp, пилоты, неожиданные взлеты и болезненные неудачи. Кикшеринг (надеюсь, вас не сбивали школьники на наших самокатах), умные камеры, финтех для водителей такси (если водитель жаловался тебе, что недополучает денег, можешь свалить на меня), whatever можно было придумать в городе на колёсах

— несколько лет трансформаций больших и тяжелых инженерных команд: логистика и стартапы фудтеха (где-то на ютубе есть перезалив старого выступления о том, как мы пытались переделать логистику всего, что связано с курьерами, из эпохи, когда я еще брился. В целом, на том же ютубе можно найти обо мне ещё). Затем Лавка (вы могли заметить, что в какой-то момент в ней появилось много разного, включая фарму, ритейл, маркет и what-not, а также она появилась за пределами РФ)

— потом я устал от построения карьеры и курса акций компаний, с которыми работаю

———

И начал заниматься только двумя вещами, которые я люблю:

1. Как получить от своего подразделения tech больше, не увеличивая бюджет?

Я видел много плохого и хорошего кода, плохих и хороших инженеров, правильно и неправильно выбранных метрик эффективности. Если N твоих разработчиков два года назад делали больше, чем делают 3*N сегодня — это сюда. Если одни и те же N стабильно меньше и хуже, чем ты ожидаешь — тоже сюда.

2. Как сделать "вот эту непонятную хреновину, которую негде скопировать"?

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

Обычно приходят с вещами на стыке сложной функции и непонятной технологии. Например (с поправкой на NDA): "а можно ли сделать умный девайс, ценой до X тысяч долларов за штуку, на котором будут крутиться такие-то модельки без бэкенда?" или "как бы нам сделать self-hosted агента, который красиво говорит на арабском?" или даже "как бы нам выжать еще несколько тысяч rps из монолита на php, который мы уже 5 лет боимся разбирать?"

Вот, собственно, и всё.

———

Если ты:

— Из любой позиции сталкиваешься с управлением разработкой (в том числе лично и напрямую в ней находишься) и хочешь получать больше результатов

или

— Хочешь сделать что-то сложное и никак не получается, либо ошибка стоит дорого и страшно даже пробовать

Приходи. Вот сюда можно написать о своей проблеме.

Бюджет Tech

Удивительно мало нанимающих менеджеров задают вопрос вида "когда ты в последний раз видел бюджет вашего tech и помнишь ли ты цифры из него, хотя бы примерно?", когда собеседуют технических руководителей высоких уровней, в том числе c-lvls.

Сейчас в меня кинут тапками крутые CTO, выросшие (как и я, кстати) по инженерному треку, но это один из важных факторов (наравне с "а как вообще устроен твой бизнес, на чем вы буквально зарабатываете?"), отличающих технического c-lvl от "руководителя разработки".

Когда cto впервые видит и вдумчиво считает деньги, вливаемые в разные команды и части продукта, иногда приходит озарение: "Б..ть, я 600к баксов в год трачу на команду, которая "развивает" продукт, приносящий нам непонятно что! А еще дополнительных QA туда нанимаю...А сколько, говорите, я плачу за нашу инфраструктуру?"

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

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

Если ты руководишь tech и все время недоволен их работой, но детали объяснить сложно — попробуй научить своих руководителей tech деньгам. Иногда это помогает :)