Ребята, привет!

А вот и первый тимлид, откликнувшийся на идею вести канал коллективно

Встречайте @antgubarev, одного из моих коллег, и его пост про холиварный вопрос - логирование времени: нужно ли, зачем и как привить его команде без диктатуры. Передаём слово

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

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

У меня не было цели использовать эти данные, чтобы спрашивать по утрам сотрудника “а почему ты вчера проработал не 8 часов а 7,5 ?!” (хотя по первости я так делал, каюсь). В первую очередь как воздух было нужно понимание происходящего на проекте. Сколько времени мы чиним баги, а сколько делаем новые бизнес-фичи. Сколько времени у нас уходит на поддержку интеграции с одним из внешних сервисов, а сколько с другим. Это позволило бы выбирать правильные направления в работе, отказываться от дорогих по времени частей, заменяя их чем-то другим, или проводить рефакторинг.

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

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

Трекать время:

😎 - можно, если осторожно
🤬- грех

Ребята, привет!

Сегодня запускаем рубрику: цитаты великих руководителей разработки

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

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

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

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

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

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

31 октября, а значит, время страшных историй 🙀

“Аааа, ничего не получается”,
“Я делаю всё не так”,
“Моя команда наверняка считает меня полным дном, пора собирать вещи и валить”

Доводилось ли вам испытывать такие чувства 🤯 А на регулярной основе?

Если да, то вы либо реально не справляетесь (сочувствуем), либо вы просто натренировали свою внутреннюю нейросеть видеть только ложку дёгтя среди сотни бочек мёда. Если второе — это синдром самозванца 😱

Как с этим бороться? Мы откровенно поговорили с человеком, которая провела с такой “профессиональной шизофренией” первые полгода тимлидства — а потом выдохнула и поборола эту дрянь с помощью:

• безумной бабки из сериала “Симпсоны”
• простого списка “трёх побед в день”
• и еще парочки практик, о которых рассказала в подкасте “Тимлид Позвонит”

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

p.s. Хотите поучаствовать в записи следующего выпуска — пишите @yeskelaveenrok, и тимлид позвонит.

Привет, сегодня у нас вопрос из зала!

Те, кто уже успел послушать вчерашний подкаст, спрашивают: что за синдром самозванца такой, и можно ли больше пруфов и деталей. Мы попросили героиню эпизода — Катю @crazycatwoman Митусову из Wrike рассказать побольше об этом деле. Передаём слово:

Этот психологический феномен был выявлен более 40 лет назад и не так уж и редок: по данным одного из исследований, свыше 50% сотрудников крупнейших ИТ-компаний хоть раз испытывали синдром самозванца. Его обладатели не могут принять свои успехи, обесценивают достижения и думают, что их “некомпетентность” вот-вот разоблачат.

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

Существует пять типов самозванцев, у каждого есть определённая модель поведения и страхи.

• Эксперт. Главный страх — знать не на 100%, дать неправильный ответ и иметь недостаточно опыта.

• Перфекционист. Главный страх — сделать хоть что-то неидеально. Часто ставит перед собой недостижимые цели, ему тяжело отпустить контроль.

• Superman/Wonder woman. Говорит “да” любой задаче, работает 24/7, но очень часто это нездоровая нагрузка.

• Гений от природы. Главный страх — если не понял или не сделал что-то быстро, то провалился.

• Ярый индивидуалист. Главный страх — просить помощи и делегировать.

Подробнее о каждом можно почитать в этой статье на Хабре.

p.s. Тоже хочешь писать в канал или задать вопрос его авторам? Обращайся к @yeskelaveenrok

Время анонимных пятничных откровений - а какой самозванец ты?

Привет, сегодня у нас в гостях Аля @EmptyKitty — тимлид команды “Деньги” в ivi, и её рассказ про

Парное программирование как способ подружить разработку и тестирование 🧑‍🤝‍🧑

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

В теории всё прекрасно, но на практике бывает так:

• тестеры только учатся писать код

• разработчики не погружены в проект автотестов, не могут оперативно и глубоко их ревьювить

• проект и автотесты написаны на одном языке, но у них разный CI, код-стайл, набор линтеров и подход к организации кода 🙈

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

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

О чём стоит позаботиться при организации парных сессий?

🤼‍♀️ Дай бойцам работать, с кем они хотят. Осознание, что “кто-то будет сидеть у моего компа и смотреть, как я туплю” — это страшно. Поэтому парное программирование — это ещё и история о поиске комфортного напарника: по темпераменту, по опыту, по скорости восприятия.

👁‍🗨 Синхронизируй их время. Если в спринте планируется такая сессия парного программирования — заранее забронируйте его в календаре у обоих, чтобы не навалились другие встречи, задачи, дела.

❌ Не планируй такие активности часто. Раз в пару спринтов — достаточно) По отзывам ребят, такой формат работ отнимает много сил, так как требует очень большой концентрации. А силы надо успевать восстанавливать.

p.s. Хочешь задать вопрос или тоже написать пост в канал? Обращайся к @yeskelaveenrok

Парное программирование

Привет! Сегодня в канале Карим @KarimAminov — руководитель QA в Eqvanta, и его история про то

Как транслировать ценности команде: пример из моей практики

Тестировщики — люди щепетильные, и была б их воля, проект не выходил бы в прод, пока не будет исправлен последний минор🙅‍♀️

Похвально, но это:

• бьёт по кошельку бизнеса, ведь мы увеличиваем time to market,

• влияет на отношения с разработкой: найти как можно больше ошибок, отдать их обратно и ждать c 🍿— не лучшая практика,

• а если бизнес не реагирует, сотрудники перестанут ощущать пользу от работы и могут начать "забивать" на неё.

Что делать? Я созвонился с одним из бизнес-заказчиков. Мы под запись обсудили, почему нам важно быстро выводить задачи в продуктив, что мы теряем и что получаем, если задача выполнена с минимально приемлемым качеством. Затем я обсудил это с QA-командой.

В итоге:

• каждый тестировщик начал осознавать, что значит простой по задаче и в чём важность его работы,

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

• мы сохранили качество тестирования на проекте.

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

p.s. Хочешь задать вопрос или тоже написать пост в канал? Обращайся к @yeskelaveenrok

p.p.s. Карим и дальше хочет делиться фишками работы с командой. Что думаешь?

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

Большинство заметок про выгорание заканчиваются советом: «сходите к психотерапевту» 🧑‍🔧 А вот что будет потом

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

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

• Время идёт, задача не сделана, я чувствую вину, ещё больше впахиваю 🌡

• Тут влазит заказчик. Он ругается, тем самым подтверждает, что «результат неидеальный» — и это отбрасывает меня обратно к началу задачи.

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

1. Я начал ставить себе промежуточные дедлайны. К каждому готовил пусть не идеальную, но рабочую версию 🤾‍♂️ Иногда это немного усложняло разработку, зато уже первый вариант часто устраивал заказчика.

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

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

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

Но это уже отдельная история...

Привет, решили начать собирать подборку материалов про то,

Как на удалёнке растить тимлидов из разработчиков и работать со стажёрами/джунами

Если знаешь полезные статьи и материалы по теме, либо хочешь расписать кейс своей команды на канале, пиши @ax8080. А пока откроем список парой историй.

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

🔎 Опыт Mad Devs. Из 25-минутного видео с доклада вы узнаете, как принимать стендапы от стажёров с помощью бота, как решать проблемы, если нанесён ущерб, и много других подводных камней и рабочих решений от хороших ребят из Киргизии. А если будет время, посмотрите и другие доклады с митапа тимлидов по той же ссылке (их там 3-в-1).

p.s. Другие подборки на канале собраны в списке полезных постов.

Привет, Антон @antgubarevcom Губарев продолжает поднимать вечные и холиварные темы. Сегодня он хочет поговорить с вами

Про переработки ⏳🎡

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

У нас в Skyeng в официальной вики четко прописано, что переработки не приветствуются. Но я:

• всё ещё встречаю рассказы о компаниях, в которых переработки не только распространены, но и поддерживается на уровне руководства 🤦‍♂️

• вижу ситуации, когда сотрудники пытаются перерабатывать по своей воле 🧟‍♂️

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

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

40 часов на работу в неделю

Ребята, привет!

Это Лёша Катаев, сегодня я сам у себя в гостях. Обещал иногда писать — стараюсь не реже 1 раза в месяц.

Иногда полезно оторваться от IDE, Slack, Хабра, reddit, Hacker News и взглянуть на мир вокруг. Вот мои способы отдохнуть и одновременно расширить свой контекст:

1️⃣ Kurzgesagt. Единственный youtube-канал, который я смотрю. Позволяет поверхностно и быстро понять, как устроен мир — на разных уровнях: как работает имунная система, как эволюционировало сознание, как умрёт Вселенная. Если не знаешь английский — включи русские субтитры. Мои любимые: Emergence – How Stupid Things Become Smart Together, The Origin of Consciousness, Everything You Need to Know About Planet Earth.

2️⃣ Wait But Why. Тот случай, когда качество победило количество. Каждый пост — 💥, каждый изменил меня и моё мировоззрение. Поможет, если ты уже задумываешься о смысле жизни и долгосрочных целях. Любимые: The Cook and the Chef, Neuralink and the Brain’s Magical Future, Taming the Mammoth, How to Pick a Career.

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

---

📖 Список самых крутых постов в канале

Привет! В гостях у канала Тигран @tintobro — продакт в GeekBrains и автор канала @blackproduct. Расскажет, почему SMART уже не тот, и как правильно описывать мечты. Передаём слово.

До недавнего времени я был адептом SMART 🧠 Использовал методику везде, писал статьи о ней. Но вот с чем я столкнулся: она подойдёт не всегда. Если ты учишь английский, то да, всё отлично. Формулируешь цель по SMART (Specific, Measurable, Attainable, Realistic, Time-bound). Получаешь: «Сдать сертификацию TOEFL минимум на 95 баллов к 15 декабря 2019 года», - и это то, что можно измерить и достигнуть.

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

Есть вещи, которые не под силу этой методике:

• Когда цель не конкретна (например, «быть счастливым»?) 😨
• Когда надо измерить мечту (как?) 😰
• Если хочешь сделать то, что никто и никогда не делал 😱

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

• Daft — сумасшедшая,
• Unrealistic — нереалистичная,
• Mental — идиотская,
• Bonkers — сумасбродная,
• Exciting — захватывающая,
• Ridiculous — нелепая.

Попробуй описать идею, о которой тебе говорили «да никогда не получится» в таком ключе. Получилось?

Привет! В гостях у канала снова Саша @a_stelm из Amasty. В прошлый раз он рассказал о проблеме «начинаю делать задачу — хочу сделать лучше — затягиваю сроки — меня никто не любит» и том, как решал её с психологом. Но как возникают такие бесконечные циклы самобичевания? Об этом он сегодня и расскажет. Передаём слово.

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

Что же такого он мог вскользь подумать? Например: «Я никогда не разберусь с такой сложной схемой». Теперь, чтобы ему не было грустно, он на автомате займётся другой задачей, из-за чего действительно не разберётся с той схемой 🤷‍♀️ И в итоге подтвердит свою ментальную установку «неудачника». Войдя в цикл, человек и дальше подсознательно начнёт избегать сложных задач.

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

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

На таком подходе основано целое направление психологии: когнитивно-поведенческая терапия. Если интересно, полистай эту книгу 📜

Мои разработчики

Ребята, привет!

Поздравляю с Новым Годом! 🎄
Особенно тех, кто много работал до последнего: планировал 2020, доделывал проекты, подводил итоги. Ведь теперь наступило время заслуженного отдыха 🎉

Помните, что нужно сделать? Удалить slack, убрать ноутбук подальше и вложиться в проект отдыха. Чтобы вернуться и фигачить с новой силой — менять мир.

В 2020 я собираюсь вернуться к каналу. Буду делиться новым опытом. Много постов не ждите — приходится работать, чтобы был материал 😂

А теперь немного демократии.
Выбираем тему для январского поста, всё из опыта последнего квартала:
1️⃣ Ключевые отличия роли CTO от тимлида
2️⃣ Как мы внедряли техническое ревью в 8 командах
3️⃣ Как я проектировал новую структуру разработки
4️⃣ Фреймворк годового и квартального планирования
5️⃣ Стратегическая сессия разработки: опыт, ошибки, советы
6️⃣ Проект централизованного найма: консистентность, SLA

--- 

📖 Список самых крутых постов в канале

Привет! Думаю, для всех неделька была сложной 😱

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

⏱ Но что если бы у тебя было всего 20 минут, чтобы:

📌 Рассказать своим бойцам, как держать фокус и не потерять себя при смене обстановки

📌 Понять, что делать и не делать лиду и как не потерять команду

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

Пользуйтесь и берегите себя!

p.s. Тем, кому привычней слушать 🎧 аудио фоном или видеть 👀 меня выступающим, посоветую свежую версию доклада про распределенные команды.

«Псс, псс, хочешь немного тестового?»

Бизнес любит тестовые задания, и у него на это 5 причин. А тимлиды должны уметь их готовить и использовать правильно: чтобы потенциальный новичок не сбежал 🏃‍♂️, а вы с командой узнали о нем все нужное 🔎.

Поэтому 16 мая днем мы собираем небольшую интерактивную онлайн-дискуссию про тестовые задания в разработке с участием:

• Ромы Ивлиева (Mos_ru, TeamleadConf),
• Саши Макарова (Yii Core Team),
• Вани Матвеева (Skyeng),
• Димы Симонова («Записки техдира») и других интересных ребят

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

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

Привет!

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

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

Сегодня мы делимся частью из них в статье. А я зашёл спросить. Хотел(а) бы послушать доклад на эту тему?

Привет!

— «Давайте перепишем все на эту технологию, она идеальна»
— «Вот так писать код нельзя, посмотри-ка статью этого крутого чувака»

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

Холивар это всего лишь следствие. Причина — в когнитивных искажениях 🤯 Том, как мы думаем, что выбираем и предлагаем правильное и лучшее для себя, команды и мира в целом, когда это не совсем так...

Один из моих тимлидов долго страдал таким: любил сам подлить маслица в огонь холивара. Теперь «просветлился» 😇 И в четверг собирает на ютубе Антона Назарова (автор отличного доклада о рациональности в ИТ), Григория Петрова (вот его рассказ про когнитивные искажения в планировании) и ребят из подкаста «Цинковый прод», чтобы обсудить:

• несколько анонимных, но реальных историй, как когнитивные искажения губили проекты и карьеры 🥀

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

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

А как у тебя с этой проблемой?

Привет!

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

Например, у нас в компании есть Олег Скляров: недавно он даже выпустил на Хабре пост, почему решил отказаться от этой роли и вернулся в сеньоры, хотя у него всё получалось. Многие знают Егора Толстого из «Подлодки» — и его историю перехода из лида разработки в продакты.

Как ребята поняли, что «хватит»? Как выбирали, куда двигаться дальше? Пришла идея выяснить это в формате публичного онлайн-интервью. Его проведёт Евгений 🐈 Кот — автор того самого доклада про экзистенциальный кризис тимлида.

Стрим пройдет тут в среду, 2 сентября — подключайся в 19 часов по Москве/Киеву/Минску. Или смотри в записи.

🎤 Будет ещё много интересных гостей.

Ребята, привет!

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

В 2020 шанс поработать на удалёнке и оценить ее плюсы и минусы получил каждый. И что, как тебе?

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

Привет!

Пару недель назад записали подкаст с Машей Поповой.
После целого года без выступлений и подкастов!
Говорим о жизни, о CTO, о проджектах.

Послушать можно на Sound Cloud, iTunes и Я.Музыке 🎧

Таймкоды:
3:06 — о себе
6:58 — топ-3 крутых продукта (Dynalist, Headspace, Huel)
16:20 — топ-2 книги, меняющих мировозрение (Rationality: From AI to Zombies и Принципы)
21:10 — что делают проджекты
24:47 — плюсы и минусы работы в Skyeng
29:39 — когда и почему без проджекта никак
33:10 — за что отвечает CTO
37:32 — как выглядят типичная неделя и рабочий день
43:59 — ключевой челендж на текущий момент: придумать фреймворк годового планирования
49:27 — как стать CTO
51:50 — совет себе назад в прошлое
55:30 — что дальше? куда расти?