Прошлый результат команды имеет смысл использовать в следующем плане вместе с условиями, при которых его получили. Если часть работы закончили по вечерам и в выходные, повторить тот же объём в обычном графике может не получиться. Переработки легко потерять при подсчёте закрытых задач, а затем незаметно включить их уже в следующее обещание.
Собственная разработка техлида занимает то же время, на которое команда рассчитывает для ревью, помощи и общих решений. Поэтому полезность его задачи ещё не объясняет, стоит ли ему браться за неё сейчас. В план придётся включить и работу, которую без его участия не могут закончить другие, а затем разобраться, какая из этих зависимостей действительно необходима.
Привычка отвечать за другого мешает обсуждать работу: объяснение может прозвучать уверенно, хотя сам автор решения ещё не успел назвать его основания. Просьба дать договорить нужна и для того, чтобы эти основания услышала команда. Если одной просьбы не хватило, продолжение зависит от того, старается ли собеседник её учитывать или отказывается что-либо менять.
Переход к новой архитектуре можно вести вместе с текущими задачами: заменять старую реализацию того модуля, который всё равно приходится менять. Это увеличивает объём текущей работы, зато позволяет проверить новую реализацию на нужной возможности. Порядок перехода будет зависеть от того, какие части системы понадобилось менять: до редко меняющегося модуля очередь может так и не дойти, хотя ради него придётся поддерживать старый код.
Уже обещанная дата делает оценку работы неудобным разговором: любой более поздний срок звучит как отказ от обязательства. Но сама дата ничего не говорит о том, что к ней должно быть готово. Пока это не определено, разработчик и заказчик могут соглашаться с одним сроком, имея в виду разные результаты.
Разработчику могут предложить возглавить команду в знак доверия к его опыту. Но интерес к более сложным задачам в разработке ещё не означает желания управлять людьми. Повышение может увести от задач, в которых как раз хотелось расти.
По названию «мидл» трудно понять, какую работу разработчику готовы доверить. Советы «стань самостоятельнее» и «проявляй инициативу» оставляют тот же вопрос: что именно он должен научиться делать? Ответ стоит искать в задачах своей команды, где можно сравнить ожидания руководителя с уже сделанной работой.
Мне не обязательно полюбить общий стиль кода, чтобы его соблюдать. Когда одинаковые вещи написаны одинаково, меньше времени уходит на выяснение, есть ли за различием смысл. Эта польза остаётся, даже если для собственного проекта я выбрал бы другой способ писать код.
На ревью я хочу проверить решения, к которым уже привык и в которых сам перестал замечать спорные места. Для этого нужно понять, что затруднило другого разработчика. Предложенная им правка может оказаться неудачной, но это ещё не повод отмахнуться от самого замечания.
За коротким советом часто стоит опыт, который помог к нему прийти: попытки, ошибки, условия, при которых выбранное действие сработало. Собеседник получает готовый вывод, но ещё может не понимать, как применить его у себя. Мне интереснее разобраться, чего ему не хватает, чем ещё раз повторить объяснение.