Про shit tolerance
Хороший твиттер-тред от Евгения Кота про то, что чем сеньорнее становится сотрудник, тем большая терпимость к говну в коде, технологиях и процессах от него ожидается. С одной стороны, я с ним согласен – деньги платятся именно за то, что заниматься часто приходится не самыми интересными и вдохновляющими вещами. С другой стороны, менталочка себе дороже, вы работодателю ничего не должны, и если нет желания воевать с ветряными мельницами, то проще сменить место работы, если ситуация на рынке это позволяет.
Хороший твиттер-тред от Евгения Кота про то, что чем сеньорнее становится сотрудник, тем большая терпимость к говну в коде, технологиях и процессах от него ожидается. С одной стороны, я с ним согласен – деньги платятся именно за то, что заниматься часто приходится не самыми интересными и вдохновляющими вещами. С другой стороны, менталочка себе дороже, вы работодателю ничего не должны, и если нет желания воевать с ветряными мельницами, то проще сменить место работы, если ситуация на рынке это позволяет.
Сервис поиска менторов
Практически в любой статье про необходимые навыки руководителя на первые места ставят рост и развитие людей. Однако это далеко не значит, что тимлид сам должен обучать своих подчиненных. Наоборот, гораздо лучше организовать процессы так, чтобы новички учились у старичков.
Звучит красиво, а что делать, не очень понятно, особенно когда старичков нет, или они не горят желанием кого-то обучать. Рабочий вариант – поискать наставника на стороне. И тут я хочу очень сильно порекомендовать сервис поиска наставников GetMentor.dev, который делает Георгий Могелашвили. Первое, про что важно знать – сервис не коммерческий, нет никаких комиссий, и делается им просто ради фана и желания помочь решить частую проблему. Второе – за несколько лет его работы там собралось больше тысячи наставников по разным областям, у половины из которых опыт больше 10 лет. В третьих – многие из наставников, как и сам сервис, ничего не берут за свою помощь.
Короче говоря, если кому-то из ваших сотрудников нужен наставник, или вы сами хотите подтянуть свои тимлидские скиллы, загляните в GetMentor.
Практически в любой статье про необходимые навыки руководителя на первые места ставят рост и развитие людей. Однако это далеко не значит, что тимлид сам должен обучать своих подчиненных. Наоборот, гораздо лучше организовать процессы так, чтобы новички учились у старичков.
Звучит красиво, а что делать, не очень понятно, особенно когда старичков нет, или они не горят желанием кого-то обучать. Рабочий вариант – поискать наставника на стороне. И тут я хочу очень сильно порекомендовать сервис поиска наставников GetMentor.dev, который делает Георгий Могелашвили. Первое, про что важно знать – сервис не коммерческий, нет никаких комиссий, и делается им просто ради фана и желания помочь решить частую проблему. Второе – за несколько лет его работы там собралось больше тысячи наставников по разным областям, у половины из которых опыт больше 10 лет. В третьих – многие из наставников, как и сам сервис, ничего не берут за свою помощь.
Короче говоря, если кому-то из ваших сотрудников нужен наставник, или вы сами хотите подтянуть свои тимлидские скиллы, загляните в GetMentor.
Как тимлиду рассказывать о результатах своей работы
Уметь рассказывать о своих достижениях важно по куче причин – среди них как своя собственная мотивация и ощущение своей полезности, так и дополнительные очки при расчете премии или повышении. В статье предлагается пошаговый гайд по тому, как правильно рассказывать о результатах своей работы с учетом контекста и аудитории.
🎯Поставьте цель, для достижения которой вы делитесь результатами
🤔Определите пользу для компании в своих результатах
👀Проанализируйте аудиторию – что им важно знать из вашего рассказа
✍️Выберите подходящую форму рассказа
🤷♂️Протестируйте на понятность, показав свой рассказ заранее нескольким людям
Советы в статье актуальны не только для презентации своих успехов, но и для повышения прозрачности результатов всей команды.
Уметь рассказывать о своих достижениях важно по куче причин – среди них как своя собственная мотивация и ощущение своей полезности, так и дополнительные очки при расчете премии или повышении. В статье предлагается пошаговый гайд по тому, как правильно рассказывать о результатах своей работы с учетом контекста и аудитории.
🎯Поставьте цель, для достижения которой вы делитесь результатами
🤔Определите пользу для компании в своих результатах
👀Проанализируйте аудиторию – что им важно знать из вашего рассказа
✍️Выберите подходящую форму рассказа
🤷♂️Протестируйте на понятность, показав свой рассказ заранее нескольким людям
Советы в статье актуальны не только для презентации своих успехов, но и для повышения прозрачности результатов всей команды.
Курс про работу с командой
Я уверен, что большинство подписчиков канала стали тимлидами следующим образом – в один прекрасный день к ним сзади подошел руководитель, похлопал по плечу, улыбнулся улыбкой авгура, и предложил новую блестящую карьерную возможность. Конечно же вы ее приняли. Кто-то ради большей зарплаты, кто-то ради нового интересного приключения, кто-то из-за неравнодушности к тому, что происходит вокруг.
После этого вам пришлось идти на ощупь, учиться слышать людей, убеждать их делать то, что надо, и отговаривать от того, что делать не надо. Мало начинающих руководителей получают хоть какое-то внятное образование или поддержку в первые годы. Даже осознание того, что менеджмент – это что-то, чему можно учиться, часто появляется поздно.
Если вы сейчас находитесь в такой ситуации, или знаете таких руководителей, посмотрите на новый курс от ребят из SETTERS EDUCATION. Они выстраивают обучение от практики, сначала показывая, как разбирать типовые кейсы, а затем погружаясь в разбор именно вашего контекста. Курс покрывает основные векторы роста тимлида – выстраивание процесса управления командой, коммуникации и собственную продуктивность.
Курс стартует 13 февраля — присоединяйтесь!
Я уверен, что большинство подписчиков канала стали тимлидами следующим образом – в один прекрасный день к ним сзади подошел руководитель, похлопал по плечу, улыбнулся улыбкой авгура, и предложил новую блестящую карьерную возможность. Конечно же вы ее приняли. Кто-то ради большей зарплаты, кто-то ради нового интересного приключения, кто-то из-за неравнодушности к тому, что происходит вокруг.
После этого вам пришлось идти на ощупь, учиться слышать людей, убеждать их делать то, что надо, и отговаривать от того, что делать не надо. Мало начинающих руководителей получают хоть какое-то внятное образование или поддержку в первые годы. Даже осознание того, что менеджмент – это что-то, чему можно учиться, часто появляется поздно.
Если вы сейчас находитесь в такой ситуации, или знаете таких руководителей, посмотрите на новый курс от ребят из SETTERS EDUCATION. Они выстраивают обучение от практики, сначала показывая, как разбирать типовые кейсы, а затем погружаясь в разбор именно вашего контекста. Курс покрывает основные векторы роста тимлида – выстраивание процесса управления командой, коммуникации и собственную продуктивность.
Курс стартует 13 февраля — присоединяйтесь!
Гайд по ненасильственному общению
Наши потребности напрямую связаны с чувствами. Если потребности удовлетворены, мы рады, если нет — злимся. Чтобы минимизировать число конфликтов и сгладить их последствия, важно сосредоточиться на понимании потребностей — чужих и собственных.
Это – ключевая идея техники ненасильственного общения, которая дает простой алгоритм для конструктивного взаимодействия даже в самых эмоционально напряженных конфликтах. Я уже не раз советовал ее в этом канале. Если вы так и не добрались до книги Маршалла Розенберга, то прочитайте хотя бы гайд по ссылке, он сделан очень качественно.
Наши потребности напрямую связаны с чувствами. Если потребности удовлетворены, мы рады, если нет — злимся. Чтобы минимизировать число конфликтов и сгладить их последствия, важно сосредоточиться на понимании потребностей — чужих и собственных.
Это – ключевая идея техники ненасильственного общения, которая дает простой алгоритм для конструктивного взаимодействия даже в самых эмоционально напряженных конфликтах. Я уже не раз советовал ее в этом канале. Если вы так и не добрались до книги Маршалла Розенберга, то прочитайте хотя бы гайд по ссылке, он сделан очень качественно.
Обучение и шаринг знаний через группы поддержки
Обучение через опыт своих коллег часто становится самым эффективным. Ты не просто перенимаешь у них знания, а сразу же смотришь, как они применяются в контексте вашей компании и процессов. В статье рассказывается про практику Mini-M – регулярные «группы поддержки» менеджеров с постоянным составом. Идея такая:
1️⃣Собираете всех руководителей, которые хотят развиваться и обсуждать свои кейсы
2️⃣Делите их на небольшие группы по 5-8 человек, за каждой группой назначаете ответственного
3️⃣Группы собираются раз в пару недель. На встрече каждый участник рассказывает свой кейс, который он хотел бы разобрать, затем группа выбирает несколько самых интересных, и разбирает их с автором, помогая найти ему решение проблемы.
Практика выглядит довольно мощной – вы одновременно строите коммьюнити лидов, поднимаете общий уровень их насмотренности и знаний, и даете безопасную площадку для обсуждения сложных проблем.
Если стало интересно, не пропустите продолжение поста с очень детальной инструкцией по проведению такой встречи.
Обучение через опыт своих коллег часто становится самым эффективным. Ты не просто перенимаешь у них знания, а сразу же смотришь, как они применяются в контексте вашей компании и процессов. В статье рассказывается про практику Mini-M – регулярные «группы поддержки» менеджеров с постоянным составом. Идея такая:
1️⃣Собираете всех руководителей, которые хотят развиваться и обсуждать свои кейсы
2️⃣Делите их на небольшие группы по 5-8 человек, за каждой группой назначаете ответственного
3️⃣Группы собираются раз в пару недель. На встрече каждый участник рассказывает свой кейс, который он хотел бы разобрать, затем группа выбирает несколько самых интересных, и разбирает их с автором, помогая найти ему решение проблемы.
Практика выглядит довольно мощной – вы одновременно строите коммьюнити лидов, поднимаете общий уровень их насмотренности и знаний, и даете безопасную площадку для обсуждения сложных проблем.
Если стало интересно, не пропустите продолжение поста с очень детальной инструкцией по проведению такой встречи.
Rubick
Jade Rubick - Uplevel your managers with Mini-M support groups
A Mini-M is a group of managers that meet weekly or biweekly. The meeting is a combination support group and working session. I describe the practice.
Трек Яндекса на TeamLeadConf про R&D и культуру компании
27 февраля на конференции TeamLeadConf стартует специальный трек, курируемый Яндексом. Идея такая – через серию докладов экспертов из разных компаний показать, как в условиях различной корпоративной культуры можно создавать инновационные технологические решения. А это – очень интересно, ведь на способность компании к инновациям влияет вообще все, начиная от структуры управления, заканчивая организацией внутренних коммуникаций.
Полезнее всего, конечно, наблюдать за этим своими глазами, но послушать очевидцев на конференции и закидать их вопросами тоже поможет развитию насмотренности. Вот несколько интересных докладов, которые я потом обязательно посмотрю в записи:
👀Алексей Гусаков из Яндекса расскажет о технологиях машинного обучения. А точнее как управлять самым инновационным отделом компании и сохранять баланс между бизнесом и наукой — и что хороший управленец может дать команде инженеров.
👀Александр Ложечкин из Райффайзен Банка, прошедший Microsoft и Amazon, точно повидал вообще всякого. В докладе он расскажет про то, можно ли менять корпоративную культуру и как она влияет на инновации.
👀Сергей Мельник, занимающийся Яндекс Станцией, расскажет про боли в создании хардварных стартапов, в которых на проверку гипотезы может требоваться несколько лет.
👀Максим Лапшин из Эрливидео расскажет о том, как инженерная культура помогает в прогнозировании сроков при разработке инноваций.
Если у вас получается прийти на конференцию – очень рекомендую, если бы был рядом, то обязательно дошел бы сам.
27 февраля на конференции TeamLeadConf стартует специальный трек, курируемый Яндексом. Идея такая – через серию докладов экспертов из разных компаний показать, как в условиях различной корпоративной культуры можно создавать инновационные технологические решения. А это – очень интересно, ведь на способность компании к инновациям влияет вообще все, начиная от структуры управления, заканчивая организацией внутренних коммуникаций.
Полезнее всего, конечно, наблюдать за этим своими глазами, но послушать очевидцев на конференции и закидать их вопросами тоже поможет развитию насмотренности. Вот несколько интересных докладов, которые я потом обязательно посмотрю в записи:
👀Алексей Гусаков из Яндекса расскажет о технологиях машинного обучения. А точнее как управлять самым инновационным отделом компании и сохранять баланс между бизнесом и наукой — и что хороший управленец может дать команде инженеров.
👀Александр Ложечкин из Райффайзен Банка, прошедший Microsoft и Amazon, точно повидал вообще всякого. В докладе он расскажет про то, можно ли менять корпоративную культуру и как она влияет на инновации.
👀Сергей Мельник, занимающийся Яндекс Станцией, расскажет про боли в создании хардварных стартапов, в которых на проверку гипотезы может требоваться несколько лет.
👀Максим Лапшин из Эрливидео расскажет о том, как инженерная культура помогает в прогнозировании сроков при разработке инноваций.
Если у вас получается прийти на конференцию – очень рекомендую, если бы был рядом, то обязательно дошел бы сам.
Big Data – во многих случаях карго-культ
Данные – новая нефть. Под этим лозунгом какое-то время назад сейлзы активно продавали важным СТО кучу различных решений для хранения и процессинга больших данных, показывая им графики-клюшки. Чем больше данных накоплено, тем более точными и взвешенными становятся принимаемые решения, и тем больше денег в итоге зарабатывает бизнес.
Бывший продакт-менеджер Google BigQuery поделился историями о том, насколько много данных действительно скапливается у компаний, и как они в итоге их используют.
👉Подавляющее большинство компаний не дотягивают до терабайта данных, кроме самых крупных энтерпрайзов.
👉Большинство витрин использует либо данные за последний месяц, либо агрегированные данные.
👉Даже этот терабайт накапливается годами. С учетом паттернов использования данных, они практически бесполезны.
Кроме этого, хранение большого объема данных на протяжении долгого времени, помимо затрачиваемых на инфраструктуру денег, влечет за собой дополнительные косвенные расходы:
💸Требования к хранимым данным ужесточаются. Политики вроде GDPR требуют реализации нетривиальной логики по тому, какие данные, когда и как надо удалять. Все это требует усложнения инфры, дополнительного времени разработки, и увеличивает риск нарваться на штрафы.
💸Данные могут играть против вас, если их затребуют при каком-нибудь расследовании.
💸Схема данных со временем эволюционирует, в результате чего запросы становятся все сложнее и сложнее, и в них проще допустить ошибки.
Мораль статьи – не нужно гнаться за построением огромных хранилищ данных, если вы не можете сформулировать, для чего вам нужны будут эти данные в сыром виде в будущем.
Данные – новая нефть. Под этим лозунгом какое-то время назад сейлзы активно продавали важным СТО кучу различных решений для хранения и процессинга больших данных, показывая им графики-клюшки. Чем больше данных накоплено, тем более точными и взвешенными становятся принимаемые решения, и тем больше денег в итоге зарабатывает бизнес.
Бывший продакт-менеджер Google BigQuery поделился историями о том, насколько много данных действительно скапливается у компаний, и как они в итоге их используют.
👉Подавляющее большинство компаний не дотягивают до терабайта данных, кроме самых крупных энтерпрайзов.
👉Большинство витрин использует либо данные за последний месяц, либо агрегированные данные.
👉Даже этот терабайт накапливается годами. С учетом паттернов использования данных, они практически бесполезны.
Кроме этого, хранение большого объема данных на протяжении долгого времени, помимо затрачиваемых на инфраструктуру денег, влечет за собой дополнительные косвенные расходы:
💸Требования к хранимым данным ужесточаются. Политики вроде GDPR требуют реализации нетривиальной логики по тому, какие данные, когда и как надо удалять. Все это требует усложнения инфры, дополнительного времени разработки, и увеличивает риск нарваться на штрафы.
💸Данные могут играть против вас, если их затребуют при каком-нибудь расследовании.
💸Схема данных со временем эволюционирует, в результате чего запросы становятся все сложнее и сложнее, и в них проще допустить ошибки.
Мораль статьи – не нужно гнаться за построением огромных хранилищ данных, если вы не можете сформулировать, для чего вам нужны будут эти данные в сыром виде в будущем.
Нейросети & NoCode VS разработчики. Кто победит?
Ажиотаж вокруг NoCode решений и нейросетей, в особенности ChatGPT, не стихает и только набирает обороты. Они сдают экзамены, пишут статьи, сценарии и код, а новости о том, что они вот-вот заменят всех, в том числе разработчиков, подхватывает огромное количество изданий и активно обсуждаются.
Но так ли это и что будет в IT? Именно это обсудят в эфире с Tech Unit Lead Авито, Александром Пряхиным, который прошел долгий путь от junior Developer до CTO.
▶️ Во время эфира, обсудят:
▫️Откуда пошли NoCode и нейросети
▫️Востребованность на рынке подобных решений – есть ли риски для инженеров
▫️За и против применения в продакшне – кейсы, когда нейросети могут быть полезны
В конце эфира можно посмотреть на то, как работает ChatGPT и как можно использовать её, развиваясь в IT.
Старт 21 февраля в 19:00 по Москве.
➡️ Приходите: https://otus.pw/mliS/ и приглашайте коллег!
Ажиотаж вокруг NoCode решений и нейросетей, в особенности ChatGPT, не стихает и только набирает обороты. Они сдают экзамены, пишут статьи, сценарии и код, а новости о том, что они вот-вот заменят всех, в том числе разработчиков, подхватывает огромное количество изданий и активно обсуждаются.
Но так ли это и что будет в IT? Именно это обсудят в эфире с Tech Unit Lead Авито, Александром Пряхиным, который прошел долгий путь от junior Developer до CTO.
▫️Откуда пошли NoCode и нейросети
▫️Востребованность на рынке подобных решений – есть ли риски для инженеров
▫️За и против применения в продакшне – кейсы, когда нейросети могут быть полезны
В конце эфира можно посмотреть на то, как работает ChatGPT и как можно использовать её, развиваясь в IT.
Старт 21 февраля в 19:00 по Москве.
Please open Telegram to view this post
VIEW IN TELEGRAM
Внедрение и жизнь с Zero Bug Policy
Пару недель назад я выкладывал пост ребят из SkyEng про то, как они боролись с накопившимся бэклогом багов на специальном мероприятии – багатоне. Они сразу предупреждали, что проблему растущего бэклога они таким образом не решили, и следующим шагом стали внедрять Zero Bug Policy.
Если не уходить в детали, то суть ZBP в том, что с любым багом надо разбираться сразу же, как только он появился – если он важный, то исправлять, а если не важный – то даже не заводить.
Конечно, в реальной жизни не в каждой команде получается внедрить практику в ее каноничном виде. В том же SkyEng в итоге пришли к трем ее подвидам:
1️⃣Классическая строгая, как описано выше
2️⃣Спринты любви, когда часть багов все-таки откладывается, но обязательно фиксится отдельным усилием команды раз в несколько итераций
3️⃣Сравнение багов по стоимости с фичами и принятие решения, что именно делать
В статье подробно и честно разбирают как плюсы, так и минусы от внедрения политики. Если вы решите повторить похожий путь в своей команде – однозначно рекомендую прочитать.
Пару недель назад я выкладывал пост ребят из SkyEng про то, как они боролись с накопившимся бэклогом багов на специальном мероприятии – багатоне. Они сразу предупреждали, что проблему растущего бэклога они таким образом не решили, и следующим шагом стали внедрять Zero Bug Policy.
Если не уходить в детали, то суть ZBP в том, что с любым багом надо разбираться сразу же, как только он появился – если он важный, то исправлять, а если не важный – то даже не заводить.
Конечно, в реальной жизни не в каждой команде получается внедрить практику в ее каноничном виде. В том же SkyEng в итоге пришли к трем ее подвидам:
1️⃣Классическая строгая, как описано выше
2️⃣Спринты любви, когда часть багов все-таки откладывается, но обязательно фиксится отдельным усилием команды раз в несколько итераций
3️⃣Сравнение багов по стоимости с фичами и принятие решения, что именно делать
В статье подробно и честно разбирают как плюсы, так и минусы от внедрения политики. Если вы решите повторить похожий путь в своей команде – однозначно рекомендую прочитать.
Хабр
Багоцид и Zero Bug Policy — как мы побеждали баги, а они нас
Кадр из фильма «Космический десант». Начало войны с багами. Принцип такой: если баг обнаружен, то мы его либо исправляем в рамках SLA, либо сразу решаем, что фиксить не будем — когда это особенность...
Как написать стратегию инженерной команды
Когда вы руководите всем инженерным департаментом, или какой-то относительно самостоятельной его частью, многие вопросы начинают упираться в наличие стратегии – согласованного со всеми артефакта, который высокоуровнево описывает принципы работы команды, ее цели и основные вехи на пути к ним.
Любовь к наличию стратегии понятна – работа по принципам жадных алгоритмов с субоптимальными решениями всегда кажется неэффективной на длинной дистанции. Наличие плана помогает упорядочить неопределенность и создать иллюзию контроля.
Пост по ссылке – золото. Автор кратко рассказывает о принципах из книги «Хорошая стратегия, плохая стратегия», прикладывает их к разработке стратегии инженерной команды и, самое главное, дает подробный пример такой стратегии. Сама книга, кстати, топовая, тоже рекомендую прочитать. Идеи оттуда я использовал и при написании инженерных, и продуктовых стратегий.
Когда вы руководите всем инженерным департаментом, или какой-то относительно самостоятельной его частью, многие вопросы начинают упираться в наличие стратегии – согласованного со всеми артефакта, который высокоуровнево описывает принципы работы команды, ее цели и основные вехи на пути к ним.
Любовь к наличию стратегии понятна – работа по принципам жадных алгоритмов с субоптимальными решениями всегда кажется неэффективной на длинной дистанции. Наличие плана помогает упорядочить неопределенность и создать иллюзию контроля.
Пост по ссылке – золото. Автор кратко рассказывает о принципах из книги «Хорошая стратегия, плохая стратегия», прикладывает их к разработке стратегии инженерной команды и, самое главное, дает подробный пример такой стратегии. Сама книга, кстати, топовая, тоже рекомендую прочитать. Идеи оттуда я использовал и при написании инженерных, и продуктовых стратегий.
Lethain
Writing an engineering strategy.
Once you become an engineering executive, an invisible timer starts ticking in the background.
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they…
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they…
Топ-10 ошибок менеджера при найме сотрудника
Материалы про найм стабильно набирают в канале больше всего лайков. Серебряных пуль не бывает, идеальный процесс за вас никто не построит, но чужой опыт помогает избежать хотя бы части чужих ошибок.
Подключайтесь к открытому эфиру с Евгением Картавцом, руководителем из команды образовательных технологий Яндекса, во время которого он расскажет:
- Как правильно задавать вопросы про опыт и ошибки кандидата, а также на что обращать внимание
- Как подойти к структуре интервью
- Как проверять кандидата через ситуационные вопросы
- Как корректно показать профессионализм вашей команды, ее ценности и не отпугнуть кандидата
Ребята обещают отдельный фокус на популярных ошибках при найме новых сотрудников и способах их избежать.
📆Дата: 28 февраля, 19:00
👉Регистрация
Реклама. Информация о рекламодателе на сайте www.otus.ru
Материалы про найм стабильно набирают в канале больше всего лайков. Серебряных пуль не бывает, идеальный процесс за вас никто не построит, но чужой опыт помогает избежать хотя бы части чужих ошибок.
Подключайтесь к открытому эфиру с Евгением Картавцом, руководителем из команды образовательных технологий Яндекса, во время которого он расскажет:
- Как правильно задавать вопросы про опыт и ошибки кандидата, а также на что обращать внимание
- Как подойти к структуре интервью
- Как проверять кандидата через ситуационные вопросы
- Как корректно показать профессионализм вашей команды, ее ценности и не отпугнуть кандидата
Ребята обещают отдельный фокус на популярных ошибках при найме новых сотрудников и способах их избежать.
📆Дата: 28 февраля, 19:00
👉Регистрация
Реклама. Информация о рекламодателе на сайте www.otus.ru
Ситуационное лидерство
Одного идеального стиля управления командой нет. Его нужно менять в зависимости от степени неопределенности задач, стадии развития команды, личностей конкретных людей внутри. Я думаю, что универсальную модель того, какой стиль лидерства в какой ситуации использовать, выработать невозможно. Люди – сложные, их отношения друг с другом сложнее в квадрате, а влияние всего этого на рабочий процесс вообще плохо предсказуемо.
Но, как известно, все модели врут, но какие-то из них полезны. В статье рассматривается довольно рабочее приближение того, как, в зависимости от стадии развития команды по Ленсиони, выбирать один из четырех стилей управления, различающихся степенью жесткости контроля и автономностью команды.
Одного идеального стиля управления командой нет. Его нужно менять в зависимости от степени неопределенности задач, стадии развития команды, личностей конкретных людей внутри. Я думаю, что универсальную модель того, какой стиль лидерства в какой ситуации использовать, выработать невозможно. Люди – сложные, их отношения друг с другом сложнее в квадрате, а влияние всего этого на рабочий процесс вообще плохо предсказуемо.
Но, как известно, все модели врут, но какие-то из них полезны. В статье рассматривается довольно рабочее приближение того, как, в зависимости от стадии развития команды по Ленсиони, выбирать один из четырех стилей управления, различающихся степенью жесткости контроля и автономностью команды.
Давайте вместе разберем интересный кейс!
Есть команда, которая отвечает за технически сложный продукт. Скажем, за компилятор какого-нибудь языка. Под капотом компилятор состоит из нескольких отдельных подсистем, которые интегрируются друг с другом, но в целом довольно независимы. В команде 10 человек. Каждый из них – эксперт только в одной из подсистем. Экспертность тут означает хорошее понимание ее архитектуры, используемого стека технологий, кейсов пользователей и того, как похожие проблемы решаются в других языках. Вместить в одного человека экспертность сразу в нескольких подсистемах скорее всего не получится.
Команда находится на критическом пути сразу нескольких больших проектов. Для каждого из них нужно сделать ряд изменений в нескольких подсистемах (но не всех!). Распределением задач и их координацией занимается тимлид команды. Эта схема довольно плохо масштабируется по многим причинам – начиная с бас-фактора в лице тимлида, заканчивая тем, что все проекты в одну голову загружаются довольно-таки плохо.
Как бы вы реорганизовали команду и процессы в ней, чтобы:
- Одновременно могла вестись работа сразу по нескольким проектам.
- Тимлид не был бы блокирующим звеном.
- Оставались ответственные за принятие технических решений в каждой из подсистем.
Кстати, если хотите разобрать ваш кейс, пишите мне в личку – какие-то разберу сам, а какие-то в похожем режиме вброшу в канал!
Есть команда, которая отвечает за технически сложный продукт. Скажем, за компилятор какого-нибудь языка. Под капотом компилятор состоит из нескольких отдельных подсистем, которые интегрируются друг с другом, но в целом довольно независимы. В команде 10 человек. Каждый из них – эксперт только в одной из подсистем. Экспертность тут означает хорошее понимание ее архитектуры, используемого стека технологий, кейсов пользователей и того, как похожие проблемы решаются в других языках. Вместить в одного человека экспертность сразу в нескольких подсистемах скорее всего не получится.
Команда находится на критическом пути сразу нескольких больших проектов. Для каждого из них нужно сделать ряд изменений в нескольких подсистемах (но не всех!). Распределением задач и их координацией занимается тимлид команды. Эта схема довольно плохо масштабируется по многим причинам – начиная с бас-фактора в лице тимлида, заканчивая тем, что все проекты в одну голову загружаются довольно-таки плохо.
Как бы вы реорганизовали команду и процессы в ней, чтобы:
- Одновременно могла вестись работа сразу по нескольким проектам.
- Тимлид не был бы блокирующим звеном.
- Оставались ответственные за принятие технических решений в каждой из подсистем.
Кстати, если хотите разобрать ваш кейс, пишите мне в личку – какие-то разберу сам, а какие-то в похожем режиме вброшу в канал!
Пример системы грейдов и инструкция по ее раскатке
Компании регулярно делятся своими системами грейдов. Для них это полезно тем, что кандидаты будут знать, с чем они столкнутся, еще до прихода в компанию. Для нас это полезно, чтобы подсматривать интересные идеи и учиться на чужих ошибках.
В этот раз посмотрим на систему, выросшую из принятой внутри New Relic. Несколько интересных особенностей:
🤔Внутри каждого грейда есть три категории, которые отличаются фиксированным скачком в зарплате. Такое дробление ведет к тому, что повышения можно делать чаще.
💪Основной критерий различия между грейдами – импакт инженера на компанию. Он растет с уровня задач и фичей до уровня успеха всей компании.
🤝Менеджеры – отдельная ветка. При переходе в менеджеры зарплата не меняется, но тайтл может быть «меньше» текущего инженерного. Если зарплата находится за рамками нового менеджерского грейда, ее не понизят, но и повышать какое-то время не будут.
Компании регулярно делятся своими системами грейдов. Для них это полезно тем, что кандидаты будут знать, с чем они столкнутся, еще до прихода в компанию. Для нас это полезно, чтобы подсматривать интересные идеи и учиться на чужих ошибках.
В этот раз посмотрим на систему, выросшую из принятой внутри New Relic. Несколько интересных особенностей:
🤔Внутри каждого грейда есть три категории, которые отличаются фиксированным скачком в зарплате. Такое дробление ведет к тому, что повышения можно делать чаще.
💪Основной критерий различия между грейдами – импакт инженера на компанию. Он растет с уровня задач и фичей до уровня успеха всей компании.
🤝Менеджеры – отдельная ветка. При переходе в менеджеры зарплата не меняется, но тайтл может быть «меньше» текущего инженерного. Если зарплата находится за рамками нового менеджерского грейда, ее не понизят, но и повышать какое-то время не будут.
Rubick
Jade Rubick - Implementing software engineering levels (with fully-usable examples)
Jade shares example engineering levels, that you can use to craft engineering levels at your company.
Интенсив по отстаиванию своей позиции за 15 минут
Отстаивать свою точку зрения часто бывает сложно. Такие задачи очень энергозатратны, их хочется бесконечно прокрастинировать, сложиться в клубочек и спрятаться в ванной, лишь бы только не входить в конфронтацию. Но делать это все-таки приходится. Есть много полезных приемов, которые помогают облегчить страдания и лучше донести свои мысли. Вы можете попробовать вкатиться в них с помощью Telegram-симулятора, который на примере нескольких кейсов покажет эти приемы и посоветует, как их отработать на практике.
А помимо бота, в интенсив входит подробный видео-разбор темы и методичка с теорией и всеми приемами.
👉Симулятор в боте тут
Отстаивать свою точку зрения часто бывает сложно. Такие задачи очень энергозатратны, их хочется бесконечно прокрастинировать, сложиться в клубочек и спрятаться в ванной, лишь бы только не входить в конфронтацию. Но делать это все-таки приходится. Есть много полезных приемов, которые помогают облегчить страдания и лучше донести свои мысли. Вы можете попробовать вкатиться в них с помощью Telegram-симулятора, который на примере нескольких кейсов покажет эти приемы и посоветует, как их отработать на практике.
А помимо бота, в интенсив входит подробный видео-разбор темы и методичка с теорией и всеми приемами.
👉Симулятор в боте тут
Гайд по работе с RFC
RFC – это структурированный письменный пропозал, задача которого погрузить всех заинтересованных в решаемую проблему, возможные решения и их трейдоффы. RFC могут принимать разную форму и решать разные проблемв. Мы в Kotlin очень активно их используем. Например, запрашивая у сообщества фидбэк на новые языковые фичи.
В статье разбирается, как внедрить практику RFC в инженерные команды, которым важно получать больше фидбэка еще до этапа реализации фичи.
Несколько шаблонов таких RFC:
- Google Docs
- Notion
RFC – это структурированный письменный пропозал, задача которого погрузить всех заинтересованных в решаемую проблему, возможные решения и их трейдоффы. RFC могут принимать разную форму и решать разные проблемв. Мы в Kotlin очень активно их используем. Например, запрашивая у сообщества фидбэк на новые языковые фичи.
В статье разбирается, как внедрить практику RFC в инженерные команды, которым важно получать больше фидбэка еще до этапа реализации фичи.
Несколько шаблонов таких RFC:
- Google Docs
- Notion
Всем привет от команды Nebius!
Nebius — это международный спин-офф облачного бизнеса Яндекса с офисами в нескольких странах. Они создают платформу, позволяющую другим компаниям строить собственный локальный облачный бизнес.
Их сотрудники — это команда ярких и талантливых личностей с большим опытом работы в построении и развитии публичного облака.
Вы можете стать ее частью — компания активно нанимает сотрудников в офисы в Белграде и Амстердаме.
На данный момент открыты вакансии для:
• backend-разработчиков — языки Golang, Java, Python , С++, С#
• frontend-разработчиков
• full-stack разработчиков
• technical product managers
• SRE
Полные описания можно найти на сайте.
Если подходящие вам вакансии ещё не открыты — отправьте своё резюме на [email protected]
Nebius — это международный спин-офф облачного бизнеса Яндекса с офисами в нескольких странах. Они создают платформу, позволяющую другим компаниям строить собственный локальный облачный бизнес.
Их сотрудники — это команда ярких и талантливых личностей с большим опытом работы в построении и развитии публичного облака.
Вы можете стать ее частью — компания активно нанимает сотрудников в офисы в Белграде и Амстердаме.
На данный момент открыты вакансии для:
• backend-разработчиков — языки Golang, Java, Python , С++, С#
• frontend-разработчиков
• full-stack разработчиков
• technical product managers
• SRE
Полные описания можно найти на сайте.
Если подходящие вам вакансии ещё не открыты — отправьте своё резюме на [email protected]