«900 продуктовиков из местного Linkedin делите на 10». PandaDoc затеяла трансформацию

dev.by поговорил с VP of Engineering в PandaDoc Ильёй Казимировским и Director of Engineering Николаем Амелишко про то, как и зачем компания «убирает стены» перед трансформацией, нанимает новых high level топов, учит сотрудников фейлиться. И, конечно, опять про культуру.  

33 комментария
«900 продуктовиков из местного Linkedin делите на 10». PandaDoc затеяла трансформацию

dev.by поговорил с VP of Engineering в PandaDoc Ильёй Казимировским и Director of Engineering Николаем Амелишко про то, как и зачем компания «убирает стены» перед трансформацией, нанимает новых high level топов, учит сотрудников фейлиться. И, конечно, опять про культуру.  

В 2018 году PandaDoc хвасталась однопроцентной текучкой благодаря культурному коду. Год назад  CTO и кофаундер Сергей Борисюк говорил, что компании удалось вырастить финансовые показатели в шесть раз, но стало больше «текучки». Что у вас происходит?

Николай: Когда компания только появилась, нас было немного, мы были заряжены и рвались на баррикады. Потом нас стало больше, мы разделились на две команды, потом на три. После 30 человек началась первая трансформация. По мотивам Spotify мы создали много маленьких команд по небольшим продуктовым направлениям. За всю команду и её результаты (как деливери, так и продукт) в таком сетапе отвечал РМ.

Мы слишком много «повесили» на РМ, они занимались и продуктом, и людьми. Это было too much, и даже некоторые из их обязанностей противоречили друг другу. В таком сетапе мы прожили полтора года.

Второй реорганизацией собрали эти команды в четыре больших юнита и выделили отдельно продакт менеджеров (отвечают за продукт) и инженерных менеджеров (отвечают за людей, деливери и технологии). Так решили проблему с перегрузкой РМ’ов. В таком сетапе прожили год. Но от всех проблем это не избавило. 

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

Приходилось перетасовывать команды, договариваться с их лидами, кто и когда может подсаппортить. Но всё это ручная балансировка, экстренное вмешательство. Чтобы от этого избавиться, мы начали реорганизацию. 

В чём её суть? 

Илья: Нам хочется создать среду, в которой команда сможет влиять на развитие бизнеса и продукта. Для этого мы убираем стены между юнитами, вводим новую структуру и кросс-функциональность. Конечно, здесь мы сталкиваемся с вызовами, например, а что будет с качеством, экспертизой, поддержкой? Будет переходный период.  

Николай: Если убрать барьеры между юнитами, всем будет проще. Раньше у каждого юнита был свой бэклог, а в юните могло быть ещё несколько команд, и у них свои бэклоги. Сейчас у нас будет единый «журнал» продукта, и все будут понимать, что у нас в приоритете. Теперь если у кого-то из маркетинга или отдела продаж возникнет срочная задача, он должен будет посмотреть в общий бэклог и определить, есть ли там что-то важнее. Плюс у нас есть таблица, где можно проверить, как твоя «хотелка» повлияет на метрики компании. Та задача, которая получает наивысший балл, идёт в разработку.

Образно говоря, в команду попадают игроки (читай — задачи) не по знакомству, а по показателям. 

А разработчикам от всего этого какая выгода? 

Илья: Раньше, если один юнит не справлялся с наплывом критических задач, он мог обратиться за помощью к другому. При этом у каждого юнита есть «окиары» (OKR, сокращенно от Objectives and Key Results). И если я буду всё время помогать другим, то не выполню свои «окиары». И будет как в фильме с Куравлевым: то провод оголенный подержал, то бабушку через дорогу перевёл, то мальчику помог. И к концу рабочего дня — так я же всем помогал! А с новой оргструктурой мы сможем все вместе решать: так, здесь провод нужно подержать, а здесь бабушку перевести. И это будет не партизанщина, а нормальный прозрачный способ. Да, это будет более сложная работа для менеджеров, но мы верим, что они справятся. Мы выйдем из зоны комфорта, но это позволит компании делать исключительно важные и приоритетные вещи. 

Трансформаций бояться не нужно, если они помогают компании развиваться. После неё меняется многое: рост сотрудников, удовлетворённость клиентов, скорость бизнеса, способность конкурировать. Мы не боимся изменений и динамики. Думаю, этот сетап проживёт чуть дольше обычного, где-то два-три года. 

Какие риски ожидаете?

Илья: К любым переменам нужно привыкнуть, а к новой команде притереться. Первое время люди обычно думают не о целях компании, а о том, как себя правильно поставить в новых условиях, начинается проверка границ. Вначале, возможно, будет даже регрессия, люди будут думать «а раньше было лучше». Сопротивление — это хорошо, это значит, что есть люди, которым не все равно, которые могут улучшить систему. Если его нет, зачем делать изменения? Я не ожидаю, что совсем всё будет плохо, но проседание на пару спринтов возможно. 

А культура что? Всё?

Илья: В PandaDoc она выражается в трёх тезисах: мы любим учиться, сильно влиять и получать от этого удовольствие. Первый год работы компании этот фан можно удержать, но, когда проходит 10-15 лет, сохранить увлечённость становится сложнее. 99% компаний это теряют.

Сергей и Микита Микадо, фаундеры, до сих пор увлечены. Им нравится драйв, они любят ошибаться и обучаться. И делать сумасшедшие заявления — «Хотим стать № 1 на рынке proposal». Мы хотим биться с крупными игроками. Конечно, где-то зафейлимся, но обязательно и научимся. Нас не интересует маленькие изменения, мы хотим делать перемены. А мир меняют увлечённые люди.

При этом надо помнить, что культурная модель — это всего-лишь инструмент, людей не обманешь. Люди за тобой пойдут, только если ты сам увлечён. Культурный код может быть прекрасен сам по себе как Библия, но по большому счёту человек от этого лучше не становится. Библия ведь не мешает нарушать её законы. То же самое и культурный код — он не может защитить нас от того, что кто-то будет что-то не так делать. 

Как всё время сохранять увлечённость команды? 

Илья: Это вопрос, на который мы хотим найти ответ. Хорошо, когда у тебя есть среда, где ты можешь ошибаться. В ней можно рисковать, играть по-крупному, реализовывать мечты. Так, кстати, работает израильская армия. Она берёт молодых людей, которым по 18 лет, даёт им менторов и спрашивает: «Какие у вас есть идеи, чтобы улучшить разведывательное оборудование?». И подростки, может, мало понимают в военной технике, но высказывают свои бредовые идеи, а менторы отвечают: «Давай попробуем».

Самые безумные идеи можно реализовывать в такой среде — что-то обязательно выстрелит. 

Насколько возможным и правильным вам кажется желание компаний сохранять дух стартапа с сотнями сотрудников в штате? 

Илья: Прекрасное желание. Есть неплохие примеры — та же Apple. Компания смогла сохранить креативность, идейность, лучшие умы. Горизонтально расти можно бесконечно, выделяя департаменты в компании. Иерархия не спасает. Хотя и даёт понятный план, чувство комфорта. А горизонтальные структуры сложнее, требуют больше движений. 

Сергей Борисюк говорил, что лиды на местах способны и должны самостоятельно принимать решения и этого достаточно, чтобы все работало. Недавно PandaDoc наняла двух топов — Director Product Operation и VP Product. Горизонтальная модель не сработала?  

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

Илья: Задача Бернарда, VP Product, двигать PandaDoc в лидеры на рынке, любым способом растить ревенью, придумывать, что ещё для клиентов сделать, чтобы они были счастливее. Задача Тейта, Director Product Operation, в том, чтобы выравнивать все идеи в единый бэклог, настраивать эффективный процесс сбора обратной связи со стороны кастомера. Также налаживать эффективное взаимодействие продуктовой организации с другими подразделениями (Sales, Marketing, BizOps, Finance).

Почему мы не смогли найти таких людей в Беларуси?

Если зайти на LinkedIn и посмотреть, сколько там специалистов с продуктовым тайтлом, то в Беларуси их примерно 900, в Литве 4000, в Польше 16000, в Берлине 77000, Лондоне — 99000. Причём в Беларуси люди могут этот тайтл написать себе, прочитав книжку, поэтому можно делить это число на 10. 

В СНГ сложно найти хороших менеджеров, потому что нас этому не учат? 

Илья: Да, в образовании большая пробоина, ни в одном вузе нет специальности Product Manager или Product Owner. К тому же у нас ещё мало опыта в рыночной экономике. Можно даже посмотреть ролик, который Никита делал на Комаровском рынке. Он спрашивал у продавцов, каким продуктом они пользуются, чтобы улучшить продажи — на него смотрели очень дико. Было это примерно семь-восемь лет назад, и я гарантирую вам, что и сегодня будет точно так же. Но если Никита задаст этот же вопрос в том же Амстердаме или Стокгольме, то люди не будут шарахаться и прятаться за помидорами с бананами, а спокойно расскажут про свой опыт. А у нас наследие прошлого всё ещё довлеет. ИТ-область вырвалась из него, в инженерии видны результаты, а в продуктовой области всё только начинается. 

High level менеджеры окупают вложенное? По каким критериям можно это отследить?

Илья: Обычно пользу нового топа можно оценить за год. Понятно, что это комбинация работы всех: и сейлзов, и маркетинга, и продукта, и онбординга. Но у топов, конечно, есть метрики, мы их с ними совместно определяем. Для продукта, например, это рост оборотных средств за счёт привлечения новых клиентов, расширение сервисов, и соотвественно, цены за лицензию для существующих, NPS (индекс потребительской лояльности) и другие.

Как измерить лояльность? 

Николай: Периодически мы задаём пользователям вопрос «С какой вероятностью вы порекомендуете PandaDoc своим друзьям/коллегам?» по шкале от 0 до 10. Далее все оценки делим на три группы: от 0 до 6 — противники, от 7 до 8 — пассивные, от 9 до 10 — сторонники. NPS равно % сторонников минус % противников. Для трекинга используем тул Wootric.

Чем отличается подход к менеджменту у нас и в Штатах? Что хорошо бы взять у тех и у этих?

Илья: Я бы не разделял на Штаты и на нас. И там, и там можно найти весь веер подходов, потому что учимся на одних и тех же книгах. Просто в Штатах физически больше опыта в управлении. Но их стили уже не назовёшь передовыми, есть масса примеров прекрасного управления и в Европе. Мир стал глобальным, и это не связано со Штатами или Беларусью. У белорусов более аналитический склад ума, фундаментальное образование, мы привыкли копать вглубь. В Штатах ребята сильны в скорости, любят рисковать, ничего не боятся. 

PandaDoc

Инструмент для управления цифровыми документами. Фаундеры — Сергей Борисюк и Микита Микадо.

Штат — 150+ сотрудников. Офисы в Беларуси, США, Филиппинах. За 2020-й собираются собрать ещё четыре команды по пять человек. 

Инвестиции — около $30 млн:

— в июле 2015 раунд на $5 млн, лид-инвестор — фонд Altos Ventures.

— в мае 2017 — $15 млн от фонда Rembrandt Ventures Partners,

— в июне 2019 — $10 млн от EBRD, Rembrandt Ventures Partners, Microsoft, Altos and Silicon Valley Bank.

dev.by проводит новое исследование рынка труда в белорусском ИТ — заполните анонимную анкету, и скоро мы поделимся результатами.​​​​​​​​​​​​​​​​​​

Работа в ИТ в Беларуси​

1. Заполните анонимную форму — 5 минут.
2. Укажите зарплатные (и другие) ожидания.
3. Выберите желаемую индустрию или область деятельности.
4. Получайте релевантные предложения​​.

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

Биотех-стартап белорусов поддержит американская корпорация
Биотех-стартап белорусов поддержит американская корпорация

Биотех-стартап белорусов поддержит американская корпорация

Fibery Михаила Дубакова появилась на Product Hunt
Fibery Михаила Дубакова появилась на Product Hunt

Fibery Михаила Дубакова появилась на Product Hunt

3 комментария
DepAcc с «БелХард» запустили проект по доставке товаров сотрудникам на удалёнке
DepAcc с «БелХард» запустили проект по доставке товаров сотрудникам на удалёнке

DepAcc с «БелХард» запустили проект по доставке товаров сотрудникам на удалёнке

1 комментарий
Техностартап с разработкой в Минске перенес кампанию на Kickstarter из-за вируса
Техностартап с разработкой в Минске перенес кампанию на Kickstarter из-за вируса

Техностартап с разработкой в Минске перенес кампанию на Kickstarter из-за вируса

Обсуждение

Vadim S
Vadim S Product Manager в My Monday
-5

Все правильно, это ответ на вопрос, почему белорусская экономика в попе. Как поставить плюс под каждой строчкой?

2

Надо просто лизнуть смартфон

15

Cлишком много базвордов я ничерта не понел. Что-то слишком сложно стало простому погроммисту в этих всех современных компаниях. Мб как-нибудь проще расскзаать, как для кретинов. А то какие-то трансофрмации и выходы из зоны комфорта и что-то в друхе "мы любим учиться и хотим быть динамичными чтобы конкурировать". А вот что сказать, то хотели нипанятна. Один беклог будет для всех с приоретизацией по умным метрикам? Ну ок, но в статье же слишком много слов, чтоб было только это? Не люблю большие компании, кучи ребят со непонятными менеджерским должностями, все что-то то говорят, говорят, но что сказать хотят вот неодуплить. Что-то слишком много стало вокруг двигателей трансформаций. Толи дело компания в 10 - 20 человек, все друг дурга знают, все помогают, никто не выделывается, и никто никому не говорит как ему работать. И никто ничего не пытается трансформировать.

3

Когда 10 человек, так можно всем вместе бабушке помогать и оголённый провод держать :)

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

6

Меня немного смущает, что весь этот трансформационный банкет за счет инвесторов )
В конце статьи краткая выжимка про pandadoc, но там нету цифр по выручке и чистой прибыли, только сколько внешних денег взяли для "burn'a" )

7

могут этот тайтл написать себе, прочитав книжку

Можно название этой книжки?)

0

Так. Ребята явно находятся на какой-то своей волне. Я подобный поток мыслей генерирую либо когда глубоко в работе нахожусь, либо спросонок.

3

В чем смысл статьи? В пандадок снова что-то решили поменять?

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

В приложении за последние 5 лет, концептуально ничего не поменялось.
Они даже вменяемого SDK для интеграции не разработали, как DocuSign.
Ваш бизнес, это типо не наша целевая аудитория.

Юзаем DocuSign, юзать это чудо не советуем.

1

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

-2

кагбэ приложение - следствие процессов)
ниже писали, что одно дело делать продукт компанией 3-12 человек
и другое в 100-200 человек
про корпорации вообще молчу

или у вас как in Soviet Яussia: приложения разрабатывают людей?

1

You are probably right, but Pandadoc needs to identify features that customers will pay for, and then upgrade their product specifically in this area, and that is the role of product management.

They also probably need to market their product better. This is business software. Businesses often pay lots of $$ for technically inferior products (e.g., Windows Servers vs. Linux, or Oracle DB) based on factors unrelated to technicals.

6

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

0

Ага, успешно исправят - ценой денег инвесторов и нервов клиентов :)

0

Как становятся продакт оунерами/менеджерами в Беларуси, основные сценарии, на мой взгляд. Аутсорс пытается стать аджайл, переименовывает проджект менеджеров/бизнес аналитиков/разработчиков ближе к клиенту в продакт оунеров, сценарий 1. Изначально продуктовая компания (скорее всего приложения иили модули мелкие какие) нанимает/промоутит 1-2-3 ответственных жопы, которые занимали аналогичные с предыдущим примером должности, которые будут отвечать за разработку, маркетинг, стратегию, миссию, кошек СЕО ну и т.д., сценарий 2. С таким раскладом у нас и не может быть школы продуктового менеджмента, потому что в каждой конторе продуктовый человек, как бы он ни назывался по тайтлу, возится в куче рутины и тушит то, что ярче горит, имхо. И пробоин у нас везде дофига, но большая пробоина как по мне, в том, что наниматели не понимают, что фокус развития продукта это не техническая разработка вообще, а определение направлений развития исходя из потребностей рынка и клиентов, изучением которых он и должен заниматься бОльшую часть своего времени. И рассматривать на эту работу надо прежде всего людей, понимающих важность ориентации на рынок, стратегии и всех экономических составляющих.

0

Еще через постель )

0

Еще через постель )

2

ох уж этот дух стартапов белорусской школы. с OKR и бэклогами

-2

расскажи как ты умеешь

ade
ade
14

Звучит так: были менеджеры, к ним наняли еще столько же менеджеров (заниматься людьми), потом наняли еще топ-менеджеров. Всем этим людям надо создавать видимость работы, а т.к. привносить value в продукт они не могут, то начитавшись книжек, экспериментируют на структуре компании.
Грустно это все, когда-то панда казалась маленьким уютным местом с хорошей культурой.

11

Я так и не понял, они табличку приклеили или прибили?

3

Раньше у каждого юнита был свой бэклог, а в юните могло быть ещё несколько команд, и у них свои бэклоги. Сейчас у нас будет единый «журнал» продукта, и все будут понимать, что у нас в приоритете.

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

1

Единый беклог совсем не плох. У тебя же есть теги чтоб отделять, у тебя же есть приоретизация, кторая мб считается формулой и основана на каких-то там данных. Ты же всегда видишь кто, что делает и куда движется организация. Не эта ли прозрачность за которую все топят? И ты наконец, можешь сам что-то решать и что-то видеть (ну в теории). А не быть просто машиной по переработке юзер сторей в пул реквесты. Или тебя вот интересует, вот мой кусок кода, вот моя таска, а вы как там вверху все видите, это не моя работа и я тут только код пишу внутри команды, а что там у других, это не важно. Хотя да если продукт большой и людей очень много, то это единый беклог, действительно плох.

6

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

-1

"хотят чтобы ты мог в любой момент открыть любой проект/компонент, быстро разобраться в коде" - эм, тогда просто поднимается приоритет, и кто-то, кто освободится, возьмет этот баг следующим и будет разбираться. Не? Никто никому не приказывает, не говорит что делать, просто поднимается приоритет, вот и всё, и не важно кто будет фиксить, у кого следущим руки дойдут и кто освободится. А в баге уже видно, кто что по нему делал, с кем можно пойти проконсультироваться. Если разработчиков больше десятка, то всегда кто-нибудь освобождается и думает, чем бы ему хотелось дальше заняться.

2

Как раз это и неэффективно - распыление ответственности.
Свой баг или баг пары коллег, с которыми я постоянно работаю над конкретным проектом займет у меня полчаса от силы, т.к. я в теме все время. А если над проектом я работаю 1-2 дня в месяц, это каждый раз тратить время и силы вспоминать как он организован.
И смысл тогда в общем беклоге, если все равно эффективней будет если все скипнут баг и он вернется к создателю.

0

Ну тогда, вопрос, если каждый пилит свою узкую область и не разбирается соседней подсистеме, то в чём вообще смысл работы. Это дико скучное занятие, зачем так жить? А если представляешь как все устроено везде (это не должно быть особо сложно, если разработчиков не больше нескольких десятков), то у тебя появляется видение продукта в целом и вообще возможность технических инициатив, архитектурных предложений, да и вообще ты перестаешь быть просто человеком, который разгребает беклог. Да эффективность поначалу ниже, но зато потом у бас фактор сильно ниже, качество кода выше, т.к ты всегда знаешь, что будет кто-то кто будет разбираться и вообще появляется большая организованность разработчиков между собой и твой код могут проревьювить несколько человек с разными взглядами из разных команд, diversity и все дела. Конечно, кто-то будет больше шарить над какой-то частью, но он и будет ревьювить пул реквесты в эту часть. Как в опен сорсе, есть мейнтейнеры, а пул реквест можно послать кто угодно. Я вообще больше люблю базарную разработку, а не собор: https://www.wikiwand.com/ru/%D0%A1%D0%BE%D0%B1%D0%BE%D1%80_%D0%B8_%D0%91%D0%B0%D0%B7%D0%B0%D1%80. И опыт растет сильнее и понимание выше.

1

Кому-то скучно, а кому-то нет.
Такое должно из инициативы исходить, а не навязываться сверху.
Человек может делает хорошо свою работу, а дальше его ждут семья, пет-проект на том же опенсорсе, хобби другие и т.д. И ему не нужно чтобы ПМ еще развлекал его багами с чужих проектов.
Но хай-левел архитектуру и бизнес-процесс системы полезно знать. Это недолго и не требует частого обновления в отличие от оригинальных и креативных костылей в каждом компоненте.

0

@grebetz n Не везде есть ПМ, которые говорят, что тебе делать. Продукт менеджеры да, технические лиды, которые помогают людям и следят за архитектурой. Ну вот классического PM, который менеджит время разработчиков, вот нет. Какая-нибудь продуктовая организация с ремоут ребятами или фрилансерами, например.

0

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

Больше похоже, что о разработке вы знаете только по книжкам для менеджеров.

-4

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

на самом деле да, круто что анализируете пройденный путь, проблемы и пытаетесь что-то менять!
и забейте на комментаторов, которые тут язвят)

лично мне было ценно узнать, что не у меня одного есть аналогичные проблемы (это значит что не я такой глупый или не я один)))

6

*один из лучших уроков полученных мной за 2 года в Targetprocess и лично от Михаила Дубакова: множественные кавычки вместо одиночной или смайла — тревожный звоночек... ;)

1

Я работал в PandaDoc. Давайте будем откровенны: Николай попал в pandadoc в 2016 году с нулевым опытом и пониманием как вообще ставится работа IT - компании. За 4 года только и были статьи из разряда: "мы делали лютую фигню, потом поняли, трансформировались, и сейчас у нас очередная лютая херня". Куча компаний с штатом в 150 человек эффективно управляются без всех этих "трансформаций" благодаря пониманию рабочего процесса и здравого смысла. Увы, Николай этим никогда не обладал. Почему он до сих пор лицо всех рассказов из PandaDoc - тоже вопрос.
Большая текучка в PD - это результат внутреннего "прогрессивного" мэнеджмента.

За себя скажу, что после определённой успешной полугодовой работы меня сделали Lead-ом и дали в подчинение старожила компании. Этот старожил за 2 недели не сделал ни одного таска и по 3-4 часа сидел трындел с Николаем и др. "мэнеджерами" каждый день в переговорке. Когда ребром поставил вопрос что же происходит - отправили на день погулять и потом сообщили об увольнении. Вот такой прогрессивный мэнеджмент и так там ставится работа. Подковёрные игры. При этом мэнеджмент на уровне школьного кружка. И уволили меня сообщив всей компании что сотрудник, проработавший 8 месяцев и сделавший крупный проект, оказался сумасшедшим. Могу дать эксклюзивное интервью dev.by если редакции очень интересно как там всё внутри происходило.

0

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