Hacker News Digest

В предоставленном тексте содержится только начало статьи "Почему я пишу код, будучи CTO" от Джона Ванга, соучредителя и технического директора компании Assembled. Статья начинается с констатации того, что многие технические директора перестали писать код несколько лет назад. Однако полного содержания статьи для создания полноценного пересказа недостаточно. Для подготовки точного и ёмкого пересказа необходимо предоставить полный текст статьи.

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

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

Хорошая политика — это стратегическое использование отношений и влияния для достижения качественных результатов. Это включает построение связей до того, как они понадобятся, понимание реальных стимулов stakeholders, эффективное управление вверх и создание win-win ситуаций. Лучшие технические лидеры владеют этими навыками, называя их «управлением заинтересованными сторонами» или «построением согласованности». Игнорирование политики лишь гарантирует, что побеждают те, кто готов в ней участвовать — часто в ущерб общему делу.

• Политика — неотъемлемая часть любой совместной работы в организациях, и её избегание лишь ослабляет влияние и позволяет другим принимать плохие решения.
• Эффективная «политика» включает в себя видимость работы, стратегическое распространение заслуг и умение доносить технические аргументы в понятных для лиц, принимающих решения, терминах.
• Плохие технические решения часто проталкиваются не из-за глупости, а из-за отсутствия в комнате нужных людей или неумения повлиять на процесс.
• Участие в политике — это не обязательно манипуляции или интриги, а стратегическое построение отношений и влияния для достижения лучших общих результатов.
• Отказ от участия в политике может быть защитным механизмом, но также означает уступку контроля над своей работой и карьерой тем, кто в ней участвует.

Руководить командой экспертов — это не о том, чтобы быть самым технически подкованным, а о том, чтобы эффективно связывать разные области знаний. Лидер служит переводчиком между специалистами: например, когда бэкенд-разработчики говорят о трёх неделях на внедрение аутентификации, а продукт-менеджеры ждут результат «к концу недели». Задача — не вдаваться в детали OAuth, а найти общий язык и объяснить ограничения.

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

• Лидерство в технических командах требует баланса между фасилитацией обсуждений и принятием решений, когда это необходимо для преодоления тупиковых ситуаций.
• Эффективный лидер действует как переводчик между командами и специалистами, обеспечивая ясность и доверие, а не просто отдавая приказы.
• Важно объяснять причины решений и брать на себя ответственность за их последствия, чтобы команда чувствовала себя в безопасности и могла двигаться вперед.
• Попытки достичь консенсуса по всем вопросам могут привести к параличу команды; иногда требуется авторитарное решение для сохранения прогресса.
• Убеждение людей редко работает только на фактах; необходимо учитывать эмоциональный и социальный контекст аудитории.

Краткий перевод на русский (в 2 раза короче):

---

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

Ключ к росту — в развитии четырёх навыков:

• технический (мастерство),
• продуктовый (понимание, что важно),
• исполнительский (доведение до результата),
• людской (влияние и коммуникация).

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

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

Работайте над собой открыто и намеренно. В долгосрочной перспективе вы получите то, что заслужите.

• «Хорошо» мало: работодателю нужен не только талант X, но и навыки Y, которые сотрудник игнорирует.
• Программа должна приносить деньги; люди важны на всех уровнях.
• Высокая продуктивность часто награждается лишь новой порцией работы: «приз за победу — ещё кусок пирога».
• Карьерный рост зависит от мотивации тех, кто решает, а не от чистой квалификации; надо говорить о своих результатов и выравниваться с целями компании.
• Умение писать (и быть заметным) — ключевой «силовой множитель», но в устных/политических культурах его эффект ограничен.

Краткие заметки об «амазонском» лидерстве

Customer Obsession
Хороший принцип, но его часто упрощают: «начать с клиента» ≠ «спросить, что он хочет». Ранний AWS делал крутые строительные блоки (EC2), а после 2012-го перешёл к «делать то, что просят». Это шаг назад. Клиенты не просят Paxos-as-a-service, но именно он им нужен, чтобы быть отказоустойчивыми. AWS стоит вернуться к выпуску внутренних блоков, а не ждать запросов.

Ownership
Принцип узок: надо думать не только о компании, но и об экосистеме. Пример — разработка стандартов прерываний для bhyve, хотя Amazon его не использует. Внутри Amazon сильные «стены»: команды не знают, что делают соседи, поэтому «действовать от лица всей компании» невозможно. Нужно ломать силосы.

Bias for Action
«Многие решения обратимы» ≠ «обратимы без потерь». Половинчатые сервисы подрывают доверие клиентов; память о провале живёт годами. Как офицер безопасности FreeBSD, я чаще говорил «стоп» и не выпускал сломанный патч, чем спешил. Доверие важнее скорости.

• Участники устали от «принцип-фатиги»: компании декларируют красивые лидерские принципы, но быстро от них отступают при первом давлении.
• «Leaders are owners» выглядит выгодно для акционеров, но невыгодно для сотрудников, получающих лишь крошечные доли RSU.
• Многие считают, что после массовых сокращений 2022 г. и жёсткого возврата в офисы принципы Amazon, включая «Strive to be Earth’s Best Employer», стали звучать лицемерно.
• Часть бывших сотрудников утверждает, что внутри компании принципы используют как инструмент контроля и оправдания низкой производительности, а не как ориентиры для роста.
• Общий вывод: формальные принципы давно превратились в «операционные гайдлайны» или пропаганду, тогда как реальной целью остаётся «make money».

Главный навык, о котором не говорят
Когда становишься менеджером, будешь ошибаться. Часто. Дашь обратную связь, которая ударит по уверенности, примешь нелепое решение, забудешь обещанное, взорвёшься на встрече. Вопрос не в том, будут ли ошибки, а что ты после.

В книге «Good Inside» доктор Бекки Кеннеди главным родительским навыком называет ремонт: вернуться, признать, взять ответственность, восстановить связь. То же в управлении.

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

Как ремонтировать

1. Конкретно: «Я трижды прервал тебя и отмёл идею — это было неправильно».
2. Не своди к себе: не рассказывай, как тебе тяжело.
3. Меняй поведение, иначе это не ошибка, а привычка.
4. Дай время: один разговор не чинит доверие.

Умение чинить освобождает: не боишься решений и сложных разговоров, потому что знаешь, что сможешь исправить. Это не оправдание безответственности, а признание: ты человек, работа сложна, идеальных нет. Задача — делать полезный продукт, растить команду и создавать условия для работы. Если сорвался — почини, выучи, иди дальше.

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