А если ты с коллегами и с начальником уже обсудил возможность ухода и начальство и коллеги против, то что?
Важно помнить, что никто из них не может вам запретить уйти. Вне зависимости от причины по которой они против: несогласие с вашим уходом демонстрирует их несостоятельность. Вы просто продолжаете делать так как считаете правильным: передаете контекст, пишите документацию и другое. Когда вы всё-таки уйдете им это понадобится. Если остаются силы и есть желание (!) — можете задавать им больше вопросов типа «что самое страшное случится если я уйду?». Ответы на этот вопрос покажут их страхи, а с ними можно уже работать.
А если ты точно знаешь, что твой уход развалит всю команду, то что - не уходить? Или уходить как?
Если ваш уход развалит команду, значит вы изначально что-то упустили. Но это нормально. В следующий раз вы поступите иначе. Если чувствуете, что здесь есть для вас место для роста — можно остаться. Если понятно, что в тех же условиях вы не сможете изменить подходы — уходите. Поговорите о риске распада команды с руководителем, попробуйте вместе с ним придумать план поддержки ребят. Сделайте максимум что вы можете в этой ситуации, но не жертвуйте собой. Жертвенность сделает ситуацию только хуже.
А если ты точно знаешь, что после тебя уйдут и остальные, то кому передавать дела - руководителю? А если он не технический сотрудник и не поймёт ничего?
Универсальный инструмент передачи информации и дел — документация. Ваша ответственность в том, чтобы быть готовым передать дела (в той форме, в которой это будет наиболее эффективно. не стоит записывать миллион голосовых). Ответственность компании эти дела принять и выяснить всё что ей необходимо для продолжения работы. Если со стороны компании не технический сотрудник — это решение компании.
(о божечки, я обожаю «Разделение». жду второй сезон)
Коллегам точно интересно. Для этого у нас бывают внутренние конференции от функций, отделов, подразделений, на которые может подключиться любой желающий. А еще раз в год проходит общая конфа всей разработки.
Но да, ты прав. Именно это и побудило меня в первый раз написать статью про то, что мы делаем в инфраструктурной команде. Повышение узнаваемости нашей работы помогало снижать количество велосипедов.
А про новости своего отдела -- тут зависит от того, сколько ты лет в компании и какого размера отдел :)
Да, всё так. В статье я привожу пример квартальных статей от тестировщиков. Раньше их не было, просто потому что ты и так мог дотянуться до любого конца функциональной зоны тестирования и знал все новости. Но с ростом компании, с ростом удалённых сотрудников — дайджесты для ребят стали необходимостью. Например, у мобильщиков нет дайджестов. потому что они сидят в одном пространстве :D
Хотела бы похвалить вас за виртуозную токсичность, но, к сожалению, пока только троечка с минусом. Так что есть куда расти, чтобы получить футболку! ;)
Есть такой подход в спорах, когда ты выходишь из поля темы обсуждения и пытаешься доказать человеку, что его мнение в принципе невозможно, а значит и то, что он потом говорит не имеет никакого смысла. Например, в обсуждениях на политические темы часто можно услышать «да тебе просто промыли мозги» и человек неизбежно начинает защищаться и говорить, что его источники информации правдивые и спор переходит в плоскость «а в своем ли уме вообще собеседник и стоит ли с ним что-то обсуждать?» Вы прибегли как раз к такой схеме. В самом начале своего комментария вы обесценили всю мою статью (и опыт в ней) поставив под сомнение мою роль, работу, честность. Хороший ход. Вероятно, у вас очень болит и ваш предыдущий опыт оставил неизгладимый отпечаток на картине мира. Мне остаётся вам только посочувствовать и пожелать хороших рабочих мозговых штурмов ;)
Сама я померить не могу (как минимум я такое не умею, у меня к этому нет доступа, это не моя задача), но уверена, что это возможно. Вот надеялась как раз, что у первого комментатора что-то есть, раз такое утверждение появилось.
Компании точно умеют считать затраты на одного нанятого сотрудника. Сколько стоит нанять человека, когда он 1) ничего не знает о вашей компании и 2) когда весь рынок в курсе кто вы, чем занимаетесь и какие проекты для разработчиков у вас есть.
И да, вы правы, что факторов очень много. Но я на 100% уверена, что если на старте проработать модель подсчёта, а потом на протяжении определенного времени фиксировать все необходимые показатели, то можно получить очень достоверный результат.
Результат работы деврел-отдела на самом деле измерим. Да сложно, но его можно оцифровать и оценить его влияние на улучшение техбренда компании и повышение её узнаваемости. В этом уже помогает такая роль как it hr брендер. Проводятся различные исследования узнаваемости бренда, по которым можно понять заметна ли компания для кандидатов или нет.
Не вижу чем это ослабляет мою позицию. Упоминание Эппл было для того, чтобы показать, что devrel это не новое веяние в моде. Это полноценный процесс, который существует уже довольно давно. Да, в России эта роль нова в том плане, что раньше отдельного человека или отдела под эти задачи не выделяли. Но деврельские задачи всё равно делались -- люди писали статьи, выступали с докладами, проводились встречи, конференции. Эппл -- действительно незаурядная компании. В том числе потому, что именно они создали понятие евангелизма в разработке и первыми зафиксировали это как процесс: построение комьюнити вокруг технологий, вокруг продукта. (они даже выпускали книгу https://textbookequity.org/Textbooks/Kawasaki_TheMacintoshWay.pdf)
Тут, конечно, еще важно отметить, что компании в принципе разные. Кто-то b2b, кто-то b2c а кто-то b2d. Все они работают по разному. У всех у них разная стартовая позиция при входе в айти-сообщество (b2b, например, может быть сложнее, чем b2c просто потому что первыми пользуются компании, а не рядовые ребята, которые по совместительству могут оказаться разработчиками и потенциальными кандидатами).
Еще важно отметить, что не всем компаниям нужна выделенная роль или отдел. Не всем компаниям нужен полный ассортимент деврельских задач. Если ты маленькая компания, которая без труда закрывает ставки и текучка, в которой минимальна, то выход наружу это скорее возможность для сотрудника транслировать свою экспертизу, если хочется. Но если ты крупная компания, которая быстро растёт и которой нужно обеспечить себе непрерывный поток квалифицированных специалистов, тебе нужно создать и регулярно подтверждать в сообществе образ желанной компании, которая первая приходит на ум при смене работы.
Если тема DevRel интересна вам чуть глубже, то я порекомендую книги:
Developer Relations. How To Build And Grow A Successful Developer Program
Хотела бы не благодарить, но не могу! Такой чудесный комментарий :) Спасибо!
Супер интересно посмотреть и почитать про «Нет значимых экономических преимуществ у компаний с DevRel перед компаниями без такового. По крайней мере, это не отражается на прибылях и уровне банкротств.» С удовольствием ознакомлюсь с этой информацией. Потому что по тому, что я вижу -- всё совсем наоборот. Ну и стоит ли упоминать, что деврельство зародилось довольно давно и не где-то там, а в компании Apple :)
Важно помнить, что никто из них не может вам запретить уйти. Вне зависимости от причины по которой они против: несогласие с вашим уходом демонстрирует их несостоятельность. Вы просто продолжаете делать так как считаете правильным: передаете контекст, пишите документацию и другое. Когда вы всё-таки уйдете им это понадобится. Если остаются силы и есть желание (!) — можете задавать им больше вопросов типа «что самое страшное случится если я уйду?». Ответы на этот вопрос покажут их страхи, а с ними можно уже работать.
Если ваш уход развалит команду, значит вы изначально что-то упустили. Но это нормально. В следующий раз вы поступите иначе. Если чувствуете, что здесь есть для вас место для роста — можно остаться. Если понятно, что в тех же условиях вы не сможете изменить подходы — уходите. Поговорите о риске распада команды с руководителем, попробуйте вместе с ним придумать план поддержки ребят. Сделайте максимум что вы можете в этой ситуации, но не жертвуйте собой. Жертвенность сделает ситуацию только хуже.
Универсальный инструмент передачи информации и дел — документация. Ваша ответственность в том, чтобы быть готовым передать дела (в той форме, в которой это будет наиболее эффективно. не стоит записывать миллион голосовых). Ответственность компании эти дела принять и выяснить всё что ей необходимо для продолжения работы. Если со стороны компании не технический сотрудник — это решение компании.
Ты как будто первый раз на Хабре ахаха :D
Спасибо! Пожалуй напишу статью про то как собираю команду :)
Привет! Принесла вам новые даты и ссылку на лендинг нашей конференции :) 22 августа онлайн, 24 офлайн в Екатеринбурге.
(о божечки, я обожаю «Разделение». жду второй сезон)
Коллегам точно интересно. Для этого у нас бывают внутренние конференции от функций, отделов, подразделений, на которые может подключиться любой желающий. А еще раз в год проходит общая конфа всей разработки.
Но да, ты прав. Именно это и побудило меня в первый раз написать статью про то, что мы делаем в инфраструктурной команде. Повышение узнаваемости нашей работы помогало снижать количество велосипедов.
А про новости своего отдела -- тут зависит от того, сколько ты лет в компании и какого размера отдел :)
Да, всё так. В статье я привожу пример квартальных статей от тестировщиков. Раньше их не было, просто потому что ты и так мог дотянуться до любого конца функциональной зоны тестирования и знал все новости. Но с ростом компании, с ростом удалённых сотрудников — дайджесты для ребят стали необходимостью. Например, у мобильщиков нет дайджестов. потому что они сидят в одном пространстве :D
Хотела бы похвалить вас за виртуозную токсичность, но, к сожалению, пока только троечка с минусом. Так что есть куда расти, чтобы получить футболку! ;)
Есть такой подход в спорах, когда ты выходишь из поля темы обсуждения и пытаешься доказать человеку, что его мнение в принципе невозможно, а значит и то, что он потом говорит не имеет никакого смысла. Например, в обсуждениях на политические темы часто можно услышать «да тебе просто промыли мозги» и человек неизбежно начинает защищаться и говорить, что его источники информации правдивые и спор переходит в плоскость «а в своем ли уме вообще собеседник и стоит ли с ним что-то обсуждать?» Вы прибегли как раз к такой схеме. В самом начале своего комментария вы обесценили всю мою статью (и опыт в ней) поставив под сомнение мою роль, работу, честность. Хороший ход. Вероятно, у вас очень болит и ваш предыдущий опыт оставил неизгладимый отпечаток на картине мира. Мне остаётся вам только посочувствовать и пожелать хороших рабочих мозговых штурмов ;)
❤️
Хмммм. Не заметила где я агитирую за деврел.
Про информацию и исследования
Сама я померить не могу (как минимум я такое не умею, у меня к этому нет доступа, это не моя задача), но уверена, что это возможно. Вот надеялась как раз, что у первого комментатора что-то есть, раз такое утверждение появилось.
Компании точно умеют считать затраты на одного нанятого сотрудника. Сколько стоит нанять человека, когда он 1) ничего не знает о вашей компании и 2) когда весь рынок в курсе кто вы, чем занимаетесь и какие проекты для разработчиков у вас есть.
И да, вы правы, что факторов очень много. Но я на 100% уверена, что если на старте проработать модель подсчёта, а потом на протяжении определенного времени фиксировать все необходимые показатели, то можно получить очень достоверный результат.
Результат работы деврел-отдела на самом деле измерим. Да сложно, но его можно оцифровать и оценить его влияние на улучшение техбренда компании и повышение её узнаваемости. В этом уже помогает такая роль как it hr брендер. Проводятся различные исследования узнаваемости бренда, по которым можно понять заметна ли компания для кандидатов или нет.
«Потому что по тому, что я вижу -- всё совсем наоборот» -- я вижу рост сферы, в которой работаю. Вижу увеличение количества вакансий и спрос на профессионалов в этой сфере. Кроме этого есть исследование от Жени Голевой, которое это подтверждает https://tproger.ru/articles/devrel-komandy-sokrashhayutsya-raswiryayutsya-ili-kachestvenno-evolyucioniruyut
Про апеллирование к компании Эппл.
Не вижу чем это ослабляет мою позицию. Упоминание Эппл было для того, чтобы показать, что devrel это не новое веяние в моде. Это полноценный процесс, который существует уже довольно давно. Да, в России эта роль нова в том плане, что раньше отдельного человека или отдела под эти задачи не выделяли. Но деврельские задачи всё равно делались -- люди писали статьи, выступали с докладами, проводились встречи, конференции. Эппл -- действительно незаурядная компании. В том числе потому, что именно они создали понятие евангелизма в разработке и первыми зафиксировали это как процесс: построение комьюнити вокруг технологий, вокруг продукта. (они даже выпускали книгу https://textbookequity.org/Textbooks/Kawasaki_TheMacintoshWay.pdf)
Тут, конечно, еще важно отметить, что компании в принципе разные. Кто-то b2b, кто-то b2c а кто-то b2d. Все они работают по разному. У всех у них разная стартовая позиция при входе в айти-сообщество (b2b, например, может быть сложнее, чем b2c просто потому что первыми пользуются компании, а не рядовые ребята, которые по совместительству могут оказаться разработчиками и потенциальными кандидатами).
Еще важно отметить, что не всем компаниям нужна выделенная роль или отдел. Не всем компаниям нужен полный ассортимент деврельских задач. Если ты маленькая компания, которая без труда закрывает ставки и текучка, в которой минимальна, то выход наружу это скорее возможность для сотрудника транслировать свою экспертизу, если хочется. Но если ты крупная компания, которая быстро растёт и которой нужно обеспечить себе непрерывный поток квалифицированных специалистов, тебе нужно создать и регулярно подтверждать в сообществе образ желанной компании, которая первая приходит на ум при смене работы.
Если тема DevRel интересна вам чуть глубже, то я порекомендую книги:
Developer Relations. How To Build And Grow A Successful Developer Program
The Business Value of Developer Relations
Хотела бы не благодарить, но не могу! Такой чудесный комментарий :) Спасибо!
Супер интересно посмотреть и почитать про «Нет значимых экономических преимуществ у компаний с DevRel перед компаниями без такового. По крайней мере, это не отражается на прибылях и уровне банкротств.» С удовольствием ознакомлюсь с этой информацией. Потому что по тому, что я вижу -- всё совсем наоборот. Ну и стоит ли упоминать, что деврельство зародилось довольно давно и не где-то там, а в компании Apple :)