Хорошая статья про непростой путь в карьере тимлида. Я бы даже сказал ловушка, в некотором роде. Автор говорит, что тимлидство - это часто совсем другая работа и иногда это и то, что вы делали раньше, когда только программировали, плюс пипл менеджмент и пр. дела

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

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

Итог статьи - держаться, стараться доучивать тех. скилы и ждать повышения до менеджера менеджеров.

https://habr.com/ru/articles/789976/

Ложные корреляции и причинно-следственная связь

Относительно недавно решил, что нужно углубить свои знания в продукт и проджект менеджменте. В процессе изучения материалов наткнулся на очень занятный момент про метрики и зависимости. Ни для кого, скорее всего, не секрет, что метрики не всегда показательны и нельзя на слово верить тому, что видишь. Более того - строить зависимости, да и вообще, делать предположения в стиле господина Шарикова из Собачьего сердца о том, как правильно все устроить.

Так вот, один любопытный человек даже сделал сайт, на котором собирает интересные ложные корреляции. Отмечу некоторые из них, которые мне показались любопытными:

- глобальный спад пиратских атак и спад поиска «download firefox» в гугле https://tylervigen.com/spurious/correlation/2204_pirate-attacks-globally_correlates-with_google-searches-for-download-firefox

- количество фильмов, в которых снялся Николас Кейдж и среднее количество просмотров упрощенных видеороликов YouTube https://tylervigen.com/spurious/correlation/6303_average-views-of-oversimplified-youtube-videos_correlates-with_the-number-of-movies-nicolas-cage-appeared-in

- степени магистра, присуждаемые в области философии и религиоведения и число модельеров в Висконсине https://tylervigen.com/spurious/correlation/9511_masters-degrees-awarded-in-philosophy-and-religious-studies_correlates-with_the-number-of-fashion-designers-in-wisconsin

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

Методика STAR

Есть такая методика проведения собесов - STAR.
Идея в целом проста - вытянуть из вас не просто то, что вы делали, а пройти по конкретному фрейму:

1. Ситуация (Situation): Описание контекста или ситуации, в которой возникла проблема или возникла необходимость действия.

2. Задача (Task): Четкое определение целей, задач или проблем, с которыми пришлось столкнуться.

3. Действие (Action): Описание конкретных действий, которые были предприняты для решения задачи или улучшения ситуации.

4. Результат (Result): Итоги и результаты действий, включая достижения, уроки, извлеченный опыт и влияние на окружающую среду.

Ну и тут вы скажете - всё понятно, но я не ищу работу. А я вам отвечу, что эта методика полезна, что называется, почти «эври дей»:

- когда вы делитесь деталями реализации задачи с кем-то, кто понимает вашу область

- в моменты рефлексии по крупным задачам и инициативам, так как ситуации могут быть разные и вы можете постфактум оценить, так ли все прошло и стоила ли игра свеч. Т.е. структурированная оценка

«Я починил»

Мнения о темах по курсу PG на YouTube канале в комментах разделились на: «вообще непонятно» и «спасибо, мне очень помогло». Это было занятно, всем спасибо за комментарии! Канал надо развивать и лучше понимать то, что нужно людям, а комментарии всегда очень помогают.

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

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

В видео обсуждаются распространенные ошибки при работе с SQL, такие как использование SELECT * вместо конкретных полей, не использование JOIN при объединении таблиц, не использование агрегатных функций и группировок, использование зарезервированных ключевых слов в названиях таблиц и колонок, случайное пропускание WHERE в DELETE / UPDATE запросах, проблемы с сравнением значений NULL и несохранение сложного sql запроса.

https://youtu.be/EaHBfaZo9wM

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

Чем дальше в лес. Конкретный пример - сейчас хочется научить LLM описывать наш релиз нотс, чтобы чуть больше раскрыть сделанные задачи, заменить сокращения из глоссария и пр. Есть несколько моделей, на которых я тещщу результат. Одна из них прям никак не хочет заменять сокращение из глоссария, который я предоставляю на вход, на подробное описание термина. В чате сообщества мне напомнили вот что - «Попробуй ей угрожать» 😎 . Сразу скажу, что частично помогло ) Вообще, часто помогает обещание поощрения или наказания. Но, вцелом, прикол, конечно - годы идут, учишься аккуратному и продуманному пипл менеджменту, постигаешь нюансы всякие, чтобы аккуратно всё было. А тут прям как в Криминальном чтиве =)

А вот полезный сайт по этому делу, делюсь с вами - https://www.promptingguide.ai/ru

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

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

В заключении хочу сказать, что важно принимать вдумчивые и взвешанные решения и не пускать всё на самотёк.

"Если я сдамся, лучше не станет"

Хочу поделиться небольшой историей. Дело было много лет назад, кажется, чуть позже эры "статусов ВКонтакте". Я от кого-то узнал об этой фразе Тайсона и в тот момент она показалась такой простой, но такой точной, ёмкой. Путеводной звездой, если угодно. Это скорее всего даже и неудивительно, так как многие великие вещи на удивление крайне просты. Так вот. В какой-то момент фраза Тайсона так меня захватила, что я даже нашел красивый постер в интернете, распечатал А3 и повесил в рамку на стену. И знаете, тогда это очень помогло. До сих пор, когда жизнь меня испытывает, я вспоминаю это простое, но ёмкое изречение, собираюсь с силами и двигаюсь дальше.
Желаю всем побольше сил, поддержки от близких и добра!

Тот самый момент

До компа у меня был Dandy в виде большой компьютерной клавиатуры. Там можно было картриджи вставлять и играть, а также запускать интерпретатор Basic.

В какой-то момент старший брат такой важный со школы вернулся, сказал "ща покажу", открыл интерпретатор Basic и начал что-то с тетради школьной набирать. Потом всех позвал и нажал Enter.

На экране начали рисоваться фракталы. Красивые такие. Анимация была плавной. Сказать, что я тогда офигел - ничего не сказать. Просто представить не мог, что школьник может сделать что-то, что будет на экране телевизора что-то рисовать. Вот тогда я понял - это моё.

Позднее, с другом Лехой, мы много на чем кодили. Сперва на QBasic, потом Visual Basic, C++, Visual C++, так и закрутилось. В 2020 году я писал статью об этом всем. Сейчас постепенно мигрировал в менеджера, но кодить все равно очень люблю.

Мне всегда было интересно как народ попадает в IT, поэтому если кто найдет в себе силы поделиться - буду рад.

Коммуникации

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

Рецепт тут простой:
☝️ Сформулируй в голове мысль, которую хочешь донести

☝️ Напиши и перед отправкой перечитай то, что получилось. Не ленись это сделать несколько раз, если будет нужно! Точность комуникации важна

☝️ Проверь доносит ли твой текст мысль полностью. Все ли будет понятно тому, кому ты пишешь (а не тебе), весь ли контекст есть, чтобы человек тебя успешно понял

Тоже самое касается постмитингов. Не написал - скажут, что "этого не было", написал не точно - тоже мало смысла будет в этой активности.

Рубрика: простые истины

☝️Сотрудника нанимают для того, чтобы он решал проблемы, а не создавал их. Поэтому помните, что согласовывать придуманные вами решения - это ОК. Постоянно эскалировать проблемы до своего руководителя и спрашивать решения у него (или еще хуже вообще не эскалировать и тихо ждать, когда все загорится) - не ок.

☝️Наверняка вы работаете в команде. Команда должна достигать успеха. С вами команде должно быть лучше, чем без вас. Соответственно вместо того, чтобы придумывать, что помешает команде сделать задачу, придумайте как помочь команде или смежникам довести задачу до завершения. Завершение - это когда пользователи начали пользоваться и рады, а не когда код написан.

☝️Если кто-то, по вашему мнению, "творит какую-то дичь", надо это с ним обсудить и послушать почему делается именно так. Возможно нужна корректировка, а может бы все ок, просто вы не так видели проблему.

--

p.s. Надеюсь, что неделя у всех выдалась продуктивная и теперь можно спокойно отдохнуть. Всем удачных выходных!

Управление ожиданиями

Представьте, что вы договорились о том, что вам придут менять батарею в комнате в субботу в течение дня. Вы строите планы на выходные исходя их этого. В пятницу сами уточняете всё ли в силе и получаете ОК. В субботу сидите ждете, не идете гулять, а человек взял и не пришел. Хуже еще, если сам не звонит с извинениями и оправданием. Наверняка такое было с каждым. Что подумаете? Что будете делать? Захотите ли с ним работать?

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

По пунктам:

☝️Проактивно держите в курсе заинтересованных лиц

☝️Не бойтесь передоговариваться. Не укусят. Хуже будет, если будете молчать

☝️Не обещайте того, в чем не уверены. Говорить, что сейчас период неизвестности - нормально. Но агументируйте почему сейчас такая ситуация, а также расскажите план по снижению неопределенности и сроки. Понятное дело, часто так делать будет странно

☝️Если тема сложная - лучше сделать отдельную встречу для разбора и пояснений, чтобы не создавать винегрет в головах у коллег

И еще раз - всегда лучше передоговориться, чем просто молча продолбать все сроки и ждать, что оно как-то само там разрулится. Оно разрулится, конечно, но не в вашу пользу.

Тайное знание

Простите, что долго не писал сюда. Постараюсь исправиться и в следующем посте расскажу, почему так произошло и какие изменения у меня случились в текущем 2024 году.

Сегодня хотел напомнить про один из «лайфхаков», который поможет каждому делать работу лучше и быть на хорошем счету у всех, с кем ведешь дела. Совет до безобразия прост. Я живу так сколько себя помню. Однако, я за свою практику в it, раньше часто сталкивался с его игнорированием другими людьми. Примерно последний год в работе такого нет, а раньше достаточно часто наблюдал такое у разных людей. Совет хорошо работает и для других сфер деятельности.

Итак: после того, как ты сделал работу, проверь её сам. Можно какой-то встречной проверкой. Если собираешь данные - найди другую метрику, которую делал не ты и сравни с ней. Или попробуй пересчитать через смежные данные. В общем, нужно проверить свою работу через другие данные.

Это могут быть не отчеты или данные, а код для код ревью, например. Посмотрите сами на PR прежде, чем показывать его кому-то. Точно ли там все ок? Все ли закоммитилось или что-то не так? Тоже самое с передачей задач в QA. Стоит прокликать базовые сценарии самому. Я лично смотрел очевидно плохие PR-ы с неработающей логикой, где, чтобы найти ошибку, нужно было хотя бы один раз запустить свой код.

Звучит просто, делается не всегда просто. Многие игнорируют. Однако имхо сдавать проверенную самим собой работу - это база.

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

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

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

Всех с наступающим!

Как и обещал, пишу, какие изменения у меня случились в этом году. Итоги года не подвожу, просто расскажу небольшую историю. TL;DR Сейчас работаю техническим менеджером в Инфраструктуре Яндекса, занимаюсь Observability. Далее расскажу, как так получилось. Драконьего разговорного на собесах не было (кто понял, тот понял) 🙂

В январе 2024 года я задумался про смену работы - все было в порядке, просто хотелось бОльшего масштаба. Далее была череда собеседований в разные компании и началось все с поиска позиции тимлида.

Что интересно, в разных компаниях это совсем разные обязанности. Мне не встретилось, кажется, ни одной вакансии, чтобы ожидания от тимлида повторились, везде свой нюанс. Где-то тимлид - это пипл менеджер, от которого вообще не ждут, что он будет программировать, т.е. совсем не нужно. Где-то ровно наоборт - это больше техлид, и вообще не пипл менеджер. Т.е. менеджментом людей там PM-ы или типа того занимаются. Где-то как из анекдота, что "вам нужен не сеньор, а целый отедел разработки". В каких-то компаниях было все в кучу с разными вариациями. Вопросов к этому всему нет, все спрашивают то, что им нужно. Было интересно и полезно.

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

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

Итог. Я всем доволен и получил, что на самом деле хотел. Иногда нужно остановиться, выдохнуть и хорошо подумать, что ты на самом деле хочешь. А когда решение принято, не сомневаться и делать. Звучит просто, знаю, а по факту мы часто работаем по накатанной и не хотим что-то менять, хоть и хочется, а может даже и надо на самом деле.

---

В новом году я желаю всем больше слушать себя, думать своей головой. Не бояться принимать решения! Больше доделывать, получать значимую дельту, а не просто работу работать. С наступающим!

А о чем встреча? Мне надо заранее как-то подготовиться?

Наверняка вы хоть раз задавались вопросом: «А о чём будет встреча?» или сами его задавали. И наверняка замечали, что некоторые встречи проходят продуктивно и приносят результаты, а другие — нет. Часто причина в том, что у встречи нет чёткой структуры (для больших встреч) или хотя бы списка тем для обсуждения. Пришли, поговорили и разошлись.

В этом посте я не буду объяснять, нужна ли вообще встреча. Предположим, она нужна.

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

Как сделать встречу эффективнее? Рецепт прост: у каждой встречи должно быть описание (повестка), а в конце встречи нужно составить и отправить участникам резюме встречи (follow-up) и желательно убедиться, что его получили, прочитали и согласились.

Зачем это нужно?

☝️ Структурность, целеполагание и экономия времени. Заранее определённая повестка помогает понять, на что направлены усилия встречи. Она организует обсуждение. Потенциально неважные вопросы можно заранее увидеть и вынести за рамки встречи или оставить их на конец.

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

☝️ Запись итогов и последующие действия. У каждой темы должна появиться резолюция и, если нужно, задача (action item) с понятным исполнителем и сроками. Зафиксировать результаты встречи и отправить коллегам — одна из самых важных частей совещания!

Ценность повестки особенно заметна при плотном графике встреч, когда приходится часто переключаться между разными задачами. Когда-то, когда у меня было 1–2 встречи в день, одна из которых дейлик, расписанная повестка не казалась чем-то очень нужным. Но сейчас, когда встреч гораздо больше, хорошо видно, что наличие повестки — это не формальность, а хороший инструмент, который позволяет проводить встречи продуктивнее. Фиксация итогов нужна в принципе всегда, чтобы посинкать ожидания всех участников встречи и зафиксировать, кто и что должен сделать. Тут, как мне кажется, иных вариантов вообще быть не может.

---

Поздравляю всех с Новым Годом и желаю быть еще более продуктивными и полезными!

Красный флаг

Есть моменты, когда необходимо привлечь особое внимание руководителя или коллеги из смежного отдела, стейкхолдера и пр. Если вы столкнулись с проблемой, которая требует срочного решения и помощи, не стесняйтесь поднимать красный флаг!

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

Действия. Что тут можно и нужно сделать:

1. Рассказать команде о проблеме. Удостовериться, что это действительно проблема. Попытаться найти решение или план. Это нужно сделать достаточно быстро, если импакт проблемы большой.

2. Предупредить пользователей, что вы в курсе проблемы и занимаетесь ее решением. Если быстро решить не получается - предупредить их о том, что нужно будет подождать. Далее не пропадать и коммуницировать время от времени. Прозрачность в коммуникациях - крайне важна! Сидеть втихую и ничего не говорить неправильно. Даже если вы в это время занимаетесь решением проблемы. Пустота быстро заполнится чем угодно, но не тем, на что вы рассчитываете =)

3. Если решения нет или оно влияет на сроки проекта - поднимайте красный флаг. Общайтесь с руководителем по этому поводу, ему как минимум нужно бысть в курсе того, что проблема есть. Скорее всего он направит вас по правильному пути или порекомендует к кому обратиться.

Правильно доносите серьезность. Поднять флаг важно не между делом в рамках какого-то иного обсуждения. Простое высказывание вашего переживания может попросту утонуть в потоке задач и проблем, которые сыпятся на голову вашего руководителя. Укажите на проблему четко и ясно. Это поможет акцентировать внимание на важности вопроса и минимизировать риски его упущения. Ваша проактивность может быть ключом к успешному решению проблемы и дальнейшему движению вперёд в рамках проекта. Хорошо работают встречи 1х1, планирование спринта, с командой на дейлике и подобное.

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

Хочется начать разбавлять контент)

Картинка смешная и довольно старая, но от этого не менее актуальная и поучительная.

Суть простая - иногда нужно просто фигачить. С искрой и огоньком так сказать.

Оценивают нас не по тому, что мы делали, а по тому, что мы сделали. И точка.

Авось

Частенько вокруг в жизни проскакивает "авось". Встречается не только в IT. Не осознавая того, мы полагаемся на случай, что создаёт риски для проектов.

Тот самый "авось не со мной", "авось как-то само разгребётся". Так вот, как было сказано в одном фильме "Надежда - это не тактика".

Киты управления
Менеджер управляет тремя "китами": люди, процессы и технологии. Где-то еще маячит бюджет, но не всегда им возможно именно управлять, однако он очень сильно может как зажать команду, так и дать воздуха. Стоит упомянуть, что если результатов от команды нет, то и бюджет скорее всего не увеличат. Тут все просто.

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

Если не заниматься всеми тремя аспектами, то пойдет перекос, и проект рискует не сойтись и быть заваленным.

Практическое применение в IT
Если говорить про IT, то нужны как минимум:
- открытость с теми, с кем работаешь
- регулярная обратная связь
- прозрачность в планировании, отчетности и принятии решений
- регулярные релизы, автотесты
- краткосрочное, среднесрочное, долгосрочное планирование. Оно помогает держать дальний фокус, иметь ближайшие цели и цели на "через полгода"
- постоянное обучение команды, чтобы идти в ногу со временем и технологиями
- процессы разгребания багов, чтобы пользователи были довольны
- улучшения технологии ("точить топор") - обновлять библиотеки, подключать AI и прочее

Эти принципы не только помогают избежать проблем, но и создают доверие внутри команды.

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

Реальные примеры
1. В одной компании несколько лет назад у моего знакомого PM, в надежде "защитить" команду, руководитель не рассказывал, что дела стали идти хуже, скорее говорил наоборот. С одной стороны человека понять можно: он хотел сохранить команду. С другой команда не слепая и по косвенным признакам всё равно всё видела. Привело это к тому, что часть команды все равно разбежалась, а менеджер потерял время. Ведь если бы он вовремя и открыто поделился с командой, что есть проблемы, которые нужно решать, то скорее всего смогу бы "опереться" на команду и решать проблемы не в одиночку. Вовлечение команды в процесс решения проблем может не только предотвратить потери, но и укрепить коллективный дух и улучшить результаты.

2. Легаси-код, который не переписывают, так как "компания уже заплатила один раз". С этим скорее всего сталкивались почти все. Тут палка о двух концах - с одной стороны важно, чтобы код был актуален, с другой стороны зачем постоянно переписывать не добавляя ценности. Тут, как и во всем, нужен баланс и умение говорить ртом вести аргументированный диалог. Нужно учитывать, что нужно будет добавить в проект в плане фич, куда планируется развивать проект, какие еще фичи нужно сделать сейчас в срочном порядке и много другое. Тут универсального рецепта как мне кажется нет - нужно общаться и делать самое важное, что будет двигать ваш проект вперед. Если легаси мешает, его нужно убирать, возможно, даже очень срочно. Если не особо мешает, то может быть нет ничего страшного, если такой код полежит еще полгода в кодовой базе. Слепое переписывание без добавления ценности может быть ресурсозатратным и необоснованным.

В общем, не давайте проектам идти на самотек. Не бойтесь смотреть вглубь проблем и использовать все ресурсы вашей команды для их решения. Не надейтесь на "авось", стройте стратегию и действуйте осознанно!