Многих IT-руководителей ценят за их инженерный опыт: зачастую до менеджерской позиции они занимались разработкой и были техлидами в командах. Но, к сожалению, с течением времени любой специалист, не программирующий ежедневно, будет терять уровень экспертизы. Предлагаю ряд способов, которые помогут уменьшить деградацию технических навыков и позволят на практике осваивать новые тренды в IT-отрасли.
Pet-проекты
Самый очевидный способ. По основному роду деятельности писать продуктовый код уже нельзя, иначе вместо руководителя вы будете чрезмерно дорогим программистом (в роли менеджера нужно все задачи выполнять чужими руками). Но никто не запретит вам писать код «для души» в личное время, решая интересные задачи и оттачивая навыки для полноценной разработки. Этот способ полностью зависит от свободного от работы времени, необходимо стараться вовремя заканчивать рабочий день и заранее планировать «окна» для глубокого погружения в pet-проект.
Code review
Участие в проверке кода поможет глубже погружаться в подконтрольные проекты, понимать текущий этап на пути к достижению цели и влиять на улучшение качества кода. Из-за дефицита времени approve на code review от технического руководителя не должен быть блокирующим, но перед каждым крупным релизом полезно выделить время на проверку.
Рекомендуется сначала прикинуть: «А как бы я сам решил эту задачу?», и потом сравнить получившийся результат со своими мыслями. В случае крупных расхождений оцените, чьё решение эффективнее. Если ваше, то обсудите его с командой, обменяйтесь знаниями. Если же предложенное решение удачнее вашего, то можно его подробно изучить и повысить свой уровень технической экспертизы. В случае нахождения неизвестных или забытых областей знаний — поставьте их себе в план на изучение.
Написание статей
Согласно методу Феймана, для глубокого изучения какой-либо темы необходимо уметь её объяснить даже ребёнку. Пытаясь рассказать сложные термины простыми словами воображаемому ребёнку или неспециалисту, находите плохо понятные вам моменты и фиксируйте их. После доизучения отмеченных тем повторите мысленный эксперимент «с ребёнком», доведите объяснение до удовлетворительного результата. Эта техника поможет вам лучше понять материал и усвоить его.
Метод подходит и для написания статей. Старайтесь объяснить понятный вам материал определённому кругу лиц. Найдя места, где объяснить материал без специфичных терминов будет сложно, остановитесь и глубже изучите тему, опираясь на свои знания. Также написание статей помогает улучшить письменную речь и «слог».
Выступления на конференциях
Так как выступление предусматривает всестороннюю подготовку и отбор – это будет дополнительной мотивацией глубоко изучить тему для её полного охвата и возможности ответить на любые каверзные вопросы. Так же вопросы из зала могут помочь взглянуть на вопрос с новой стороны и получить дополнительные знания, обменяться опытом.
Решение инцидентов
Во время технических инцидентов дорога каждая секунда. В этот период организм максимально мобилизируется, и принимаемые сообща решения, помимо возможного решения проблемы, способствуют концентрированному обучению. Кроме того, после решения инцидента при его разборе также легко находятся области, необходимые для изучения и проработки.
Участие в грумингах и планировании
Давая оценку в storypoint или человеко-днях, вы продумываете: «Как бы я сам сделал эту задачу?» Работает тот же набор нейронных связей, что и при ежедневной разработке, а значит, эти нейроны будут меньше страдать от деградации. Если ваша оценка и оценка инженеров из команды сильно различаются, то при обсуждении отличий можно лучше понять ошибки и получить новый опыт.
Хакатоны
Этот способ подойдёт тем руководителям, у кого есть более-менее свободные выходные и нет семейных обязательств. На хакатоне в сжатое время можно запрограммировать рабочий MVP продукта (руки-то помнят), а соревновательная обстановка добавит драйва и эмоций. Не рекомендую часто участвовать в хакатонах: как правило, после полного напряжения сил нужен отдых, а времени на восстановление может и не оказаться (работа руководителя часто непредсказуема). При грамотном использовании хакатоны помогут поддерживать средний уровень экспертизы и получать готовые для развития pet-проекты, а при частом участии могут привести к выгоранию.
Участие в собеседованиях
Регулярное собеседование кандидатов позволит улучшить отбор персонала, повысить культуру в организации и способствовать развитию существующих команд. На техническом интервью особо интересен рассказ кандидата о его прошлом инженерном опыте. Задавая уточняющие вопросы про технологии и успешно применённые технические решения, можно лучше узнать о трендах в отрасли и обогатить свои знания.
Заключение
В целом, сохранение технической экспертизы является важной задачей для руководителей. Правильное использование и сохранение технических знаний позволит компании оставаться конкурентоспособной, а руководителям — эффективно управлять и развивать своих сотрудников.
А какие способы используете вы?
Комментарии (8)
Ravager
28.09.2023 10:48+1какие способы используете вы
Не иду на руководящие должности где не будет возможности писать код. Потому что потом фиг работу найдешь. Самый свободный человек это программист, что-то не понравилось, взял вещички и на выход. А будучи руководителем ты становишься заложником компании, это золотая клетка. Некоторые вообще считают что быть программистом или писать код после менеджера это зашквар, но это не очень умно.
SeekerOfTruth Автор
28.09.2023 10:48Действительно разработчику в разы проще сменить компанию. и многие программисты после опыта работы руководителем возвращаются в прошлую должность(это совершенно нормальный процесс, опытный программист всегда более ценен чем немотивированный руководитель)
Но если инженер сменил перешёл на менеджерскую позицию, и несмотря на кучу минусов решил остаться и продолжить своё развитие в новом амплуа - ряд описанных выше способов могут помочь сохранить хотя бы часть экспертизыNeverIn
28.09.2023 10:48Риск профессиональной деквалификации менеджера должен компенсироваться кратным уровнем зп, а этого нет как мы видим, поэтому и ценность перехода сомнительна.
Whatis_love
28.09.2023 10:48хаха, прикольно, я все чаще замечаю что использую статьи программистов в своих инженерных задачах - мне прям нравится, придумывать как применять их опыт на своей практике далекой от написания кода
Kriminalist
Экспертиза - это процесс.
expertise -
опыт m
компетенция f
квалификация f
экспертные знания
компетентность f
навыки m
профессионализм m
ноу-хау n
мастерство n
подготовка f
эрудиция f
SeekerOfTruth Автор
не смог понять основную мысль в комментарии, можете подробнее объяснить?
из букв m f n должна какая то формула получиться? или может есть статья где это описано?
arakchi
Разрешите я попробую пояснить за автора комментария. Он, вероятно, имел в виду, что слово "экспертиза" в русском языке не имеет того значения в котором Вы его употребили в заголовке. Словари дают толкование которые можно можно обобщить примерно как "процесс исследования чего-то кем-то, кто имеет соответствующие навыки". Вы же его использовали как кальку с английского (как, например, "назначу 'митинг' вместо 'встречи'") слова expertise, которое в контексте статьи лучше всего (на мой взгляд) переводится как "компетенция" ("Способы сохранения технической компетенции для руководителей"), или "квалификацию".
И автор комментария привёл Вам возможные переводы слова expertise с которого Вы сделали кальку. А заодно цитату из вашей статьи, которую можно интерпретировать, как призывающую не делать так.
Буквы же f, n, m это просто обозначения рода и числа, для слов-вариантов перевода (компетенция f - женского рода). Очевидно, попали в комментарий в процессе копирования и не были удалены.
Извините за много текста. Я, просто, тоже очень печалюсь когда вижу такую кальку, массовое её использование начал замечать лет пять назад.
Kriminalist
Снимаю шляпу в реверансе! :)