Что Я Хотел Бы Знать, Прежде Чем Стать Техническим Директором



Что я хотел бы знать, прежде чем стать техническим директором

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

Это был бурный период, наполненный замечательными впечатлениями.

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

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

Стартапы — это быстроходные лодки с якорями — текущими проблемами и болевыми точками в использовании продукта, — которые не дают ему двигаться.

Чем глубже якорь, тем сильнее боль клиента и тем больше якорь замедляет движение лодки.

Решения, которые вы принимаете в первый день, имеют волновой эффект с течением времени.

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

Возможно, именно поэтому облачные провайдеры предлагают стартапам первоначальный баланс до 100 000 долларов за свои услуги.

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

По мере того, как вы набираете обороты, давление разрабатываемого функционала возрастает и прекратить переработку кода становится невозможным и немыслимым.

Я остался доволен нашим выбором: Amazon Web Services, Elastic Beanstalk, Firebase, AngularJS, Coffeescript, Kafka, Simple Queue System, SocketStream, Docker, SemaphoreCI, MySQL. Из этого списка только AngularJS и MySQL были связаны с дальнейшими проблемами масштабирования.

Наш монолитный набор кода AngularJS слишком велик.

Первоначальная загрузка занимает довольно много времени, а приложение работает довольно медленно.

MySQL (в RDS) аварийно завершает работу и перезапускается из-за увеличения сложности запросов BI. Это было трудно исправить.

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

CoffeeScript и AngularJS — самые устаревшие компоненты (мы планируем перейти на TypeScript и последнюю версию Angular).

Все наши технологии были довольно продвинутыми, когда мы их представили, и это чудо, что мое пристрастие к «хипстерским» технологиям не вызвало каких-либо серьезных проблем.

Я ценю очень лаконичный синтаксис CoffeeScript и считаю, что с годами он помог мне повысить личную продуктивность.

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

При внедрении любой новой технологии вы берете на себя долгосрочный «технический долг».

Аналогично, написанные вами компоненты и библиотеки останутся с вами надолго.

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

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

Это стало так называемой спиралью смерти для многих проектов.

У нас хорошо зарекомендовал себя метод правило бойскаута :

«Когда вы уйдете, постарайтесь оставить этот мир немного лучше/чище, чем когда вы пришли».

- Роберт Баден Пауэлл, основатель организации бойскаутов и девушек-гидов

Мы стараемся вносить небольшие улучшения в проблемные участки кода, над которым работаем.

Иногда бывает трудно подумать об общем состоянии (всегда несовершенном) кодовой базы; вместо этого мы концентрируемся на постоянных небольших улучшениях.

Наконец, небольшое замечание о тестировании: мне было очень трудно убедить команду реализовать написание тестов.

Я написал тесты для многих частей системы и настроил серверы для автоматического запуска тестов.

Несмотря на это, я редко вижу, чтобы кто-то еще добавлял тесты.

Я всегда хотел, чтобы тестирование процветало из-за присущих ему достоинств, но, к сожалению, этого не произошло.

Мои идеи по решению этой проблемы: Переобучитесь написанию тестов и убедитесь, что у разработчиков есть достаточно времени для их написания.

Требовать хотя бы один тест для проверки основных функций.

Оптимизируйте тестовый сервер, чтобы тесты выполнялись за 10 секунд вместо десяти минут (ой!).

Помимо чисто технических решений, «хлеб» технического директора — управление людьми.

Повседневная деятельность включает в себя управление, руководство, найм и увольнение сотрудников.

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

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

«Новым» рекрутерам, вероятно, придется потратить больше времени и отказать большему количеству людей.

Требуемый отбор оказался более строгим, чем я ожидал.

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

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

К счастью, мы получили несколько полезных советов по этому поводу от Майкла Сибеля и Y Combinator: Нанимайте сотрудников только тогда, когда вы чувствуете, что вам это крайне необходимо (например, вы не успеваете за разработкой новых функций, необходимых для заключения новых контрактов).

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

Это ключевой вопрос.

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

) Итог: если вы не уверены в заполнении конкретной позиции, вероятно, еще слишком рано.

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

Чаще всего это заканчивалось неудачей.

Тем не менее, управление людьми прошло относительно гладко.

Регулярные, открытые и честные обзоры эффективности работы, в которых обсуждается, что было хорошо, а что нет, помогли мне и моим коллегам построить здоровые и продуктивные отношения.

Я обнаружил, что увольнение людей — самая трудная часть работы.

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

Это всегда сложно сделать.

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

Знание плана личного развития помогает некоторым людям оказаться на высоте и стать высокопродуктивными членами команды.

У каждого должна быть возможность.

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

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

С какими высказываниями автора вы согласны, а что считаете ошибкой в работе КТО?

Что я хотел бы знать, прежде чем стать техническим директором

Теги: #Разработка стартапов #Карьера в ИТ-индустрии #Управление развитием #ИТ-инфраструктура #технический директор #технический директор

Вместе с данным постом часто просматривают: