Инженерия ПО
Техническое лидерство
Staff Engineer в Google зарабатывает больше Engineering Manager - без управления людьми, только через технический авторитет. Will Larson ('Staff Engineer' книга): Staff+ Engineers влияют на десятки инженеров через architecture decisions, технические стандарты, mentoring. Техническое лидерство - это карьерный путь, параллельный management track.
- **Google Staff/Principal Engineers**: техническая карьерная лестница IC3-IC9 без перехода в management. Staff Engineer влияет на техническое направление 20-50 инженеров без формальной власти
- **Amazon 'Bar Raiser'**: специальная роль в найме - опытный Senior/Staff Engineer который не из команды нанимающей. Ставит высокую техническую планку независимо от hiring pressure
- **Stripe Engineering Principles**: открытый документ с техническими принципами - как принимаются решения, что ценится. TL формирует такие документы и следит за их соблюдением
Роль Tech Lead
Tech Lead - не просто Senior Engineer с административными обязанностями. Patrick Kua в 'Talking with Tech Leads': TL тратит ~30% времени на код, остальное - на технические решения, выравнивание команды, коммуникацию с product/management. Ключевое напряжение: TL несёт ответственность за технические результаты команды, но достигает их через других людей, не лично.
Ответственности TL: техническое направление (architecture decisions, tech debt prioritization, technology choices), качество кода команды (code review culture, standards, tooling), онбординг и развитие инженеров, интерфейс между командой и product/management (техническая трансляция требований), устранение блокеров. TL не является менеджером: не проводит performance reviews, не нанимает/увольняет. Это отличает роль от Engineering Manager (EM).
Tech Lead замечает что команда выбрала архитектурное решение которое считает неоптимальным. Правильное действие?
Mentoring и развитие команды
Mentoring - передача знаний и опыта для ускорения роста инженеров. Отличается от teaching (передача конкретных знаний) и coaching (помощь в раскрытии собственных ответов). Хороший ментор не даёт готовые ответы - задаёт правильные вопросы. 'Что ты уже пробовал?' 'Какие альтернативы рассматривал?' 'Какие trade-offs видишь?' Это развивает мышление, а не зависимость от ментора.
Bus factor (truck factor) - минимальное количество людей, потеря которых парализует проект. Bus factor 1 - катастрофический risk: один человек знает критическую систему. TL отвечает за повышение bus factor команды: pair programming, documentation, rotation - разные люди работают с разными частями системы. Google: Code Ownership требует от владельцев документировать свои компоненты и менторить других.
Junior инженер застрял над задачей и пришёл за помощью к TL. Как лучше всего помочь?
Техническое принятие решений
Architecture Decision Record (ADR) - документ фиксирующий архитектурное решение с контекстом и обоснованием. Формат Michael Nygard: Context (почему нужно решение), Decision (что выбрали), Status (Proposed/Accepted/Deprecated), Consequences (последствия, включая негативные). Хранится в репозитории рядом с кодом (docs/adr/). Цель: будущий инженер через 2 года понимает почему приняли решение, а не только что.
RFC (Request for Comments) - процесс для крупных технических изменений. TL пишет документ с предложением, команда асинхронно комментирует (GitHub PR или Google Doc). Срок для feedback (1-2 недели), затем решение. Преимущества: мнение каждого учтено, решение документировано, нет необходимости в долгих synchronous встречах. Amazon PR/FAQ: новая фича описывается как press release - если не звучит убедительно для пользователя, нужно пересмотреть.
TL принял архитектурное решение месяц назад. Новый инженер спрашивает почему использован Kafka вместо SQS. TL не помнит деталей. Что помогло бы?
Влияние без формальной власти
TL влияет через авторитет знаний (expertise authority), а не через формальную власть. Три типа влияния: Rational Persuasion (данные, логика, прецеденты), Inspirational Appeal (связь с ценностями команды), Consultation (вовлечение в разработку решения создаёт ownership). Staff Engineer в крупных компаниях (Google, Amazon) - высокая техническая роль без управления людьми, строится полностью на influence.
Управление stakeholders: TL должен уметь объяснять технические решения non-technical аудитории (product, CEO, investors). Техника: business impact framing. Вместо 'нам нужно рефакторить monolith к microservices' - 'текущая архитектура занимает 3 недели на добавление payment метода; с proposed изменением - 3 дня'. Техническая debt в деньгах и времени, не в технических терминах.
Tech Lead - это самый хороший программист в команде, который принимает все технические решения
Tech Lead - это человек который помогает команде принимать хорошие технические решения. Лучший TL строит систему где команда может принимать хорошие решения без постоянного участия TL
TL который принимает все решения создаёт single point of failure и не растит команду. Цель - distributed technical leadership через ADR, RFC, code review culture
TL хочет убедить CEO инвестировать в technical debt reduction. CEO говорит 'у нас нет времени, нужны фичи'. Как аргументировать?
Связанные темы
Техническое лидерство пересекается с процессами и архитектурой:
- Документирование и ADR — ADR - ключевой инструмент TL для документирования архитектурных решений и передачи контекста команде
- Эстимация и планирование — TL участвует в технических эстимациях и помогает команде давать реалистичные оценки с учётом technical risk
Вопросы для размышления
- Как TL принять архитектурное решение за командой когда команда разделилась 50/50 и обе стороны имеют весомые аргументы?
- Bus factor 1 - катастрофический риск. Как TL балансирует между необходимостью распределить знания и уважением к expertise отдельных инженеров?
- TL часто 30% кодирует, 70% другое. Как не потерять техническую глубину и оставаться credible техническим лидером?