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

Помните я собирал вопросы для CTO?
Ура, история получила продолжение!

3 сентября в Москве мы организуем митап Секреты крутой разработки. На наши с вами вопросы ответят технические директора из Avito, Яндекса, Тинькофф, Додо Пиццы, ЦИАН, Plesk и Agima. 🎉🎉🎉

Вопросы:
• Как крутые CTO понимают, что с разработкой все хорошо?
• Как производить улучшения в командах?
• Демократия vs авторитаризм
• Насколько глубоко нужно разбираться в технической части?
• Всё о найме
• Всё о деньгах

Если ты тимлид или CTO — заполняй анкету! В зале всего 60 мест, не откладывай.
Только хочешь стать тимлидом или живёшь не в Москве — смотри трансляцию. Запись тоже будет 🎥

Всем привет!

Начинаем налаживать обмен опытом между нашими тимлидами и теми, кто хочет ими стать.

10 августа — Пенза Тимлид платформы Vimbox Юра Юрин и подкаст "Девшахта" будут в местном бизнес-инкубаторе и его окрестностях. Ещё будет много интересного для php-шников. Если знаешь таких, поделись ссылкой https://clck.ru/HFoW7. Мероприятие бесплатное.

24 и 25 августа — Краснодар Сразу два наших тимлида приедут на масштабную Krd.Dev. Лови Ваню Матвеева, лида нашей маркетинговой разработки, если хочешь узнать о тонкостях гексагональной архитектуры и поговорить о DDD. С Кириллом Роговым, главным по WebRTC, можно поговорить о личном и командном планировании для тимлида. Конференция платная https://krd.dev/events/14, но вокруг есть много мест для посиделок.

P.S. Если ты двигаешь сообщество в своём городе и хочешь, чтобы наши ребята приехали к вам — пиши @yeskelaveenrok

Привет!

За последнюю неделю мне 10 раз скинули ссылку на карту навыков и развития тимлида. Кажется, это повод выложить ссылку в канал. Карта будет полезна тебе, если ты пишешь профиль для найма, описываешь ожидания от тимлида, составляешь PDP и KPI. База знаний и описание ролей выглядят сыровато, а вот MindMap полезен уже сейчас: составить карту на его основе или дополнить ту, на которую уже потратил недели, как в моём случае.

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

Всем привет!

А давайте применим магию краудсорсинга и составим огромный список принципов в разработке! В ответ на мои посты о книге Рэя Далио и принципах в команде биллинга трое подписчиков скинули мне принципы своих команд и компаний 🔥🔥🔥. Так и возникла эта идея: соберём со всех, отсортируем и поможем друг другу.

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

Поехали! Если у тебя в команде есть принципы — скопируй их в эту форму. Если их ещё нет — скидывай туда свои идеи.

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

Привет. Вызываем тимлидов на разговор. Точнее, звоним тебе!

Какие ошибки найма ты совершил, но больше никогда? Какие инструменты никому не посоветуешь, а какие хвалишь на каждом углу? Помнишь список вопросов для митапа CTO? Теперь мы хотим обсудить их с тобой. Все. По очереди. Голосом. А ещё послушать рассказы о командах, принципах и практиках.

Мои коллеги — три тимлида из Skyeng, запустили подкаст "ТимлидПозвонит" и ищут гостей для новых выпусков. Сам схожу в гости, если проект доживёт до 10 эпизода 😈

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

ТимлидПозвонит
• Расшифровка на Хабре
• Youtube
• Soundcloud

P.S. Пиши @yeskelaveenrok, если хочешь участвовать в следующих выпусках

---

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

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

Завтра в 19:00 мск мы перевернём календарь и проведём митап для CTO. На наши вопросы ответят технические директора из Avito, Яндекса, Тинькофф, Додо Пиццы, ЦИАН, Plesk, Agima, Mos.ru и Skyeng. Мы будем вести трансляцию на youtube, ссылка будет на лендинге.

Два моих основных способа развития как руководителя — такой вот обмен опытом с крутыми ребятами и чтение книг. И я, наконец, публикую список 50 книг для тимлидов и CTO!

Рейтинг составил на основе:
• количества рекомендаций от подписчиков канала
• популярности книги
• рейтинга книги

Как использовать список:
• Убедиться, что читал хотя бы половину из топ-10
• Выбрать книги для включения в PDP тимлида
• Посмотреть на список и всплеснуть руками: "Ну и бред! Стивен Кови вместо Кнута и Макконнелла!"

---

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

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

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

Встречайте @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. Тем, кому привычней слушать 🎧 аудио фоном или видеть 👀 меня выступающим, посоветую свежую версию доклада про распределенные команды.