Есть ли шанс, что лидерские бункеры исчезнут, когда продукт стабилизируется?

Предыстория:
я работал в индийском стартапе, где вице-президент по инженерным вопросам непосредственно руководил своей командой из 11 человек. Даже если он назначал руководителей групп, у них никогда не было возможности принимать решения или реальной ответственности в качестве руководителей. Раньше он ставил людям оценки «отлично» больше года, а когда хотел уволить одного и того же человека, ставил ему одну плохую оценку, включал в план повышения производительности и увольнял. Он был менее квалифицирован, чем его подчиненные, и не знал хороших методов работы с программным обеспечением. Ему не нравилось, когда продуктовая команда пыталась выяснить, почему наша реализация заняла 9 месяцев, хотя должна была занять 3 месяца, и он скрывал от них подробности. Токсическая культура. Я ушел.

Сейчас меня наняла в качестве консультанта компания, которая почти вышла из режима стартапа и имеет проверенный продукт. Проблема в том, что менеджер, которому я подчиняюсь, похож на предыдущего вице-президента. Он не знает хороших методов работы с программным обеспечением, таких как шаблоны проектирования. Код написан хаотично. Тестовые случаи почти не написаны. Никаких обзоров кода, поэтому разработчики в конечном итоге пишут код, в котором одна функция может занимать 400 строк и иметь имена переменных, такие как «lki». Вместо использования IDE они по-прежнему запускают программы из командной строки. Все решения принимает менеджер. Руководители его команды не знают всех подробностей о работе, которую они сами выполняют (несмотря на то, что они работают там более 5 лет). Он ожидает, что все будут следовать только тому, что он говорит. Эта компания очень требовательна к правилам, проверкам и т. д. Это то, что заставило меня думать, что все будет хорошо организовано. Но, увидев код, я вижу, что это кошмар.

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

Мои вопросы:
Так ли это в большинстве компаний? Где должность «тимлид» дается просто для ее тезки, а руководители не вкладывают никаких усилий в то, чтобы сотрудник учился и становился лучшим инженером-программистом или менеджером? В таких компаниях (где лидеры команд — всего лишь марионетки, а сами менеджеры не осведомлены о передовых методах разработки программного обеспечения) обещание «позже» — просто пряник, подвешенный на кнуте?
Я спрашиваю, потому что мне нужно выяснить, стоит ли оставаться и «просто выполнять работу», независимо от того, как структурирован код, или я могу надеяться поискать компании, где вещи реализованы лучше, и у меня есть возможность расти в плане знаний и управленческих навыков.

Вы сказали, что вас наняли в качестве консультанта. Вы имеете в виду работу на полную ставку или только разовое обучение? Вы консультируете по вопросам деловой практики и организации или просто имеете в виду высококвалифицированного разработчика?
Это штатная должность. Я разработчик. Я удивлен отрицательными отзывами за настоящий вопрос.
Я независимый консультант. Работаю в этой компании всего несколько месяцев. Контракт заканчивается через несколько месяцев. Соглашение заключалось в том, что на полпути, если они или я не захотим работать друг с другом, мы можем разойтись, если я даю им несколько месяцев, чтобы нанять замену. Дата принятия решения приближается, и судя по их ответам, похоже, они пытаются нанять меня на постоянную работу.
Это случается много, но не универсально. Старайтесь изо всех сил искать ключи к менталитету «сделай это» в будущих интервью. Может быть нормально спросить прямо, где, по их мнению, они находятся на спектре «сделай это» по сравнению с «очисткой частей, которые клиент не может видеть». Большинство магазинов прекрасно знают, где они лежат. Поскольку вы консультируетесь, когда осталось не так много времени, ИМО дайте им то, что они хотят, и двигайтесь дальше, когда сможете, не сражаясь в битве, которую невозможно выиграть.

Ответы (2)

В большинстве компаний так?

Нет, это не так. Большинство компаний работают намного лучше, чем это. То, что вы описываете, является недееспособной и неустойчивой моделью. «Инженерный менеджер» не может отслеживать каждую часть кода в деталях, и это означает, что он будет принимать неверные решения, но его команда будет следовать им, даже если они знают, что они неверны (потому что им было приказано это делать. ) По мере роста размера компании это начнет давать сбои. Менеджер станет узким местом, поскольку разработчики ждут, пока он примет решение о том, что им следует делать, но он слишком занят, чтобы принять решение. Эти проблемы могут начаться уже с 20 разработчиков.

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

Ваш скрытый вопрос:

Изменится ли это?

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

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

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

Помните, что это в Индии. Проблема, которую я вижу впереди, заключается в том, что если я приму их предложение взять меня в качестве постоянного сотрудника, если продукт застрянет или выйдет из строя из-за того, что он настолько запутан, они могут придумать оправдание, что это моя вина, и уволить меня. В их обзоре Glassdoor говорится, что они отрицательно отзываются о старых сотрудниках. Или, возможно, было бы правильно уйти через несколько месяцев, когда истечет срок действия контракта, и работать удаленно за пределами Индии, где, надеюсь, они соблюдают баланс между работой и личной жизнью и применяют передовые методы работы с программным обеспечением.
Я не очень хорошо знаком с индийскими обычаями, но в любом случае я бы посоветовал уехать как можно скорее. К тому времени, как менеджер был уволен в истории выше, я уже ушел и нашел должность с отличным менеджментом. Моя новая компания знала старого менеджера и специально спросила, была ли его практика причиной моего ухода.
Первый вице-президент, которого я упомянул, покинул компанию, потому что не был уверен в следующем раунде финансирования. Затем генеральный директор поговорил с генеральным директором другой компании и вернул вице-президента, потому что сотрудники считали его хорошим, а его замена не говорила с ними по-доброму, как раньше вице-президент. В нынешней компании даже отдел кадров и другие сотрудники считают, что менеджер хорошо справляется со своей работой. Вице-президент и этот менеджер умеют договариваться друг с другом, и похоже, что компаниям просто нужен кто-то, кто может держать сотрудников под контролем и выполнять работу. Я видел еще много подобных, сохраняющих свою работу.

Нет.

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

Не подскажете, какие вопросы я могу задать? Менеджер умеет отклоняться и давать расплывчатые ответы.
Попробуйте пройти собеседование с кем-то, а не с менеджером. Затем спросите их, насколько они автономны в принятии решений. Если вас не берет на собеседование кто-то, кроме менеджера, это тревожный сигнал.
У меня взял интервью один из подхалимов менеджера. Во время интервью он сам пробормотал, что ему интересно, почему его попросили взять интервью у меня, когда мой набор навыков был совершенно другим. У меня также брал интервью начальник менеджера, который сказал что-то, что заставило меня почувствовать, что менеджер тоже скрывает детали проекта от своего босса. Красный флаг. Я знаю. Мне не нужно спрашивать об автономности. Я уже видел, что у них нет автономии.
@Julia: Клейворт имел в виду задавать вопросы в ваших будущих интервью в других компаниях.