×

Как стать СТО: рассказывают технические директоры IТ-компаний

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

Дмитрий Абрамов, Delivery Director, Deputy Head of Kiev R&D Center в DataArt

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

Станет сложно, когда окажется, что Chief — это не просто «главный». Это босс, это лидер большой команды, это глава части компании, это ответственный за бесперебойную работу всех технических инструментов: от приложений пользователей до серверов в облаке и подписок на внешние SaaS и платёжные системы. Придётся работать с людьми, и когда от CTO-новичка начинает зависеть их найм, зарплаты и увольнение, не все справляются одинаково хорошо. Более того, придётся заниматься также бюджетами, контрактами, переговорами с бизнесом, защитой перед финансовым директором или владельцем компании своих идей и людей. Как ни крути, но C-level обязывает быть не просто инженером, но и уметь управлять компанией в команде других топов. Не для всех начинающих очевидно, что топ-босс должен уметь делать очень многое, иначе ему не выжить.

Чтобы иметь возможность стать CTO, нужно в первую очередь понять, как работает бизнес. Откуда он берёт деньги, кто его клиенты, что компания для них делает, какими инструментами для этого пользуется и какие средства вкладывает в поддержку своей инфраструктуры? Понимание базовой экономики бизнеса, умение составлять и исполнять бюджет is a must. Дальше следует озаботиться умением общаться с внутренним заказчиком и совместно работать над созданием новых сервисов. Ну и, естественно, нужно быть сильным технически, чтобы уметь планировать и создавать то, что необходимо компании для жизни.

Для получения опыта, необходимого для CTO, я советовал бы поработать в нескольких проектах, которые привели к выходу продукта на рынок. Причём делать это в роли тимлида, архитектора или PM. Желательно иметь частое общение с бизнесом, для которого делается продукт, чтобы научиться понимать его ожидания и ограничения.

Павел Никиточкин, CTO & Management 3.0 Practitioner в JetThoughts

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

Вы не научитесь быть СТО в школе. Ресурсов, которые помогут именно научиться быть CTO не так много, как хотелось бы, но все же я постараюсь указать пути вашего развития и получения навыков для того, чтобы стать опытнее в этом деле:

  • банальная, но все же самая эффективная стратегия — найти наставников, которые лучше вас, и учиться у них, опирайтесь на опыт успешных СЕО/СТО;
  • если в вашем окружении таковых нет, напишите холодные письма или свяжитесь с опытными СТО или техлидами посредством Twitter (или других соцсетей) и попросите у них совет/наставничество за чашечкой кофе;
  • познавательной будет книга Джоела Бисли «Современный СТО»;
  • из подкастов рекомендую обратить внимание на: CTO Think, Modern CTO;
  • посещайте встречи и собрания CTO в различных крупных городах. Это могут быть конференции и саммиты. Можно найти в Календаре;
  • черпайте знания в профильных сообществах и каналах. Как пример — популярный @rands.

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

Программистам, которые начинали с увлечения технологиями, придется перестроиться и перейти на «скучную» для них сторону. Technical Frameworks заменяются на Management Frameworks. Programming Language превратятся в Official/Corporate Language! Clean Code на Team Culture!

Как развиваться дальше? Наставлять других — помогать начинающим и тем самым давать оценку своим методам и улучшать их. Конкуренты не дадут засохнуть, надо всегда повышать производительность. Для этого надо иметь среду, позволяющую проводить постоянные эксперименты и делать выводы.

Зеник Матчишин, СТО в Altran Ukraine (Lohika)

Перед тим як почати навчання, найкраще визначити, якого типу СТО ви хочете стати. Якщо дуже все спростити, є 3 види СТО:

1. Технічний-технічний. Виключно програмує, з бізнесом не пересікається.
2. Технічний-бізнес. Трошки програмує, трошки пересікається з бізнесом.
3. Бізнес-бізнес. Не програмує, але використовує багаж знань, щоб допомагати бізнесу.

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

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

  • взяти і зробити один продукт з нуля та побути з ним хоча б 3-6 місяців після продакшена — шлях продуктового СТО;
  • паралельно брати участь в максимальній кількості проектів у ролі людини, яка «вирішує технічні проблеми» — шлях сервісного СТО.

Паралельно треба обов’язково бути в ситуаціях, коли ви працюєте з іншими СТО для вироблення поведінкових моделей та пасивного менторства. Проекти бувають дуже різні, тому стартовою точкою є відповідь на питання «Що я маю робити, щоб все працювало, і я був не потрібний». Ця відповідь буде містити набір технологій, підходів та практик, включаючи й підходи до людей. Як тільки ви це зробили раз і несли за це відповідальність, ви вже майже там. Пропорційно до розміру компанії росте потреба в people/soft skills. Чим більше людей, тим більше ви маєте бути доступні. Типово це має бути виправлено на рівні архітекта, але бажано не зупинятись.

Головні труднощі:

  1. Треба розуміти, що ви будете в команді, і найчастіше це буде компроміс: «Так, AWS — це добре, але тут хочуть Azure, тому якщо ми хочемо рухатись далі, треба змінити підхід».
  2. Комунікувати технічні рішення треба буде часто нетехнічним людям, тому без високих навиків комунікації будуть постійні конфлікти.
  3. Треба також нести відповідальність за чужі рішення. В галузі є багато людей, які не затримуються на роботі і бавляться в resume driven розробку, і з їхніми аргументами та рішеннями треба теж вміти працювати. СТО — це в першу чергу відповідальність, і різні відмовки не є хорошим розвитком подій.
  4. Кількість дрібних задач буде дуже великою, тому якщо є труднощі з багатозадачністю, краще навіть не починати.
  5. Деколи технології не вистрілюють, і треба вміти переходити на інші речі. Програмне забезпечення — це таки не будинок, і деякі речі міняти можна, але треба вміти і знати як.
  6. Треба дружити з грошима, так як на рівні СТО вже треба працювати з бюджетами та фінансовим плануванням.
  7. По суті, тиск для розвитку вже не зупиниться, ви можете вибрати тільки напрямок (мені це більше плюс, проте комусь і мінус).

В залежності від вашого позиціонування та типу є 3 можливих шляхи розвитку:

  1. Покривати собою повний поточний технічний стек.
  2. Постійно стрибати зі стеку на стек.
  3. Вийти на мета-рівень та працювати в режимі make things happen.

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

Тарас Мурашко, CTO в EVO

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

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

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

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

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

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

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

Дмитро Волошин, СТО в Preply

У нас немає профільної освіти на роль СТО, тому вчитися краще на практиці. Варто розуміти, що це частково управлінська посада, оскільки СТО взаємодіє з менеджментом компанії, але не плутати її з VP-Engineering — роль якоготполягає більше в роботі з людьми. Для себе я визначаю роль СТО в тому, щоб перетворювати людський потенціал команди розробників в якісний технічний продукт. Тобто відповідати за технічний стек, мати візію його розвитку і підтримувати процеси.

Відповідно найкраще до цієї ролі готують ролі нижчого рівня — Head of Engineering, Technical Lead, Solution Architect. Наприклад, у час моєї відсутності роль СТО в компанії виконує хтось з technical leads. На практиці варто брати великі проекти з впровадження нових процесів, технологій чи просто об’ємного функціоналу і доводити їх від початку до продакшену. В ідеалі варто також розвивати базові компетенції роботи з людьми, софт-скіли.

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

З теоретичних речей для подальшого розвитку варто читати технічну літературу, розуміти, куди рухається індустрія. СТО повинен мати досить великий авторитет в команді, адже команди розробки дуже раціональні. Хороший варіант розвитку — мати ментора СТО більшої компанії, відвідувати тематичні конференції. Також зауважу, що в Києві раз в півроку проводяться СТО мітапи, і для цього є закрита группа.

Дмитрий Лапшин, СТО в Sigma Software

Если честно, слабо себе представляю, как можно специально «учиться на CTO». И даже не уверен, что существуют какие-то специализированные курсы по этой теме. Скорее, стоит говорить о том, на чём фокусироваться в процессе обучения:

— Расти не только «вглубь», но и «вширь». Кажется, широкий технический кругозор и понимание того, как работает высокотехнологичный бизнес — это обязательная программа-минимум.
— Системный подход и целостное видение решения проблем.
— Эффективная коммуникация. Даже самый опытный программист в принципе может позволить себе быть букой-затворником. Но CTO общается и с проектными командами, и с руководством компании, и с клиентами. Важно подбирать нужные слова и проявлять находчивость, иногда даже немного быть дипломатом.

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

Затем, думаю, что крайне важно избежать соблазна поддаться хайпу и начать думать в ключе: «Ага, вот теперь-то я точно сделаю всё стильно-модно-молодёжно!». Потому что в реальности нередко технологии, активно нахваливаемые в блогах и на конференциях, на самом деле имеют ограниченную область применения и/или существенные подводные камни.

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

И, наконец, если вы выросли до CTO из «сурового технаря», вам поначалу может быть сложно смотреть на проблему с точки зрения бизнеса, а иногда и маркетинга/продаж. И здесь совершенно точно приходится делать над собой усилие и, как говорили во времена былые, «учиться, учиться и ещё раз учиться».

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

Не менее полезно следить за современными тенденциями в области разработки ПО и IT-технологий в целом. Изучать и пробовать новое, даже если не видишь этому непосредственное применение в текущих задачах и ближайшем будущем. Знания в мешке за плечами не носить, а пригодиться они могут весьма неожиданно. Иначе — закостенеешь и рано или поздно отстанешь от жизни, применяя старые и, возможно, уже неэффективные подходы для решения насущных проблем.

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

Как показывает опыт, нужно быть готовым даже к радикальной смене парадигм. Когда я сам был разработчиком, «рулили» ООП, скрупулезный контроль качества и подходы к разработке с тщательным планированием наперёд. Спустя 10-15 лет «на коне» функционально-реактивный подход, Agile, Lean и Minimum Viable Products с качеством «бета-версии». А ещё через 10 лет, возможно, мы вообще будем писать очень мало классического кода, а вместо этого обучать нейросети. Так или иначе, почивать на лаврах совершенно точно не придётся, постоянное обучение и вовлеченность — неотъемлемая часть профессии.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




52 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Шестеро респондентів — якась не надто репрезентативна вибірка.

Я можу дати відповідь на це риторичне питання таким чином на базі власного досвіду:

1. Треба стати найкращим
2. Треба допомагати кожному співробітнику стати краще

Все інше — це деталі, та залежить від обставин та конкретного складу команди.

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

а ви себе вважаєтє кращим за інших в вашій команді?

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

Specialization :
* Go; PHP OOP ( Zend Certified Engineer )
* TYPO3 (Certified TYPO3 Integrator), Drupal

Віктор, хулі не ясно ?

Я можу порадити, чи поставити додаткові завдання команді прибиральників.

Універсальний солдат :)

1. Треба стати найкращим

Найкращим бухгалтером?

кожному співробітнику

Допомогти прибиральникам краще прибирати?

Все інше — це деталі

Ви точно СТО?)

Сергію,
1. Так. Навіть бухгалтеру деколи потрібна допомога. В мене є такий досвід.
2. Так. Якщо це стосується офісу, де працює моя команда. Я можу порадити, чи поставити додаткові завдання команді прибиральників.
3. Так. Я точно CTO :)

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

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

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

напишите холодные письма или свяжитесь с опытными СТО или техлидами посредством Twitter (или других соцсетей) и попросите у них совет/наставничество за чашечкой кофе;

Серьезно? Этот совет подходит разве что для написания журналистом статьи на ДОУ :)

Стать сильным разработчиком, побыть архитектором

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

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

Последний абзац у Зеника Матчишина больше всего понравился. Если кратко, то надо пилить свой пет-проект, узнавать все понемногу и немного обо всем.

Мои выводы по статье:
Три стратегических решения для желающих увеличить шансы стать CTO:

— поработать PM’ом
— жить в Киеве
— стать сооснователем компании.

напишите холодные письма или свяжитесь с опытными СТО или техлидами посредством Twitter (или других соцсетей) и попросите у них совет/наставничество за чашечкой кофе;
Серьезно? Этот совет подходит разве что для написания журналистом статьи на ДОУ :)

Вы не представляете сколько людей так чему-то учились, просто приглашали успешных людей на чашку кофе...

— Сколько людей?
— Чему научились?
— Кем были те успешные люди?

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

Хочешь стать СЕО? — Пригласи СЕО на чашку кофе.
Хочешь стать СТО? — Пригласи СТО на чашку кофе.
Хочешь стать программистом? — Пригласи программиста на чашку кофе.

Хочешь стать программистом? — Пригласи программиста на чашку кофе.

в этом случае нужен не кофе)

Я не совсем понимаю, когда в ауторс компаниях люди называются CTO — ведь это позиция соеденяющая бизнес и технологии, бизнес в данном случае это продажи и продакшн — разработка на заказ, а не для себя, что ограничивает объем и ответственность в принятии ключевых решений, которые и принимает CTO, но в большей степени продажи, ведь аутсорс и аутстаф по сути построен вокруг продаж.Для аутсорса таким образом в принципе эта позиция не природна, это скрорей Vice President Of Engineering или Head of technology, поправьте если ошибаюсь.

Head of technology — да, по смыслу это название ближе к сути позиции, но вот как-то так сложилось, что во многих компаниях официально позиция называется именно CTO.

С другой стороны, CTO обязан учитывать интересы и бизнеса тоже.

Вот еще попалась интересная статья на тему; правда, не про outsourcing:

medium.com/...​-engineering-f1c7563643a3

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

Я не совсем понимаю, когда в аутcорс компаниях люди называются CTO

еще как минимум должна быть выглаженная рубашка (на фото все в рубашках)

просто цікаво, скільки жінок СТО в українських офісах?

Слово Officer може стати проблемою, бо зараз прийнято використовувати фемінітиви. CTM — Chief Technology Mistress може спрацювати.

просто цікаво, наскільки цей коментарій релевантний до мого питання.

яке питання — така і відповідь)

ваша думка дуже важлива для нас :)

Це спроба розпалити срач про харасмент в ІТ? Краще дайте відповідь, чому особисто ви не стали СТО (і скоріше за все не прагнете).

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

а звідки ви знаєте про мої прагнення? в мене ще все попереду

Просто не задавайте провокативних питань. Чудово якщо ви не бачите проблем для себе, якщо всі жінки думатимуть так само — то і дизбалансу чоловіків/жінок серед СТО теж значно поменше.

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

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

розмова вже йде в іншу сторону — освіти

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

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

З іншого боку, якщо жінок СТО насправді не так багато, чи взагалі немає, як вони мали б опинитися тут?

1. Стериотипне мислення ще ніхто не відмінив
2. А хто тоді СТО — «отброси общєства»?
3. Тому я і написала своє питання, може хтось бачив статистику і любєзно відповів би мені, бо гугл не дає відповіть на моє питання. Але вже йде n-ний меседж в треді, а так ніхто і не допоміг, тільки про провокацію і сорочки.

1. Стериотипне мислення ще ніхто не відмінив

Воно вже не в тренді :-) чи не так?

А хто тоді СТО — «отброси общєства»?

Не місце красить людину, а людина прикрашає місце. Якщо Вам не подобається робити те, чим займаються СТО, Ви все одно зможете стати СТО, якщо дуже забажаєте, але чи принесе це Вам щастя? Ні, це принесе лише розчарування такою «успішністю.» Я гадаю, що варто займатись тим, що подобається не зважаючи на колір шкіри, гендерну приналежність чи щось інше не важливе.

3. Тому я і написала своє питання, може хтось бачив статистику і любєзно відповів би мені, бо гугл не дає відповіть на моє питання. Але вже йде n-ний меседж в треді, а так ніхто і не допоміг, тільки про провокацію і сорочки.

dou.ua/...​a/articles/portrait-2018

Частка жінок в ІТ продовжує зростати — на 3 п.п. за рік та на 7 п.п. з 2016 року. Жінки частіше працюють тестувальницями (24%), розробницями (23%), нетехнічними спеціалістами — HR, PR, Sales (20%).

dou.ua/...​nta/articles/women-in-it
Але про частку СТО жінок там немає, Ви праві. Може тому, що нікому це не важливо? Яка для мене різниці мій СТО чоловік або жінка, якщо вони професіонали?

А почему вы не поинтересовались, например, сколько афро-украинцев среди СТО в украинских компаниях? Или сколько геев? Или сколько людей с ограниченными возможностями? Список тем достаточно большой.

Good news, everyone! www.linkedin.com/...​words=CTO ukraine&page=11
Есть женщина на 11-й странице. И не все в рубашках.

По Україні такої статистики не зустрічав. Глобально — 14% www.women.com/...​f-fortune-500-female-ctos

А я думал, что только через постель. А оно вон как получается.

Статью не читал, но самый очевидный для меня способ — принять офер на позицию CTO. Еще, как вариант, запустить свой pet-проект с сказать, что ты — CTO.

* Офер може бути зовнішній, чи внутрішній.

Если там есть бизнес-состовляющая — то формально ты его CTO :)

Так это практически универсальный шаблон

но самый очевидный для меня способ — принять офер на позицию <название_должности>. Еще, как вариант, запустить свой pet-проект с сказать, что ты — <название_должности>

Ох уж эти программисты, любят все обобщать 🙂.

Угу: founder, CEO і CTO в одном флаконе.
P.S.
А, чуть не забув головне — краватку-метелика причіпити. :)

Підписатись на коментарі