Шановний SaaStr: Що робить поганим технічним директором?

Шановний SaaStr: Що робить поганим технічним директором?

Хоча немає юридичного визначення технічного директора 🙂 або чіткої межі між технічним директором і VPE, я б запропонував технічному директору-початківцю справді лише кілька речей, які дуже складні:

• Зберіть невелику команду (3–9) дуже хороших інженерів
• Це супер спритні
• Це може доставити багато дуже функціонального, дуже розумного коду, який підтримує раннє, дуже швидке зростання (з дуже маленької бази); і
• Це може реагувати та позитивно реагувати на цілу масу проблем, від простоїв до безпеки, проблем API та багато іншого. Це часто ніколи не передбачалося і не є частиною специфікації роботи.

Отже... «поганий» технічний директор — це той, хто не може найняти сильну команду «коробок для піци». Поганий технічний директор добре розробляє сам себе, але не може залучити до нього/неї трьох інших чудових інженерів.

«Поганий» технічний директор недостатньо спритний, і не може випускати швидкі випуски та функції, щоб врятувати великі справи, виправити жахливі помилки тощо. «Поганий» технічний директор іноді хоче зробити це, але просто недостатньо хороший. Або «поганий» технічний директор надто невмотивований / будь-що, щоб робити те, що потрібно, щоб не відставати.

«Поганий» технічний директор не піклується про дуже-дуже швидке зростання. Багато чого змінюється, коли у вас з’являються перші клієнти. Це захоплююче, але також виснажливо і дуже напружено. Чудовий технічний директор сприймає ці зміни, бере активну участь у них і керує ними. Поганий технічний директор чинить опір змінам, пов’язаним із розширенням першої клієнтської бази.

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

Цей набір навичок має важливе значення, але потім… але багато з них не масштабується. Навички, необхідні для створення розумного хака з невеликою командою та його швидкого повторення, щоб реагувати на потреби клієнтів і ринку… це не ті самі навички, які потрібні для масштабування від 10 до 100 інженерів. Рефакторинг кодової бази. Поставляти програмне забезпечення дійсно корпоративного рівня. Зайти в кімнату, повну ІТ-директорів, і вселити впевненість.

Іноді технічні директори можуть стати справжніми віце-президентами з інженерії. Але зазвичай вони цього не хочуть. Вони хочуть, щоб компанія залучила справжнього менеджера, щоб збільшити команду за межі 1–2 коробок для піци. У той час як технічний директор може зосередитися на створенні супергнучких речей нового покоління.

У SaaS плануйте найняти справжнього віце-президента з інженерії приблизно на 5-8 мільйонів доларів США в ARR. Тоді вона тобі знадобиться. Вони можуть взяти на себе рутинні справи. Як тільки ви переходите у фазу, де це більше... рутина.

(примітка: оновлення класичної відповіді SaaStr)

...

Ось приклад чудового технічного директора стартапу:

Джерело: https://www.saastr.com/makes-bad-cto/