К книге
Настоящий CTO: думай как технический директор2. Взаимодействие с руководством и коллегами. 2.4. Принимаем дела у предыдущего технического директора. 2.4.1. Цените, а не принижайте
12%
2. Взаимодействие с руководством и коллегами. 2.4. Принимаем дела у предыдущего технического директора. 2.4.1. Цените, а не принижайте
41

Очевидно, но от этого не менее важно: когда вы начнете разбираться в наследстве предыдущего технического директора – никогда не относитесь пренебрежительно к его решениям и методам работы, как бы вам того ни хотелось. Не стоит становиться «директором по обвинениям», который мигом переводит стрелки, чтобы отвести критику от себя. Не беспокойтесь – все знают, что вы новичок и не несете ответственности за прошлое. Вам не нужно об этом напоминать.

Лучше отметьте достижения. В конце концов, независимо от того, что вы думаете о тех или иных решениях предыдущего CTO – он успешно управлял технологиями, и компания генерировала достаточно прибыли, чтобы предложить вам достойную зарплату. Для понимания каких-то решений вам будет не хватать исторического контекста: они были приняты в свое время и в своих условиях. Не спешите судить.

Иногда дело не в том, что предыдущий CTO не знал лучшего способа (хотя в большинстве случаев так и есть – люди не знают того, чего не знают). Возможно, их заставил пойти по данному пути генеральный директор, который считал, что знает лучше, а у технического директора не было навыков или данных, чтобы убедить его в обратном. Вы никогда не узнаете истинную причину, поэтому нет смысла оглядываться назад, только вперед. Какие бы проблемы ни возникли, теперь их решать вам.

Заметки с полей

Вы сделали… что?

Я часто сталкивался с очень креативными решениями и, вместо того чтобы осуждать их, хвалил творчество и изобретательность их создателя, мысленно крича: «О чем ты вообще думал?» Для одной портфельной компании мы искали нового технического директора на смену тому, который работал со дня ее основания. Этот джентльмен не доверял стандартным системам контроля версий (CVS, SVN или Git). Что сделал он? Он создал и поддерживал свой собственный стандарт и заставлял команду использовать его. С одной стороны, я должен был оценить его изобретательность, но, покопавшись, я обнаружил, что это не более чем причудливое архивирование, а не контроль версий в современном представлении. Предложение перейти на Git я аргументировал возможностью использовать встроенный инструментарий в IDE, не поднимая шума и не привлекая внимания к тому, насколько слаб имеющийся «контроль версий». Таким образом все сохранили лицо. Не афишируйте свои победы и не ищите похвалы за то, что вы умнее. Просто сделайте свою работу и двигайтесь дальше.

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

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

Предыдущая главаГлава 41 из 332Следующая глава