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

https://medium.com/sketchdeck-developer-blog/what-i-wish-i-knew-when-i-became-cto-fdc934b790e3
  • Перевод


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

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

Стартапы — это быстрые лодки, имеющие якоря — текущие проблемы и боли в использовании продукта, которые мешают ей двигаться. Чем глубже якорь, тем сильнее клиентская боль и тем сильнее якорь тормозит движение лодки. Решения, которые вы принимаете в первый день, имеют «волновые» последствия со временем. Теперь я в полной мере понимаю то, что инфраструктура, фреймворки и языки программирования, которые вы выберете, будут удерживать вас в течение очень долгого времени. Возможно, именно по этой причине облачные провайдеры предлагают стартапам исходный баланс до 100 000 долларов на свои услуги.

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

Я был доволен нашим выбором: Amazon Web Services, Elastic Beanstalk, Firebase, AngularJS, Coffeescript, Kafka, Simple Queue System, SocketStream, Docker, SemaphoreCI, MySQL. Из списка, только AngularJS и MySQL были связаны с дальнейшими проблемами масштабирования. Наш монолитный AngularJS code-bundle слишком большой. Первоначальная загрузка занимает довольно много времени и приложение работает довольно медленно. MySQL (в RDS) выходит из строя и перезапускается из-за растущей сложности BI запросов. Это было трудно исправить.

Сейчас я понимаю, что технологии имеют удивительно короткий срок службы. CoffeeScript и AngularJS являются наиболее устаревшими компонентами (мы планируем перейти на TypeScript и последнюю версию Angular). Все наши технологии были довольно передовыми, когда мы их внедряли, и это чудо, что мое пристрастие к «хипстерским» технологиям не вызвало серьезных проблем.

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

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

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

Я всегда был стабилен по отношению к «the grand re-write», при котором разработка новых фич останавливается и части системы просто воссоздаются заново. Это становилось так называемой спиралью смерти для многих проектов. Метод, который хорошо работал у нас, — это правило бойскаута:
«Уходя, попытайтесь оставить этот мир немного лучше/чище, чем он был до вашего прихода» — Роберт Баден Пауэлл (Robert Baden Powell, Founder of the Boy Scouts and Girl Guides)

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

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

  • Запустить повторное обучение по написанию тестов и убедиться, что у разработчиков достаточно времени для их написания
  • Требовать по крайней мере одного теста для существенных функциональностей
  • Оптимизировать тестовый сервер, чтобы завершать тесты в течение 10 секунд вместо десяти минут (ouch!).

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

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

Знать, когда нанимать, — это древняя головоломка: закрыть эту должностную обязанность сейчас или позже, и какие роли закрыть в первую очередь? Это особенно сложно, если вы только что получили финансирование и теперь чувствуете себя обязанным вложить деньги в работу. К счастью, мы получили полезные советы по этому поводу от Майкла Сибеля (Michael Siebel) и Y Combinator:

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

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

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

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

Прим. переводчика: хороший пример для работы с личным планом развития сотрудника Adobe's Check-in Toolkit

  • Уважаемые читатели, пожалуйста, поделитесь своим опытом работы в качестве технического директора в комментариях.
  • С какими утверждениями автора вы согласны, а что считаете ошибкой в работе CTO?

  • +19
  • 15,1k
  • 4
Cloud4Y 66,09
#1 Корпоративный облачный провайдер
Поделиться публикацией
Комментарии 4
    0
    А кто должен собщить личный план развития — работник работодателю или наоборот?!
      +2

      Я думаю, тут инициатива с обоих сторон. Сначала обсуждение с сотрудником, как он видит свое будущее, развитие и так далее. Затем составление плана развития и его предметное обсуждение с сотрудником

      0
      плохо, конечно, такое за глаза говорить (перевод же), но
      Я был доволен нашим выбором: Amazon Web Services,

      Я высоко ценю весьма лаконичный синтаксис CoffeeScript

      мы планируем перейти на TypeScript и последнюю версию Angular

      собственно, более чем понятно, что автору не хватает компетенции для оценки технологий, он просто хавает весь хайп и всё соответствующее давно
        –2
        Опять перевод.

        А что-нибудь, более приближенное к российским реалиям?

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

        Самое читаемое