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

Как 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. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

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

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