Вскрытие об уходе с работы моей мечты через 4 месяца

Часть 1: Введение

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

[1] Существует мнение, что Google квалифицирует систему как «достаточно сложную».

1.1 — Цель

«Все проблемы — это ваши проблемы». — Мой старый наставник, в 1:1"

«Все проблемы — системные проблемы» — Тот же наставник, на собрании команды

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

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

1.2 — Пояснения

«Самая большая проблема в общении — это иллюзия того, что оно произошло»
— Конор Кенни.

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

1. Этот документ предназначен для анонимизации. Многие учетные записи объединены из нескольких событий. Не связывайте ничего в этом документе ни с кем из сотрудников Google.
2. Мой опыт ограничен. До этого я работал только в одном стартапе, и у меня нет точки отсчета в отношении масштабов проблем, которые я поднимаю. Я не утверждаю, что какая-либо проблема является причудой моей команды, проблемой всей отрасли, проблемой, уникальной для Google, или любыми другими подобными утверждениями.
3. Система работает достаточно хорошо для большинства инженеров. Цель этой части состоит в том, чтобы расширить рамки того, для кого это хорошо работает и в какой степени.
4. Каждую неделю инженеры сталкиваются с многочисленными сложными решениями как на техническом, так и на межличностном фронтах. Важно отметить, что любое решение, которое попало в этот документ, является «выбранным» и не отражает таланты какого-либо сотрудника Google.
5. Этот документ написан с примесью сухого юмора, который может показаться негативным, особенно в некоторых заголовках. Обещаю, что все будет беззаботно и в хорошем настроении.

Часть 2: Об инженерии

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

2.1 — Как решить любую проблему в истории человечества

Руководство для начинающих

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

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

2.2 — Отключение предупреждений

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

Я не получил свой ноутбук в течение первых 4 дней, что заставило меня чувствовать себя позади после первой недели работы в Google. Меня заверили, что «просто привести вас в офис в течение первой недели — это уже победа!», и мне было предложено несколько десятков часов дополнительных ознакомительных материалов. Когда я пытался поднять вопрос, меня заверили: «Первые несколько недель — пустяк!». Я попросил об ответственности, и если бы мы могли установить график работы с материалом. Мне сказали не беспокоиться об этом и делать все, что мне нравится.

Подобные заверения давались каждый раз, когда я пытался выразить беспокойство: «Я недоволен своим прогрессом» приводит к «Подключение к Google может занять месяцы! Не беспокойтесь об этом!».

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

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

2.3 — Решение проблем, которых не существует

Иногда его называют «Создание проблем».

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

Еще одно запоминающееся взаимодействие было примерно таким:

Гуглер : «Синдром самозванца очень распространен в Google! Хочешь поговорить об этом подробнее?»

Я : «Нет, у меня нет синдрома самозванца. Можем ли мы переориентироваться на XYZ?»

Сотрудник Google начинает перечислять ресурсы для борьбы с синдромом самозванца

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

2.4 — Ответственность

Первый шаг к решению проблемы — решить попробовать

В конце концов я имел честь присутствовать на Q&A Noogler, где у меня была возможность задать вопрос вице-президенту. «Я считаю, что отличные результаты следуют за отличными процессами. Передача знаний, адаптация, проверка и другие подобные процессы — это то, о чем мне больше всего интересно узнать здесь, в Google. Какими процессами в Google вы больше всего гордитесь?». Вкратце их ответ был таким: «Я согласен, что все эти вещи важны. У них всех есть возможности для улучшения в Google».

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

• Признание основной проблемы, ощущение, что Google — это не то место, где процесс глубоко ценится или о нем думают. Обсуждение того, почему я так думаю.
• Обсуждение частей процесса, которыми гордится другой гугл
• Организация какой-либо встречи или процесса, направленного на итерацию нашего процесса.

Ведущий : «Я не могу реконтекстуализировать комментарии вице-президента»
Я : «Можем ли мы подробнее обсудить мои опасения по поводу инженерной философии»
Ведущий : «Давайте попробуем переориентироваться на то, что я могу сделать, чтобы помочь как лидер».
Я : «Просто слушать было бы полезно. И есть шанс, что мы могли бы найти способ, которым вы могли бы помочь, поговорив об этом. Вы не знаете, что не можете помочь, если не знаете проблемы».
Ведущий : «Ты только что сам себе противоречил. Вы просили меня «просто выслушать», но также просите меня помочь».

Товарищ по команде, объехавший полмира на GVC, не может помочь с большинством физических проблем. К счастью, редко когда инженер не может попасть в свой офис из-за того, что входная дверь заблокирована валуном. Чаще проблемы носят мозговой характер, и лучший первый шаг к решению таких проблем — вдумчивый разговор с другими инженерами. Я призываю вас быть готовыми, вы, скорее всего, сможете помочь, чем вы думаете[2].

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

Часть 3: Об инженерах

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

3.1 — Сотрудничество

«Силою дружбы мы сможем преодолеть любые препятствия!»
- Мой маленький пони: Дружба - это чудо

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

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

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

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

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

3.2 — Связь

«Вы можете иметь все это. Только не все сразу». - Опра Уинфри

Существует бесчисленное множество способов передать определенную информацию. Несколько вариантов более вежливы, чем другие, поэтому мы выбираем один из них. А прямолинейность полезна, поэтому мы сужаем наши варианты до тех, которые воплощают это качество. Думайте об этом как о диаграмме Венна, где наш окончательный выбор находится где-то в объединении всех атрибутов, которые мы хотим, чтобы наша речь воплощала. Чем больше положительных качеств мы прибавляем к нашей речи, тем более скованной она становится и тем дальше развивает наше риторическое мастерство. Пока, в конце концов, мы не вынуждены начать идти на компромиссы, на которые мы не собирались. Любое «качество», которое мы явно не пытаемся поддерживать в своей речи, теряется.

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

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

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

Какая шина на автомобиле важнее? Кажется, что и прямолинейность, и эмпатия необходимы для полезного общения. Также кажется, что для получения наилучших возможных результатов, чтобы сделать шаг ближе к нашему идеалу, мы, инженеры, должны жестко критиковать все предлагаемые решения. Проклятая проблема, с которой мы сталкиваемся, заключается в том, что иногда между «жестоко критичным» и «добрым» нет союза, или, по крайней мере, мы не можем его найти. Инженер, с которым мне не удалось связаться, известен как особенно профессиональный и чуткий собеседник, что чрезвычайно полезно для них и нашей команды. Можно ли разумно попросить их поставить под угрозу этот стиль ради моей выгоды? Возможно нет.

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

3.3 — Передача знаний

Не бывает глупых вопросов, но некоторые полезнее других

Вы прибываете на пляж в свой первый день в качестве копателя ям. Когда вы цепляетесь за песок, вы понимаете, что продвигаетесь на несколько порядков медленнее, чем ожидали. «Я копаю медленнее, чем ожидал», — делитесь вы с командой. «Просто задавайте вопросы!» они отвечают.

Так что разумно вы спрашиваете о песке. Вы спрашиваете об океане. Вы спрашиваете о ракушках. До сих пор непонятно, как быстро вырыть ямы на пляже. С твердым пониманием всего, что вас окружает, вы спрашиваете:
«Мне все еще чего-то не хватает. Как ты копаешь?
«О, я просто иду вот так»
«Что ты имеешь в виду… вот так?»
«Эм…. ты просто… возьми… И сделай это…»
«Подожди, что ты имеешь в виду под этим»
«О. Например, лопата.
"Хм? У нас есть лопаты? Раньше я использовал лопаты. Можно мне один?"
«Я уверен, что вы идете»

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

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

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

Не смотрите, как кто-то пытается копать ямы руками. Дайте им лопату.

[5] Ямокопатель имеет больше общего с некоторыми корпоративными должностями, чем можно было бы ожидать.

Часть 4: Заключение

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

Ом — Системы

«Хорошие результаты зависят от хороших систем» — наставник

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

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

Один из моих последних разговоров был примерно таким [6]:

Я : «Для меня важно, чтобы мы, как команда, могли повторять наш процесс».
Гуглер : «Есть другие роли, которые могли бы лучше подходить для того, чтобы сосредоточиться на этом, помимо разработки. Может быть, эти роли были бы вам интересны».
Я: «Я инженер, и эти вещи имеют решающее значение для нашей роли. Передача знаний и общение — вот некоторые примеры, которые по своей сути необходимы каждому инженеру».
Googler : «Работа инженера — писать код, а не думать о процессах».

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

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

[6] Этот разговор драматизирован, укорочен и вырван из контекста. Я не могу точно зафиксировать разговор, но это точное отражение того, как я его пережил.

Заключительные примечания

«У меня не было времени написать тебе короткое письмо, поэтому я написал длинное» — Блез Паскаль

Спасибо, что прочитали всех. Надеюсь, вы что-то из этого вынесли.

Если у кого-то есть точки зрения на эту статью, которыми они хотели бы поделиться, не стесняйтесь обращаться ко мне по адресу [email protected] .

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