Те, про що я дізнався як технічний директор

Іспанська версія тут

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

ЗАМОВЛЕННЯ: Це мій досвід і те, що, на мою думку, я дізнався, а не таблиці закону. Інші люди будуть думати інакше, і я не той, хто скаже, що вони помиляються, тому я очікую дебатів чи полеміки з деяких питань. О, і я старий, тож не чекайте анімованих GIF-файлів у цій статті. Я не публікую в середовищі 🙂

Вся справа в цифрах, манекен!

Цифри, цифри, цифри.

Числа змушують стартап кружляти. Спочатку вся справа в грошах. Хороші ідеї? Гарні практики? Нічого з цього не має значення, якщо у вас немає грошей. А після грошей будуть когорти, воронки, MRR або що завгодно. Цифри визначають успіх чи невдачу компанії. Не продукт, не технологія, не призи, не переговори. Все це допоміжні засоби для досягнення мети; вони можуть бути незамінними, але якщо ніхто не використовує ваш продукт, ви не досягнете успіху.

Як підказка … кол. Метрики, аналіз можливостей, дослідження ринку. Хороші ідеї перестають бути хорошими, якщо вони не підкріплені показником успіху. Серця можуть підняти фінансовий раунд, а не чотири. Існує лише два типи провидців: ті, кому пощастило, і ті, хто знає, що вони роблять. Забудьте пісні сирени і зрозумійте, чого хочуть люди, чого коштувало б дати їм це і знайти середній шлях.

Як інженер в технологічній компанії, я завжди вважаю, що ми пупок світу. Але коли ти розумієшся на бізнесі, то розумієш, що, зрештою, це все про чорні та червоні цифри на білому тлі.

Вам не потрібно вирішувати всі проблеми

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

Слон у кімнаті. Це своєрідне мистецтво, щоб сказати “ні”. Це ускладнює справи, породжує недовіру та провокує дискусії. Набагато зручніше відпустити себе, перетворити команду на виконавця і уникати конфліктів. Але в довгостроковій перспективі знання того, як вибирати свої битви, дозволяє заощадити сили, щоб протистояти тим, які дійсно важливі.

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

У мене пішло три роки, щоб навчитися говорити «ні», і це те, про що я шкодую. Я спалив цілі команди, будуючи ідеї, які нікуди не дійшли. Зараз я ціную варіанти набагато більше, і коли мені постають проблема, ідея чи функціональність, моє перше запитання: “Чому?” Іноді чат може заощадити тижні роботи; ніколи не сумнівайтесь у силі питання в часі.

Ви не працюєте в компанії. ви є частиною спільноти

І ні, я не маю на увазі Twitter. Для мене найважливіша робота технічного менеджера – не вибирати технології (для цього вам потрібна ваша команда). Це робить людей щасливими, спілкуючись один з одним. І я кажу не лише про стосунки між інженерами, які є досить складними. Я говорю про зв’язки кожної людини в офісі з рештою однолітків. Інжиніринг та маркетинг, продукція та бізнес, підтримка, обслуговування клієнтів. За всіма цими іменами стоять люди. З їх мотивацією, проблемами, цілями та мріями. Неважливо, якщо вони не розуміють, що робить інженерна справа, неважливо, чи інженерна справа не розуміє маркетингових прагнень. За кожним відділом є люди, і розуміння людей – це те, що доставить вас у безпечну гавань.

Як маленька порада … змусьте їх знати один одного. Візьміть їх на пиво, організовуйте вечері, не чекайте, поки ваша компанія влаштує гру в пейнтбол, щоб створити краватки. Розуміння – це те, над чим ви працюєте щодня, довіра набувається з часом. Не думайте, що ви можете вирішити проблеми за допомогою декількох пістолетів для фарбування. Якщо що, ви отримаєте синці та пару анекдотів. Але якщо у вас є пиво в четвер, ви можете виявити, що кішка вашої партнерки померла, або що менеджер з маркетингу стурбований оцінкою її дочки. Перефразовуючи фразу Немо: “Партнери – це люди, а не їжа”.

І як я це дізнався? Ну, в основному, коли я виявив, що були проблеми, які виникли через відсутність розуміння. “Я не знаю, чому вони просять нас це зробити”, або “Що ми робимо?”. Якщо ви змусите людей знати один одного, ці проблеми пом’якшуються. Якщо ви покладете обличчя людям, які ховаються за електронними листами, це вас не буде так турбувати, що вони просять вас про допомогу.

Слідкуйте за взаємодією команди

Моя команда складається з блискучих, жахливих і часом проблематичних людей. Здебільшого, як решта людства. А щоб команда залишалася здоровою, ви повинні стежити за її стосунками. Тертя, які можна вважати анекдотичними, не є, робочі дискусії швидко стають особистими суперечками. І ці сутички, якщо їх не контролювати, зазвичай закінчуються погано … або людина йде, або ситуація закріплюється і гниє команду.

Як маленька порада … поговоріть з людьми у вашій групі. Поклади вухо. Виведіть їх їсти. Слухай. Створюють відчуття спокою; ви не суддя, крім випадків, коли ситуація серйозна. Тим часом ти будеш радником. Якщо ви бачите аргумент, ви можете втрутитися, але було б набагато краще, якби хтось інший вступився. Авторитет іноді є непродуктивним. Шукайте профіль, який вміє вести діалог і просити про допомогу. Цей профіль може розповісти вам про настрій команди. І будьте готові до сюрпризів, адже скільки б ви не дивилися, завжди будуть підземні потоки, які вибухнуть тоді, коли ви цього найменше очікуєте.

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

Різноманітна команда – це щаслива команда

Ви бачили це у багатьох команд. Команди, сформовані лише з чоловіків, або старших, або юніорів, мудреців, ніндзя, повних штабелерів, що завгодно. Погана, погана, погана ідея. Найкраща команда – та, яка має всілякі профілі. Я не збираюся обговорювати, чому необхідно мати статеве розмаїття (у найширшому ступені), тому що протилежне – це загальна аберація в комп’ютерній техніці. Але я наводжу вам кілька прикладів, які я бачив за цей час і які, сподіваюся, підтримають мою тезу:

Двоє мудреців витратять більше часу на те, щоб бути правильними, ніж на те, щоб продукт процвітав.

Якщо вони всі молодші, спочатку все буде просто, а наприкінці страшно.

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

Якщо вони всі чоловіки, прямолінійні, білі, ви в кінцевому підсумку будете працювати в клітці горил в зоопарку (є більше причин шукати різноманітність, але дозвольте мені скористатися цим прикладом).

Повний стек – це ще один спосіб закликати лікарів загальної практики, і відсутність передових знань у технології означатиме марнотратство.

Ніндзя – це ще один спосіб закликати фахівців, і відсутність загальних знань призведе до того, що все робиться за однаковою технологією, навіть якщо це не ідеально для товару.

Словом, якщо немає різноманітності, є проблеми. Якщо є різноманітність, у вас будуть інші проблеми, але, на мій погляд, вони будуть більш керовані.

Як підказка … різноманітність називає різноманітність. Ставте на це з самого початку, перевіряйте, які профілі можуть працювати, робіть нотатки. Це буде непросто, але з досвідом ви дізнаєтеся, що працює, а що ні.

Я дізнався про це через невдачу. У нас була велика мінливість у команді, і багато разів нам не вдавалося досягти рівноваги. Врешті-решт ми обрали міцну базу для людей похилого віку, ще одного серед юніорів, різного віку, статі, сексуальної орієнтації, знань та інтересів. Я думаю, що ми нарешті знайшли рівновагу, але цілком можливо, що те, що працює для нас, працює не для всіх. Зрештою кожна команда – це світ … з’ясуйте, який із вас.

Змусьте колектив вирости

І я не про цифри, а про особистий ріст. Коли ви створюєте команду з нуля, вам доведеться шукати людей, які “роблять речі”. Але з плином часу ви побачите, що ці люди мають мотивацію, і якщо це піде добре, вони захочуть долучитися до процесу. Це чудово. Насправді це принципово. Як технічний директор, вашим першим завданням має бути навчання вашого наступника. І не тому, що ти хочеш піти, а тому, що тобі це буде потрібно.

Будьте обережні, люди повинні хотіти брати на себе відповідальність, і не всі можуть. Але ви виявите, що багато людей готові допомогти, чим можуть. Цілком можливо, що цей розробник хоче стати менеджером, або що цей QA готовий підготувати систему якості на бізнес-рівні. Завжди заохочуйте ці потреби, і якщо можете, створюйте їх. Але завжди, завжди, у межах того, що людина хоче зробити. Термін “план кар’єри” в цій галузі дещо неправильний, але це було б щось подібне.

Як підказка, проведіть зустрічі з людьми, щоб з’ясувати, що їх спонукає. У наступному пункті ми побачимо тренування, але є деякі нетренінгові сфери, які ви, можливо, захочете вивчити. Нові технології, організаційні методи, помодорос, управління змінами … напевно, люди здивують вас своїми ідеями.

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

Тренуйте своїх людей. навіть якщо ви не бачите негайного повернення на тренуванні.

Я думаю, ми всі сходяться в тому, що навчання є фундаментальним. Не так очевидно, що люди можуть мати інтереси, які не пов’язані безпосередньо з вашою компанією. Чи слід тоді їх тренувати?

Я відповідаю “так, але”.

Навчання – річ курйозна. Це не тільки дає вам знання, але і відкриває ваш розум. Знаєте, “для молотка все – цвяхи”. Якщо вас попросять вивчити селен, і що програмне забезпечення не використовується у компанії, ви можете ні. Але хіба селен не є стандартом? Чи не було б простіше навчитися зі стандарту, щоб зрозуміти, як тестувати? Ці інвестиції можуть не мати прямого використання у вашому продукті, але я можу запевнити вас, що в довгостроковій перспективі, якщо у вас є більш широке бачення технологій, ви знайдете кращі рішення.

Зараз, а отже і “але”. Людині доведеться пояснити, як ці знання допоможуть компанії. Це має дві переваги: ця людина буде в курсі інвестицій компанії. Це також дозволить йому думати про найкращі способи оцінити свої знання.

Як порада … ви працюєте над навчанням команди з такою ж суворістю, як і над дорожньою картою проекту. Зрозумійте частини, які хочуть вдосконалити, запишіть їх ідеї та дайте їм інструменти, необхідні для їх досягнення.

Знову ж таки, я навчився цього важким шляхом із людьми, які покинули проект, коли відчули застряглість на рівні підготовки. Дійсно, краще вкладати гроші в людей, ніж у мисливців за головами (при всій повазі до професії, що досить складно).

Навчіться делегувати

Тісно пов’язаний з двома попередніми пунктами. Якщо ви хочете, щоб проект протікав, вам доведеться делегувати його. Ви не можете бути вузьким місцем чи фундаментальною частиною команди. В ідеалі ви повинні мати можливість виїхати на місяць, не помічаючи вашої відсутності. Слідкуйте, можливо, вам доведеться мати справу з багатьма речами, коли ви почнете, принаймні, поки не зіберете команду. Але ваша мета повинна бути зменшити потребу мати вас поруч.

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

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

Якщо ви хочете, щоб час вдосконалювався, вам доведеться його шукати

Давайте дивитися правді в очі; технічний борг зацікавить вашого генерального директора лише тоді, коли він вибухне йому в обличчя. Якщо ви хочете вдосконалитися, вам потрібно буде битися. Зазвичай ваша команда просить про це. Шукати гарний баланс між функціональними можливостями та механізмами; бувають випадки, коли ви не можете вдосконалитись, і пробіли в часі між функціоналами, які ви можете використовувати. Скористайтеся ними, оскільки ваша команда захоче виправити ситуацію, і ви повинні дозволити їм це зробити.

Як підказка … навчіть інші відділи про важливість стабільної бази коду. Але говоріть з точки зору швидкості; немає сенсу стверджувати, що це потрібно робити «просто тому». Кожен може зрозуміти, що покалічений продукт йде повільніше, ніж здоровий. Але пам’ятайте: це не завжди буде час зробити це. Тож вибирайте часові рамки. І одного разу вибравшись, боріться за його отримання.

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

Якщо ви їх любите, відпустіть їх …

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

Щоб пом’якшити втрати людей, вам слід переконатись у відсутності елеваторів, щоб усі ділились знаннями. Команда повинна бути в змозі впоратися з втратою члена, і ви повинні мати можливість управляти будь-якими втратами, включаючи всю команду.

Як підказка … документ. Я знаю, що ніколи не потрібно це робити, і це нудно, але це єдиний спосіб поділитися знаннями. У нашому випадку ми використовуємо поняття, і хоча ми документуємо лише кілька місяців, ми вже мали дуже хороші результати з новими інкорпораціями.

Ще одна порада: зрозумійте, чому люди їдуть. Проведіть аналіз совісті та змініть свою поведінку та поведінку команди, щоб запобігти майбутнім виїздам.

Але, як я вже кажу, не божеволійте. Зрештою це завжди трапляється.

І як я це дізнався? За ці три роки я майже повністю програв три команди. Причини різні, частково через мої помилки, частково через ринок, частково через нормальну еволюцію проекту. Одного разу ми втратили п’ятьох інженерів за три дні, що означало вісімдесят відсотків команди. Ми вижили завдяки зусиллям усіх, спільним знанням та хорошому управлінню. Тож я вам кажу: це можна зробити.

… але намагайся, щоб ніхто не хотів піти

Ах, одвічне питання. Як змусити людей залишитися? Ну, відповідь … з усім вищесказаним. Усі вищезазначені моменти я засвоїв, намагаючись зробити людей щасливими на роботі. Звичайно, я залишив речі: гідні зарплати, віддалені дні, спільна відповідальність за проект, гнучкі методології … але ви все це вже знаєте, це зовнішні винагороди. У попередніх пунктах я намагався пояснити все, що ми придумали, щоб створити здорову і довготривалу команду з власними винагородами.

Як підказка … все вищесказане. Слухайте їх, змушуйте їх рости, розуміти їх проблеми, покладати на них обов’язки, нехай вдосконалюються і відпускають.

Як я це дізнався: втрачаючи людей та пробуючи різні підходи. Ми знаходимося в ідеальному моменті в нашій компанії? Ні, тому що ідеального моменту не існує, але ми перебуваємо в найкращому моменті. Команда працює як ракета, люди задоволені, а зацікавлені сторони розслаблені. Чи можемо ми вдосконалитись? Без сумніву, ми працюємо над цим.

Змініть, спробуйте, повторіть. все ще потрібно зробити.

Неважливо, бували ви тут тиждень, місяць, рік чи п’ять. Ваша робота полягає в забезпеченні стійкого та постійного вдосконалення вашої команди, її взаємодії з іншими командами та гарної розробки продукту. Це нескінченна історія. І якщо ви зробите це правильно, коли ваші відносини з компанією закінчаться, ніхто цього не помітить.

Що, на мій погляд, є найкращим закінченням для технічного директора в компанії.

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/what-ive-learned-cto-ludo-bermejo-fernandez/.

Ludo Bermejo Fernandez люб’язно дозволив нам перекласти і опублікувати цю статтю.