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

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

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

В общем, если написал длинное письмо — стирай его нафиг и назначай встречу.

Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода:

Важный принцип из ГТД — нужно отделить принятие решения от его выполнения. Скажем, хочу я пробежать Московский Марафон. Если я просто поставлю себе в календаре напоминалку за месяц до старта, что пора бы зарегиться на марафон, то в день напоминалки меня начнут одолевать сомнения: а надо ли оно мне? А смогу ли?

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

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

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

Этого не будет. Если такие ребята где-то и существуют, то странно, что мы нанимаем их, а не они — нас.

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

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

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

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

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

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