Вчера вы писали код и закрывали тикеты. Сегодня вас повысили, и вам нужно ставить задачи и давать сложный фидбек. Но говорить вы всё ещё привыкли как инженеры. Если не освоить новый стиль общения, повышение легко превратится выгорание.
Эта инструкция пригодится тем, кто делает первые шаги в лидерстве, а разработчикам поможет лучше понять своих руководителей.
Кто пишет: Ксения Александрович, Engineering Manager в PandaDoc, и Людмила Сухинина, Technical/Team Lead и Resource Manager, создатели комьюнити для лидов и менеджеров First Time Leaders Community.
Как давать людям расти, не вредя продукту
«Я 8 лет была успешным инженером, говорила на языке if/else и чистого кода. Моя ценность измерялась тем, насколько быстро и красиво я закрывала задачи», — вспоминает Ксения.
Два года назад она стала Engineering Manager в PandaDoc и теперь отвечает не только за технические решения, но и за развитие команды и людей. Именно тогда она почувствовала: привычный способ коммуникации перестал работать.
Похожая история и у Людмилы Сухининой. Она больше десяти лет занималась iOS-разработкой, а затем перешла на гибридную роль, которая сочетает управление разработкой, людьми и ответственность за бизнес-задачи.
«Когда ты индивидуальный контрибьютор, всё довольно прозрачно: для компаний было важно, насколько быстро и качественно я могу решить техническую задачу, снять блокер или помочь команде с архитектурным решением. Сейчас же кроме технической части нужно заниматься развитием сотрудников», — рассказывает Людмила.
Этот переход обычно самый трудный. Сеньору можно просто выдать решение, но в менеджерской роли важно не чинить баг, а помочь человеку найти ответ самому. Ксения подчёркивает, что готовый ответ лишает сотрудника роста и скрывает причины вроде усталости или нехватки знаний.
«Спросите разработчика: «Как ты видишь проблему? Что уже пробовал? Чего не хватает, чтобы закрыть задачу?».
Однажды уставший инженер три часа бился над задачей и уверял, что вариантов больше нет. Ксения продолжала задавать вопросы и предложила поискать решение ещё час. И за этот час он сам нашёл решение, и вырос как специалист.
Иногда ошибка может стоить заказчику денег, поэтому лидер обязан учитывать не только техническую сторону, но и последствия для бизнеса. Людмила вспоминает, как перед релизом разработчик принёс простой баг, но она почувствовала, что проблема глубже. После проверки оказалось: нужен рефакторинг модуля на несколько дней, а времени не было. Они выбрали безопасный точечный фикс, а полный рефакторинг перенесли в техдолг.
То есть ваша суперсила, как менеджера, — задавать правильные вопросы, а не давать быстрые ответы. И давать пространство для профессионального роста, но не за счёт проекта.
Говорите о коде так, чтобы вас услышал бизнес
Девушки признаются, что для них «точка перелома» наступила, когда они поняли: техническая логика не равна логике бизнеса.
«Пытаться обсуждать с C-level техдолг или устаревший фреймворк — это как выдавать им доклад на латыни. Они кивают, но внутри ничего не меняется», — говорит она.
Тогда Людмила начала менять язык. Вместо абстрактных технических формулировок появились конкретные связки с бизнесом.
- не «этот модуль хрупкий», а «каждый сбой логина — потерянная транзакция»,
- «непредсказуемые релизы повышают риск не уложиться в SLA»,
- «если мы не сделаем оптимизацию сейчас, команда будет тратить X часов в месяц на обходные костыли».
Когда умеешь говорить на языке бизнеса, то менеджмент охотнее прислушиваются к тебе.
Как сохранить доверие команды, оставаясь менеджером
Этот барьер сложнее всего преодолеть. Вчера мы были равны, а сегодня кому-то нужно давать сложный фидбек. Нельзя быть лучшим другом и лучшим менеджером одновременно.
Особенно сложно, когда коллега начинает активно критиковать новую политику компании или негативно высказываться о другом руководителе, когда вы просто встретились на кофе. Сейчас даже неформальная беседа — это официальная коммуникация.
Если такое случается, Ксения советует мягко напомнить о границах.
«Я говорю в таких ситуациях: «я понимаю, что эта политика вызывает вопросы. Если у тебя есть конструктивный фидбек по ней, я готова обсудить это на нашем 1-на-1 и передать его дальше. Но здесь я бы предложила сменить тему».
Людмила подчёркивает, что она должна постоянно «фильтровать» информацию от разных стейкхолдеров и принимать решения, с которыми не всегда все будут согласны.
«Были моменты, когда разработчики пытались обсуждать со мной бизнес-решения „как с коллегой“. Критиковали процессы, спорили с менеджментом, делились недовольством заказчиком. Но я не могу позволить себе быть только на стороне команды или только на стороне бизнеса. Я должна быть связующим звеном, которому доверяют обе стороны», — говорит она.
First Time Leaders Community
Девушки стали менеджерками в ИТ по разным траекториям, но столкнулись с одинаковой проблемой: очень мало кто говорит про трудности, которые возникают у начинающих лидеров.
А вопросы, страхи и новые ситуации появляются каждый день. Поэтому решили создать комьюнити First Time Leaders, где можно обсудить вещи, которые вас волнуют без страха. Разобрать сложные кейсы, которые возникают на работе. И это не просто очередной чат, а полноценная экосистема, где вы можете развиваться как управленец.
Что делает First Time Leaders Community:
- Book Club — читают бизнес- и лидерские книги и обсуждаем ключевые идеи через призму реальной работы.
- Регулярные онлайн-ивенты — разговаривают про коммуникацию, фидбек, конфликты, границы, мотивацию, эмоциональную устойчивость.
- Discussion Mastermind Club — ежемесячные мастермайнды, где участники приходят со своими запросами, обсуждают сложности, получают поддержку и решения от других лидов.
- Тематические встречи с экспертами о найме, развитии людей, переходе в менеджмент, работе со стейкхолдерами и отношениях с бизнесом.
Если вам откликается присоединяйтесь. Там лидеры поддерживают друг друга, делятся опытом и растут вместе.
Мнение авторов может не отражать позицию редакции.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.