Если вы менеджер и хотите, чтобы ваши лучшие разработчики выгорели и разуверились в вашей способности руководить – могу помочь. Мне довелось работать в двух командах, подверженных выгоранию, и молча смотреть, как окружающие меня талантливые программисты один за другим покидали команду или компанию.
В первом случае я был ведущим специалистом в стартапе на посевной стадии с финансированием, работал непосредственно под и совместно с руководителем. Во втором я был одним из рядовых разработчиков, работал в команде из одиннадцати человек в составе крупной технологической компании (уровня Meta, Google, Apple и т.д.). Вот пошаговое руководство из методички выгорания, по которой работали эти команды.
Шаг первый: не доверяйте своим разработчикам
Первое, что нужно делать – контролировать разработчиков во всех мелочах. Они, конечно, умные, но точно ли понимают, как, по вашему мнению, должен выглядеть продукт? Наверняка нет.
В должности ведущего разработчика стартапа я работал в тесном контакте с руководителем. Он названивал мне постоянно, разговоры длились часами, мы закапывались в мельчайшие детали имплементации, которые никак реально не влияли на пользовательский опыт. «А ты уверен, что нам нужен именно DynamoDB? Почему эта Lambda-функция использует Python, а не Node?» Это постоянное дерганье очень утомляло.
Работая в команде крупной корпорации, я тоже имел мало свободы в своих действиях. И нельзя сказать, что вина лежала на моем начальстве – просто вся система была так устроена. Помню, как-то раз я проектировал архитектуру системы, которую тогда создавал, и мне полунамеками сообщили следующее: «Имплементация этого проекта должна пройти вот таким путем. Да, я понимаю, что это займет гораздо больше времени, но мне так нужно (чтобы мои промо-материалы потом смотрелись эффектнее)».
Я убежден, что на самом деле лучших специалистов привлекает и удерживает одна простая вещь: с ними обращаются, как со взрослыми людьми. Если вы нанимаете лучших из лучших, нет никакой необходимости заваливать их правилами и политиками, чтобы добиться хорошей работы. Они профессионалы – так дайте им возможность маневрировать, самим оптимальным образом организовывать свою работу и отвечать за результат. С этим они, вероятно, справятся лучше, чем вы.
Марк Рэндольф, сооснователь Netflix
Шаг второй: введите ненужные, тягомотные процедуры
В период моей работы в стартапе в один прекрасный день меня стали заставлять расписывать огромные дизайн-документы, прежде чем браться за реализацию чего бы то ни было. Создание любого, даже самого крохотного эндпоинта API требовало бесконечных предварительных обсуждений. Неожиданно имплементация новой функциональности стала занимать уже не несколько дней, а несколько недель. Хоть на стену лезь.
И что самое худшее: продукт тогда еще даже не дошел до стадии релиза! Все эти процедуры были абсолютно бессмысленны, ведь мы пока и копейки выручки не получили. Послушайте, да, в Google сложилась культура, которая строится на куче дизайн-документов и одностраничных презентаций. Но, пока вы на стадии стартапа, вы никакой не Google. В Google культура письменной фиксации необходима, так как это компания огромных размеров и состав сотрудников в ней постоянно меняется.
В этом отношении легко перегнуть палку. В одной из команд крупной корпорации набор обязательных процедур нередко затягивался слишком надолго. Чтобы получить доступ к данным определенного типа, мне нужно было отправить письменный запрос, на который члены другой команды должны были вручную дать согласие – в итоге работа у меня стопорилась на несколько дней. Для запуска новой функциональности требовалось одобрение специалистов по безопасности, продуктовой команды, технического отдела, юристов, аналитиков, следящих за соответствием требованиям, и собаки директора.
Случалось, что у меня целый день уходил на правку документов, рассылку электронных писем, чтение документации и разговоры с коллегами. Я занимался вещами, которые не давали никакого выхлопа, и не потому, что мне этого хотелось.
Сломанный руль – метафора того ощущения на работе, когда твои действия, кажется, вообще ни на что не влияют. Вроде поворачиваешь, а машина всё равно едет прямо. В рабочих профессиях такое случается редко: там собрал машину – появилась машина. В интеллектуальном труде такое сплошь и рядом: ну, отправил ты письмо, и что?
Эмметт Шир, сооснователь Twitch
Конечно, подобные процедуры бывают необходимы, но и баланс тоже нужен. Не каждый проект, над которым работает разработчик, требует следования всем этим процедурам, и, соответственно, их не всегда следует вводить. К счастью, не все команды в крупных корпорациях такие. Я бы даже сказал, что их меньшинство.
Шаг третий: не позволяйте коду дойти до клиентов
Нет ничего хуже, чем восемь месяцев корпеть над тем, чего никто никогда не увидит. Особенно если в течение этих восьми месяцев вам то и дело приходилось засиживаться на работе допоздна. А еще того хуже, если эти восемь месяцев растягиваются до двенадцати, шестнадцати, двадцати, а потом весь проект зарубают, и то, над чем вы трудились, никогда не доходит до людей, которые могли бы этим пользоваться.
По рассказам разработчиков, работа над тем, что никогда не выходит на рынок – один из основных источников выгорания.
Релизы вдыхают жизнь в образ нашего мышления. Цикл обратной связи приносит нам новые знания, придает уверенности для быстрого принятия решений, а значит, ускоряет темп работы. Высокий темп совершенствования продукта радует и увлекает пользователей. То, что мы сразу видим плоды своего усердного труда, мотивирует нас продолжать работу. Создание команды, где старания быстро дают результат, расширяет возможности, что привлекает новых людей, и, как следствие, нанимать сотрудников становится проще.
Из статьи Shipping is your company’s heartbeat (2013)
В стартатпе, где я работал, мы вкалывали над продуктом целый год, прежде чем он попал в руки хотя бы одному клиенту. Всякий раз, когда нам казалось, что продукт уже готов к релизу, руководитель просил добавить «еще пару инструментов». Спустя какое-то время команда потеряла веру в то, что руководитель сможет довести проект до ума. Тяжело было эмоционально вкладываться в работу, получая обратную связь только в виде измышлений начальника, а не впечатлений реальных пользователей.
К моменту выхода на рынок продукт должен не содержать багов и обеспечивать хороший пользовательский опыт. Но безукоризненным он быть не обязан. Когда начальник начинает гнаться за недостижимым идеалом, для команды это не означает ничего хорошего. Особенно учитывая, что мы еще даже Product-Market Fit на тот момент не достигли. Перфекционизмом часто прикрывается прокрастинация. Оглядываясь назад, я предполагаю, что наш руководитель попросту оттягивал тот момент, когда придется реально продавать продукт и получать критические отзывы.
Работа в крупной корпорации сопровождалась постоянными реорганизациями, директора и вице-президенты то и дело сменяли друг друга. После очередной реорганизации приходил новый начальник с новым видением будущего компании. Иными словами, требования постоянно менялись, многие проекты, работа над которыми велась месяцы, а то и годы, отправлялись в утиль, и нам не удавалось увидеть, как наша работа меняет что-то в окружающем мире.
Иногда продукт не доходит до пользователя из-за отсутствия концентрации. Когда за проектом не стоит четкого представления о его перспективе, он обречен на провал.
Джони Айв приводил такое высказывание Стива Джобса о концентрации: «Концентрация – это не то, к чему стремишься… и не то, что практикуешь по понедельникам. Она должна не покидать тебя ни на минуту».
Источник
Бонусный шаг: побольше обещайте, поменьше выполняйте
Этот шаг – кульминация всего, что говорилось прежде. Последний гвоздь в крышку гроба, так сказать. Большей части программистов из команд, о которых я говорю, слишком щедро давали обещания, но обещанных благ они так и не получили.
В моем стартапе, в течение того года, когда продукт всё никак не мог дойти до релиза, руководитель какое-то время проводил сбор пожертвований. Изначально у меня была значительная доля в компании, однако сбор пожертвований до этапа Product-Market Fit привел к тому, что стоимость моих акций стала снижаться. И существенно. Внезапно стартап утратил для меня привлекательность с финансовой точки зрения – я бы мог заработать столько же за десять лет в крупной корпорации, даже если экзит бы принес миллиард долларов. Вот только в корпорациях оплата гарантирована и производится ликвидными активами, а миллиард как результат экзита – очень редкое событие в такой среде.
В крупной корпорации каждый уволившийся разработчик устраивался на работу по одной из следующих причин:
- Видение продукта: его захватила концепция продукта и способность решать те или иные проблемы.
- Возможность расширить границы и засветиться: ему казалось, что он сможет расширить поле своей деятельности.
- Улучшение карьерных возможностей: то, что он расширит набор навыков и окажется на виду, могло привести к продвижению по карьерной лестнице.
Увы, из года в год каждый из этих разработчиков по крупице терял надежду когда-либо достигнуть своей цели. А ощущение безнадежности ускоряет выгорание. Причины, побудившие их устроиться в компанию, никак не реализовывались в действительности. Когда разочарование достигало определенного предела, они уходили.
В конечном итоге выгорание добралось и до меня. И я тоже уволился.
Основные выводы по выгоранию
Выгорание не всегда связано с продолжительностью работы
Сейчас я работаю больше, чем в тех командах, где выгорел. Чувствую себя при этом замечательно. Я получаю удовольствие, развиваюсь и своими глазами вижу, как моя работа влияет на жизнь пользователей.
Всё же нужно отметить, что выгорание действительно может проистекать из слишком большой нагрузки. Удаленка создала дополнительные условия для выгорания, так как работа и личная жизнь стали менее четко отделяться друг от друга. Легко проникнуться чувством, что ты находишься на некоем «бесконечном дежурстве».
Выгорание приходит тогда, когда мои старания не имеют значения
Если выкладываешь в какое-то дело много времени и сил, хочется, чтобы это к чему-то привело. Когда тебе предоставляют свободу в работе над проектом и ты доводишь его до релиза, это ощущается как достижение. По мне так лучше пусть проект окажется полным провалом и крахом, чем вообще не увидит свет.
Мне нужно проникнуться миссией
Описанный опыт привел меня к осознанию, что для меня важно разделять миссию команды. Если мне безразлично та область, к которой принадлежит продукт, и те знания, которые может передать мне команда, то выгорание неизбежно.
Сомнения в миссии – это то состояние, когда начинаешь задаваться вопросом: «А зачем я вообще это делаю?» Обычно оно приходит вместе с устойчивым благополучием. Если тебе позарез нужны деньги, которые заплатят за эту неделю, дураку понятно, почему ты делаешь то, что делаешь. Но если представить, что тебе не о чем тревожиться следующие полгода? Или пару лет?
Здесь всё индивидуально. Лично мне удовлетворение приносит то, что моя работа чему-то служит; другим его может приносить совместная работа с другими людьми, возможность содержать семью или учиться чему-то новому.
Выгорание – более распространенное явление, чем я предполагал
Почти половина от общего числа сотрудников сообщает, что в некоторой мере ощущает выгорание, и это, скорее всего, заниженная цифра по сравнению с тем, как обстоят дела в реальности.
