­­­Работа в команде: чему я научилась за шесть лет в разработке продуктов

Меня зовут Маша Шевченко, я занимаюсь созданием и развитием продуктов в компании SoftServe. 85% времени в моем календаре забронировано встречами с людьми. Я не организационный коуч, психотерапевт или HR-специалист. Я — продакт.

Календарь продакта.jpg

Свой путь в IT я начинала со стартапа, потом была продуктовая компания, и сейчас я в аутсорсе. Было огромное количество разных форматов отношений с людьми, разных процессов и ситуаций. Этот опыт дает мне возможность смотреть на тему работы в команде с разных углов и точек зрения.

В компании, где я работаю сейчас, часто говорят, что software development — это «people’s business». Мне близка эта мысль, ведь абсолютно все, что мы делаем вне зависимости от домена, бизнес-модели и масштаба — о людях.

  • С точки зрения адреса поставляемой ценности — чью проблему мы закрываем? Кто наша персона?
  • С точки зрения процесса создания той самой ценности — как именно мы закрываем эту проблему? Какое решение и какие процессы стоят за этим?

Поговорим о втором — о составляющих работы с людьми для создания ценных решений. О принципах, которые помогут спать по ночам спокойно, быть уверенным в высоком eNPS и в том, что где-нибудь возле кулера (ок, на смолтоке в зуме) вас как тимлида\менеджера не проклинают.

Мы обсудим ценности и культуру, прозрачность, обратную связь, психологическую безопасность, доверие и право на ошибку. Ведь они касаются всех участников процесса создания продуктов — менеджеров, инженеров, тимлидов и владельцев бизнеса.

Бонус-треком в конце каждого блока предлагаю вам «вопросы на подумать» за вином\чаем или на пробежке.

Ценности и культура

Первым пунктом выношу то, что очень часто нельзя потрогать руками, измерить в простых понятных метриках и показать в качестве достижения на 20-м слайде в вашей квартальной отчетной презентации.

Культура и ценности компании, в которой вы работаете, — это обо всем сразу. О коммуникации и tone of voice, который вы используете на дейли или когда вас принимают на работу. О заботе вашей команды в случае неприятных ситуаций и\или болезни. Об искренней радости за ваши успехи за пределами работы. О тактичности и толерантности вне зависимости от возраста, пола, национальности, языка общения или языка программирования.

Культура и ценности для меня — это быть частью чего-то большого и кайфового, зная, как именно ты полезен для бизнеса, и зная, что тебя здесь ценят. Это основа и гигиенический минимум. Это то, что нельзя потрогать, но можно ощутить. Мне повезло работать в компании, где культура и ценности — не пустые слова.

Я люблю аналогию со строительством дома: от того, какого качества фундамент вы заложите, будет зависеть будущее вашего дома, и как долго он прослужит. Так и здесь — не имея базы из культуры и ценностей, вы обречены на недолгосрочные отношения и высокий показатель оттока сотрудников.

Что такое «культура» для вас конкретно?

Считаете ли вы культуру вашей компании своей культурой?

Руководствуетесь ли вы какими-либо принципами на работе?

Откуда они у вас возникли?

Нравятся ли вам принципы вашей компании?

Подходят ли они вам и почему?

Прозрачность

А — информация о результатах компании, прибыльности бизнеса, P&L, целях, кешфлоу, акционерах и т.д.

Здесь все просто — если люди не знают о финансовой динамике своего работодателя, они начинают самостоятельно придумывать факты, которые могут быть очень далеки от истины.

«Мне кажется, что моя компания сейчас в полной заднице, потому что я видела, в каком плохом настроении был CFO на звонке» или «У нашего топ-менеджера новый BMW — думаю, мы на подъеме, и можно просить повышение». Обе ситуации могут быть супер обманчивы: CFO плохо спал после вечеринки (ну например), и в компании все на самом деле on track, а новый BMW, оказывается, взят в кредит, а дела идут совсем не так, как хотелось бы.

Прокоммуницируйте о компании то, что считаете нужным, иначе люди додумают сами то, что считают нужным они. Нет основания предполагать, что ваша команда будет доверять вам и выкладываться на 100%, если вы ей не доверяете и не делитесь ключевыми показателями успешности. Как и в отношениях между людьми — it takes two to tango.

Б — информация о процессах

Я знаю парней, которые знают парней ©, которым замена монитора на рабочем месте в одной украинской IT-компании стоила двух месяцев переписок по почте с более чем 30 разными участниками. Человек пытался решить очень простой вопрос так, как умел и мог, но в результате его отправляли от одного к другому почти два месяца подряд. В результате человек монитор получил. И уволился :)

Прозрачность в процессах касается всего: собеседования, онбординга, решения вопросов с бухгалтерией, отпуска, больничного, вашей техники, канцелярии, корпоративного обучения или performance appraisal.

Может показаться, что инвестиции в дизайн и имплементацию стройных процессов не оправданы, ведь «ну и так вроде как-то все работает норм». Здесь уже вопрос целей и качества — вам и вашим клиентам нужны топовые решения и блестящая репутация, или вашим клиентам нужны решения, которые «ну вроде норм»?

Понимаете ли вы, насколько финансово успешна ваша компания?

Довольны ли вы детализацией этой информации?

Считаете ли вы ваши процессы прозрачными?

Какие признаки для вас в первую очередь говорят об отсутствии прозрачности в компании?

Система обратной связи

К большому счастью (или к сожалению), люди еще не научились читать мысли друг друга. И пока нам остается помнить, что мы не живем и работаем в вакууме. Что нам для роста и развития надо понимать, куда именно нам расти и развиваться. И нет лучшего способа это понять, чем обратная связь от людей, которые вас окружают.

Я совершала много ошибок, но хочу подчеркнуть одну из самых неприятных — я боялась запрашивать обратную связь по себе. Причина была (и отчасти остается) в моей неуверенности в себе и непонимании вклада в «общее дело». Этот момент связан с тем, что у продакт-менеджера часто нет прямого и осязаемого результата работы (идеально подходит слово «deliverable»). Мы строим процессы, создаем смыслы и ценности, которые нельзя потрогать. В отличие, например, от дизайнера или инженера, которые получают прототип или код на продакшене в конце итерации работы.

Вернемся к обратной связи. Если вы недовольны человеком\его поступком\реакцией\поведением, то спросите себя — что вы сделали, чтобы он узнал об этом? Есть случаи, когда люди понимают, что делают дичь, но продолжают ее делать осознанно. Я о другом — в своем большинстве люди могут попросту не понимать этого. Человеку надо сказать, что он делает дичь, и объяснить, как можно исправить ситуацию. Здесь без серьезной обоймы софт скилов не обойтись, ведь есть риск ранить, обидеть и демотивировать неправильно построенным разговором или неуместной лексикой. Точно так же с запросом обратной связи по себе — как вы поймете, что двигаетесь в правильном направлении, если не спросите?

Навык давать и запрашивать обратную связь — абсолютный маст хэв для эффективного взаимодействия в команде. А что касается встреч «121» — так это вообще отдельная тема.

Кстати, отличные материалы о «121» могу порекомендовать по мотивам воркшопа Димы Миндры из Граммарли. А об искусстве обратной связи (общие принципы и концепт «бутерброда») — лекция Татьяны Петрухи.

Когда последний раз вы давали обратную связь своей команде?

Кто был инициатором?

Была она только со знаком «минус» или и со знаком «плюс»?

Когда и у кого вы запрашивали обратную связь по себе? Что стало триггером? Что стало результатом?

Существует ли у вас фреймворк, который используется для «121»-встреч? Готовитесь ли вы к ним?

Но здесь хочу дополнить, что не вся обратная связь, которую вы получаете по себе, вам на самом деле нужна. Только вам принимать решение, что из нее использовать, а что — нет. Ведь это просто субъективная точка зрения, а не план действий. Для меня критериями go\no go являются:

  • Я запросила эту обратную связь или человек сам поделился?
  • Насколько ее автор является экспертом в теме вопроса \ в материале?

Психологическая безопасность

Вы можете быть успешными на рынке как бизнес, поднимать раунд за раундом, пополнять портфолио кейсами из списка Fortune 100, но какой в этом толк, если ваш инженер плачет боится попросить о повышении?

Создание и поддержка атмосферы психологической безопасности зачастую лежит на плечах HR-отдела и, в основном, начинается и заканчивается парочкой не самых интересных тренингов. От сложноподчиненных концепций до комфортного микроклимата в команде — миллионы крошечных шагов, улучшений и бесед. Но самое главное — поступков. В первую очередь ваших как менеджера\лида.

Нет ничего хуже, чем слушать о высокоморальных принципах утром, а вечером видеть, как эти же принципы превращаются в пыль вашим топ-менеджментом. Eat what you pray, как говорит моя тимлид.

По этому поводу у меня была личная история, иллюстрирующая, какая на самом деле может быть (и должна быть имхо) атмосфера психологической безопасности.

В период моего первого в жизни депрессивного эпизода в один из дней на работе перед очередным звонком я разревелась. Ну так, по-взрослому, знаете. Пишу коллегам, с которыми звонок, что many sorries но я не могу говорить. Что мне жить тут почти получается, а говорить и решать вопросы я точно не могу. Звонок и повод для звонка были действительно важными и срочными, и я ожидала услышать сухое «ок» или что-то вроде того. Но я получила мощную поддержку и услышала: «Маш, как я могу тебе помочь сейчас? Что я могу сделать? Даже не думай о работе, береги себя и возьми столько времени на решение твоих проблем, сколько понадобится».

Я прочла это и расплакалась еще больше. Но в этот раз уже от того, что, оказывается, ТАК МОЖНО БЫЛО <3.

Существует множество техник и приемов для создания атмосферы психологической безопасности, но универсальных рецептов нет. И если у стартапа из 50 человек получилось создать кайфовый экологичный микроклимат в команде благодаря подходу X, то это совсем не значит, что в вашем случае продуктовой команды из 500 человек этот метод X будет уместен и эффективен.

Не так важно, какой метод вы выберете. Важно — делаете ли вы это с любовью, заботой и уважением к людям.

Чувствуете ли вы себя в безопасности на работе?

Как это — чувствовать себя в безопасности?

Что влияет на это состояние?

Как вы можете его изменять?

Влияете ли вы на микроклимат в вашей команде?

Что портит его, а что — улучшает?

Доверие

Где-то мелькала мысль, что валюта нашего времени — это человеческое внимание. Не соглашусь, потому что считаю главной валютой нашего времени доверие. Его часто так непросто завоевать и настолько легко растерять, что не ценить по-настоящему доверительные отношения на работе сочту дурным тоном.

Для меня доверие начинается с фразы «я уверен в тебе и в твоей экспертизе, делай, как считаешь нужным». Сказанная вовремя, в нужном месте и авторитетным для тебя человеком, эта фраза может окрылить на полгода вперед. Дать невероятный толчок для развития и сумасшедшую мотивацию колбасить так, что есть шанс свернуть горы. Или даже немножко больше.

Делегирование является ярким примером «прокаченности» уровня доверия в команде. Персонально для меня делегирование — это тот еще челлендж, и я работаю над этим. Но именно по тому, делегирует ли топ-менеджмент не только work-to-be-done, но и decision-making процесс, можно судить об уровне доверия в команде или в компании. Делегирование — это рост, это масштабирование и развитие. Команда в целом и конкретный человек в частности не смогут стать быстрее\выше\сильнее, если им не дать такую возможность.

Безусловно, делегирование и доверие имеет свой флипсайд, и топ-менеджмент часто расплачивается за ошибки своих людей. В этом и есть одновременно сложность и магия быть лидером.

По этой теме могу порекомендовать пятимодульный курс от Миши Нестора. Он возник на основании воркшопа, который я сама прошла и осталась довольна (нет, мне не платили за рекламу).

Доверяете ли вы своей команде?

Как вы это понимаете?

Когда вы не готовы доверять людям в своей команде, а когда — готовы?

Что на это влияет?

Как вы поступаете, если человек не оправдал ваше доверие?

Право на ошибку

Обожаю фразу: «We are our failures».

Право на ошибку — это базовый принцип не только на работе, но и в жизни.

Говоря об ошибках на работе, важно определить, что именно значит «ошибка» для вас и вашей команды? Какие у нее характеристики, и как человек понимает, что он совершил ошибку? Разумеется, есть ситуации, когда прилетает от менеджмента или от клиента, и тут уже не до лексических тонкостей и словесных оборотов. Но мы о «мирном времени».

Слова имеют большое значение, и если задуматься о том, что часто разные незапланированные ситуации на работе ошибками не являются (а являются дежурной подгорающей историей с определенным уровнем вероятности и последствий), то стоит задать себе вопрос — а зачем мы вообще употребляем слово «ошибка»? Чтобы указать на несовершенство решения? Чтобы акцентировать свое превосходство в определенном вопросе? Чтобы доказать свою правоту?

По моему мнению, это о рисках и грамотной с ними работе.

Нанимая джуна на лид-позицию, мы принимаем риски того, что человек, возможно, не вытащит весь объем задач. Это ошибка?

Выкатывая костыльное решение для проверки одной из гипотез продукта мы принимаем риски того, что будут вопросы к архитектуре и пользовательскому опыту. Но гипотезу мы проверим. А это можно считать ошибкой?

В моем мире я называю это уроками. И здесь важно понять, готовы ли мы сейчас проходить такие уроки. Есть ли у нас ресурс для этого? И, в конце концов, чему нас эти уроки должны научить? Ведь у каждой такой «ошибки» своя цена и свои последствия. Как short-term, так и long-term.

А еще важно давать право на ошибку не только своей команде, но и себе. Как показывает опыт общения с коллегами с украинского IT, это является одной из самых больных точек для многих. Не давать себе возможности ошибиться \ оступиться — значит приговаривать себя к постоянной борьбе с перфекционизмом. А это такая себе история, потому что, напомню, perfect is the enemy of good. И часто намного больше нам нужны сделанные неидеальные решения СЕЙЧАС, чем идеальные ПОТОМ. У меня самой (как и у многих из вас, я знаю точно!) существует инстинкт отличницы.

Но об этом я буду чирикать со своим психотерапевтом :)

Резюмируя, хочется еще раз отметить важность не только профессиональных прикладных навыков для создания решений, но и принципов работы с людьми. First things first — начинайте с ценностей вашей компании и транслируйте их в команды. Так вы заложите надежный фундамент взаимоотношений. Создавайте прозрачные процессы и делитесь с вашими тиммейтами финансовыми успехами компании — вы же ведь все за одно. Выделяйте время на обратную связь в обе стороны. Только давать ее и не получать взамен — неэффективно и бессмысленно. Старайтесь создавать атмосферу психологической безопасности и доверия для всех людей, с которыми работаете. Потому что только такие команды могут играть в долгую. А ведь мы все именно к этому стремимся. Не так ли?

Вместо эпилога

Планируя этот материал, я хотела написать еще о своих персональных ошибках в работе с людьми, о специфике взаимодействия с разными функциональными направлениями (дизайн \ разработка \ аналитика \ топ-менеджмент), о важности неформального общения вне работы с коллегами, но эта статья получилась бы слишком большой.

Поэтому если вам интересно продолжение — дайте мне об этом знать в комментариях или в личке.

👍НравитсяПонравилось8
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Зворотній фідбек і файна корпоративна культура грають ще ту важливу роль.

Спасибо за такую интересную тему и статью. У меня к вам 2 вопроса
1. при наличии графика в значительной степени состоящего из встреч — как у вас обстоят дела с переработками? ну то есть же какие-то задачи которые требуют у вас самостоятельной работы и их получается надо делать вне этого графика?
2. до вашей статьи я верил в то что успешный РО может быть и немного интровертом. Сейчас сомневаюсь. Насколько важно постоянное и активное взаимодействие с множеством людей чтобы развивать продукт?

1. дела с овертаймами сейчас обстоят норм, но я к этому пришла через годы и часы овертаймов. удивительным образом грамотная приоритезация и режим «телефон экраном вниз и кобласишь» помогают избежать любой ненужной работы)
2. отвечу вопросом на вопрос — а насколько важно крутить педали если едешь на велосипеде? коммуникация — скилл № 1 для продакта имхо

2. не всегда надо крутить педали велосипеда, не постоянно. Даже если гонка.

Маша, дякую дуже. Заінтригувала, чекаю на продовження)

Стаття виглядає як реклама

Я — продакт

всегда люто горю с этого перевода/сокращения

Создание и поддержка атмосферы психологической безопасности

я бы сказал что это создание иллюзии, нужно понимать что нигде и никогда нет полной безопасности.

соглашусь относительно того, что никогда и нигде нет 100% безопасности. но ведь я говорю не об идеальном мире, а о том, что всегда надо стремиться к созданию *максимально близкой* к идеальной.

Крутая статья! Очень интересно почитать продолжение

И часто намного больше нам нужны сделанные неидеальные решения СЕЙЧАС, чем идеальные ПОТОМ.

Это типичный конфликт интересов у продакта — его не интересует цикл разработки, перспективы, технический долг, его дело выдать «продукт» любой ценой, получить премию и продолжить дальнейшее разрушение компании. У многих soft/hard компаний продакты оторваны от разработки и не имеют права на неё влиять. Работу продакта можно описать только как partner with engineering, sales, marketing, business development, and other teams. Другими словами — всё и ничего толком ©

Это обобщенное описание продакт-менеджера курильщика. Продакт-менеджер здорового человека обязан и интересуется (это лишь малая толика его обязанностей) и если он этим не занимается — он кто угодно по должности, но не продакт-менеджер =):

  • SDLC aka цикла разработки — иногда синтезируя собственные модели и постоянно настраивая существующие в зависимости от фазы, цикла, домена, обстоятельств, размера команды, требований и прочее
  • Vision/strategy/goals/objectives aka перспективы — это его ежедневная обязанность продакт-менеджера, формировать, измерять, отслеживать и корректировать курс разработки продукта
  • Maintenance backlog aka технический долг — также часть работы продакта балансировать чтобы убедиться что с одной стороны появляется новая функциональность (что-то же должно драйвать прибыль и расширять клиентскую базу, правда?), а с другой стороны — что существующее качество находится под контролем
его дело выдать «продукт» любой ценой, получить премию и продолжить дальнейшее разрушение компании.

это притянутое за уши токсичное описание деструктивного характера и, скорее всего, какого-то частного случая, и мне жаль что ваш опыт сотрудничества с продакт-менеджерами может быть обобщен только таким образом. Об этом утверждает как статистика зарплатная, пример: www.levels.fyi/company/Google/salaries (зарабатывают много но не существенно чем другие специалисты) так и здравый смысл, иначе просто быть не может, если бы все шло к разрушению, с чего бы индустрия испытывала постоянный рост?

У многих soft/hard компаний продакты оторваны от разработки и не имеют права на неё влиять.

можно ли увидеть какие-то данные или статистику или ресурс где бы это можно было бы проверить? у меня сложилось кардинально противоположное мнение из личного опыта и общения с продакт-менеджерами.

Работу продакта можно описать только как partner with engineering, sales, marketing, business development, and other teams.

можно ли поинтересоваться что является источником такого скупого описания обязанностей, с личного опыта, а также из ряда источников профессиональной литературы утверждается обратное, примеры: Steven Haines, Gayle McDowell, Jackie Bavaro, Marty Cagan, Michael Porter, Michael Porter, Clayton Christensen.

Спасибо!

Продакт-менеджер здорового человека обязан и интересуется (это лишь малая толика его обязанностей) и если он этим не занимается — он кто угодно по должности, но не продакт-менеджер

Всё равно не ясно зачем они нужны. Простое размазывание обязанностей и перетягивание одеяла у менеджеров напрямую связанных с разработкой.

можно ли увидеть какие-то данные или статистику или ресурс где бы это можно было бы проверить? у меня сложилось кардинально противоположное мнение из личного опыта и общения с продакт-менеджерами.

Только работая в топовых продуктовых компаниях можно получить такие данные.

можно ли поинтересоваться что является источником такого скупого описания обязанностей, с личного опыта, а также из ряда источников профессиональной литературы утверждается обратное, примеры: Steven Haines, Gayle McDowell, Jackie Bavaro, Marty Cagan, Michael Porter, Michael Porter, Clayton Christensen.

Наверное Google их не читал %)
careers.google.com/...​_FR&jid=182715001&page=10

А вообще это типичная калька обязанностей продакта.

Всё равно не ясно зачем они нужны. Простое размазывание обязанностей и перетягивание одеяла у менеджеров напрямую связанных с разработкой.
А вообще это типичная калька обязанностей продакта.

Вот пример того как выглядит (или он к этому стремиться) Product Management в нормальной продуктовой компании:

  • Responsibilities — описаны в правом нижнем углу разделенные по фазам продуктового цикла, Product Lifecycle
  • Components — грубо говоря работу можно разделить на 4 составляющие: Product, Execution, Strategy, Leadership — справа, Product Management
  • Books — если интересно, посредине
  • Artefacts — то, что в идеале должен подготавливать продакт, но это далеко не все, слева, Product Management Artefacts
  • Frameworks — инструментарий, которым он/она должны владеть, вверху Frameworks

Спасибо!

Вот пример того как выглядит (или он к этому стремиться) Product Management в нормальной продуктовой компании:

Нормальная продуктовая — это какая? SoftServe позиционирует себя как Engineering Services, что и написано на сайте. И среди Engineering Services есть сервис Product Management (который ну никакак не часть Engineering Services(!!!)):

SoftServe’s manages the entire product development process from ideation to end user testing. Using design thinking methodology, we lead our clients in: envisioning an ideal solution, validating design through prototyping, developing and implementing innovation, and optimizing for increased sustainability.

Это очень сильно не то, что делает product manager в продуктовых и продуктово-сервисных компаниях.

Нормальная продуктовая — это какая? SoftServe позиционирует себя...

а это уже переход на личности с тонким намеком)) на то, что я описываю продакта аутсорсинговой компании. Конечно же, если интересно как выглядит конкретно мой карьерный путь, сюда пожалуйста.
=)

я описываю продакта аутсорсинговой компании

так продакт — он на стороне владельца продукта
конечно, полезно чтобы его заместитель был на стороне исполнителя, если владелец и исполнитель — разные бизнес субъекты

Презентация специально сделана так, чтобы после третьего слайда начинало тошнить от круговорота и дальше никто не читал?

За вашим посиланням підверджуються слова Mykola Kotliarenko

Нет

Вообще ваше дополнение действительно указывает на «размазывание обязанностей и перетягивание одеяла»

Чтобы выкристолизовать основную бизнес-функцию роли — нужно убрать все, без чего роль останется нужной=уникальной

Например можно начать с определения
Продакт-менеджер
что в нем подразумевается под «продакт» и что он менеджит?

SDLC aka цикла разработки

не, это функция проджект менеджеров. они менеджат ход проекта.

Maintenance backlog aka технический долг

не, это тоже есть кому менеджить. например в фразе «технический долг» уже намекается прилагательным — кто, какие специалисты обязаны его, долг этот технический — оценить, и держать под контролем, выбирая соответствующие технические решения

Vision/strategy/goals/objectives aka перспективы — это его ежедневная обязанность продакт-менеджера, формировать, измерять, отслеживать и корректировать курс разработки продукта

о, это уже выглядит уникальным. кто-то в проекте должен отвечать, знать набор фичей, их бизнес-ценность, и получая информацию от проджект-менеджеров, технарей, «маркетинга» и заинтересованных стейкхолдеров — сводить ее в — продукт. то есть цельное и формальное описание конечного результата, его атрибутов и характеристик.
нередко эту функцию берут на себя проджект менеджеры. когда продакта на проекте нет. хотя, когда продакта на проекте нет, эту функцию бывает берут на себя и ведущие разработчики, тех. лиды с архитектами.

все остальное что вы написали — не продакта ума дело. или он тогда «в каждой бочке затычка», с явно размытой зоной ответственности.

«в каждой бочке затычка», с явно размытой зоной ответственности.

это экзальтированно-упрощенное описание моих должностных инструкций =))

я и не отрицаю что нередко бывает такая роль:
«В каждой бочке затычка» и выписана должностная инструкция под нее, и штатная единица утверждена приказом по предприятию.
Название конечно дается какое-то покрасивее конечно :)

На одной моей прошлой работе я не знал как зовут моего product manager, потому что они менялись чаще 2 раз в год и было сложно запомнить их имена. Приход, месяц онбоардинга, месяц эйфории, 3 месяца, чтоб понять, что product manager в этой организации не имеют ни полномочий ни прав, месяц на собеседования.

Самое страшное для продакта — это заболеть или уйти в длинный отпуск, тогда всем слишком очевидно становится что и без пятого колеса телега продолжает нормально ехать.

Я не спал пять лет и у меня под глазами мешки
Я сам не видел (Но мне так сказали)

Я — продакт

И у меня нет башки
......

©

Обожаю фразу: «We are our failures».

Право на ошибку — это базовый принцип не только на работе, но и в жизни.

удачи мучаться каждый год))))))

особенно после 50. я сейчас как раз наблюдаю, людей в конце жизни. они ошибались и довольно часто. и даже детям не нужны, ближе к 60.

Но ты-то никогда не ошибаешься. В отличие от старичков Даннинга и Крюгера.

Когда вы не готовы доверять людям в своей команде, а когда — готовы?

„Leadership is about recognizing that there’s a greatness in everyone, and your job is to create an environment where that greatness can emerge.”
Bill Campbell

А какие продукты? Продовольственные или хоз товары?

Подписаться на комментарии