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

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

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

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

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

Что же делать? Как снять эту боль?

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

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

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

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

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

Во-первых, в сложные годы особенно остро встаёт вопрос «а кто я?». Спрашиваешь себя: «Я вообще профессионал? Я что-то могу?» Многие начали искать работу на новых для себя рынках и, соответственно, задаваться вопросом — а нужны ли мы там?

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

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

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

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

Этого всего нет в других индустриях, так ведь? Или есть?

В недавней статье я писал о том, что не всем нужно развиваться. Теперь встаёт вопрос: а как же развиваться тем, кто хочет развиваться?

Даже если ты стремишься к развитию, это не означает, что ты должен учиться 24/7, читать что-то новое каждый вечер после работы, запускать по пет-проекту в месяц или контрибьютить в десяток опенсорс-проектов.

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

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

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

Но действительно ли всё это надо? Разработчик в самом деле обязан проводить всё своё свободное время за написанием кода? А обязан ли разработчик постоянно развиваться?

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

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

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

Привет!

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

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

Всем привет! Меня зовут Меньшиков Илья, я тимлид в Бизнес-юните классифайдов в VK.

Вместе с командой мы работали над сервисом быстрого поиска вакансий и сотрудников на основе геолокации – VK Работа. Рост продукта сопровождался ростом команды, поэтому мне довелось провести достаточно много собеседований на позиции разработчиков и накопить немалый опыт. Несколько раз мы перестраивали процесс найма в команду, убирая излишние шаги. В этой статье я хочу поделиться тем, как мы в итоге выстроили процесс собеседований: что меняли, от чего отказывались и что получилось в итоге.