Многие проблемы с людьми на работе можно было бы решить, пройдя краткий курс психологии.

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

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

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

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

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

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

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

Сотрудники любят, чтобы их технологически развивали и всячески наставляли, и многие думают, что это можно получить только от руководителя с развитыми hard skills, но так ли это? Часто у руководителей в определенный момент встает ребром вопрос выбора между развитием технической экспертизы и софт скиллами. Как его сделать? Нужно ли его делать ?

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

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

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

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

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

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

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

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

Я расскажу про переезд нескольких продуктов внутри Booking.com с монолитной архитектуры и Perl на Java и микросервисы с точки зрения менеджера.
Расскажу:
* почему и когда это стоит делать;
* как продать это бизнесу;
* какие сложности возникают в команде и как их преодолеть;
* как понять, что все получилось (или нет).

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

В докладе мы обсудим общие принципы организации разработки таких продуктов:
- soft skills инженеров, требуемые в таких проектах;
- как организовать аккумуляцию и обмен знаниями;
- проектирование компонентов в условиях высокой неопределенности;
- роль peer review в обеспечении качества проекта;
- взаимоотношения с командой, внешними и внутренними заказчиками.

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

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

Когда же у тебя двадцать продуктовых full stack-команд, больше сотни одних только разработчиков, число репозиториев кода, стремительно приближающееся к трём сотням, а бизнес вынуждает тебя стремительно итерироваться в борьбе за мировое господство единственного продукта, который вы все делаете и который вас кормит (и в котором, между прочим, миллионы строк кода)… дела могут принять совсем скверный оборот…

… особенно для тебя, лида продуктовой команды и заложника, которому и сделать всё хочется получше, без скошенных углов, и легаси бы почистить, и торопливый бизнес порадовать — но при этом у PM'а не выпросишь и 10% спринта, пока всё не взорвётся, перерабатывать всё время невозможно — что делать, как не опустить руки?

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

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

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

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

Самое время всё запороть!

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

* Какие шишки мы набили и лайфхаки нашли в EORA, когда учились управлять Data Science-командой с нуля.
* Как мы сейчас строим процесс Data Science-разработки.

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

* Лидерство. Нужно ли интроверту становиться экстравертом?
* Идеальная пирамида тимлида.
* Все хорошие тимлиды делают это.
* Ошибки сделаны до нас, повторять их необязательно.
* Трансформация — путь к «идеальной пирамиде тимлида».

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

Рано или поздно и вовсе даже независимо от времени года и места проживания нашему инженерному брату в голову лезут всякие мысли. От банальных: “А что сейчас надо изучать?” до “Я и в 40 лет буду код писать?”. Классики называли это экзистенциализмом, а если по-простому, без зауми, то каждый рано или поздно спрашивает себя: “А что делать дальше?”. И вот тут и наступает порою самый переломный момент: как расти над собой и при этом заниматься тем, что нравится.

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

Одна из самых распространённых ошибок: берём хорошего инженера и делаем из него плохого менеджера. И вот уже код уходит из рук, подчинённые — "бездари, сам бы всё написал, да времени нет, эх, как раньше всё просто было".

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

Как угнаться за трендами, хайпами, блокчейнами, нейроннымисетями, биткоинкупитьбезкомиссии, когда так хочется спать?
В какой-то мере, отвечая Вадиму Макиашвили и его нетленке "36", попробуем ответить на классический вопрос "Что делать".

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

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

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

В компании Флант сейчас более 80 сотрудников, и мы все работаем удаленно, сопровождая более 100 DevOps-проектов. Но так было не всегда: за последние 7 лет мы проделали долгий путь и уже почти 2 года работаем в режиме полностью распределенной команды.

Расскажем, как мы пришли к этому результату, какие препятствия мы преодолели на своем пути, в том числе:
- как мы обеспечили клиентский сервис и воркфлоу задач в команде — способ удерживать внимание на десятке проектов;
- какие внутренние инструменты автоматизации мы используем — почему были разработаны свои сервисы, а не используются trello, jira и другие;
- какие у нас культурные особенности, и как мы подбираем сотрудников — почему не всем подходит удаленная работа;
- какие роли и зоны ответственности необходимы в команде — управление командой и борьба с прерываниями;
- какие мы используем подходы к планированию и описанию задач — как оставаться вместе, когда вас разделяет много километров.

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

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

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

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

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

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

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

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

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

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

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

Что, если в основу роста команды поставить культуру? Не best practice, не процессы и фреймворки, а культуру?

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

Поделюсь, как в нашей компании культура:
[+] помогает каждый день поддерживать быстрый рост команды;
[+] повлияла на распространение Agile-практик и фреймворков наряду с OKR и проектным управлением;
[+] оказывает влияние на принимаемые решения.

Только самое важное – без bullshit’а.

• Как должны появляться задачи, отвечающие интересам заказчика — цепочка от глобальной цели компании до постановки задачи с разбиением на слои. Зоны ответственности и выделение порождаемых артефактов.
• Проблемы и боли teamlead'а и команды разработки в целом при плохой/ неправильной/ неполной постановке задач.
• Критерии корректно поставленной задачи, состав минимально необходимой постановки для достижения успешного результата.
• Инструментарий по работе с задачами:
- валидация;
- техническая декомпозиция;
- линковка задач;
- оценка трудозатрат / технических рисков;
- приоритизация.

"Когда?" - наш Product Owner постоянно задавал нам этот вопрос, ожидая, что мы назовем ему точную дату релиза его задачи. Мы честно описывали техническое решение задачи и выставляли Estimate, но он не спасал. Задачи, оцененные в 2 дня, попадали на продакшн через 4. Мы оценивали время разработки, и это было не то, что нужно заказчику.

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

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

По многолетнему опыту обучения и личной работы с руководителями первого уровня (тимлидами, менеджерами команд и проектов) становится заметно, что их можно поделить на две большие группы (исключения бывают, но редко и точечно):
1. технические профессионалы — самый сильный программист в проекте становится его тимлидом;
2. коммуникативные профессионалы — те, кто хорошо умеют находить общий язык со всеми членами команды, «неадекватным» заказчиком, «странным» руководством и т.д.

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

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

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

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

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

В своем докладе я расскажу про процессы и инструменты, которые помогут изменить mindset и отношение к изменениям в команде.

Рассказываю о том, что принимают за выгорание, и чем оно является на самом деле. Помогу распознать этот синдром и найти его причину. Объясню, что неэффективно делать при выгорании и как лучше поступить, чтобы получилось не только Туда, но и Обратно.

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

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

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

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

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

Рынок IT-специалистов постоянно растет, и всем постоянно не хватает людей. За сильного специалиста обычно борется сразу несколько компаний, растут зарплаты и другие виды компенсации. Вывод: все IT-бизнесы заинтересованы в том, чтобы на рынке стало больше специалистов. Привлекая на этот рынок женщин, можно увеличить его на 10, 20, 30% или даже больше. Это значит, что если вы сейчас не вкладываетесь в привлечение женщин в IT, это делает кто-то другой.

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

Ты — тимлид. Ты уже настроил процессы разработки и тестирования: помог команде с автотестами, внедрил CI/CD и гитфлоу, все сервисы мониторятся и алертинги алертят. Ты участвуешь в найме, решаешь конфликты, адаптируешь новых сотрудников. Ты раздаешь и декомпозируешь задачи, помогаешь с оценкой и планированием. И что делать, когда кажется, что все процессы настроены? Куда и как развиваться? Какие еще возможности для увеличения эффективности и продуктивности команды и собственного роста?

«Не терпите гениальных придурков – цена для работы команды слишком высока!» (Рид Гастингс, основатель Netflix).

Сегодня для реализации IT-проектов командная работа важнее индивидуальной экспертности. Как кто-то сказал: «Век гениальных главных конструкторов прошел», – сложность современных задач просто не может уместиться в голове одного человека!

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

Разберем:
* Лидерство vs манипуляция.
* Псевдолидерство, «амбициозный коммуникатор».
* Тимлид и экспертная позиция.
* Работа с наиболее талантливыми.
* Психологическая «токсичность» и ее признаки.
* Организация командной работы для решения сложных проблем (в отличие от работы с задачами).
* «Психологические» алгоритмы и приемы в работе тимлида.

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

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

В компании, где проекты появляются с завидной регулярностью (а таких, мне кажется, довольно много) новые возможности, а также и новые зоны ответственности возникают повсеместно.

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

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

Я расскажу о практиках проведения встреч, церемоний, которые помогают принимать решения командой так, чтобы:
1) были использованы ум и опыт каждого члена команды;
2) его разделяли все члены команды;
3) решение содержало в себе вклад каждого участника.

Вам будет интересен этот доклад, если:
* вас не устраивает пассивность вашей команды во время принятия ключевых решений (по архитектуре, по внедрению практик, фреймворков и т.п.);
* вы хотите, чтобы никто не тупил в телефон или ноутбук во время командных встреч;
* вы периодически сталкиваетесь с ситуацией в вашей команде вроде "А я же говорил, что это работать не будет, но меня не послушали!".

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

Однажды я столкнулся с вопросом, как разложить знания в команде по полочкам? Как выяснить, кто в каких областях эксперт, а где у нас узкое место? Как грамотно показать точки роста или объяснить принимаемые решения по распределению работ и задач?

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

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

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

Нужна конкретика! В своем докладе я поделюсь детальными, применимыми советами по нескольким аспектам управления: ЧТО и КАК делать тимлиду. Я собрал практики, полученные опытным путем, в единый рецепт, который поможет вам взглянуть на свои привычные процессы и подходы со стороны.

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

Доклад призван предотвратить неочевидные, но распространенные ошибки тимлидов.
Киллер-фича — множество примеров и инструментов, которые можно внедрять сразу после конференции.

Техническое интервью — дело сложное.

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

Однако, с этим можно справится, применив инженерный подход!

Я расскажу о том, как можно построить процесс интервью так, чтобы:
- проверять готовность человека решать именно наши задачи;
- проверять не только знания, но и side — AKA soft-skills. В первую очередь — обучаемость;
- иметь возможность делегировать интервьюирование;
- оценивать результаты интервью количественно;
- получать повторяемые результаты.

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

В инженерном подразделении Контура работает 1200 человек. Это примерно 90 команд, распределённых по 9 городам или работающих удалённо. Я расскажу в докладе, как предлагать людям и командам «правила игры», которые выгодны для них и решают ваши задачи. Покажу на примерах, как это работает в Контуре: вы узнаете, как упростить найм с помощью свободного рынка труда внутри компании и пофиксить все уязвимости безопасности с помощью социального давления.

Не повторяйте это дома, а вот на работе — попробуйте.

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

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

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

Бывает так, что задач столько, что не вывести своими руками. И руками своих сотрудников тоже (если они есть).

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

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

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

С чем у вас ассоциируется DevRel?

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

Своё профессиональное развитие, развитие команды, мотивация, коммуникации. Задачи, где пригодится DevRel, — их много и они разные.

В докладе поделюсь наблюдениями, какие способы применения DevRel оказываются самыми полезными для тимлидов.