Предъявлять высокие требования Пришел со временем к мысли, что предъявлять высокие требования – уважение к команде.

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

Это справедливо особенно в большой компании, чтобы не быть бета тестером. Это отнимает очень много ресурса и времени. Тестировать временем СМО или C-level – непозволительная роскошь.

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

Просто "требовать" тоже не подход. Право на ошибку остается. И это не значит, что надо говорить "НЕТ" гипотезам и все с 1 раза должно получаться.

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

Считаю, что это и уважение к человеку – позволять расти над собой. И для управленца – не быть всегда одним ответственным, на которого перекладывают все согласования. Можно поднимать постепенно планку качества, но объясняя:

🔵Definition of Done. Что значит «готово» для презентации, бюджета, брифа и т.д. 🔵Шэринг знаний и опыта команды. Чек-листы и примеры. «Как надо / как не надо» – чтобы не угадывали.

Мне не всегда просто дается говорить «нет». Не знаю, может, у вас так же?

Но постепенно такой подход приживается. Пробовал начинать с малого. Вижу, что работу сделали плохо – и прям говорю: "Не принимаю, дальше смотреть не готов. Переделайте, перепроверьте и приносите".