А при чем тут нетфликс?
Миграции - это штука, которую нужно упомянуть в design review. И все.
Реализуется обычно как пара строчек на flyway, но иногда - сложнее. Иногда - много сложнее и надо эксплуатации рассказать.

Миграции чего? Рдбмс?

Любых db, почему только реляционных?

Понял, не знал

Ну, стандартная штука, была коллекция, стал кортеж. Тут уже не просто "колонку пустую добавить", тут нужно данные перетряхнуть.
И такие штуки надо уметь делать кусочками (один запрос упадет по памяти и заблокирует все нафиг), следить за их статусом, проверять полноту, учитывать сервисам и т.п.
Для rdbms есть liquidbase и flyway, для nosql надо свое обычно писать.
Впрочем, у flyway куча ограничений, так что все равно лучше свое писать.

Ну и вот если человек пишет свои первые 20 tech design - ему нужно на что-то опираться  и тут чеклисты - очень помогают.
Как и примеры (надо будет добавить в доклад, кстати) "хорошего" и "плохого".

Разработчик вообще должен думать только над важным.
Все, что можно убрать в инструкции, чеклисты, автоматизацию - должно быть туда убрано.

+

Кстати, как относишься к кросс командному ревью? Меряешь как-то процесс ревью в своей команде/командах? Если да, то какими линейками?

Это разные вопросы.
1. Я вообще плохо отношусь к обязательному code review, это как раз про "заставлять программиста думать про неважные вещи".
Кросс-командное - тут тоже не нужное
2. Иногда (часто) полезно кросс-командное review-on-demand или seagull-review (например кого-то из старших членов гильдии)
3. review процессов вне команды смысла обычно не имеет, так как процессы выстраданы конкретной командой.
Тут скорее коучинг лидов имеет смысл, им занимаюсь время от времени, как у себя в компании, так и в других компаниях.

Линейки и метрики в разработке - обычно приносят больше вреда, нежели пользы.
То, что можно очевидно померить деньгами - меряю (кстати, на CodeFest был хороший доклад Виталия Шароватова про TЭО, советую послушать), что нельзя - ну и нафиг

Есть вот ещё такой вопрос наболевший у меня, если не сложно - буду рад послушать твой алгоритм действий

https://t.me/tlbootcamp/26896

Это к Виктору, скорее.
Но, классический первый вопрос - "а что такое лоуперформер и как ты это определил"?

А после коучинга лиды всё равно занимаются 3-м пунктом
По поводу линеек не согласен, могут быть выбраны не те линейки, просто

А зачем им ревьюить процессы друг друга? Советовать -да. Обмениваться личным опытом или обсуждать проблемы - да. Но это скорее про работу гильдии, нежели про review

Я еще не видел ни одной приличной линейки. Хотя показывали мне много разных.

Я вот не смог найти никаких обоснований этой модели, честно говоря.
И ее смысл мне не очевиден (как и большей части "моделей" в менеджменте - которые не модели, а в лучшем случае классификации)

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

Тут дофига причин.
От "ему не хочется работать в этой команде", "ему не хочется работать в режиме мустанга" до "выгорел".
А дальше - разные варианты
1) иногда производительность - не самое важное свойство. У меня в одной команде был очень слабый разработчик (и без роста), но он очень хорошо влиял на всю команду (коммуникации, шутки и т.п.) - и полностью окупал свою зарплату.
2) иногда рост - не важное свойство. У меня был сотрудник, который не рос, но был готов писать отчеты (которые прочим писать было лень, слишком одинаковые). Он это делал медленно и не очень качественно, но зато я мог переключать ресурсы других разработчиков на другие задачи и не давать им "демотивирующие" задачи.
3) иногда более медленный рост демотивирует прочую команду - и тогда надо расставаться.

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

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