Делегирование — скользкая дорожка

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

Убежден: тех-лид должен продолжать «марать руки». CTO тоже может марать руки - этого очень не хватает в работе.

И здесь позволю себе небольшое лирическое отступление.
Часто тех-лид не понимает цели, ради которой ему нужно «марать руки». Просто раскатить минорное обновление, чтобы показать всем, что еще способен кодить? Нет. Нужно понимать, насколько удобно разработчикам использовать конвейер. Выявлять ключевые проблемы в среде разработки, чтобы помочь своим инженерам и сделать рабочую среду лучше.

Проблема «царя во дворце»

Проблема мистера «Царь во дворце» часто кроется в том, что он считает свою работу чисто стратегической. Думать масштабно и делегировать результаты своих размышлений подчиненным. Так поступают многие и теряют доверие.
О таких часто говорят на разных уровнях: «Ну все понятно, ему хорошо.
Но его не видно, и он ничего не делает».

Если только делегируешь — значит, забыл, что значит работать по-настоящему.
Мне нравится смотреть на свои направления как в стратегии (я про Starcraft, но скорее про Dawn of War 2): наблюдаю, куда движутся команды, что у них происходит в каналах коммуникации, вижу проблемные участки или нарушения коммуникации, спускаюсь на дропподе, погружаюсь в проблему до самой земли и даже до червей в земле. Ищу ключевые проблемы и работаю над тем, чтобы помочь команде увидеть общую картину, чтобы на основе стратегии применять тактику, а не просто бежать и делать.

Важность понимания корня проблемы

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

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

Вместо того чтобы остановиться и подумать: может, стоит перестать делать кучу бесполезной работы и подумать, какие ключевые проблемы стоит решить и кому.
Задай вопрос: куда мы идем и зачем? Что мы тут строим?

тех-лид с чистыми ручками

Тех-лид, твоя работа — показывать делом и учить младших разработчиков. Ради всего святого, это же очевидно! Если ничего не делаешь, сидя на стуле в кабинете, с чего взял, что твоя команда начнет шевелиться вдохновенно и искать точки достижения успеха?
ТехЛид - это не про пенсию и покой. Это про другой уровень задач.

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

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



#codemonsterslog