Должны ли они быть у нас?

Должности инженеров примерно отражают опыт инженера, его ответственность и роль в команде. Вот некоторые часто встречающиеся титулы инженеров:

  • Инженер-программист
  • Старший инженер-программист
  • Штатный инженер-программист
  • Главный инженер-программист

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

Работа в небольшой команде

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

Вся команда инженеров могла поместиться в одном конференц-зале. В обед мы все брали еду около часа и использовали канал Slack, #lunchatone, чтобы координировать обеденное время. Мы сидели за большим столом для пикника, обедали и болтали.

Мы хорошо знали цели и миссию компании и верили в них. Недоразумений в общении почти не было.

В такой небольшой рабочей среде различать звания инженеров не имело бы смысла.

От отсутствия титулов к титулам

Когда компания выросла, мы, естественно, начали думать о названиях и структурах команд.

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

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

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

Например, инженер-программист теперь будет старшим инженером-программистом Android в отделе доходов.

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

Переход может быть бурным

В конце концов, когда большая реорганизация была завершена, каждому присвоили новый титул, который отражал их домен и уровень. Каждый уровень также сопровождался пространным описанием обязанностей и ожиданий.

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

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

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

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

Некоторые проблемы с названиями

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

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

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

Рекрутинг тоже усложнился. Раньше нам нужно было задать следующие вопросы: 1) умный ли этот человек? 2) могу ли я работать с этим человеком? Теперь некоторые вопросы, которые нам обычно задавали во время подведения итогов собеседования, были следующими: 1) если этот кандидат не соответствует планке для старшего инженера-программиста, можем ли мы привлечь его в качестве младшего? 2) в какую команду следует включить этого инженера? 3) есть ли в этой команде инженер с более высоким званием, который может принять этого кандидата?

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

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

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

Как насчет званий инженеров, основанных на функциональных возможностях работы

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

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

Но недостатком было то, что мы создали искусственные границы.

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

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

Рабочее место, где спрятаны инженерные звания

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

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

Конечно, у каждой медали есть две стороны.

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

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

Некоторые высокопоставленные IC не получили желаемого признания, поэтому они могут изменить свое название на что-то более красивое как внутри страны, так и за ее пределами. В конце концов, наличие должности старшего инженера-программиста, штатного инженера-программиста или главного инженера-программиста в вашем резюме выглядит намного лучше, чем просто инженер-программист.

Заключение

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

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

Что вы думаете об уровнях и званиях инженеров? Как всегда, я тоже хотел бы услышать от вас.

Want to Connect?
Follow me on Twitter.