К основному контенту

Как Google от менеджеров пытался отказаться

На самом деле про попытку отказа от менеджеров я узнал раскручивая попавшуюся на глаза историю про проект Oxygen.
История на самом деле давняя, берет свое начало аж в 2002 году. Лари Пейдж и Сергей Брин решили, что менеджеры только мешают быстрой разработке, и решили их попробовать без них. Эксперимент закончился через несколько месяцев: число страждущих порешать проблемы напрямую через Пейджа (а другого способа не было) превысило его пропускную способность :)

В итоге менеджеров вернули, потому что они все-таки приносили пользу: помощь в приоритезации проектов, фасилитации взаимодействия, поддержка в карьере сотрудников и направление процессов и систем в соответствии с целями компании.

Но вопрос в том, как понять, какой менеджер полезен, а какой так себе. В 2009 (по другим источникам в 2008) Google запустил проект Oxygen, целью которого стал ответ на вопросы "Зачем нужны менеджеры и какие". Вылилось это в исследование с анализом работы более 10000 менеджеров по 100 параметрам, на основе оценки их работы, обратной связи от сотрудников (пример такого фидбека можно посмотреть в этой статье) и других отчетов.

В 2012 результаты опубликовали:
A good manager (переводить не буду, кому надо пояснения, тому сюда):
  1. Is a good coach
  2. Empowers the team and does not micromanage 
  3. Expresses interest in and concern for team members’ success and personal well-being
  4. Is productive and results-oriented
  5. Is a good communicator—listens and shares information
  6. Helps with career development
  7. Has a clear vision and strategy for the team
  8. Has key technical skills that help him or her advise the team
Позже в этот список добавили еще 2 пункта, а два обновили:
  1. Is a good coach
  2. Empowers team and does not micromanage
  3. Creates an inclusive team environment, showing concern for success and well-being
  4. Is productive and results-oriented
  5. Is a good communicator — listens and shares information
  6. Supports career development and discusses performance
  7. Has a clear vision/strategy for the team
  8. Has key technical skills to help advise the team
  9. Collaborates across Google
  10. Is a strong decision maker
оригинал тут https://www.impraise.com/blog/google-project-oxygen-revisited-what-it-takes-to-be-a-great-manager
На основе проведенного анализа Google начал проводить регулярное обучение для всех менеджеров. Что про него думали менеджеры Гугла?
Вот отрывок отсюда
Managers have expressed few concerns about signing up for the courses and going public with the changes they need to make. Eric Clayberg, for one, has found his training invaluable. A seasoned software-engineering manager and serial entrepreneur, Clayberg had led teams for 18 years before Google bought his latest start-up. But he feels he learned more about management in six months of Oxygen surveys and people ops courses than in the previous two decades. “For instance,” he says, “I was worried about the flat organizational structure at Google; I knew it would be hard to help people on my team get promoted. I learned in the classes about how to provide career development beyond promotions. I now spend a third to half my time looking for ways to help my team members grow.” And to his surprise, his reports have welcomed his advice. “Engineers hate being micromanaged on the technical side,” he observes, “but they love being closely managed on the career side.

В общем, интересная тема, есть над чем подумать и порефлексировать. У меня список неполный получился в 2014 году :)

Источники для почитать самому:
Для самообразования и рефлексии, серия видео про то как стать/быть менеджером от Стратоплан
«Как стать & Как быть менеджером»: А. Орлов
«Как стать & Как быть менеджером»: М. Завилейский
«Как стать & Как быть менеджером»: Олег М. Вайнберг

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

(Яндекс/Гугл, перестаньте выдавать ее в выдаче) План "Б" или как прикольно провести субботний день

Отступление: название заметки так зашло в ожидания SEO, что люди уже 11 лет сюда по результатам поиска заходят 😂. Простите, но тут не про то как тусануть и было уже давно. Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? отве