Книга о росте менеджера в IT от ментора стажёров до CTO. Мне очень понравилась, в первую очередь тем, что речь не о абстрактном менеджменте или менеджменте заводов и отделов продаж — а именно о нашей отрасли, понятными примерами из неё.
Дальше отдельные заметки, из того что понаотмечал себе (и там скорее то, чего сейчас у меня нет / не хватает на это времени / не понятно нужно ли оно).
Про 1-on-1 — регулярность и формальность, чтобы :
- на них находилось время
- находилось время на что-то кроме них
- т.е. чтобы можно было организовать отрезки времени, когда тебя не отвлекают
При этом при небольшой команде и плотной работе с ней — надо понимать, зачем они и что там обсуждать, нет смысла превращать это в дублирование статус репортов.
Про план развития и план на 30-60-90 дней. Второе — хорошая штука при онбординге. Первое может быть нужно в первые n лет. Хорошей практикой должно быть требование роста. Т.е. если работник не вырос за год-два-три — это повод с ним расстаться. Хорошие примеры про отмазки и причины почему задачи брались медленнее и вообще роста не получалось — тут был праздник, а тут вы были в отпуске, а тут у меня болела собака — все по отдельности, ок, но когда оно сплошняком — повод задуматься.
Про грейды — взять чьи-то чужие грейды — прямой путь к фейлу. Если мы вводим их в первый раз — лучше делать их на основе сложившихся уже уровней в вашей компании. Задуматься о них стоит, если ушло 2-3 человека, потому что им не понятны карьерные перспективы. Раньше скорее всего — лишняя трата времени и лишняя бюрократия. Если и вводить грейды, то в зависимости от ответственности (а не знаний или навыков), широкие и с пересекающимися вилками, если они привязаны к зарплате.
Про построение процессов — рост формальности процессов растет с ростом компании, по мере роста рисков и из-за удаления руководителя разработки от непосредственно кода, для того, чтобы не было внезапных сюрпризов. Может происходить как проактивно (но надо не перестараться и не бездумно внедрять все подряд, а понимать, какие риски мы сейчас покрываем конкретно этой практикой), так и реактивно по мере инцидентов (классный пример, что ааа, тут второй месяц пишут непойми что и прогресс неясен, а там новая функциональность оказалась написана на скале, которую в компании не знает никто, кроме того, кто это написал, и на это потрачено уже достаточно много времени, чтобы просто от этого теперь отказаться). Мысль, что код ревью — не ловит баги, баги ловят тесты, а социальная практика, повышающая качество кода за счет знания, что кто-то его будет смотреть (и увидит, что он на скале :), и насмотренность на разные части продукта разными разработчиками
В целом — книге моя твердая 5 🙂