Переоценка кадров или как сеньоры становятся мидлами, а мидлы джунами

так как возможно разработчик Майк занят на супер ответственном проекте или его задача требует высокой концентрации

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

для мидла очень важен навык «сигнализировать о проблеме», и если он им не обладает, то по софт скиллам это возвращает его к джунам

если уж для мидла маст хев «сигнализировать», то почему у вас еще не понижен до джуна сеньор, который вовремя не сказал своему менеджеру о нецелевых тратах рабочего времени?

Все это деление — сплошная условность. А почему вообще этих категорий 3, а не 5 или 10? Как в других областях деятельности.

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

За ваше предложение обсуждать проблемы на стендапе, понижаю вас из тимлида в джуны.

Резать косты призываете.
Себя для объективности не забывайте (проеб-ся лишних 2 дня — какой ты нах лид — в сторону!)

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

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

Сдал проект с чувством выполненого долга, воодушевление так и прет. Тут подходит ТЛ и говорит «что ты джун, отвлекаешь сеньеров от серьезных дел? И вообще, работаешь медленно и тобой нужно заняться».

Статья неоднозначная, понимаю негатив комментаторов — однако когда-то приходилось сталкиваться с примерами из статьи. На самом деле это выглядит так, образно выражаясь — у человека есть наживка и удочка, кто-то уже прикормил можно сказать, а он к тебе приходит за рыбой. Конечно возникает диссонанс, ведь мне тоже придётся тратить время и разбираться в проблеме, почему бы сразу самому этим не заняться? И наоборот, бывает так, что в команде кто-то один обладает неким ключевым знанием про требуемый компонент системы, и тогда к кому обращаться, если не к нему? Это уже совсем другое дело.

Горизонтальные неформальные связи — это наоборот круто. Вообще, все, что связано с получением новых знаний и общением — это ОООЧЕНЬ круто. Иначе надо понимать, что люди — биороботы, которые отрабатывают показатели.
Понижение Тома до уровня джуна — вроде невелика потеря для компании, но из статьи не очень ясно, велика ли потеря. Анализа-то нет. Технические проблемы могут быть реально непростыми. Например, плохо задокументирована CRM. Или перевод документации кривой (но об этом ни Том, ни Майк не в курсе). Или документацию надо более новую скачать.

Как по мне, наоборот:
1. Человек первоначально пытался сам разобраться, джуны напротив при каждом пчихе сразу идут донимать своих коллег. Оценка сроков опять вещь субъективная, все мы любим недооценивать сложность той или иной работы потому что большинство из нас оптимисты, пессимисты бы на первой десяти багах в своей карьере бы повесились ))

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

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

В своей команде я практиковал противоположный подход. Взаимопомощь всегда в топе приоритетов.
Субъективно, тайтл совершенно не важен(и у нас он используются разве что только при поиске кандидатов). Столкнуться с проблемой, которую ты ещё не решал и не знаешь как это сделать, может каждый. Своевременный сигнал о затруднениях конечно штука важная, но ведь решённая задача — это лучше?
Я не отрицаю необходимости в поиске информации в гугле, чаще всего там можно найти решение или хотя бы подсказку, но ведь не всегда.

Все эти истории «разработчик очень занят своей задачей и не может отвлечься» чаще всего ни о чём. Да, бывают действительно срочные проблемы (подгарает что-то на проде к примеру), но в подавляющем большинстве такие проблемы решаются достаточно быстро.

Дополнительно от подобного процесса я получаю плюсы:

• Новые знания получают оба участника диалога (ну или как минимум 1, если Майк уже знал решение)
• Люди за 0,5 — 1 час разрисовали доску в поисках правильного решения, при этом Майку и Тому уже проще общаться между собой. А ещё Майк в следующий раз может рассчитывать на помощь Тома. Ведь именно так зарождается здоровая атмосфера в команде, нет?

И да, я понимаю, что Майк отвлёкся от своей задачи. Я 9 лет в IT, но честно говоря никогда не встречал ситуации, когда 1-2 часа обуславливали успех или провал фичи.

В приведённом автором примере(если предположить, что Майк отказал в помощи) бы я бы скорее обратил внимание на причину отказа. В случае, если бы Майк действительно был очень занят, я бы ожидал от него услышать что-то вроде «Том, извини, я сейчас очень занят, надо быстро разобраться с алертом с прода. Когда закончу с этим делом — помогу. Если ждать не можешь, пингани Джерри, он вроде что-то подобное уже решал»