“Год без штанов”
Обзор и конспект книги Скотта Беркуна
Моя оценка: 10/10
Книга описывает работу из дома и культуру “Automattic”, компании, создавшей самую популярную блог-систему и конструктор сайтов “Wordpress”.
Оценка 10/10 — сложная. Наивысший балл получает сама культура. Она потрясающая, продуктивная, и во-многом вдохновила культуру Эквид. Автор же — нарцисс и зануда, и все здорово усложняет. Возможно потому что он пытается описать нюансы и для читателей, далеких от ИТ.
Здесь и далее, “автор” — не я, автор статьи, а автор книги.
Здесь и далее, “Мэтт” — Мэтт Муленвег, основатель и доброжелательный диктатор Wordpress.
Без штанов
Automattic — партнер Ecwid, мы с ними общались еще до покупки ими WooCommerce. Помню первый визит в их офис в Сан-Франциско. Это был большой, просторный офис, похожий на хороший зал для мини-футбола. В офисе никого не было, кроме партнерского менеджера с которой мы должны были встретиться. Только тогда я в полной мере понял: у Automattic вообще нет офисов, а этот, в Сан-Франциско — это место встреч. Книга описывает, как когда приезжает пресса ребят из Сан-Франциско просят подтятунуться и работать из офиса, чтобы пресса хоть как-то “увидела компанию”. Раз офис — место для гостей, в офисе обязательная “комната с мерчем”.
Найм в компании, работающие с открытым кодом начинается с конца. Нанимают тех, кто… уже хорошо работает! Мне про это рассказывал еще Монти, основатель MySQL, которого я привозил на Ulcamp. Просто смотришь кто как из добровольцев коммитает код. Кто отлично делает это бесплатно, тому предлагаешь работу. А способность продуктивно работать удаленно человек уже доказал.
Культура Automattic очень близка культуре Эквид. Во многом потому что изначально были близки, а на уровне практик — потому что читали в блогах и вдохновлялись.
Первый намек на структуру
Автор книги пришел в “Automattic” из Майкрософт, уже состоявшимся менеджером. На это время в Automattic было всего 50 человек, и ВСЕ ОНИ НАПРЯМУЮ РЕПОРТИЛИ Мэтту Муленвегу (основателю, здесь и далее — “Мэтт”).
Компания как раз решила вводить структуру, и разбить людей на 10 команд по 5 человек. Автор книги стал менеджером одной из команд:
- Единственным, нанятым со стороны
- Единственным профессиональным менеджером, а не кодером
- Единственным назначенным, а не выбранным
Остальные 9 команд лидера выбрали сами.
Команды получили названия, миссию, и “P2”: свой “дом”, блог на Wordpress. В блоге как сама команда так и члены других обсуждают дела команды. Так же есть центральный P2 компании.
Чуть позже, команды кастомизовали и украсили свои блоги. Гордость и самообытность подразделения были еще у военных особенностью культуры Гвардейских частей. Хороший элемент культуры.
В “Automattic” нет собеседований, только тестовое задание. Собеседование — крайне ненадежный способ определить пригодность кандидата. Что человек делает — гораздо более показательно.
Автор, хоть и был шокирован культурой Automattic, но восторгался культурой и основателем. Это очень важно при найме “опытных стариков”. Такие могут быть крайне полезны молодым компаниям, но только если у них есть вот эта вера в основателя. Вариант с “я из МакКинзи, а вы — банда распиздяев” — не сработает.
Техподдержка — основа основ
Любой сотрудник, программист это, продажник или фин директор, начинает работу с практике в тех поддержке.
Нет давления на производительность. Цель — в том, чтобы новичок понял компанию и ее клиентов. Толерантность к “я финдиректор, давайте финансами займусь!” — нулевая. Только техподдержка. И хотелось бы к концу практики увидеть производительность. Это ранний индикатор будущего успеха в компании.
Мы в Эквиде вводим схожую систему с практикой. Я тоже проходил. Мне в первую смену на “чатах” (продвинутая ступень практики) попался старый клиент X-Cart и мог друг, из Амстердама. Было очень весело, ну и много узнал про Эквид :)
Автор книги — более олдскульный менеджер. Из него в книге прямо льется пафос, “не царское это дело, тех поддержку оказывать”. Он бесится на некомпетентность клиентов, на “глупые вопросы” — в книге, публично!
Нельзя так. Это то что я не люблю в советской инженерной культуре. “Я инженер, а ты — говно. И научись разбираться с моим продуктом.” Нет, товарищ инженер, если клиенту нужна помощь при работе с твоим продуктом, и ты при этом считаешь себя правым, а клиента ––нет, то очень возможно, что говно — ты.
Меня всегда удивляли люди, которые так гордятся, что они — умные программисты, а “тетка эта” не может в трех кнопках разобраться. Да, не может. СКАЖИ ЕЙ ЗА ЭТО СПАСИБО. У тебя есть работа лишь потому, что ты умеешь делать что-то что не умеет она. А завтра ты придешь в госпиталь и она будет делать тебе колоноскопию. Она умеет это делать, ты нет, но она тебя в этом не винит. Просто продолжает процедуру :) У каждого своя специализация, каждую нужно уважать. Или подростки, которые не хотят научить маму как настроить WhatsApp. “Как можно не уметь!?” Чувак, сбей спесь, она тебя научила ходить на горшок..
Автор же провентилировался про скандалистых клиентов. И да, это не круто, когда клиенты хамят. Но в Эквиде, например, все равно считается неприличным рассказывать публично про “плохих клиентов”. Бывает клиенты орут и хамят. Редко, но бывает. У техподдержки Эквида в этом случае правило: “представь, что это маленький ребенок”. Он орет и плачет не потому что плохой, а потому что ему больно, или некомфортно, он хочет спать или он хочет грудь. На него бесполезно орать в ответ. Все что можно — выразить сочувствие, понять что именно вызывает дискомфорт, и убрать этот дискомфорт. Это — единственная взрослая и конструктивная позиция.
Конечно, автор проникся непосредственным опытом техподдержки и понимания клиентов. Он упоминает, что в “Майкрософт” есть доступная продактам база данных типичных обращений в саппорт (интересно, наша продуктовая команда такое использует?!). База — это круто, но совсем не дает такого интуитивного понимания как работа в поддержке.
Стандартные вопросы техподдержки Wordpress клиенту:
“Что ты увидел?”
“Что ожидал увидеть?”
WWW: Веселье и Вечеринки Важны
Автора в культуре WP шокировали рассказы о том как кто вчера набухался, кто еле дошел до номера, и кто именно и как нахулиганил.
Добрые рассказы и милые хулиганства.
Постепенно он понял, что это ВАЖНО. Такая разгуляй–бравада объединяет, а способность про это рассказывать означает способность быть уязвимым для своей команды. Когда ты уязвим и видишь что в эту уязвимость не бьют, ты понимаешь: “здесь безопасно, могу быть собой, это моя команда, она поддержит во всем”. Это выводит доверие на новый уровень.
В культуре WP много пранков и шуток. Как и в Эквид, это важная часть культуры. Я помню, когда Калифорнийский офис выпадал ненадолго из культуры что “можно и посмеяться с (или даже над) начальником”. В это время мы были не только скучными — но и медленными. Хорошо что починили.
Все вышеперечисленное: юмор, вечеринки — это создает ПЛЕМЯ.
Журналы часто пишут про очередной набор лучших практик от какой-нибудь “выстрелившей” компании. Но просто брать и копировать это не работает, потому что далеко не все практики работают в отрыве от культуры компании. Некоторые практики несовместимы с некоторыми культурами. Культура — то, что сложнее всего изменить. Секретный соус.
Книги обычно не пишут про это вечеринки. Пишут “культура бла бла бла”. Процессы “бла бла бла”. Но кто в книге никто не напишет “заблевали все здание Филармонии!”
Процессы
Почти все взаимодействие в WP — это чаты. Это эпоха “до Slack”, поэтому Skype и IRC.
Понедельник: каждый пишет на P2 команды свою MIT: Most Important Thing (Самое Важное Дело) на неделю.
Четверг: каждый пишет апдейт по достигнутому за неделю. Мы в Эквид для этого используем “Marco Polo”. Это соцсеть для семей и друзей. Сам выбор ее в Эквид — почти “социальный хак”. Говорят у “Macro Polo” нехило взлетел бизнес в карантин: они сближают людей, а это сейчас ценно.
Пятница: менеджер дает апдейт на P2 менеджеров менеджеров.
Правило: если работаешь — должен быть онлайн в IRC. Я помню о таком же правиле и в MySQL. Cвободный график и свободные часы, но ты должен четко переключаться между работой и не работой. И быть доступным.
Менеджерские практики
Допинывать людей — полезно и нужно. Менеджер должен это делать, если они результаты запаздывают, или если есть ожидание что будут опаздывать. Но нужно уметь это делать с юмором и креативно. Не задевая ничьих чувств. Вообще, дружественный юмор, полу-шутка (не обидная!) — отличный способ доставки отрицательной обратной связи. Не путать с высмеиванием и издевательством!
Работа менеджера — это:
- нанять правильных людей
- определить приоритеты
- убрать препятствия на пути производительности
- убраться с пути самому.
Слишком дефенсивный менеджмент, оптимизированный на минимизацию рисков, убирает не только риски, но и свершения.
Даже небезопасность иногда повышает безопасность. Т.е. отсутствие защит от ошибки при правильной культуре включает осторожность и 100% фокус персонала на исключении ошибок — и приводит к безупречным результатам. Изобилие защит может повышать безответственность. Тут мнение автора, и полагаю применять это нужно с осторожностью, зная где этот принцип хорош а где нет.
Автор устраивал one-on-ones со своими сотрудниками раз в месяц. Спрашивал одно и то же:
- Что идет хорошо?
- Что плохо?
- Чего мне нужно делать больше?
- Чего меньше?
Как старший ведет себя в комнате, к чему он толерантен — задаёт культуру. Как ведут себя в его отсутствие — показывает культуру.
Недостатки программистских культур
В распределенной структуре организации, построенной “как выросло так выросло” бандой кодеров есть миллион приемуществ, но важно знать и недостатки.
Приходя из “менеджерской” культуры Майкрософт автор, хоть и восхищается “программистской” культурой Automattic (ту, что мы в Эквиде называем “пиратской”), но и документирует недостатки.
В моем пересказе вообще больше про “минусы”, чем про плюсы. Особенностью моих конспектов в том что я в значимой степени пропускаю очевидное для себя. А то что для нас хорошо работает — это часто очевидное. Итак, к неработающему:
Негативная сторона инкрементальности
Инкрементальность — это круто, дает постоянный прогресс и возможность итеративно двигаться с максимально короткой петлей обратной связи.
Но самостоятельный выбор проектов, и решение о выборе на базе общения текстом в интра-вебе или Slack , имеют темную сторону.
Общение в Slack часто сиюминутно, транзакционно. Зашел — посмотрел, откомментировал. Это не “глубокое время”. Не “сесть и подумать”. Поэтому требующее “глубокого” времени может игнорироваться и долго висеть, а в работу браться то, что можно обдумать за казуальное 5-минутное окно.
Заметка от себя: это важно балансировать стратегическими приоритетами, выделенными сессиями стратегического планирования (СД, OKR). Упорным продавливанием через инерцию системы значимых проектов.
2D vs 3D фичи
Это не совсем идея книги, но тема для меня важна и книга спровоцировала ее формулирование. Назову концепцию “3D фичи”.
В инкрементальном режиме, и программисты и продакты “вкатываются” в тот код который пишут. В те проблемы, которые привыкли решать. И когда выбирают следующий шаг, делают что-то что находится в той же плоскости что существующий код и уже решаемые проблемы. Это как искать потерянные ключи там где лучше светит фонарь.
У проектов же, которые выбирал Майкрософтовский менеджер, не было привязки к текущему коду. Они были не на уровне “как удобнее сделать написание блога”, а на уровне “зачем вообще нужна блог? что в результате?”. Поэтому он сделал много потрясающих вещей, например системы нотификаций о комментах, граватары и т.п. Кто из программистов подумал бы о том чтобы облегчить блоггерам придумывание самих ТЕМ постов? “Хэммингуэй”-подобную систему, помогающую хорошо писать? Или “вознаграждающий салют”, когда пост дописан?
См. на диаграмму ниже. Простите мои кривые руки, рисование — не моя сильная сторона.
Когда думаешь “кодом” и текущим функционалом, ты, анализируя систему с фичами “A-F”, при выборе следующего шага выбираешь между естественными “H”, “I” и “G”, прилегающими к текущей кодбазе. Сделал каталог товаров? Давай сделаем поддержку скидок и подарочных сертификатов. Получается вот так плоско разрастающаяся система.
Возвращаемся к “зачем мы вообще это делаем?” “в чем успех пользователя?” “какую проблему нам нужно решать, даже если мы понятия не имеем как ее вообще решить кодом?”. И тут оказывается, что нужно не поддержку скидок писать, а понять что главная проблема продавца — отсутствие траффика. И что в платежках продавец разобраться не может. И тут уже начинаешь прикручивать “создавалку” рекламы на Facebook и Google в один клик, хотя это вне твой изначальной экспертизы и решать эту проблему сложно.
На диаграмме добавляется новое измерение, с вариантами “L” и “M”, крайне неудобными команде, но крайне нужными пользователю. И реализовав “M” это потом открывает “O”. И итоговый продукт становится не плоско размазанным, а сконцентрированным вокруг мощного ядра: насущных проблем пользователя. (Поясняю свой художественный замысел: “L” идет “вверх”, “M” — вниз).
Сопротивление выручке 🤑
“Нет… Нет, нет, нет, нет! Никакой выручки! Зачем вам выручка? Если у вас будет выручка, то все всегда будут спрашивать сколько этой выручки!” — Russ Hanneman
Это не только фишка профессионального буллшитера из Долины. Идеаллистические культуры, построенные программистами, тоже сопротивляются выручке. У Wordpress, когда он уже был четвертью сайтов в мире, выручка была, насколько я знаю, около $20MM. У GoDaddy в то же время — больше $1000MM.
У меня годы ушли, чтобы преодолеть сопротивление выручке в Эквид. X-Cart был сразу про деньги, а Ecwid начинал, как и Wordpress, с только бесплатной версии. Изменить ментальность сложно. Вроде как мы настолько клиентоориентированы, что деньги зарабатывать — западло.
Это еще и прикрытие страха. Выручка — сложно. Выручка — проверка реальной ценности. Говорить “я делаю это на благо мира” — легко. Кто проверит благо для мира? Получить комплименты за бесплатный продукт всегда проще.
Как сдвинуть эту ментальность? Работает формула: “Не стесняйтесь выручки. Выручка — отражение созданной для мира ценности. Выручку нельзя обмануть. Создаете благо для мира, не создавая выручки? Не исключено что вы обманиваете себя. А выручку не обманешь.”
Трансформация очень болезненная. Когда начинаешь измерять все выручкой, отчетливо видишь, как многое из того что делаешь не выстреливает. Но люди — существа адаптивные, несколько итераций и результаты появляются. И уже кодеры в инженерной организации задают CEO вопрос: “да, но где в этом деньги”.
Бесхозные “низкорастущие фрукты”
Иногда мелочь долго обсуждается но никто не берёт ее в работу. Автор приводит пример когда на сайте кнопка была не с той стороны, годами. Потом кто-то просто “плюнул и, наконец, сделал”. И простой A/B тест показал потрясающее улучшение.
У нас было схожее. Я годами говорил про “провести A/B тест с флагами стран”, про который услышал от Facebook на f8. Никто не брал в работу, и проект был слишком мелкий чтобы я управлял им сам. В итоге когда я взбесился, сказал “это длиться годы, сейчас начну зверствовать, дайте мне блять мои флажки”. Тест реализовали. Меньше дня работы. Увеличение конверсии на 75%.
Но думаю в других организациях тоже так. У нас это осложняется что руки у команды маркетинга — с другой стороны глобуса. Попавшие в “складки” организации проекты будут подвисать, даже если у них супер-потенциал.
Воображаемые проекты
Ох, как он меня зацепил “воображаемыми проектами”! Автор рассказывал , как CEO описывал некоторый “проект будущего”. Какой он был не помню, но свои-то воображаемые помню прекрасно. Возьмем один, например. Назовем его“Новый Биллинг”.
Бывает такое что основатель долго говорит о светлом будущем, и, если достаточно долго говорить, то проект обретает жизнь, но не в реальностях, а в фантазиях. Люди начинают откладывать какие-то вещи, потому что “когда будет Новый Биллинг это решится само”. Главной особенностью Воображаемых Проектов является то что они такие кардинальные и важные, что никто их не берется делать прямо сейчас.
Глава самоуправляемых компаний, “пиратских команд”, таких как Эквид, привык, что проекты подхватываются командой сами. Но некоторые никто не подхватывает, сколько бы ты не говорил! Сколько у меня провалов было связано с этим в прошлом!
Воображаемые Проекты могут жить ГОДАМИ (я это видел), без малейшего прогресса, но с реальным вредом. Потому что корзинка того, что это проект в себя включает, постоянно расширяется. И все попавшее в эту корзину конвертируется из из реальных инициатив в Воображаемую.
В итоге я в Эквид запретил то, что называю “проектификацией инцициатив”. К примеру, задача “реализовать поддержку взымания платежей в Австралийских Долларах”, на три дня работы. Реакция на это инженеров или планировщиков: “когда будет Новый Биллинг, в нем уж точно будет поддержка Австралийских Долларов”. Это — искренний ответ “оно же делается, у нас ведь для этого Проект есть”. Но в реальности этот ответ значит “мы не будем это делать”. К сожалению, даже сам отвечающий это понимает. На это легко купиться и я покупался. Нет! Никогда больше!
Даже если я хочу “Новый Биллинг”, даже если мы будем строить “Новый Биллинг”, нельзя запаковывать конкретную инициативу под зонтик проекта с непонятным статусом. Дайте мне Австралийские Доллары, сегодня. И если для этого нужно написать кусок “Нового Биллинга” — пишите, приблизимся и к той цели. А нет — так значит не имеет он никакого отношения к “Австралийским Долларам”.
Авто предлагает отличный тест на воображаемые проекты. Это выделение ресурсов. Если проект есть, все про него говорят, кивают головами что “важно”, а выделенных на 100% посвященных значимых ресурсов нет — значит проект воображаемый.
Воображаемые проекты на стороне партнера — жуткая вещь в партнерских продажах. Вот ты подписал уже сделку, партнер говорит: “Да, интегрируем вас. Только старый биллинг это не поддерживает. Но отличные новости: мы строим Новый Крутой Биллинг, он уж точно будет поддерживать!”. Бежать как от огня такого. Запустят через год. Работать не будет. Реагировать: “ой, а можно нам чтобы не так круто, как будет потом, с Новым Крутым, но зато прямо сейчас?!”
Лучший способ борьбы с Воображаемыми Проектами — OKR.
В целом, автор с позиции опытного менеджера говорит, что нелегко добавлять процессы в самоуправляемые компании, такие компании сопротивляются. Но добавлять процессы надо.
Особенно важно вводить планирование времени выпуска фич, а не “как допишу — так и выпущу”. Культура самоуправления и доверия сопротивляется, говорит “куда спешить, я же не саботирую, хорошо пишу, предсказать все равно невозможно”. Да, прогнозирование в начале будет неточным. Но это не значит что от него нужно отказываться. С каждой итерацией оно будет точнее. Как говорил Джобс, “Real Artists Ship”. И раз даже в Apple ему это нужно было говорить, значит и в Apple ему приходилось бороться с культурой “дорисую когда дорисую, у меня тут творческий процесс!”
В этом отношении Яна Франк очень крутая, умеет выдавать результаты творческого труда с совершенно механистической дисциплиной.
Еще из любопытного, что автор взял “Новый Биллинг” в работу сам. Это выдает в нем корпоративного политика. Если CEO носится с какой-то темой “как дурак с фантиками”, навигаторы корпоративных джунглей обязательно постараются быть именно в этой теме.
Начинаем рисовать с лица
Многие основанные программистами компании вначале пишут код “кишок”, а потом лепят интерфейс. Программистам так проще, они мыслят внутренностями. Но как показал мой опыт в X-Cart, интерфейсы тогда повторяют своей структурой… SQL-схему базы данных!
Интерфейс — не отправлялка SQL запросов. ЛЮДИ — это всегда самая сложная часть, поэтому с нее нужно начать. Вначале нужно делать интерфейсы, которые легко и понятно решали бы задачи людей. А потом это уже проблемы бэкенда — сделать нормальные внутренности.
Эра работы из дома
Среди коммунистических партий разных стран состоялись активные дебаты на тему “будут ли деньги при коммунизме”.
Компартия Кубы, например, считает что денег при коммунизме не будет.
Компартия Китая — что будут.
Компартия СССР придерживается компромиссной точки зрения: “кой у кого будут, а кой у кого и нет!”
Работа из дома, без прямого давления социума вокруг многое раскрывает про человека.
Кто хочет работать — будет прекрасно и производительно работать из дома.
Кто не хочет работать — нормально работать не будет нигде, и из дома в особенности.
В офисе можно “изображать бурную детальность”. В работе же из дома никто не видит ваших стараний. Только результат. И вы не можете больше “делать вид”. Вы или хороши в вашем деле или нет.
Вот, кстати, данные Эквид о том как повлиял переход на 100% работу из дома на производительность:
Мы решили, что карантин — хороший повод перейти к наймам удаленно. Теперь мы берем на работу без привязки к локации.
“Работа из дома” — это скорее “работа откуда угодно”. Это и офис и балкон, и коворкинг, и дом на колесах, и яхта где-то, если есть нормальный Инет. Только из постели нельзя работать, вопрос времени, когда заработаете боль где-либо в теле от плохой эргономики.
Что есть работа вообще? В чем разница от других активностей? Автор предлагает описание: “то, что я бы лучше не делал”. И это плохое описание. Есть язык племен, в котором нет слова “работа”. У них есть “охота” (главная активность) и есть все остальное мелкое, что поддерживает жизнь. И “охота” — это и работа, и добыча, и жизнь, и радость.
Мы проводим на работе значимую часть своей жизни. Зачем делать то, что для вас — не “охота”? Когда я закрывал недавнюю сделку Эквид с Morgan Stanley и PeakSpan, я в течении 2 месяцев работал по 16 часов и 8 выходные. Почти не спал. Я закрыл ее, и что дальше? Я понял что был абсолютно счастлив в этой дикой битве за закрытие. Процесс меня радовал больше чем победа, пусть с этой победой и пришла солидная сумма на счет. Сумма мне в итоге не была важна. Деньи есть — хорошо. Путь важнее.
Деньги не важны. Если вы делаете какую-то фигню, но хорошо за это получаете — это ужасная ловушка. Ваша большая зарплата — компенсация за дыру в душе, доплата за бедность. За настоящую фундаментальную бедность работы над фигней. И деньги эту дыру не закроют. Более того, на плохой работе мозг не вовлечен, и вы деградируете. В это время другие люди, пусть получая меньше, прогрессируют. Со временем они вас обгонят, и пойдут вперед. И все время будут счастливы. А вы залипните в ловушку денег и будете на одной старой работе, пока не потеряете актуальность.
В итоге проиграете и по счастью и по деньгам. Не делайте такой ошибки.
Способность нанимать удаленно — конкурентное приемущество
Преимущества удаленных команд — доступ к глобальному таланту и высокая стабильность команды. Подумайте: вот вы наняли человека в Долине. А у него десять предложений от рекрутеров в день, и если он хорош, его зовут работать и Google и Facebook и Apple.
Но если вы способны нанять человека из маленького городка в Сербии, и дать ему возможность работать в потрясающей глобальной компании, с интересной командой — альтернативы вам практически нет.
Продуктовые процессы на прощание
Перед уходом чувак решил подарить команде генеральную уборку в интерфейсах и продуктовые процессы.
Команда Скотта смотрела на интерфейсы и записывала то, что они думали является вызовами и потребностями для клиента в этом контексте. Потом смотрели за живыми сессиями или интервьюировали пользователей. Угадали примерно ноль. Была огромная разница между ожиданиями и реальностью, а кажущиеся удобными интерфейсы не отвечали кейсам пользователей. Но документирование ожиданий позволяло сильнее видеть разницу и лучше калибровать свою интуицию на будущее. Так же в результате сравнения ожиданий с реальностью появлялся список интерфейсных проблем.
Был фокус брать и решать одну интерфейсную проблему в день. Не важно какую, но каждый день.
Раньше у его команды не было Roadmap и долговременного планирования. Чтобы сделать, команда накидала все идеи, старые и новые, на пин-борд (это было во время живой рабочей сессии на Гавайях). Каждый мог в любой момент подойти к этой доске и переставить любые заметки местами, так чтобы определить приоритеты. В первые дни вся доска была в постоянном танце, но постепенно состояние стабилизировалась и на доске оказался роадмап с приоритетами, которые приняла вся команда.
Перед тем как уйти, Скотт не только подготовил себе смену, но и какое-то время поработал подчиненным у нового руководителя. Эта работа старого лидера подчиненным была отличным сигналом передачи власти команде.
“Махнем куда-нибудь вместе?” 🏖️
Личный контакт все равно важен. Поэтому даже компании без офиса раз в год собираются в одной локации, на неделю. Монти из MySQL / MariaDB тоже рассказывал о сборах. Сэкономленное на офисах можно потратить на встречи в прекрасных местах по всему миру. Масштаб компании дает переговорный рычаг. Оккупировать курорт со “своими” — это ли не здорово?! Смена декораций и живые встречи с товарищами выводят творчество на новый уровень. Кроме больших съездов всей команды, есть и более часты съезды под-команд.
В случае с Automattic, распределенность позволяет устраивать и сходки клиентов по всему миру. Где бы не произошел эвент, наверняка где-то рядом есть и сотрудник компании.
Если Эквид будет переходить на схожий формат, то нам придется учитывать Американо-Российскую динамику. Выбирать страны куда всем легко без виз, т.е. Турция, Доминикана и т.п.
Я публикую многое из того, чему научился сам. Чтобы не пропустить свежий выпуск, подписывайтесь в:
Телеграм 💌 https://t.me/ruslanlearns 💌 … или Facebook 👍
