Илья Безделев о карьере в IT

Работа в Amazon и Google сильно отличается и, по моим наблюдениям, фундаментальная разница в том, как они работают с неопределённостью.

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

Гугл подходит к проблеме неопределённости с позиции “давайте начнём, а там разберёмся”. Можно сказать, что Гугл лавирует в потоках неопределённости и органически находит лучший путь сквозь тернии неизвестного.

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

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

Плюс подхода Амазона в том, что компания очень хорошо понимает, куда она вкладывает деньги и умело управляет этими инвестициями. Это также способствует интеллектуальной дисциплине в целом. Минус — это очень много работы, которая замедляет старт проекта. Эту культуру тоже выдержит не каждый — бывает, документы для начала новых проектов переписываются по 20-30 раз. Нужна выдержка, дисциплина и умение принимать жёсткий фидбек.

Где лучше?

Как говорил один мой русский коллега “to whom how”. Обе компании — супер успешные. Оба подхода работают. В неопределённости кому-то комфортнее плавать, а кому-то комфортнее искоренять. Иными словами, “кому как”.


Иногда меня спрашивают сколько часов я работаю. Этот вопрос на самом деле нерелевантный. Я “провожу на работе” около 8 часов в день, иногда чуть больше, иногда чуть меньше. Но работаю я всегда.

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

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

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

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

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


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

Примерно в 20% взаимодействий с людьми в сфере обслуживания и профессиональных услуг (рестораны, врачи, тренеры) сервис на порядок выше, чем в США. Эти люди глубоко клиенто-ориентированы, профессиональны и с огоньком в глазах решают вашу проблему.

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

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

Я говорю про администратора популярного ресторана, которая сказала гостям за соседним столиком “у нас не ресторан быстрого питания” в ответ на их просьбу принять заказ после 40 минут ожидания. Про отвалившуюся плитку, которую просто прислонили обратно к стене, авось не заметят. Про модное французское кафе на Красной Площади, которое открывается с задержкой на несколько минут несмотря на скопившуюся на улице толпу.

Попивая кофе в том кафе, я думал о том, почему в России, стране с первоклассными специалистами, присутствует такая расхлябанность в работе и отсутствие клиенто-ориентированности. И мне в голову пришёл термин “профессиональная апатия”. Люди не вкладываются в работу, не стремятся быть лучше, а просто хотят дождаться конца рабочего дня.

Им всё равно.

В английском есть выражение “do what you love, love what you do”, суть которого в том, чтобы делать любое дело качественно и с любовью. Когда человек выбирает делать только определённые дела качественно, а другие — на “и так сойдёт”, то он предаёт свою внутреннюю страсть к созиданию. Он давит её и превращается в неэмпатичного робота, который механически следует процессу. Можно сказать, что эти 8 часов в день на работе он и не живёт вовсе.

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

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

Долгосрочная ценность для бизнеса — в Customer Lifetime Value (CLV), ценности клиента на протяжении его “жизни”. Для сферы услуг ценность — в повторных заказах и сарафанном радио. Лояльность и увеличение CLV создаётся через “wow”, через экспириенс, которым хочется делиться с друзьями. Его создают люди, которым не всё равно, работающие на таких же, кто готов давать свободу и разжигать внутренний огонь, а не гасить его.


Когда люди меняют работу, они часто бегут “от” чего-то. От неинтересной работы, “не тех” людей, “не той” культуры. Многие ищут место, где трава позеленее, но в итоге приземляются в те же самые проблемы. Даже в популярной песне “Life” Юлия Зиверт поёт “если все вокруг не те, поищи в себе”.

Поэтому принято считать, что бежать нужно “к чему-то”, а не “от чего-то”. В этом есть здравое зерно, но проблема в том, что мы не всегда знаем куда бежать.

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

С каждым шагом происходит escalation of commitment (эскалация приверженности?), когда ты уже вложил столько усилий в этот путь, что не можешь соскочить с него, став жертвой когнитивного искажения sunk cost fallacy. “Утопленные затраты” это то, что ты уже вложил и, кажется, что, если соскочишь, то всё это было зря. В итоге “топишь” ещё больше затрат и можешь закончить руинами. Эти затраты уже утонули, их нельзя вернуть, но можно сократить будущие потери перестав вкладывать.

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

В подкасте Эзры Кляйна обсуждалась тема перехода из создателя в менеджмент. Эзра — создатель и основал компанию Vox Media, которая делает интересные подкасты. В какой-то момент он стал её СЕО и на шоу он рассказывал, как изменение в характере работы опустили его на самое дно. Он потерял себя. Тогда он принял решение уйти с важного поста и снова вести подкаст. И снова стал счастлив. Он прибежал “к”, убегая “от”.

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

Но в побегах “от” кроются огромные возможности. Желание сбежать — это сигнал тела, говорящий “что-то идёт не так”. Это повод начать внутреннюю работу и начать меняться. В этих поисках вы можете приблизиться к себе и увидеть мир с другой стороны даже в том месте, где вы уже находитесь. И можете более ясно увидеть своё “к”, которое до этого было более размытым. Побег “от” вырывает вас из инерции и застоя.

Побег “от” иногда нужен для того, чтобы создать себе перезагрузку. Начать что-то новое. Как говорил Гурджиев, “чтобы родиться заново, нужно сначала умереть”. Эта фигуральная смерть пугает людей, это риск, на неё сложно идти осознанно. Но когда ваша амигдала находится в режиме перегруза и вместо “бей” говорит “а давай-ка в этот раз мы лучше убежим”, это отличная возможность что-то поменять в жизни.

Только при одном “но” — бежать надо не сразу. Стоит остановиться, заглянуть в себя, долго смотреть внутрь, разглядеть новый вектор, а потом уже идти в его направлении. Это будет эксперимент. Там, куда вы придёте, тоже может оказаться не то. Тогда нужно пробовать снова и снова при условии, что вы всё же бежите от объективных факторов несовместимости. Важно не превратить побеги в крысиные бега от самого себя.

Я сбегал по-разному. 5 стран, 8 городов, разные работы, уходил где-то красиво, где-то не очень. Первые годы моей карьеры, ещё учась в универе, я бежал сломя голову, меняя проекты как перчатки. В итоге на этапе полного выгорания и потери себя я пошёл работать курьером в DHL, развозил посылки. То время дало мне возможность замедлиться и поразмыслить. Я ненавидел свою работу и в итоге сбежал от неё, но на тот раз уже “к” чему-то, что мне нравилось.

Все мои годы в DHL я был на качелях и в конце концов сбежал “от” — не дождавшись оффера от программы МВА, я ушёл из компании. В итоге я всё же получил оффер, но изначально я был готов идти на риск, потому что работать там я уже не мог. На МВА я шёл с чётким пониманием того, что хочу и добился этого, идя “к”. Но это не обошлось без падения на дно, пика депрессии, психотерапии и посвящения в духовные практики, которые помогли мне немного узнать себя.

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


Недавно был неприятный опыт с приложением, на котором можно объяснить принципы эффективной коммуникации Грайса (Grice maxims) и как они применимы в дизайне.

Контекст: я открыл приложение Литрес для аудиокниг и увидел странную надпись: “Пожалуйста подождите. Мы сохраняем ваши книги!” Именно так — без запятой после слова “пожалуйста”. Но неграмотность не была самой большой проблемой. Я ничего не мог сделать в приложении пока 30 секунд смотрел на эту надпись на медленном интернете на острове посреди Тихого океана.

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

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

Первый принцип “maxim of quantity говорит, что коммуникация должна быть информативной и давать ровно столько информации сколько нужно, ни больше, ни меньше. Сообщение в Литресе — всё, что угодно, но не информативная информация. Её мало и она не несёт никакого смысла для человека, не понимающего процесса “мы сохраняем ваши книги”.

Второй принцип “maxim of quality” — информация должна быть достоверной и “качественной”. Я думаю, сообщение в приложении достоверно в том смысле, что оно с точностью описывает какой-то внутренний процесс “сохранения книг”. Однако, оно не даёт никакой полезной информации пользователю.

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

Третий принцип “maxim of relation” — информация должна быть релевантной. Я открываю приложение и 30 секунд смотрю на это сообщение без понятия что происходит. Оно не помогает мне достигнуть моих целей. Оно не помогает Литресу достигнуть бизнес-целей. Оно нерелевантно для контекста, в котором показывается.

Ну и, наконец, последний принцип “maxim of manner”, который учит нас избегать неопределённости и двусмысленности. Отсутствие смысла (для пользователя) в неоднозначных сообщениях ведёт к неопределённости. Зачем? Почему? Любые ненужные вопросы, которые возникают у пользователя делают экспириенс хуже. UX должен “растворяться” и быть незаметным. UX — это лишь инструмент решения проблемы пользователя.

Принципы Грайса можно использовать двумя способами:

  • Глубоко их в себя впитать, чтобы “чувствовать” их. Для этого нужно тренировать мышечную память — анализировать текст в чужих приложениях, статьях и разговорах, чтобы учиться видеть несоответствия. А так же учиться самому выражаться в правильном количестве, достоверно, релевантно и ясно.
  • Проверять текст перед запуском продуктов и фич, используя принципы как чеклист. Ваш прекрасный продукт может быть похоронен заживо, если пользователь не поймёт как им пользоваться или будет раздражён интерфейсом. Если у вас не монополия на рынке, это может быть первый и последний раз, когда пользователь использовал ваш продукт, прежде чем перейти к конкурентам. Потому что не понял, что сделать, чтобы заплатить вам денег.

Принципы Грайса также показывают как принципы из одного домена можно применить в другом. О них мне рассказал Principal Information Architect, с которым мы вместе создавали в Амазоне чатбота. Он старше меня на 25 лет и занимается дизайном и информационной архитектурой дольше, чем я живу. От него я узнал про дизайн больше, чем от кого-либо — в первую очередь, он научил меня мыслить принципами. Вот вам и эйджизм в айти.

P.S. Как Литрес мог решить эту проблему? Вообще ничего не показывать. На главной странице приложения нет моих книг. Можно было показать обычный первый экран и “сохранять книги” в фоновом процессе, тем более, если он требует доступа в сеть. А уж если пользователь забрёл на экран, требующих “сохранённых” книг, там можно было показать spinner (крутилку, к которой все привыкли) с каким-нибудь полезным текстом.

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


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

В эссе “Maker’s Schedule, Manager’s Schedule” Пол Грэм описывает важность создания непрерывного времени для фокуса для специалистов и о хаосе менеджеров, чья работа во многом состоит из митингов. Для эффективности специалистов митинги бывают губительными, а менеджеры от митингов попросту устают, особенно, когда митинги неэффективны.

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

Плохие митинги — это те, где люди не вовлечены и сидят в своих телефонах, компьютерах или мыслях. Присутствуют, но не присутствуют. Они есть, но их нет. Знакомо? Плохие митинги тянутся как бесконечность и время ощущается как отдирание жвачки с подошвы. Сколько ни тяни, нить жвачки становится тоньше, но жвачка всё там же.

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

У хороших митингов список приглашённых включает только тех, кто может принести пользу или тех, на кого влияют решения, принимаемые в митинге. Важно соблюсти правильный баланс, чтобы не пригласить слишком мало или слишком много людей. Исключив кого-то, можно создать проблему, ну а если тебя позвали в митинг из 30 человек, то есть смысл спросить у организатора “в чём ты видишь мой вклад?” Это твоё время и у тебя есть контроль на тем, куда ты его тратишь. Будь рациональным.

По итогам хорошего митинга всегда есть следующие шаги и ответственные за них, прописанные письменно в общем документе или системе. В подкасте Postlight Пол и Рич говорили, что самый ненадёжный сотрудник — это “мы”. В митингах “мы” часто берёт на себя слишком много задач и вся команда чувствует себя хорошо когда “нам надо улучшить процесс Х”. Вместо этого, процесс Х должен улучшать Илья Безделев и через неделю он должен отчитаться о прогрессе.

Всегда должна быть ответственность (accountability). В Apple ответственный человек называется Directly Responsible Individual (DRI) и у каждой задачи есть DRI. Мне очень нравится их подход, потому что он убирает неопределённость из “мы”. DRI должен сделать всё, что нужно, чтобы добиться результата. Это включает в себя выполнение собственных задач, координацию с другими командами, и экскалацию руководству, если возникают тупиковые проблемы.

Теперь о второй проблеме — ненужности митингов. Митинги между членами команды — очень продуктивное время, в ходе которого рождаются идеи, решаются проблемы и строятся отношения. Такие митинги даже обидно называть словом “митинг”, потому что они супер полезны. Особенно, если эти митинги — спонтанные в коридоре у доски с маркерами. Но есть и другие, которые ощущаются как пустая трата времени.

Такие митинги часто имеют одну из двух целей: координация стейкхолдеров или брифинг вышестоящего руководства. Координация — неизбежное зло больших компаний. В каждом проекте есть зависимости, стейкхолдеры, yada-yada-yada (американское “и тд и тп”), которых нужно координировать. На таких митингах, как правило, много людей, говорящих по очереди, и сидеть в таких митингах, если ты отвечаешь только за небольшой участок работы — пытка.

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

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

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

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


Когда я пришёл в Google, синдром самозванца оставил меня примерно на 10-м месяце, а придя в Amazon пятью годами раньше я смог войти в струю и почувствовать себя уверенно за неделю. В чём была разница?

Предыдущие посты по теме: Синдром самозванца ч.2, Синдром самозванца в Google.

Я писал про три фактора, усложняющих смену работы: домен (область знаний и экспертизы), культура компании и позиция. Их и разберём на моём примере.

В Амазон я пришёл интерном Senior Product Manager на проект, связанный с рекламной платформой для amazon.com. Это был знакомый домен и у меня был весь необходимый набор скиллов в статистике, A/B тестировании, SQL, а также опыт с AdWords и AdSense, который был напрямую применим в работе.

Культура Амазона, основанная на документах, подошла мне идеально. Я люблю писать структурированные документы и скрупулёзно дорабатывать их через анализ и обратную связь до тех пор, пока не появится кристальная ясность. За неделю я освоился, стал “своим в доску” и успешно закончил проект, который принёс оффер на фулл-тайм позицию.

Придя в AWS (облачный бизнес Амазона) следующим летом, я освоился за пару дней и к концу первой недели уже написал первый черновик требований для нового проекта — платформы аналитики. Я опять попал в знакомый домен и, вдобавок, хорошо ориентировался в культуре. Через 4 года меня промотировали на уровень Principal, а ещё через год я перешёл в Google.

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

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

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

Самое важное в этом переходе — смена домена. Я перешёл из комфортной для себя области чатботов, веб-приложений и аналитики в облачную инфраструктуру. В самые дебри Kubernetes, Knative, Istio и других страшных названий. Что бы я ни делал, что бы ни читал, у меня всегда было ощущение, что я отстаю в понимании технических деталей. Мне приходилось звать с собой инженеров на разговоры с клиентами, потому что на каждом звонке меня заставали врасплох каким-нибудь техническим вопросом.

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

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

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

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

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

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

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

И, как говорят американцы — “fake it till you make it.” Это про меня, да и, наверное, про всех из вас, кто рискует и идёт в неизведанные для себя дебри.


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

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

История 1: из учителя в программисты.

В Амазоне я нанял девушку, которая пришла в программирование далеко за 30. Сандра 15 лет проработала учителем и решила, что пора что-то менять. Пошла в кодерский буткэмп, который обещал шанс трудоустройства, изучила программирование практически с нуля и пришла на стажировку в Амазон. После стажировки её взяли на фулл-тайм и спустя год она перешла ко мне в команду.

Моя команда на тот момент была на 100% мужской и мы были рады новой перспективе. Сандра была не просто новичком-программистом — у неё был опыт укрощения подростков, коучинга и презентаций. Она быстро схватывала новую информацию и вносила ясность в работу всей команды, задавая важные вопросы, о которых мы до этого не задумывались. Вся команда выиграла от её присутствия.

Мы “воспользовались” Сандрой, чтобы привлечь в команду больше женщин, так как это делало нашу среду более привлекательной, чем 100% мужской коллектив. К моему уходу из компании наша команда разработки состояла на 25% из женщин, что вполне неплохо для big tech. Сандра помогала нанимать женщин и коучила новичков. Одна из наших новеньких пришла в разработку из профессии медсестры в возрасте под 30.

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

История 2: как женщина-руководитель привлекает больше женщин в организацию.

Моим первым руководителем в Амазоне была вице-президент организации, создающей платформы для облачного UX. Дороти пришла в компанию в конце 90х совсем молоденькой разработчицей и доросла до уровня, который вне досягаемости для большинства людей в индустрии.

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

Как итог, у нас в организации был большой процент женщин на руководящих позициях, которые в свою очередь привлекали ещё больше талантливых женщин-специалистов. Естественно, никаких квот и поблажек из-за пола (“обратной дискриминации”) у нас не было — все кандидаты проходили одинаково жёсткий отбор. Но, получая несколько офферов, они выбирали тот, где они чувствовали бóльшую связь с командой.

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

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

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

Поделитесь историями — своими или людей, которых вы знаете.

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

Перешлите пост и комменты тем, кому нужна поддержка, тем, кто может поддержать и тем, кто ещё сомневается в том, что способность к программированию не определяется генетикой ❤️


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

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

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

Индустриальный дизайнер Рэймонд Лоуи (Raymond Loewy, 1893-1986) сформулировал принцип MAYA - Most Advanced Yet Acceptable. Он был инноватором, влияние которого по сей день живёт в американской культуре. Дизайны его автомобилей и бытовых приборов были основаны на правильной комбинации “наиболее продвинутых идей, которые всё же будут приемлемы” для потребителей.

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

Знания могут быть не переносимы из одного домена в другой, но принципы очень даже применимы. Один из самых ярких примеров в технологическом мире — концепция Lean Startup, родившаяся из принципов Toyota Production System, которые в свою очередь основаны на теории очередей и японской культуре.

Принципы из карате и буддизма можно заимствовать в изучении новой специальности. «Приходи на мат с белым поясом, несмотря на твой опыт» говорит нам о том, что нужно всегда ощущать себя как новичок, который ничего не знает и готов впитывать всё новое.

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

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

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

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

Когда я занимался композицией музыки, у меня не было оригинальных идей, но я знал, что хочу что-то необычное. Мне нравились Deftones, Depeche Mode и Sleep. Я стал разбирать музыкальную теорию и искать фишки, которые делают их звучание уникальным и нравятся именно мне. Потом я осознанно использовал эти находки и создавал музыку практически математическим путём. Это было сложно, но со временем начало усваиваться на подкорке и стало более естественным. Теперь я чаще слышу “фишки” в музыке.

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

Этот подход применим и к креативу.

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

Когда я перешёл работать в Google, “что-то как пошло не так”. У меня ушло около полугода, что бы докопаться до причины и, возможно, кому-то из вас эти инсайты будут полезными.

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

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

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

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

Ну и наконец — позиция. Если вы переходите с позиции продакт менеджера в одной компании на такую же позицию в другой, конечно же, будут отличия, но они будут минимальными. Но если вы переходите с позиции разработчика на позицию продакта (или наоборот), то разрыв будет колоссальный и вам придётся обучаться новой профессии на ходу. Люди, которые меняют профессию («войти в айти», я о вас), думаю, хорошо ощущают это на себе.

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

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

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

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

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

Что же пошло не так в моём опыте? Я поменял одну компанию с очень сильной культурой (Amazon) на другую с культурой, во многом диаметрально противоположной Амазону (Google). Я до сих пор адаптируюсь. При этом, я ещё и сменил доменную область на такую, в которой нет лёгких путей, один хардкор. У меня ушло полгода, чтобы не чувствовать себя самозванцем в разговорах с коллегами. Для сравнения, на предыдущих местах я через месяц-два уже был на пике эффективности.


После истории про мой опыт с SQL вы спрашивали как быстро осваивать технические навыки. Держите четыре принципа, которые помогают мне и помогут вам.

1) Фундаментальные знания

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

Моему поколению учиться было и сложнее, и проще. Сложнее, потому что не было бесконечного количества курсов, видео и статей. Была документация и несколько книжек. Многих библиотек и фреймворков ещё не было, а так же не было универсального доступа к информации в Интернете (Гугл запустился в 1998). Мы многое делали своими руками и приходилось делать даже такие вещи как манипуляцию пикселей на экране. Это было сложно и неэффективно, но важно для понимания основ.

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

Мы учились при помощи дедукции (от частного к общему), потому что у нас не было другого выбора. Сейчас можно обойтись без фундаментального понимания и хватать знания на поверхности методом индукции, идя от общего к частному. Но всегда будет оставаться ощущение пробелов в знаниях и новые технологии будут заводить в тупик.

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

2) Начинайте с простого

“Любая сложная система — это эволюция простой системы” (с) Systemantics by John Gall. Не хватайтесь сразу за Node.js, где асинхронность сведёт вас с ума и вы решите, что программирование — не для вас. Не трогайте Java и C++. Вообще не трогайте объектно-ориентированное программирование в самом начале. Начните с Python, который уже установлен на ваш Мак и легко устанавливается на другие платформы.

Идите постепенно от фундаментальных основ к фреймворкам, которые вы будете понимать, а не просто использовать. Первый год пройдёт медленно. Но через 5 вы будете профессионалом, который знает больше, чем 80% остальных людей в профессии и хватает новые технологии на лету, ведь все новые технологии без исключения основаны на старых.

3) Не отвлекайтесь

У нас было огромное преимущество — отвлекаться было не на что. У современного человека снижены способности концентрации из-за постоянной смены контекста, нотификаций и погони за лёгким дофамином развлечений.

Начали что-то изучать — сидите и изучайте. Отведите минимум 2 часа на каждое занятие, уберите телефон и не вставайте раньше времени. Когда я был в универе, я мог просидеть по 14 часов без еды, занимаясь одним и тем же. Сейчас я не могу себе такого позволить из-за детей, работы, да и выносливость уже не та. Но те часы работают на меня сейчас, 20 лет спустя. Думайте о себе будущем, которому будет легко за счёт вашей боли сейчас.

4) Идите туда, где вам нравится и хорошо получается

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

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


Этот пост был опубликован на моём инстаграме в виде стори с картинками, которые можно посмотреть тут.

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

Мой дед Сергей Лаврентьевич (RIP 😢) по ночам сторожил аптеку у родственников, но летом это мешало даче. Он предложил мне поработать за него, а всю зарплату отдать мне. Я согласился и пошёл за 1500 (я не ошибся нулями, полторы тысячи!) рублей ночевать в другом конце города на раскладушке в месте с фармацевтическим запахом.

Я уже не могу вспомнить где именно она была, но это был спальный микрорайон “Юбилейный” в Иркутске. Аптека закрывалась часов в 20, а в выходные в 17:00 и находиться там было адски скучно. Но там был компьютер 😈

На нем я сначала занимался по программе скорочтения и перечитал всего Достоевского. Это быстро надоело, уставали глаза за старым монитором. Тогда я решил научиться современным технологиям для интернета. На тот момент я уже знал HTML, CSS, JavaScript (он был не тот, что сейчас) и Perl. Так же был опыт с C++ и неплохие знания Pascal (под DOS). Я купил книжку по PHP и SQL и начал писать «Гостевую книгу».

В своей обычной ебанатской манере, я освоил оба языка за несколько ночей и после этого устроился на работу к @aleksandrpyankov разработчиком на PHP+SQL. Эта история освещается в подкасте @uehavshie (первый эпизод). Первые годы я использовал SQL исключительно для разработки бэкэнда на PHP и позже — C++ под Windows.

Когда я начал работать в DHL, SQL пригодился мне для коррекции времени сканирования отправок, которое мы зафакапили из-за перевода часов. Чтобы не разрушить операционные показатели, я разобрался как устроена БД корпоративного приложения на FoxPro (кажется), подсоединился к ней и сделал запрос, который убил нафиг все данные за тот день. Пришлось всё переделывать и мы ещё больше зафакапили показатели… хотфиксы в продакшене без тестирования - плохая идея.

Потом подвернулась вакансия аналитика в Москве, где нужно было знать базы данных в MS Access. Я купил книжку и за пару ночей освоил Access, сделал тестовое задание и получил работу в Москве. Так началась 5-летняя сага в бизнес-аналитике и переезды в разные страны.

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

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

Получив оффер на фулл-тайм, я пришёл строить облачную платформу аналитики, анализирующую миллиарды событий в день. Это было бы сложно без глубокого знания SQL. Я работал над ней год и переключился на чатботов, но использовал SQL (+Python) для анализа продукта и понимания паттернов использования продукта.

Когда я пришел в Google, знаете, что я сделал в первую очередь?

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

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


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

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

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

Всё было не так в детстве и юношестве — мне повезло вырасти без Ютуба и портативных плееров. Потребление информации в детстве было лимитированным и осознанным, но с приобретением первого смартфона в 2007 году, я пустился во все тяжкие потребления контента.

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

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


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

После интервью для подкаста @uehavshie я решился попробовать себя в подкастинге. Решение несколько месяцев варилось в котелке, но окончательно принялось “за несколько минут”. Мета-инсайт: этот пример показывает, как сложным решениям лучше дать придти органически, а не форсировать.

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

Я знал про платформы, потому что немного следил за развитием подкастинга на подкасте Бена Томпсона Stratechery, в котором, в частности, освещалось как Spotify купил Anchor и Gimlet Media. Gimlet Media — это компания-подкастер, которая началась с создания шоу Startup — подкаста про создание подкастинговой компании. Зачем я это слушал на протяжении нескольких лет? Очевидно, чтобы пригодилось сейчас.

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

Reaper достаточно сложный и… айтишники сейчас заценят… у него даже есть свой package manager. Для понимания этих концепций мне было полезно понимание npm и pip из разработки на Node и Python. Удобно, что не нужно с этим разбираться с нуля.

Я нашёл хороший туториал по редактированию подкастов в Reaper от компании Podigy, в котором много технических деталей, из которых 70% понятны благодаря тому, что я записывал вокал для демо своих песен и разбирался с эквалайзерами, компрессорами и шумоподавлением.

За один вечер я разобрался со всем, что мне нужно для начала подкастинга. Дело осталось за самым сложным — действием… скоро!


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

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

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

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

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

Что делать?

Нужно учиться понимать, что важно, а что нет. И для этого есть прекрасный инструмент — матрица Эйзенхауэра. Это матрица 2х2, которая в оригинале делит задачи на срочные/несрочные и важные/неважные. Я не люблю определение “неважное” и использую “менее важное”, а о неважных задачах стараюсь попросту не думать.

Матрица Эйзенхауэра
Матрица Эйзенхауэра

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

Вписывайте дела в секторы матрицы:

  • Срочное / важное — это самое важное прямо сейчас. Надо делать. Важно внимательно пройтись по списку и понять, почему эти дела важные и срочные и правда ли это. Кто определяет приоритет? Что случится, если их не сделать прямо сейчас? Если в этой категории больше трёх дел, то вы, скорее всего, неадекватно оцениваете важность.
  • Срочное / менее важное — это бестолковые авралы и вы сливаете в них энергию. Их нужно по возможности исключить. Например, могут быть проблемы системного характера, такие как отсутствие документации, ведущие к регулярной эскалации пользовательских запросов продуктовой команде. Это можно решить улучшением документации и процессов. Ищите пути системного решения таких проблем.
  • Несрочное / менее важное — эти дела можно оставить на потом, пока они сами о себе не напомнят. Мне нравится подход к приоритизации компании Basecamp — если фича/проблема/запрос реально нужные, вы не сможете их игнорировать, потому что вам со всех сторон будут говорить об их важности. Если же они неважные, то они так и утонут под весом более важных задач. Не бойтесь не делать. Другими словами, забейте.
  • Несрочное / важное — это золотая жила для долгосрочных результатов. Это те лягушки, про которые я писал ранее — дела, которые не хочется делать, но способные не просто принести краткосрочный результат, а поменять направление. Улучшение процессов для искоренения авралов дел обычно попадает в эту категорию. Легко фокусироваться на огне, который горит под носом. Тушение даже приносит удовлетворение в моменте, но важно отойти назад и потратить время на установку системы автоматического тушения пожаров.

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


Иногда хочется просто ничего не делать. А как же “действие, действие и ещё раз действие?” На самом деле, есть разница между ленью и ничего-не-деланием.

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

Лень — это самосаботаж и с ней нужно работать. Даже если она пришла как звоночек выгорания, потупить в инстаграм или нетфликс не спасёт ситуацию. Это вступает в силу лень второго порядка, или мета-лень, когда вы ленитесь искать истинные причины лени.

Ничего-не-делание хорошо показано в книге Роберта Пёрсига “Дзен и искусство ухода за мотоциклом”, которую я недавно начал перечитывать. В книге автор с сыном и друзьями путешествует на мотоцикле по американской глубинке в начале 1970х. Пёрсиг говорит, что “в маленьких городах в глуши люди охотно показывают тебе направление и спрашивают откуда ты, потому что им некуда спешить. Они могут себе позволить быть приятными”.

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

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


Вышел второй выпуск моего интервью для подкаста Уехавшие, благодаря которому я узнал, что знаю два слова… «как бы» и «то есть» 🤷‍♂️ Скажу об этом сам, пока мне не начали писать о чистоте речи.

Мы записывали подкаст 4 часа и получился очень интересный разговор. Напомню, что в первом выпуске я рассказал о становлении карьеры и переездах в Дубай, Сингапур, Германию и США.

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

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

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

P.S. Мне не нравится заниматься лайкоцыганством, но алгоритмы соц сетей и подкастовых платформ предпочитают контент, на который много реакций. Поэтому не скупитесь, ведь «один маленький клик для человека - это гигантский скачок для создателей контента» (с) Нил Циолковский.

Ссылки на подкаст


Порядочная часть моей работы — анти-гламурное принятие решений, которые со стороны могут выглядеть тривиальными. Иногда принятие решений растягивается на недели, а иногда — месяцы, потому что на вопросы нет правильных ответов. На любое предложение находятся серьёзные “но”, которые ставят весь план под сомнение.

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

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

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

Можно провести аналогию с одним из законов сложных систем из книги “Systemantics” (автор John Gall), который говорит, что любая успешная сложная система — это результат эволюции простой системы. А система, которую изначально запланировали как сложную, будет стопроцентно провальной. Так же и с карьерой.

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

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

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

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

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

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

P.P.S. С чего начать? Один из способов найти применение себя к сложной задаче с высокой ценностью — это исправить то, на что другие жалуются. Жаловаться — это пассивно-агрессивная и деструктивная позиция, если за ней не следует действие по исправлению ситуации. Не все ситуации можно сделать лучше, но какие-то можно, но только если начать действовать.


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

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

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

Было обидно от необходимости подстраиваться под систему, которую возненавидел, как мне кажется, именно в тот день, выходя из 20-го автобуса на улице Карла Либкнехта в Иркутске. Этот момент до сих пор стоит у меня перед глазами.

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

И знаете что?

Это ничего не изменило. Н.и.ч.е.г.о.

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

Так же ничего не изменило то, что в бизнес-школе я напрягся, попал в топ 20% по успеваемости и выпустился “с почестями”, пытаясь исправить свой ранний опыт. Выхлопа ноль, только эго потешил. Лучше бы провёл больше времени с ребёнком или почитал Нила Геймана.

Хочется сказать всем, кто парится — “не парьтесь, всё будет так как вам надо”, но такие советы легко давать только тогда, когда уже прошёл эту часть пути и вынес свои собственные уроки. Всем, кто только начинает карьеру, предстоит сделать свои ошибки, цена которых познаётся опытным путём.

За сим всё. Я пошёл париться из-за грядущей презентации директору.


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

Для начала надо отметить, что продакт менеджеры не работают на «проектах». Я отвечаю за развитие бизнеса, в основе которого лежит технологический продукт, и работа на нём бессрочна — она продолжается до тех пор, пока продукт существует. Результаты достигаются через запуски и другие проекты, для которых вместе разработчиками я задаю направление.

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

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

В какой-то момент начали складываться очертания того, куда я попал, и я начал документ под названием MVSR — Mission, Vision, Strategy, Roadmap. Миссия - это то, зачем мы существуем, высокая идея. Видение - цель на 3-5 лет. Стратегия - как мы достигаем видение и как это увязано со стратегией организации и Google Cloud. Roadmap - конкретные фичи, которые мы планируем сделать в ближайшее время.

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

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

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

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

Эти идеи пришли из трёх источников:

  • Физик Ричард Фейнман практиковал письмо всего, что он знает о предмете, чтобы увидеть границы своих знаний.
  • Мой бывший босс в Амазоне использовал документ MVSR, когда он пришёл в нашу организацию и наводил порядок.
  • Книга «Первые 90 дней» хорошо описывает баланс между техническими знаниями и организационным ориентированием на новом месте.

Итак, когда начинаешь работу в новой для себя сфере/команде/проекте:

  1. Максимально быстро получи общее представление о продукте, процессах, людях и технологиях через общение с людьми, чтение внутренних документов, просмотр видео и т.п.
  2. Начни писать то, что узнал. Это поможет как тебе, так и другим, потому что теперь «племенные» знания (tribal knowledge) становятся задокументированными знаниями и их легко передавать дальше.
  3. Возьми какой-нибудь проект, чтобы окунуться в детали. Погрузись туда с головой. Это поможет понять технические проблемы и ограничения, а также построить отношения с коллегами и пользователями.
  4. Пока у тебя свежий взгляд, подвергай текущие процессы сомнению, но не переусердствуй, так как ты ещё многого не знаешь. Просто задавай вопрос «почему» и изучай ответы. У тебя есть шанс изменить мышление команды к лучшему.
  5. Документируй всё. Повторяюсь, но это важно. Человек, который способен излагать свои мысли и синтезировать информацию письменно, сразу же приносит пользу любой команде. Люди это оценят.
  6. Поставь на паузу другие интеллектуальные задачи. Я на время перестал читать книги не по теме ибо мозг опух так, что я даже не мог нормально разговаривать после рабочего дня. Был перегруз от интенсива. Отдых важен.