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

Если серьёзно, карьера мобильного разработчика, который хочет вырасти в большого руководителя, может складываться по‑разному. Например, мой путь начался в 2013 году, и за это время я успел поработать и в маленьких стартапах, и в больших корпорациях. Сейчас я Director of Engineering в Яндекс Go. Последние шесть лет я управляю разными командами разного размера: от 5 до 200+ человек.

В этой статье я хочу рассказать, какие есть пути развития в мобильной разработке, что делать, если ты уже тимлид, кто такие крутые Individual Contributors (топовые разработчики) и как стать одним из них. Обо всём этом читайте под катом: попробуем разобраться, как расти и куда это может завести.

Карьерная лестница

Про карьерные возможности 

Многие представляют себе стандартную (и, забегая вперёд, стереотипную) схему карьерного роста примерно так: Junior — Middle — Senior — Team Lead — Head Of Function. Я сам жил в такой парадигме достаточно много лет: был уверен, что единственный путь развития разработчика — это тимлидство. В целом туда и пришёл.

Но есть альтернативная точка зрения: после того, как вы стали iOS‑инженером (любым инженером) высокого уровня — Senior и выше — вам надо обязательно записать какой‑нибудь подкаст, иначе развиваться дальше не получится. Это, конечно, шутка, но до сих пор актуальная: подкастов становится всё больше и больше.

Итак, как на самом деле выглядит карьерная лестница разработчика и какая из ступеней — тимлидство?

Начнём с того, что Junior — не самая первая ступенька карьеры. Первая ступенька — это интерн или стажёр. То есть кто‑то, кто вообще ничего ещё не умеет. А Junior — это человек, у которого уже есть хоть какой‑то продакшн‑опыт: писал собственное приложение, работал в стартапе, развивал свой проект в сторе. Если продолжить эту схему и разложить её на уровни, можно ввести условные грейды: интерн — разработчик первого уровня, а, например, Senior — четвёртого уровня.

А вот тимлид, на мой взгляд, — отдельная профессия. В индустрии примерно так и заведено: есть трек Individual Сontributor, то есть разработчика, и трек Engineering Manager. В этой парадигме переход в тимлиды возможен примерно в тот момент, когда вы уже готовы из Middle вырасти в Senior. Уходите в руководители и начинайте заниматься людьми, процессами, командой.

Но куда расти дальше, если ты уже Senior? Можно стать Staff или Principal Engineer или двигаться в сторону параллельных веток в руководстве — Engineering Manager или Senior Engineering Manager. Можно стать одним из супертоповых Fellow Engineer, которые находятся где‑то на уровне CTO, на самой верхушке компании.

Какой бы из путей вы ни выбрали, знайте: в карьере разработчика намного больше веток и возможностей, чем Junior — Middle — Senior. Дальше — примерно бесконечный рост. И между ветками‑профессиями (если считать тимлидство отдельной профессией) можно перемещаться. Можно даже стать Product или Project Manager.

Про доход и влияние

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

В вымышленной системе грейдов с рисунка выше тимлид, скорее всего, получает примерно столько же, сколько и Senior‑разработчик, потому что у них одинаковый грейд. Суперкрутой Fellow Engineer внутри компании вполне может получать столько же, сколько CTO.

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

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

Кто такой Top IC

Топовыми разработчиками, или Top Individual Contributors, можно считать всех, кто выше Senior. Их отличает то, как и сколько они пишут код, как быстро справляются с задачами, насколько сложные проблемы могут решать и насколько крупные проекты способны закодить в одиночку. Чем выше грейд, тем больше такие разработчики могут сделать самостоятельно — или даже брать на себя проблемы, с которыми больше никто в команде не справится.

Определить его очень просто. К кому в команде вы обратитесь, если не сможете решить какую‑либо задачу? Скорее всего, человек, про которого вы сейчас подумали, и есть Top IC. Можете с ним побольше пообщаться и попробовать дотянуться до его уровня в будущем.

Но дело не только в профессиональных умениях, но и во вспомогательных. Есть два очень важных навыка, которые помогают расти грамотному техническому специалисту.

• Во‑первых, проактивность — не путать с ретроактивностью. Для простоты понимания приведу аналогию. Представьте: море, волны, а вы находитесь на плоту. Куда несёт волна, туда и плывёте — знакомьтесь, ретроактивность. А проактивность — это когда вы берёте вёсла и выплываете, куда хотите.

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

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

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

Как лиду стать CTO

Итак, перейду к тому, ради чего вы, возможно, открыли эту статью: как стать лидом и вырасти из него в CTO. Я расскажу о своём опыте и подробно остановлюсь на каждом из этапов.

Чем вообще отличаются лиды разных грейдов? Мне кажется, есть три основных критерия:

1. Размер команды. Чем выше уровень руководителя, тем больше его команда. Это не прямая взаимосвязь, но чаще всего получается именно так.

2. Зона ответственности. Чем выше грейд, тем шире зона ответственности и одновременно больше неопределённость. Например, если вы тимлид в небольшой команде и у вас в подчинении пять сотрудников, скорее всего, вы решаете задачки формата «как сделать редизайн главного экрана, что для этого нужно». Если вы руководитель разработки, то ваша зона ответственности расширяется до решений масштаба «нужно ли внедрять SwiftUI или нет». А если вы целый CTO, вы, вероятно, ломаете голову уже над тем, как улучшить наём в компанию. Чувствуете разброс степени неопределённости?

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

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

Это календарь неформального лида. Здесь есть командные встречи, синки по статусам проектов, планирование — в целом понятно, что большую часть своего времени человек пишет код. И это нормально: он пока ещё разработчик

Предположим, что у вас получилось завоевать авторитет у команды и тимлида и появилась возможность вырасти. Поздравляю, вы перешли на первый уровень!

Руководитель первого уровня — меньше 5 человек 

Первый уровень — небольшая команда до пяти человек. Как только вы обзаведётесь собственной командой, вы станете ответственным за людей, которые в неё входят. И первое, о чём стоит начать думать, — наём, развитие, мотивация, увольнение.

Наём 

Почему бы не позвать всех своих друзей и не работать весело вместе?

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

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

Развитие

Вам нужно сделать так, чтобы разработчики росли одновременно и в хард‑скилах и в софт‑скилах.

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

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

Мотивация

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

Пример: вы собрали команду, где все хотят раз в неделю ходить играть в бильярд и у вас даже образовался клуб. Но вдруг одному из участников команды приходит выгодный оффер. С одной стороны ему, конечно, интересно начать получать на 20% больше. А с другой — у него такая классная команда, руководитель в нём заинтересован и помогает расти. И бильярд раз в неделю ещё. Будет ли так же в другой команде, неизвестно. Почему бы просто не попросить повышения у текущего руководителя?

Это пример хороших межличностных отношений между руководителем и подчинённым. Ключ к правильной нематериальной мотивации — понимать цели и ценности каждого члена своей команды. Я считаю, что основная цель руководителя — помочь своему сотруднику достичь следующего уровня, если он, конечно, этого хочет. А если не хочет, то просто как‑то помочь.

Увольнение

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

Обычно увольнение происходит по двум причинам:

1. Сотрудник не справляется со своими задачами. Очевидно не справляется: в каждом таске такое количество багов, что нужно переписывать весь код. Профит от его увольнения будет больше, чем если вы попробуете как‑то переучить его.

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

Делегирование

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

Самая частая ошибка делегирования — пытаться переделать задачу по‑своему, после того как вы доверили её кому‑то из команды. Напоминаю: теперь вы оптимизируете работу команды и больше не можете делать всю работу самостоятельно. Делегирование позволит вам успевать больше. Если подход подчинённого отличается от решения в вашей голове, но он сделал всё вовремя, код соответствует требованиям, прошёл все тесты и работает — всё хорошо. Отстаньте от подчинённого, не настаивайте на своём решении и выпускайте код в продакшн.

Другая особенность руководства в том, что в какой‑то момент вы осознаете, что стали получать намного меньше быстрых результатов. Как было раньше? Вы приходили на работу, писали код и к вечеру уже мёржили пул‑реквест. Теперь будет по‑другому: вы порешали какие‑то тимлидские вопросики, но мгновенно ничего не поменялось. Это не значит, что вы больше не эффективны. Просто тимлидство — совсем другая работа и оценивается иначе: насколько хорошо вы помогаете своей команде. Чтобы адекватно оценивать себя, полезно погрузиться в комьюнити руководителей (неважно, внутри или вне компании) или найти ментора.

Руководитель второго уровня — от 5 до 15 человек

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

Не пугайтесь, это стандартная ситуация. Чтобы выйти из неё, вам нужно будет вырастить несколько мини‑лидов, таких же, каким вы были сами на первом этапе. Вот тут‑то и пригодится развитие софт‑скилов сотрудников.

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

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

Примерно через 6–12 месяцев с вами случится первый кризис управления. Через него тоже проходят абсолютно все: в какой‑то момент вы задумаетесь, чем вообще теперь занимаетесь вместо написания кода. Напоминаю: управление командой — совсем другая работа. И если как инженер и разработчик вы уже умеете и знаете многое, то как руководителю вам ещё расти и расти. Вы не понимаете, как оценивать свою работу, из‑за того что результат больше не мгновенный, а отложенный. И не получаете удовлетворения от работы, не чувствуете своей эффективности.

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

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

Руководитель третьего уровня — от 15 до 50 человек

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

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

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

• ОКР (Objectives and Key Results). Поможет проверять, что цели, которые вы ставите, достигнуты. Но одного ОКР недостаточно. Не забывайте, что у хорошего руководителя команда развивается, потому что он вкладывается в развитие людей и улучшает рабочие процессы так, чтобы его подчиненные добивалась всё новых и новых результатов.

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

• Ретроспективы. Участники команды должны понимать, что если они расскажут о чём‑то плохом, им, как минимум, ничего не будет. Им помогут, а может, ещё и поощрят. Ретроспективы работают только тогда, когда команда видит в них смысл: если её участники доверяют друг другу и руководителю.

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

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

Ещё одно неочевидное наблюдение: на третьем уровне тимлидства пора начать инвестировать в поиск замены себе, как бы странно это ни звучало. Вы же хотите стать CTO? Чтобы это случилось как можно скорее, на каждом этапе важно оставлять кого‑то, кто сможет выполнять вашу работу.

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

Но если мы говорим уже про команду из 30, 40 и 50 человек, то, чтобы найти действительно хорошего руководителя, который сможет выполнять вашу работу после вас, нужно целенаправленно вкладываться в его развитие. То есть вы должны постоянно усиливать свою команду, нанимать сильных людей и растить команду. При этом сделать так, чтобы всё, что можно, работало на процессах, а не на людях.

Руководитель четвёртого уровня — от 50 до 120 человек

Следующий уровень — это когда… На самом деле я не встречал эффективной команды, которая состояла бы больше чем из 50 людей одной компетенции. Я знаю, что они есть, но обычно уже на таком этапе, на командах под 100 человек, руководитель начинает отвечать за несколько компетенций. Например, логичное развитие карьеры руководителя iOS‑разработки, который хочет расти, — начать отвечать за Android и тестирование (QA).

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

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

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

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

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

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

Маленький спойлер или лайфхак: если вы вдруг только‑только стали руководителем крупной команды мобильной разработки (или некрупной, неважно), есть две цели, за которые можно «топить», пока вы не разобрались, что делать. Первая — ускорение разработки, а вторая — повышение качества. Это две штуки, в которых всегда есть что улучшать. В большинстве случаев они будут полезны для вашей команды. На какое‑то время хватит, но всё равно не недооценивайте важность погружения в бизнес‑контекст.

Пятый уровень — вся разработка (150+ человек)

Ваш руководитель уже, наверное, CTO. А вы каким‑то образом добрались до пятого уровня и начали управлять всей разработкой, которая есть в вашем продукте.

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

Кстати, встреч становится больше, но они занимают меньше времени. Это позволяет успевать работать. Если в вашей компании приняты встречи по часу, попробуйте проводить получасовые — они обычно оказываются эффективнее.

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

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

Стратегия — это уже конкретные шаги, которые позволят воплотить в жизнь ваше видение. Например, вы сформулировали видение: вы понимаете, что ваша компания хочет развиваться на разных рынках, поэтому нужно внедрить SwiftUI и Backend Driven UI, которые позволят вам гибче менять интерфейс в iOS‑приложении. А для этого придётся провести внутренний рефакторинг, который займёт около полутора лет, потому что кодовая база — полмиллиона строк кода. Стратегия — это когда вы продумаете конкретные шаги, которые нужно начать делать прямо сейчас, чтобы через полтора года у вас была кодовая база со SwiftUI и Backend Driven UI.

Прикольный сайд‑эффект: с этого момента вы начнёте решать ещё и разные проблемы на уровне всей компании, даже если компания достаточно крупная. Например, а как вообще должен быть устроен процесс найма инженеров? Какие технологии мы хотим использовать и почему? А как можно повысить эффективность всей разработки, а не только части, и вообще что такое эффективность в разработке?

Теперь вы сможете немножко по‑другому посмотреть на цикл управления, понять, что важно вашим стейкхолдерам и как на всё это повлиять.

Думаю, с опытом руководства всей разработкой можно управлять любым количеством людей. Когда вы научились разбираться в непонятных зонах ответственности, решать несформулированные, нечёткие задачи и вырабатывать ключевые метрики для подразделений, формировать видение — вы можете масштабировать этот опыт, и дальше вы будете решать задачи формата «как должна выглядеть стратегия чего‑то там на 10 лет». В целом ничего кардинально нового как будто бы уже не будет.

Вместо заключения

Итак, как расти? Топ-3 советов, которые помогут вырасти в управленческом треке:

• Делать немного больше, чем от вас ожидают на базовом этапе. То есть выходить немножечко за пределы своей зоны ответственности. Это позволит вам доказать, что вы не только улучшаете свою непосредственную зону ответственности, но и умеете делать что‑то ещё.

• Постоянно развивать свою команду. Вам нужны сильные сотрудники и преемники. Ваша команда со временем должна начать работать лучше, чем раньше.

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

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

И ещё одно: стать CTO, будучи мобильным разработчиком, можно. Даже несмотря на то, что большинство CTO в прошлом — бэкендеры. У меня получилось. Дерзайте — вы тоже сможете!

Спасибо, что дочитали до конца. Приходите пообщаться в комментариях.