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

• Инфраструктура : Мост Золотые Ворота строился около четырех лет (1933–1937) и стоил нам около 500 миллионов долларов в сегодняшних долларах. В отличие от этого, SDS ( система предотвращения самоубийств ), которая, по сути, добавляет сеть вокруг моста, займет у нас пять лет (2017–2023) и, по прогнозам, будет стоить нам около 217 миллионов долларов. Если вы сделаете обзор крупных инфраструктурных проектов в Калифорнии, то обнаружите, что для проектов, завершенных до 1950-х годов, работа выполнялась быстрее, дешевле и качественнее, чем сегодня, по крайней мере в 5 раз больше, хотя сегодня у нас больше капитала, лучшая технология, лучшее сырье и больше абсолютное количество инженеров-строителей и архитекторов.
• Технологические компании : Adobe, несмотря на все свои финансовые и человеческие ресурсы, вынуждена приобрести конкурента за 20 миллиардов долларов. Еще неизвестно, переплатила ли Adobe за Figma, но более интересный вопрос заключается в том, почему компания со 100-кратным персоналом, 100-кратным опытом работы с инструментами проектирования и 100-кратным финансовым капиталом не смогла победить?

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

Почему происходит сползание процесса?

Любой процесс начинается с добрых намерений.

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

Дорога к перфекционизму

Я помню, как один благонамеренный менеджер говорил своим непосредственным подчиненным писать программное обеспечение, как будто оно прослужит 100 лет. Хотя это замечание было преувеличенным, совет перекликается с тем, что я часто слышал в технологической индустрии из таких пословиц, как «семь раз отмерь и один раз напиши» или «если у вас нет времени сделать это правильно, есть ли у вас время, чтобы сделать это правильно». это дважды?». Это не плохой совет. В некоторых ситуациях приходится писать код так, как будто он прослужит 100 лет., и без планирования идти сломя голову к исполнению расточительно. Тем не менее, чрезмерное внимание к планированию может привести к параличу и неспособности признать преимущества обучения через итерацию. Я предпочел бы жить в мире, где программное обеспечение переписывается каждый год, потому что существует твердое понимание того, что совершенства не существует и что необходимым условием эволюции являются изменения, а не в мире, где все работает на « кодовых базах 50-летней давности ».

Слишком много клея

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

• Люди, работающие с клеем, мешают другим людям улучшать свои нетехнические навыки. Например, технический руководитель, который не позволяет своей команде говорить о своей работе или часто выступает в качестве «буфера», по сути, лишает IC возможности бороться и, в конечном итоге, улучшить свои коммуникативные навыки.
• Экстремальные и токсичные варианты клеевого поведения иногда проявляются в приписывании чужой работы или в чрезмерно преувеличенной атрибуции («например, без меня в качестве посредника проект не увенчается успехом»). В то время как Таня рассказывает о ситуациях, когда люди из Клея часто не получают признания, мой опыт полностью противоположен. Потому что люди Клея — хорошие коммуникаторы, они знают, как рекламировать свою работу и хорошо играть в политику. В свою очередь, они получают более широкую известность и больше возможностей для продвижения, в то время как инженер, работающий над деталями реализации, часто получает символическое признание или вообще не получает признания.
• И, наконец, добавление слишком большого количества связующих людей снижает ответственность и ответственность отдельных инженеров. Вместо того, чтобы добавлять людей для управления технически компетентной командой, я бы просто уволил инженеров, которые, кажется, не имеют бизнес-интуиции, не имеют навыков общения или не могут составить абзац, описывающий, почему их работа эффективна. Предположение о том, что вам нужно больше клея для управления инженерами, приводит к игнорированию общего стереотипа, согласно которому технически блестящие люди также обладают высоким уровнем общего интеллекта, много читают, учатся всю жизнь и очень хороши в бизнесе, а не только в программировании.

Когда я работал в Novell, я узнал, что есть люди, которых я называю «склеивающие». Клеевые люди — невероятно приятные люди, которые сидят на промежуточных границах между группами и помогают в деятельности. И они очень-очень преданные, и люди их любят, и вам они совсем не нужны.

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

Энтропия

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

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

• Удаление мертвого кода, который не выполняется в продакшене. Я взаимодействовал со многими кодовыми базами, где> 50% кода было мертвым кодом и создавало когнитивную нагрузку для коллег. Я бы хотел, чтобы в пространстве производительности разработчиков было что-то, что генерировало бы покрытие кода на основе строк, выполняемых в продакшене. Каждый квартал вы останавливаетесь и просматриваете эти отчеты и просто удаляете файлы, которые не выполнялись.
• Как продакт-менеджеры, мы недостаточно размышляем о том, какие функции следует убрать или вернуть. Тем не менее, остановиться и подумать о том, что следует удалить, может иметь большое значение для упрощения и улучшения взаимодействия с пользователем. Я считаю себя технически подкованным, но я обнаружил, что многие продукты, созданные сегодня, были гипероптимизированы для набора существующих пользователей, что приводит к загромождению и запутанности UX для новых пользователей. Спросив в конце квартала «Какую функцию мы можем отменить?» может быть полезно для уменьшения беспорядка.

Эго - враг

Райан Холидей в своей книге «Эго — враг» предполагает, что существует сильное «искушение, которое существует для всех — разговоры и шумиха заменяют действие». Эго — главная причина, по которой прогресс и инновации могут быть тусклыми во многих организациях. Вот как проявляется эго:

• Видеть, как одни и те же люди жаждут поделиться своими мыслями в групповом разговоре, даже если их идеи не приносят никакой или очень мало маргинальной ценности.
• Наличие людей, которые никогда не занимаются активным спонсорством своих коллег или пытаются скрыть известность. Если вы менеджер или менеджер менеджеров, вы можете заметить это, увидев, как часто ваш непосредственный подчиненный говорит об успехах или вкладе других людей в ваши личные встречи. Отсутствие признания или бескорыстное спонсорство других людей может быть признаком нездорового эго.
• Оптимизация для команды, а не для всей компании или организации. Я позаимствовал диаграмму из «Пути штатного инженера» Тани Рейли, и она прекрасно иллюстрирует эту проблему, когда команды оптимизируются для достижения локального максимума. Например, согласны ли вы распустить свою команду и перераспределить сотрудников по другим командам, если в вашем домене вы входите в режим обслуживания? Большинство менеджеров никогда бы так не поступили, потому что это означало бы потерю социального и политического капитала внутри компании.

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

Заключение

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

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