Для чего нужны уровни? Вы понимаете карьерную лестницу в вашей компании? Как вы читаете истории работы? Как выглядят примеры?
Как разработчик, наступает момент, когда мы начинаем задумываться и понимать, что наш рост не является линейным. Как и состояния материи в физике (твердое тело, жидкость и газ), мы также проходим через разные состояния в нашей карьере. Точно так же, как связь между льдом и водой не очевидна, просто глядя на фотографию, мне нужен был некоторый опыт, чтобы понять этапы карьеры.
Более 15 лет я использовал три грубых ярлыка для моделирования этапов карьеры разработчиков: Требуется руководство, Работает независимо и Ведет других. Я использую его в интервью как промежуточное звено для построения карьерных лестниц в компаниях. Я использую его, когда консультирую разработчиков, занимаюсь продвижением и проверяю возможности. Я использую его для не разработчиков.
Я много лет разбирался в простоте этой модели, и, хотя ей не хватает точности других карьерных моделей, я возвращаюсь к ней как к инструменту первого порядка. Это просто кажется естественным и эффективным для компаний, рабочих семей и даже отраслей. По сути, это те же стадии, что и в средневековых гильдиях ремесленников (которые до сих пор используются в некоторых ремеслах): ученик, подмастерье и мастер.
В этой статье я определю модель, применим ее к примерам, поделюсь предысторией и посмотрю вдаль.
Определение
Хотя мои ярлыки имеют интуитивно понятное отображение для большинства людей, со временем я усовершенствовал способ классификации поведения и людей на основе их действий и объяснений. Это также работает, когда мне нужно оценить собственное поведение. Это не однозначное суждение, поскольку мы не находимся на одной стадии по всем измерениям.
Как только я начинаю прислушиваться к чьей-то сцене, я обнаруживаю, что люди довольно легко сами классифицируются, поскольку они объясняют, над чем они работают. Я задаю несколько вопросов, но в основном мне нужно просто слушать и наблюдать за поведением, и они откроют правду. Я предпочитаю искать в этом упражнении положительные сигналы силы. Я также умею исследовать риски (отрицательные атрибуты), которые необходимо учитывать, но мне нравится разделять их при определении этапа карьеры.
Прислушиваясь к: Требуется руководство
Я демонстрирую ценность почти исключительно через создание Продукта (90%).
Я обращаюсь к своим лидерам за видением и задачами. Мне доверяют внедрять решения. Я планирую для себя дни и недели. Я наиболее успешен, когда выполняю спринтерские задачи.
Когда я что-то вижу, я что-то говорю. Я следую лучшим практикам. Я управляю рисками, избегая двусмысленности.
Я восприимчива. Я стремлюсь владеть и создавать функции.
Прослушивание: работает независимо
Я демонстрирую ценность в основном через создание продукта (75%), и у меня есть сторонние концерты, создающие процесс и людей.
Я обращаюсь к своим руководителям за видением и целями, и мне доверяют разработку и реализацию функций. Я планирую для себя недели и месяцы. Я добиваюсь наибольшего успеха, когда достигаю целей нашей команды.
Когда я что-то вижу, я что-то делаю. Я нахожу и анализирую процессы и инструменты, которые могу использовать, чтобы повысить свою эффективность. Я рассматриваю внешние изменения и двусмысленность как риски, которыми нужно управлять. Я знаю, когда мне нужна помощь и как ее найти.
Я самоуверен. Меня заинтриговали новые технологии. Я использую исследования и данные, когда представляю свои идеи. Я стремлюсь проектировать и строить системы.
Прислушиваясь к: Ведет других
Я демонстрирую ценность равномерно, создавая продукт, процесс и людей (33% / 33% / 33%).
Я обращаюсь к своим лидерам за видением и возможностями, и мне доверяют разрабатывать цели для команды. Я планирую для себя и других по месяцам и кварталам. Я наиболее успешен, когда моя команда добивается поставленных целей.
Я предвижу, когда другим понадобится помощь, и вмешиваюсь. Я уравновешиваю потребности команды с потребностями бизнеса.
Я спокойно признаю незнание технических тем. Я скептически отношусь к карго-культам и смене парадигм. Я прислушиваюсь к своим предубеждениям и стараюсь опровергнуть их, когда представляю свои идеи. Я рассматриваю внешние изменения как вызов и возможность проявить себя.
Я ищу неоднозначные проблемы, чтобы добиться ясности. Я синтезирую и стимулирую внедрение новых процессов для себя и организации. Я стремлюсь строить сети и бизнес.
использование
Чаще всего использую эту модель при приеме на работу. В рамках подготовки я также сравниваю их резюме с такими сайтами, как level.fyi и progression.fyi, но многие компании не указаны в списке. Я поделюсь некоторыми примерами поведенческих вопросов, но для краткости в ответах не будут упоминаться технические особенности, которые обычно требуются. Все ответы на разных этапах достаточно сильны.
Вопрос: Расскажите мне о случае, когда вы знали, что вашему коллеге нужна помощь, и решили вмешаться. Как вы определили необходимость? Что ты сделал? Как все вышло?
Ответ от Требуется руководство: к нам присоединился новый сотрудник. После их адаптации мой руководитель попросил меня помочь с их первым заданием на спринт, пока они знакомились с нашими системами. Они застряли в одном из тех же мест, с которыми у меня были проблемы вначале. Я сидел с ними, и мы вместе работали над этим. Мы смогли выполнить задание, и опоздание было всего на один день. Теперь они знают об этой проблеме и могут помочь следующему, кто застрянет. Я сказал своему боссу, что все там застревают, и мы должны это исправить.
Ответ от Работает самостоятельно: к нам присоединился новый сотрудник. После адаптации они взяли первое задание на спринт из нашего бэклога. Во время стендапа они не говорили, что их заблокировали, но я видел, что они медленно продвигаются. Я знал, над чем они работают, и отправил им некоторую документацию, которая могла помочь. Научите человека ловить рыбу, понимаете? Им все еще требовалась небольшая помощь, но мы сделали это, и опоздали всего на один день. Впоследствии я обновил документацию тем, что мы сделали.
Ответ от Ведет других: у нас появился новый участник в команде, и я всегда настраиваю вводные и последующие проверки, чтобы отслеживать прогресс. Во время вступительного разговора я понял, что им понадобится дополнительная помощь в их первом задании. Я отправил им нашу документацию и попросил предыдущего новичка подружиться, если возникнут какие-либо проблемы. При первом задании возникла икота, но приятель помог, и опоздание было всего на день. В ходе моих последующих наблюдений я понял, что икота - это обычное дело для новичков. Я дважды сверился с командой, а затем добавил работу в наш список невыполненных работ, указав крайний срок до следующего присоединения. Когда к нам присоединился следующий человек, я убедился, что проблема больше не вызывает проблем.
Вопрос: Расскажите о недавнем инциденте, с которым вы справились в рамках DevOps? Каков был график? Что ты сделал? Как все вышло?
Ответ от Требуется руководство: мне звонили ночью. Я следил за модулем Runbook и откатил развертывание, чтобы устранить проблему. Утром я просмотрел коммиты и сократил количество изменений до двух. Я принес его, чтобы встать, и кто-то объяснил, почему он сломался. Я вызвался исправить это, зная, к кому обратиться за помощью.
Ответ от Работает независимо: ночью мне звонили. После отката я убедился, что ошибка устранена, и отследил плохие изменения. Утром я получил исправление и отправил его на проверку кода. Наша команда новичок в реагировании на инциденты, поэтому я также начал использовать процесс 5 почему, чтобы выяснить первопричины. Я добавил первопричину в нашу задолженность по техническому долгу. Честно говоря, у нас большой технический долг, и я был разочарован тем, что у нас, кажется, никогда не бывает достаточно времени, чтобы его исправить.
Ответ от Ведет других: у нас ночью произошел серьезный сбой в работе. Один из моих коллег получил постраничный вызов и предпринял меры по устранению рисков, что было хорошим знаком для нашего модуля Runbook. Я формализовал процессы реагирования на инциденты, которые теперь включают анализ первопричин. Хорошим и плохим было то, что этот последний сбой был известным риском в нашей очереди, и мы не устранили его.
Предыстория
У меня уже была идея стать разработчиком, когда я присоединился к Microsoft в качестве подрядчика. Я начал отвечать на телефонные звонки в службу поддержки продуктов (PSS) в 1994 году. Мой план был расплывчатым по многим деталям, но он был смелым для человека, не имеющего работы и не имеющего ученой степени. Я написал, что хотел «распространить информацию в глобальном масштабе» для цели моего первого резюме.
У меня все еще мурашки по коже, когда я вспоминаю, как Гарт Браун познакомил меня с NCSA Mosaic, работающим на SPARCstation. Я знал, что хочу быть строителем Интернета, даже когда потенциал Интернета был в основном гипотетическим. Моя страсть к этой идее способствовала моему росту в те ранние годы, побуждая рисковать.
Оказавшись внутри PSS, я обнаружил самодидактический мир грез. Учебные материалы были полностью открытыми и полны первоклассных прикладных знаний. Как будто они взяли все руководства, которые были в публикации, а затем сократили их до только хороших частей.
Я была голодной губкой. Я научился поддерживать новые продукты каждый месяц: MS-Works, Multi-Media, WFW311, MS-Office Setup и т. Д. Я был так взволнован, что пошел на риск, например, отказавшись от этой первой в моей жизни акции PSS. Это было бы умным шагом в карьере, но я искал прыжки.
И прыгнул! Я пересмотрел свою роль так быстро, как смог доказать свои новые навыки.
Я переехал в здание 5 в качестве тестировщика (STE) после того, как Брюс Джонсон показал мне открытие в Internet Explorer (IE). Там мне пришлось наблюдать, как Raymond Chen отлаживает необработанную сборку, когда мои тесты выявляли сбои в Windows 95. Я впервые отправил код, который был инструментом, который можно было загрузить через FTP или BBS. Это было диалоговое окно, написанное на одной длинной уродливой C-функции, которая преобразовывала закладки Netscape в избранное IE. Нил Смит спас меня от увольнения за разговор с репортером при моем первом запуске, когда все возбужденные люди выстраивались в полночь у магазинов, чтобы купить 13 дискет Win95.
Я получил синий значок как тестируемый разработчик (SDET) на IE3 и перешел в здание 27. Там я написал свою первую производственную функцию, выполняя постоянную окраску ссылок. Технически это не было моей работой как SDET, но Бхарат Шьям убедил меня реализовать мою идею и внедрить ее. А Крис Гузак убедил меня сделать его COM -объектом, так родился IUrlHistoryStg . Я был настолько невежественен, что когда я сделал свой первый переход на главную линию, используя SLM, я оставался один в офисе до 4 утра, исправляя все перебои в сборке. Некоторые уроки можно извлечь, только нарушив сборку.
А потом я стал настоящим живым разработчиком IE4 / Shell. Некоторое время я скрывался в списках рассылки uri @ bunyip, поэтому я взял на себя объединение всех независимых копий парсинга URL в IE и выучил первое правило программирования для Интернета: НИКОГДА НЕ ПИШИТЕ ВАШ СОБСТВЕННЫЙ ПАРСЕР URL. Этому я так и не научился, но часто рассказываю другим людям. Я узнал, как выглядит хороший босс-разработчик, от Chee Chew, который также научил меня играть в го и Age of Empires за обедом в здании 31.
После того, как мы выпустили IE4 и Windows 98, моя карьера программирования завершилась. Я достиг своей цели - стать разработчиком. В некотором роде мне казалось, что я переборщил с созданием платформ, которые привели в действие бум доткомов: мы трансформировали мир, и информация высвобождалась.
Я торжествовал. Мне нравилось быть разработчиком. Мне нравилось работать с блестящими людьми. Мне нравилось работать над такими впечатляющими продуктами.
Но у меня не было запланировано второго акта. Я обнаружил, что без давления на вершину, плато - хорошее место, чтобы перевести дух и полюбоваться пейзажем. Я стал больше внимания уделять разработчикам, которые меня окружали. Я прислушивался к их планам. Я слышал их планы и мечты. Я слышал их победы и разочарования. Я слышал их теории и обещания. Я собрал истории, которые нашли отклик.
Я наблюдал 3 этапа для разработчиков: Clueless, Hotshot и Inscrutable. Большинство из них попало в диапазон от невежественных до горячих. И я знал, что тоже был там. Я больше не чувствовал себя совершенно невежественным (это было зарезервировано для стажеров;), но были некоторые сумасшедшие умные и опытные разработчики, которые давали понять, как многому нужно научиться. И некоторые разработчики, например архитекторы, действительно казались невероятно далекими. Я не мог сказать, были ли они намеренно загадочными, или я действительно был более стажером, чем мне хотелось верить.
В тот момент я рассматривал потенциальные возможности карьерного роста, но игнорировал путь перехода к менеджеру или к другой семье. Я также читал, но в основном игнорировал, инструменты, которые Microsoft HR использовал для определения лестничных уровней. Они были абстрактными, и мне было трудно сопоставить их с тем, что я видел в повседневной жизни.
Так что я погрузился в свою горячую зону, наслаждался жизнью, оттачивал свой код, но у меня не было особого плана на то, что будет дальше. А затем, в 2000 году, Microsoft обновила уровни карьерной лестницы. Они также изменили все инструменты, документацию и, я полагаю, обучение менеджеров, которое подтвердило для меня, насколько эти вещи произвольны. Это сопровождалось крахом доткомов, который перевернул столы на рынке труда, моделях компенсации и для многих людей их личных состояниях технологических акций. Это было время, когда вокруг компании много разглядывалось.
В одной из частых дискуссий об изменениях в кафетерии кто-то говорит, что новые уровни на самом деле ничего не изменили. Они сказали: «Вы можете просто сопоставить старую систему и новую систему с реальными уровнями: Требуется руководство, Работает независимо и Ведет других». Загорелась лампочка; это было так просто!
Дальнейшие мысли
А как насчет других лидерских качеств? Конечно, есть много других карьерных возможностей. Подобно лидерам военного и мирного времени в политике, компаниям требуются стили руководства, соответствующие фазам: разведка, кризис, масштабирование, садоводство и т. Д. Пути продвижения становятся такими же разнообразными, как и потребности бизнеса, в котором они работают, особенно для отдельных участников. (ИС).
А как насчет трека менеджера? Я могу рекомендовать это! Я делал это раньше и сделаю это снова. Мне нравится, когда я инвестирую в людей и делаю их сильнее. Мы часто измеряем масштаб влияния, проверяя, насколько велика организация и где они находятся. Для менеджеров это довольно очевидно, но более мягкое влияние интегральных схем делает это более тонким. Но просто управлять людьми волшебным образом не превращает кого-то в лидера. У вас также может быть кто-то, кто достиг лидирует, но играет ограниченную роль, случайно или намеренно. И наоборот, когда кто-то играет большую роль, но все же не демонстрирует лидов других.
А как насчет Гэндальфа Белого? Это правда, что по мере того, как люди растут, ведет за собой других, они неравномерно распределяются между созданием продукта, процесса и людей. Все больше внимания уделяется тому, как усилить воздействие, работая через других людей. Они понимают, что миссия требует одновременного создания ценности во многих измерениях.
Что случилось со всем этим названием? Я был не один. Все эти люди изменили мою карьеру. Я благодарен за то, что они были союзниками, спонсорами или просто вдохновителями. Не имеет значения, обнаружил я их или они открыли меня, потому что я в любом случае изменился. Я знаю, что мне еще есть чему поучиться, и я ищу людей, которые бросят вызов и поддержат мой следующий этап роста.
Работа Эмре Айдогана и Лоры Дизлер - © ️2021 Zeke Arany-Lucas
Зик Арани-Лукас - старший главный инженер из Сиэтла, живет и работает в Берлине с 2014 года. Он работает в сфере высоких технологий более 25 лет, начав с разработки веб-браузеров в 90-х годах. , в том числе долгое время работы в Microsoft и Amazon на нескольких руководящих должностях. Вы также можете подписаться на него в LinkedIn и Twitter, а также на его подкаст The Introspective Developer, в Spotify, Apple Podcasts, Instagram и Facebook.
