В начале этой осени я наткнулся на Всероссийский рейтинг IT-брендов работодателей 2024 от Хабра. Увидел, что у меня были знакомые руководители разных уровней в 15 компаниях из первых 30. Скинул им ссылку на отчёт и получил от 12 человек крайне любопытные реакции. Чаще всего в духе "неожиданно" или даже "странно". Дальнейшее общение показало две вещи.

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

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

Логично всплывает вопрос. Если такое происходят в лучших ИТ-работодателях, что происходит в худших? И насколько релевантен мой анализ? Для этого я погрузился в статистику и исследования.

Масштаб проблемы

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

В российском ИТ о сотрудниках заботятся на очень высоком уровне. Компании из ИТ, бигтеха, финтеха и прочих сфер, связанных с разработкой, постоянно оказываются в топах лучших работодателей РБК, Head Hunter, Forbes и прочих порталов, а отчёты консалтинговых компаний типа большой аудиторской четвёрки говорят о том, что IT-сектор лидирует во внедрении специализированных программ психологической помощи и профилактики выгорания. Как человек, который регулярно общается и мониторит работу HR и заботу о сотрудниках в самых разных отраслях, я ответственно заявляю, что служба HR в ИТ на две головы более продвинута, чем во многих прочих отраслях.

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

Заботы больше, зарплаты выше, условия труда лучше. Вот только уровень выгорания в ИТ выше. Об этом отчётливо свидетельствует, например, исследование от службы исследований компании Head Hunter 2019 года. В нём измеряли субъективный уровень счастья сотрудников разных отраслей на шкале от 0 до 10, где 10 – наивысший уровень счастья.

ИТ-сотрудники оказались в списке самых несчастных профессий, оценив свой уровень счастья на 4,8 баллов, . Рядом с работниками из автомобильной сферы (4,4), рабочим персоналом (4,7) и теми, кто только начинает свою профессиональную карьеру (4,8).

В декабре 2023 года совместный опрос 2000 сотрудников ИТ проектом «Хабр Карьера» с HR-платформой Beehive установил, что у 88% - есть признаки эмоционального выгорания, а 66% - демонстрирует высокие или даже крайне высокие уровни выгорания. 

С апатией или деперсонализацией ситуация получше, но всё равно цифры не радуют.

Неудивительно, что сотрудники и свою продуктивную эффективность оценивают довольно скептично. Впрочем, здесь ещё стоит добавить, что речь шла про опросы, а не замеры. Плюс, что современная ИТ-сфера такова, что многие сотрудники долгие годы живут в режиме выгорания, потому могут и не помнить свои реальные возможности. А какая-то часть из-за регулярного хаоса могли вообще ни разу не работать на пике своей производительности, ведь регулярный стресс критически снижает наши умственные способности уже с третьего месяца!

И это выливается не только в снижение продуктивности, но и ощутимые проблемы со здоровьем. Об этом, например, говорит исследование «Health problems and stress in Information Technology and Business Process Outsourcing employees» 2015 года, в котором у 1000 обследованных сотрудников ИТ была обнаружена прямая зависимость между наличием физических и психологических расстройств и выявлены такие заболевания: 

?56% — нарушения опорно-двигательного аппарата,

?54% — депрессия, тревога и бессонница, 

?40% — ожирение,

?36% — дислипидемия (высокий уровень холестерина),

?22% — гипертония,

?10% — диабет.

И эта статистика по людям со средним возрастом не выше 40 лет.

Схожую статистику можно найти и в других источниках. Например, опрос HeadHunter 2023 года показал, что 62% российских сотрудников в ИТ жалуются на хронические боли в спине и шее, что входит в нарушения опорно-двигательного аппарата. Можно взять и исследование Минздрава 2020 года, согласно которому ИТ-специалисты болеют чаще других, включая ОРВИ и сердечно-сосудистые заболевания. Хотя там же и говорят, что проблемы с опорно-двигательным аппаратом в ИТ встречается «всего» в 30% случаев, хотя и такая цифра позволяет ИТ-сотрудникам стать лидерами среди прочих профессий (у работников госструктур и медиков, занимающих второе и третье места – 24% и 23%).

И, наконец. Только 20% сотрудников, согласно “2024 Developer Survey” от Stack Overflow, довольны своей работой.

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

И исследование "Jekyll and Hyde leadership" 2024 года это отлично объясняет, когда находит простую зависимость: здоровью сотрудников непредсказуемый менеджмент наносит больше вреда, чем стабильный, но токсичный и тираничный. И даже существенно более высокий уровень заботы не спасает.

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

Лучше перейдём к рассмотрению причин организационного хаоса более детально. Ведь в основе проблем в ИТ лежит именно он.

Виноват кто угодно, кроме

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

При этом докладчик на слайде упомянул недавний крайне показательный отчёт Дмитрия Свиридкина об организационном дурдоме, который он наблюдал в Amazon Web Service. Мы его обязательно разберём позже отдельно с позиции «в чём проблема – как исправить – какая организационный провал скрывается за этим набором сложностей», а пока вернёмся к выступлению.

В качестве главной идеи докладчик озвучил, что HR должны бороться с таким хаосом. Как, спросите вы? О, это любопытно. С помощью отслеживания уровня бюрократизации в компании (это реальная метрика с живой методологией оценки), который оценивается на основе анкетирования сотрудников. То есть, помимо кучи всяких опросов с не самым высоким уровнем прозрачности и честности предлагается проводить ещё один. И тут мне хочется спросить: эти цифры нужны, чтобы что? Получили мы сегодня 37, вчера 26, а завтра – 33, дальше-то что? Можно ли верить цифре «доля желающих уволиться за последние 2 года снизилась с 15% до 12%», если реальная текучесть кадров по штатке выросла с 40% до 45%? Кто влияет на эту цифру, и кто может её менять? Кроме метода «мы неправильно считаем», разумеется.

И я спросил докладчика: может, хватит уже накидывать на HR, и не пора ли спросить с СТО, который организовать работу никак не может? Ведь все косяки бизнеса из его кейса – как раз организационные. Как раз те, за которые должен отвечать главный по разработке.

Докладчик сразу ответил, что СТО за это отвечать не должен, чем и спровоцировал появление этой статьи.

Но для начала нам нужно разобраться с одним вопросом.

Кто такой СТО, кого, возможно, уже пора уволить?

Вот здесь очень тонкий момент. 

Если говорить совсем упрощённо, это тот человек, кто отвечает за ИТ, включая разработку и сопровождение. Это может быть СТО. Может быть CIO. Может быть CPO. Иногда – СОО. Может быть какая-то иная аббревиатура, я встречал даже CBDO. А может быть техдир или просто заместитель генерального директора.

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

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

Моя задача - не найти ведьм. Не уволить 50% СТО, CIO и прочих сотрудников. Моя задача - показать, что организация в ИТ-компаниях может быть очень сильно улучшена. Улучшена в пользу счастья сотрудников, и одновременно - роста их продуктивности, вовлечённости, ощущения безопасности и спокойствия, а следом - и ростов результатов бизнеса.

И сразу ещё два нюанса: ниже я перечислю 36 организационных проблем и сложностей, связанных с ИТ. 

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

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

Посчитаем?

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

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

0 - проблема не встречается или совсем не существенна

2- проблема регулярно встречается

5 - проблема не просто регулярно возникает, но и её влияние на работу компании максимально разрушительно. 

И далее вы складываете все значения одно за другим, пункт за пунктом. 

Ниже 36 проблем организационного характера. Так что на выходе вы гипотетически можете получить сумму в 180 баллов, но, понятно, что получите меньше. 

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

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

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

И по итогу – делаете выводы. А затем, в зависимости от суммы баллов и вашей позиции, увольняете СТО, увольняетесь сами, стараетесь внедрить отдельные практики и рекомендации или пишете комментарий, что финансист ничего не понимает. 

На самом деле, мне относительно легко, эту статью с проблемами валидировало уже минимум 60 человек, но я всё равно в ИТ ничего не понимаю.

Я изначально планировал выдать все эти пункты структурированным списком, но быстро понял, что при таком построении вы их можете начать путать оценивать “ассоциативно”: вы же поставили предыдущей боли 5 баллов, почему бы и следующей не поставить 5. Хотя у вас её может и не быть.

Чтобы такого избежать, я делю весь список на 2 части. Первый строится на публичном описании проблем в Amazon Web Services, второй - дополняет его. Как раз, вам удобно сделать небольшую паузу при прочтении этого лонгрида и подсчёте баллов.

Провал в Amazon Web Services (AWS)

Как говорится, “я очень не хотел делать этот лонгрид”, но на него меня сподвигла история выгорания Дмитрия Свиридкина в компании AWS.

Автор отработал в компании ровно 3 года с 2022 по 2025, после чего уволился из-за дикого стресса, к которому привели очень много причин. 

Дмитрий всегда считал себя достаточно стрессоустойчивым, но за 3 года работы в AWS заработал себе чудовищный стрессовый кашель, связанный с работой. 

В своей истории автор не выделяет эти пункты и боли, у него другая цель. Так что их я выделяю сам. Получилось 18 организационных проблем, которые смог увидеть и описать в своей истории Дмитрий. Для удобства, цитаты из его истории будут идти курсивом в начале каждого пункта.

Перейдём же к их рассмотрению.

18 Организационных проблем AWS

1. Работа без фокуса

"Пользователь может жаловаться, что у него упал 1 запрос из миллиона. Пользователь может жаловаться, что у него устаревшее железо."

Пользователь может прийти и сказать, что он уволил всех программистов.

Давайте сделаем эту фичу, потому что её просил клиент. И эту, потому что её делает конкурент. И вот эти 20 штук, потому что можем. А ещё наш PR-директор был на конференции и узнал, что надо полностью переделывать UI/UX, потому что такой новый тренд. И везде надо придумать и внедрить ИИ, мы же передовая компания. 

И получается, что компания бегает хаотично за самыми разными целями без какой-то системы или единого плана.

Нет, она при этом может пробегать эти спринты крайне эффективно, достигая рекордных значений Time-to-market, быстро, писать суперкачественный код без легаси (на самом деле, такого никогда не происходит), но толку от этого всего, если на выходе мы бегаем кругами?

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

95% заявок идут от 70% клиентов с отрицательной экономикой, которые съедали больше, чем приносили. 3% предложений – от 20% клиентов с околонулевой доходностью. И только 2% - от тех 10% клиентов, кто реально приносил деньги и за себя, и за остальных. Стало очень понятно: если гоняться за всеми заявками, мы будет работать на самых громких клиентов, несущих нам только убытки. А не на прибыльных и выгодных.

Один мой подписчик поделился такой историей. Работает в условном финтехе на сотни тысяч активных клиентов, цифры несколько искажены, но достаточно и сути. Аналитики взяли статистику пользования продуктами, сервисами и фичами, которые разработаны и выпущены в тираж в 2024 году. И выяснили, что 15% функционала применялось, условно, 5 раз за год. Ещё на 15% функционала – 3 регулярных пользователя. И реально качественный функционал, который регулярно применяется (об окупаемости речи не идёт) – всего 20%. Фактически получилось, что компания могла не внедрять больше половины сервисов и фич, и ничего бы не потеряла. Только могла сэкономить средства и силы разработчиков. 

Так ведь весь этот избыточный функционал нужно поддерживать как серверами, так и силами погроммистов. А в ряде случаев продуктивней "отстреливать" его, как это делают в корпорации «Booking», где по итогу тестов закрывают до 90% новых сервисов и фич. Но мы сейчас рассматриваем более критичную проблему: проблему работы вообще без приоритетов.

Хотя устранить её несложно. Достаточно перед накидыванием задач в бэклог проводить внятный экономический анализ. Если есть стратегия - уже хорошо, отдельные компании только на этом могут отбросить до 80% самых разных несвязанных активностей и хотелок. 

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

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

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

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

2. Установка на переработки

"Jassy also urged employees to "move fast and act like owners," as some of the company’s competition is "working seven days a week, 15 hours a day."

В современном мире есть огромная вера в переработки. Что можно трудиться по 10-12 часов в день по 6 дней в недели или больше и быть продуктивным. Эта вера основывается на отдельных исторических феноменах прошлого и постоянно подпитывается в СМИ, историях успеха и так далее. 

Хотя трудиться больше адекватных 40 часов в неделю действительно продуктивно можно не более месяца. И после этого нужно отдыхать.

Вот вам наглядно схема, что происходит с людьми в режиме переработок, голубые поля – с первых дней, синие – примерно с 5-й недели в режиме умеренных переработок по 50-60 часов, тёмно-серые – с 9-й недели работы по 50-60 часов. И, да, они «складываются». Или даже "мультиплицируются".

Так что самым плодотворным режимом для профессий, особенно для сложных и требующих решение сложных задач, включая разработку, будет спокойная ровная работа по 40 часов в неделю. А то и по 30-35. 

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

А как добиться работы без переработок, мы обсудим в том числе и здесь.

3. Избыток встреч

"Документ будут ревьюить прямо на митинге по обсуждению этого документа. Ведь заранее его мало кто прочитает. Так что первые 15-20 минут митинга вы будете молча читать. В большой корпорации у всех много митингов."

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

“Остановите безумие встреч», – буквально кричит своим названием статья «Stop the Meeting Madness» от Harvard Business Review 2017 года. Начало тоже подходящее: «Многие топ-менеджеры испытывают потрясение от количества встреч, что не удивительно. Они проводят на таких мероприятиях, в среднем, 23 часа против 10 часов ещё 60 лет назад. Что хуже всего – такие встречи чаще всего плохо организованы и плохо проводятся… Каждая минута на таком мероприятии съедает нашу способность к творческому принятию решений и эффективности».

Исследователи изучили опыт 182 топ-менеджеров в самых разных отраслях:

?65% опрошенных ответили, что встречи мешают им выполнять их работу

?71% - сказали, что встречи непродуктивны и неэффективны

?64% - признались, что встречи убивают возможность вдумчивого решения вопросов

?62% - отметили, что встречи даже мешают налаживать командную работу. 

С тех пор число рабочих встреч продолжает расти, а их эффективность – снижается ещё сильней.

Исследование «Hybrid Work Is Just Work. Are We Doing It Wrong?» корпорации Microsoft показало, что с 2019 до 2022 года среднее число рабочих встреч выросло на 153%. На всякий случай: в два с половиной раза. И даже после того, как пандемия ушла в прошлое, а многие с удалёнки вернулись в офисы, объём и длительность встреч практически не снизилась.

Так что первым шагом к отказу от переработок и лишних потерь времени для абсолютного большинства компаний станет решение вопроса: «Как сделать так, чтобы ужать в 1,5-3 раза число встреч, чтобы они были реально продуктивны не в 30% случаев, а хотя бы в 80%». 

И вот вам основные идеи для затравки: 

?К совещаниям надо готовиться

?Идеи и варианты решений лучше продумывать заранее

?Нужно ограничивать число участников

?Лучше делать 3 короткие встречи на 3 активных участников, чем 1 часовую – на 6

?Нет ничего хуже ловушки удобного для лидера группы решения.

P.S. Мне ещё совершенно непонятно, что у 40-60% директоров нет ощущения контроля над своим расписанием. У тех, у кого реально критичными являются встречи с генеральным директором, некоторыми заказчиками и подрядчиками. И даже с ними можно договариваться. Если директор не способен организовать своё время, да что он, вообще, может?

4. Чрезмерная бюрократия

"Любое хоть сколько-нибудь серьезное изменение больше 10 строчек потребует многомесячных обсуждений"

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

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

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

И если вдруг согласованная в 100500 инстанциях правка приводит к ошибкам, ответственным за неё оказывается исполнитель. А не кто-то один.

5. Совместительство и размытие зон ответственности

"Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job.”

Это означает что oncall-оператор должен примерно всё. И тот, кто ответит на тикет, станет ответственным за его решение и должен будет отвечать на любые вопросы."

Безответственность – это отдельная огромная проблема в ИТ, когда многие функциональные и командные роли совмещаются или распределяются между несколькими сотрудниками. 

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

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

Или у вас разработчики с QA-инженерами играют в пинг-понг, не желая принимать ответственность за качество кода. Первые хотят быстро написать и сбросить код на вторых, а те хотят сфокусироваться над интеграционном тестировании, а не поиске базовых ошибок. То есть, каждая группа хочет делать что-то интересное для себя, потому будут сбрасывать скучные, хотя и нужные задачи на других.

Чёткие зоны ответственности с прозрачным разделением труда – самое рациональное, спокойной и одновременно выгодное. Особенно в условиях Agile и прочих гибких практик, когда хватает хаоса и неопределённости.

6. Медленное принятие решений и бессмысленная работа

"При оценивании затрат на какую-либо фичу, менеджер может сказать "let's keep rollout aside".

Релиз проекта, который я сделал за 2 недели, занял полтора года."

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

Получается, как в игре Tetris: все успешные решения быстро пропадают, а провалы и ошибки остаются надолго.

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

Исследования показают, что до 40% работников считают свою работу или её значительную часть бессмысленной или даже вредной, а 20% работников отсутствие какого-то смысла в их работе заставляет ощущать себя «убогими». Буквально, «miserable». Ещё 60% находят в своей работе мало смысла, что практически обнуляет любое их удовлетворение от работы.

Если же сотрудник не видит особенного смысла в своей работе, то он и работает хуже. Придание же осмысленности, согласно исследованиям, повышает производительность труда на 10-33%, снижает текучесть кадров на схожие значения и повышает уровень зарплаты, при которой сотрудник согласится сменить работу от 30% до 66%.

И это касается не только рядовых сотрудников. 37% директоров и 53% руководителей среднего звена и вовсе не понимают цели своей работы, согласно «Global leadership forecast» 2023 года. 

7. Сбой в Work-life и невозможность отключиться от работы

"Правда, те кто разбирается скорее всего сидят в Сиэтле, c которым у вас 8 часов разницы.

Oncall rotation"

Большая проблема в ИТ заключается в том, что работа стала сильно размазываться по времени и пространству. Особенно – после пандемии, когда удалёнка активно вошла в нашу реальность, а сотрудники с заказчиками разъехались по разным часовым поясам. 

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

Добавьте к этому дежурства и всяческие «oncall rotation». А ещё – требования многих руководителей, что сотрудники должны оставаться на связи в своё нерабочее время. А ещё – что решение сложных задач частично происходит на заднем плане, в нашем бессознательном или «бэклоге», то есть, обработка идёт даже на выходных.

И такое всепоглощение работы вредно по трём причинам. 

Во-первых, это приводит к нарушениям циркадного ритма и социального времени. 

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

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

А следом – сотрудник не может полноценно трудиться и в рабочие часы. А то и доходит до выгорания.

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

Есть статистика, что 73% россиян регулярно трудятся на выходных. Но, если вы хотите, чтобы ваши сотрудники были продуктивны, выходить в выходные они должны примерно никогда, разве что в чрезвычайных ситуациях.

P.S. О том, как продуктивно выстраивать work-life баланс, есть и отдельная статья.

8. Отсутствие чётких и адекватных требований

"А потом начнется прожарка (Bar Rising!) с кучей вопросов. Предполагается что вы, как Доктор Стрэндж, просмотрите все варианты будущего и точно совместно выберете единственно верное решение заранее."

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

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

И руководителям приходится угадывать, что же от них нужно директорам, а не следовать определённым заданным требованиям.

Неудивительно, что в итоге всё сваливается на переписывание идей у конкурентов. Что ещё вы ожидаете от людей, которые просто хотят спокойно делать крутой продукт, а руководство на них вешает свои же ответственности: от стратегии до целеполагания.

И при этом не только работу не организовывает, так ещё и мешает за её пределами.

9. Изолированность команд и дефицит коммуникаций

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

Самое время взять статистику от Fierce 2011 года, согласно которой главной причиной провалов бизнеса в 86% случаев признаётся плохая внутренняя коммуникация. Добавить вывод исследования «The Frontline Leader Project» 2019 года: 52% директоров считают, что их сотрудники работают изолированно друг от друга и недостаточно общаются. И посмотреть на вывод McKinsey Institute в «The social economy» 2012 года: качественная внутренняя коммуникация способна повысить производительность труда на 20-25%. 

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

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

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

Работник без общения с окружающими не способен реализовывать потребность в лидерстве и власти даже на каком-то локальном и ситуационном уровне – не находится объектов влияния. 

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

А значит, ухудшается и возможность быть креативным, анализирующим и думающим.

То есть, из-за дефицита общения сотрудники теряют возможность удовлетворять от четверти до половины своих нефинансовых потребностей. И следом - теряют в удовлетворённости, вовлечённости, продуктивности и так далее.

А ещё – воплощают закон Конвея в жизнь: чем хуже коммуникация, тем сильней выражена модульность продукта.

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

10. Отсутствие контроля над жизнью

"Мне кажется, лучшего рецепта для выработки синдрома самозванца придумать нельзя. Такой Bar Rising может заставить сомневаться в себе кого угодно"

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

Продемонстрирую феномен на паре примеров.

Автоматические лифты долгое время не были популярными: люди боялись ими пользоваться, предпочитая те, которые обслуживались специальными людьми. Всё перевернула большая красная кнопка "Стоп". Люди увидели, что у них есть возможность влиять на ситуацию и стали регулярно пользоваться автоматическими лифтами. Понятия не имея, что эта кнопка делает и работает ли вообще.

Этот же путь успешно прошли и беспилотные автомобили. Практика показала: люди быстро привыкают к новым рискам с возможностью ими управлять. Даже когда водителю настоятельно рекомендуется держать руки на руле и быть готовым принять управление, многие перестают следить за дорогой и занимаются своими делами уже через 5-10 минут.

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

Неудивительно, что исследовательская компания IPSOS выделяет ощущение контроля в качестве одного из ключевых драйверов, который значительно влияет на счастье людей.

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

11. Непрозрачность карьерного трека

"В 2022 году меня наняли как L5 Software Engineer. Мне дали оценку exceeded role expectations. Надо еще один документик написать. Вот еще чуть-чуть, надо еще продемонстрировать operational excellence. Еще один системный документик и точняк."

ИТ – одна из самых требовательных к постоянному обучению сотрудников сфера. Если не самая требовательная. За 5-7 лет вполне себе можно успеть выучить, отработать и забыть 3-4 разных технологии. А ещё – чем выше должность, тем больше всего приходится держать в голове, и тем сложней задачи. С учётом плохой организации работы мы получаем, что более высокий уровень ИТ-специалиста сопряжён и с более высоким уровнем стресса, нервного напряжения и выгорания. Про это ещё в «One Road to Turnover» в 2000 году писали, но с тех пор ситуация стала ещё более сложная для сотрудников ИТ.

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

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

И буквы «ИПР» или индивидуальный путь развития – должны быть не просто тратой чернил принтера, а конкретными планами обучения. Чтобы человек мог понимать, что он может вырасти до желаемой должности за условные 2 года, а может – за 5. И знал, каким образом этого добиться.

А теперь добавьте к этому, что в успешных компаниях сотрудники учатся более 70 часов в год, а руководители – свыше 100, преимущественно за счёт бизнеса в его целях. Сколько часов учатся ваши сотрудники?

12. Выстроена система обмана 

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

Система манипулирования сотрудниками в компании AWS, описанная Дмитрием, многим менеджерам может показаться эффективной и удобной. Постоянно обещаешь сотруднику рост, вынуждаешь его таким образом надрываться, постоянно показывать лучшие результаты. Но не повышаешь.

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

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

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

Обманутый сотрудник крайне редко остаётся высокопродуктивным, тем более – он не остаётся вовлечённым и заинтересованным, инициативным. 

Так что обман сотрудников может быть локально оптимальной, но для хорошо выстроенной системы это будет чистейший проявлением зла. Потому что в долгосрочной перспективе доверие сокращает стоимость ведения бизнеса. В том числе и за это в 2009 году Оливер Уильямсон получил Нобелевскую премию по экономике.

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

Впрочем, здесь нужно добавить ещё один важный аспект честности, про который обычно забывают. 

72% программ по развитию корпоративной культуры не вызвали роста доверия, вовлечения и не помогли лучше удерживать сотрудников. В 57% случаев всё стало даже хуже. 

Почему такие проекты не работают, отвечает статья "To Change Company Culture, Focus on Systems—Not Communication" в Harvard Business Review:

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

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

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

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

13. Метрики превыше смысла

"В Амазоне есть система ежедневного анонимного опроса по ощущениям заряженности, быстрых изменений и радости от применения GenAI. В конце каждого месяца вы собираетесь командой и играете в мафию: кто ж из нас недоволен"

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

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

Увы, но современная сфера ИТ вляпалась в обе эти ошибки. И если про Time-to-market мы уже поговорили ранее, то на законе Гудхарта надо остановиться отдельно. Потому что это прямое воплощение логики: метрики превыше смысла.

Например, постоянная гонка за оперативностью разворачивания ПО в 2012 году привело к банкротству компании Knight Capital Group. Влияние time-to-market оказалось настолько высоко, что ради скорости жертвовали тестированием и качеством. И система из-за набора внутренних ошибок и отсутствия систем контроля просто купила акций на 7 миллиардов долларов и повесила на бизнес больше обязательств, чем та могла выполнить.

В случае с AWS, например, это вылилось в то, что руководство пытается воздействовать на сотрудников, чтобы те ставили более приятные их сердцу оценки. А не изменить что-то в бизнесе, чтобы реально повлиять на заряженность, быстрые изменения и прочие КПИ. Что называется, поставьте себе в ведомости 100%, не мучайте людей своей бесполезной или даже вредной глупостью.

Такое прямое влияние на КПИ в лучшем случае просто создаёт определённые ритуалы и шаманские танцы с бубном, чтобы система выдала нужные метрики. В худшем – начинает прямо вредить бизнесу (см., например, статью про случаи локальной оптимизации).

Хотите реальной пользы от метрик – организовывайте понятную всем систему, поверх которой и можно вешать KPI, OKR и прочие датчики. 

14. Хайп превыше смысла

"От почти всех проектов хотят видеть GenAI, в каком угодно виде. А вот вам еще KPI на использования GenAI в работе."

В середине 1990-х компания Intel была лидером рынка x86-совместимых процессоров. И слишком поверила в свою технологию IA-64, пошла ва-банк и переключилась полностью на её разворачивание. В итоге – потеряли миллиарды долларов на запуске ещё не до конца готовой технологии, открыли рынки конкуренту в лице AMD и уступила той лидерство. Просто потому, что компания AMD выпустила более простое, но куда более качественное решение AMD64 или x86-64, которое при этом было совместимо и с миллионами 32-битных приложений. Впоследствии компания Intel признала свою ошибку и сама перешла на такой “формат”.

Можно вспомнить и про ставку Microsoft на WinFS и технологию работы с метаданными вместо файловой системы. Но я тут легко что-то навру или перепутаю.

Хотя многие и делают ставку на ИИ или прочую технологию на волне хайпа, бизнес – не про технологии и не про красивые слова в резюме его сотрудников, а про клиентов, выручку и прибыль. Это не отменяет важность отслеживания и работы с новыми технологиями. Это ставит другой важный вопрос: что бизнес от этого всего получит. Только новую строчку в резюме выгорающих сотрудников?

15. Обязательный возврат в офис

"Return-to-office на 5 дней"

Многие компании ещё в 2023 году начали возвращать сотрудников с удалёнки обратно в офис, так ещё и делают это в обязательном порядке, чтобы те проводили в офисе 5 дней в неделю, как у Дмитрия из AWS. 

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

? исследование LinkedIn: сотрудники на гибридном формате работают больше чистого времени, потому на 4% более продуктивны

?По оценке Global Workplace Analytics, на каждом сотруднике США, работающем 50% времени на удалёнке, компании экономят более $10 тысяч ежегодно

?По данным Global Workplace Analytics, сами сотрудники на удалёнке могут сэкономить от $600 до $6000 в год, что может восприниматься сотрудниками как дополнительный бонус, который они не захотят потерять с возвратом в офис без компенсации

?78% сотрудников в Великобритании нашли гибрид более комфортным 

?47% сотрудников улучшили своё благополучие, получив возможность работать из дома, установила Организация экономического сотрудничества и развития

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

?За счёт уменьшения загрузки многие компании смогли перебраться в более комфортные офисы, что облегчило наём персонала, по данным того же ISG 

?Самый популярный формат офисов - open space - не только не повышает личное общение, наоборот, понижает его на 70% 

?По данным Envoy, 80% начальников, которые требовали работников вернуться в офисы в 2021-2023 годах, сожалеют об этом требовании и предпочли бы решить это иначе

?Исследование "Return-to-Office Mandates" 2024 года не обнаружило никакого позитивного влияния на бизнес этого решения среди 137 компаний из S&P500. Вместо этого упали настрой и мотивация сотрудников работать. Как вы наверняка помните, чем выше недовольство сотрудников работой сейчас, тем хуже дела у компании впоследствии.

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

Так что переход на обязательные 5 дней в офисе после удалёнки– это большие потери для компаний.

16. Слишком много или совсем без документации

"Перед каждой фичей надо написать документ. Даже если вы еще совершенно не понимаете, осуществима ли фича и как ее реализовывать."

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

Это один из таких примеров избыточной бюрократии, которая не создаёт ценности. Если в компании делают фичу, по которой на предварительном этапе документ нужно читать 15-20 минут, это точно перебор.

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

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

17. Отсутствие системности информации

"CloudFront невероятно большой. Там огроменное количество статей на вики, многие из ниx устарели, ведут не туда или просто совершенно бесполезны. Огромный контекст, который нельзя удержать в голове."

Ещё одна большая и довольно частая проблема, которая особенно остро выстреливает, когда на плохо выстроенные процессы накладывается отсутствие прозрачности. И сотрудник не понимает, что ему делать с рабочей задачей, куда идти, к кому обращаться. 

Или ему нужно разобраться в документации, а она разрознена, противоречива или содержит 150 тысяч лишних слов на 10 тысяч нужных. Как у AWS.

18. Негативный новостной фон

"Регулярно анонсируют увольнения тысячами и десятками тысяч человек. CEO требует ощущать себя как в самом большом стартапе.

Ну и конечно легендарно разослать письмо о своем видении светлого GenAI будущего и как оно нам поможет сократить наш workforce еще дальше.

И вот, за три дня до моего последнего дня: мы еще HR посокращаем и еще кого-то за компанию."

Я 7 раз работал в антикризисных проектах, когда околобанкротную компанию нужно было провести мимо кассового разрыва или вывести в плюс. И даже в таком сложном положении очень важно было находить позитивные решения и доносить их до команды: чтобы спокойно могли работать и верить в будущее компании, даже если оно было не так прекрасно, а веры не было у самого. Потому что я отлично видел не раз, насколько сильно может падать продуктивность сотрудников, насколько быстро могут увольняться хорошие работники, насколько безответственно они начинают выполнять свои задачи, когда они не ассоциируют своё будущее с компанией. Логично, что мои наблюдения подтверждались и различными исследованиями.

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

---

Антракт 

Итак, мы с вами прошли половину пути, надеюсь, сейчас вы зафиксируете, сколько баллов вы уже набрали, чтобы не потерять. Статистика Хабра говорит, что до 80% тех, кто дошёл до середины статьи, дочитывают до конца. Надеюсь, если вы ещё это читаете, вторая половина вам тоже зайдёт, там даже больше вкусного.

А пока я хочу обратиться к некоторым читателям.

Господа владельцы бизнесов, СЕО, HRD и прочие лица, принимающие решения!

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

Вам не обязательно увольнять СТО или предпринимать иные резкие шаги. 

Вы можете привлечь меня в качестве партнёра по развитию.

Мой бэкграунд - более 20 лет работы в финансах, в качестве финансового директора - с 2010 года. Моя ключевая роль - финансовый архитектор, который для отличной финансовой работы регулярно выстраивает взаимодействие и организацию ключевых подразделений. 

Мой опыт включает самые различные проекты в разных отраслях с крутыми достижениями. Я запускал в жизнь один из первых финтех-банков, много работал со стартапами и спасением компаний из предбанкротных ситуаций. В том числе - с “продажей” бизнеса инвесторам и банкам. 

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

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

В этом я буду крайне полезен целому ряду компаний. Возможно, что именно вам. Если так, вы можете связаться со мной через Telegram - @Sertakov.

Антракт закончен, перейдём ко второй части.

Вторая часть проблем

Эту часть организационных ошибок Дмитрий не описывал. Возможно, не видел. Возможно, не осознавал, что на его работу они тоже влияют. Скорее всего, просто не ставил себе цель перечислить все замеченные “баги”. Главное, что это тоже серьёзные проблемы, которые сильно бьют по сотрудникам, их уровню удовлетворения работы и возможности спокойно и продуктивно трудиться, а следом - вредят результатам бизнеса.

Продолжим считать дальше.

19. Отсутствие или несоблюдение стратегии

Статистика того, как компании разрабатывают и воплощают стратегию, удручает. Взять, например, данные Bridges Building Consultancy из «20-Year Results From Surveying Strategy Implementation» 2020 года:

?85% компаний не достигают даже ⅔ из запланированных целей 

?только 20% руководителей отслеживают достижение стратегических целей хотя бы раз в месяц

?всего у 28% компаний работает система отслеживания ключевых метрик

?80% руководителей на стратегические задачи тратят меньше 20 часов в месяц, а 48% – не тратят даже 8 часов

?61% руководителей признаются, что их стратегия внедряется плохо или «недостаточно успешна», а всего 64% считают, что они имеют все необходимые для этого навыки.

В «работе без фокуса» я предлагал посадить экономиста, который бы хотя бы давал примерные ориентиры по тому, какую пользу для клиентов и бизнеса принесёт продукт, фича или доработка. Вот хорошо было бы этому сотруднику ещё и добавить право задавать неприятные вопросы в духе: «А как это связано со стратегией?» Или хотя бы «А как это соответствует нашим долгосрочным приоритетам», но об этом в следующем пункте.

P.S. Если вам нужны примеры хороших стратегий, есть подходящая статья.

20. Отсутствие приоритетов 

Исследование Gallup «The Manager Experience: Top Challenges & Perks of Managers» 2019 года выявило, что 42% директоров имеют множественные конкурирующие между собой приоритеты. И эти 42% смогли осознать такую проблему. Сколько из оставшихся 58% просто не могут это выявить или боятся признаться?

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

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

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

В одном из исследований 81% сотрудников подтвердили мысль, что расстановка приоритетов очень важна для выполнения их задач, но только 31% сказал, что их руководство хотя бы иногда это делает. То есть, команда и работники оказываются в условиях, когда они сами должны разбираться с тем, что и в какой последовательности реализовывать. Или им приходится внедрять и одно, и другое, и третье, жертвуя качеством решений, разработки и тестирования. 

А значит – надо ставить приоритеты и доносить их до сотрудников.

21. Дискредитация стратегии

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

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

Не надо так.

22. Постоянные отвлечения

Мы теряем 15-20% времени в среднем из-за отвлечений и переключения внимания. А отдельные сотрудники или представители некоторых профессий - даже больше. Почта, телефон, обращение коллег, посторонний шум, какая-то активность на заднем плане - что угодно может сбить концентрацию сотрудника и заставить его потратить лишнее время на повторное включение в задачу, а то и повторное её решение. И такие события происходят в среднем у работников 15 раз в час. Каждые 4 минуты! Достаточно одной минуты на сторонние активности, чтобы к решению сложной задачи человек смог полноценно вернуться спустя 20 с лишним минут! 

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

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

Статистика показывает, что в периоды, когда сотрудник может сфокусированно работать над своими задачами без отвлечений и постоянных вмешательств, его производительность труда вырастает на 40-80%. Для руководителей эта цифра и вовсе доходит до 200-300%. 

23. Организационный долг

Нет, я не про технический долг, это отдельная песня. 

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

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

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

Или же мы гонимся за time-to-market или форсированно делаем какие-то задачи, которые нужны «вчера», и проводим performance review или даже code review поверхностно и для галочки. Просто не до того. И получаем брошенных на произвол сотрудников или упавшее качество кода. Ах, да, в ИТ же time-to-market – ключевая метрика, так что это происходит чуть ли не постоянно, верно?

24. Технический долг

Ровно та же история. Снова мы бегаем за двадцатью тремя зайцами сразу в попытке, чтобы наш time-to-market познал дзен и 42. А на выходе – не успеваем рефакторить код, игнорируем обновления библиотек или фреймворков, не делаем автотесты.

Не финансисту вам про техдолг рассказывать.

25. Хаос в процессах

Вот так может выглядеть типовая схема какого-то отдельного процесса в ИТ.

Эта схема - чистая метафора огр взаимодействия (именно ОГР, не очепятка).

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

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

Фактически, одной схемой закрывается весь процесс, когда сперва руководитель проекта определяет операционный план по проекту, а затем – уже происходит его перевод в цифры для бюджетирования. А если на его распечатку добавить даты, к которым каждый этап должен быть выполнен, получается готовый рабочий документ.

В итоге при хорошей изначальной проработке плана уже в ходе реализации достаточно было встретиться с руководителем проекта раз в неделю на 5-10 минут, уточнить, всё ли идёт по плану, а затем, при необходимости, ещё за полчаса поправить данные в 1С и финмодель, чтобы по проекту и для компании в целом был актуальный бюджет на следующие 12-18 месяцев. (Ах, да, план-факт выверялся по операционному плану, это тоже важно)

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

26. Борьба с конфликтами

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

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

И если мы боремся с конфликтами, а не их причинами, мы только закрываем глаза на реальные проблемы, игнорируем их будущее развитие в реальные кризисы, так ещё и получаем сотрудников, которым всё равно.

27. Фасилитация проблем

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

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

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

28. Агенты изменений не видят всей картины

Исследование McKinsey «How many people are really needed in a transformation?» 2021 года прямо показывает, что для успешной реализации изменений надо вовлечь хотя бы 7% сотрудников, а в идеале – свыше 10%. 

Для начала – стоит показать всю картину хотя бы для 7% сотрудников. Для 7% самых важных сотрудников.

29. Простои и панические релизы

В 2017 году исследование "The 1E 2017 IT Incident Response Report" выявило, что 29% времени ИТ занимается реагированием на различные инциденты и события. Понятно, что в их число входит и проблемы из-за кибербезопасности.  

Есть и статистика от Forrester, согласно которой 41% компаний сталкиваются с простоями минимум раз в месяц. То есть, в типичной компании каждые 1,5 месяца происходит плановый пожар. Который приходится срочно латать и без того измученными плохой организацией сотрудниками.

Пункт №29, но встречается довольно часто. И часто является отражением огромного числа прочих проблем.

30. Отсутствие резервов 

У многих почему-то есть уверенность, что идеальная организация – когда сотрудники всё время трудятся и не тратят ни минуты времени. Но даже японские корпорации, добившиеся высочайшего уровня организации своих производственных цепочек и планирования выпуска продукции, из-за чего могли работать нон-стоп 99% времени, закладывали 5% резервов на мощности. То есть, даже идеальный сценарий организации предполагает простои, паузы и резервы. 

Об этом же говорит и классическая формула Кингмана:

Очередь = Вариативность Загрузка (1 – Загрузка).

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

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

Но, всё равно, не менее 10%.

31. Митинги по утрам, работа - вечером

Исследование «Breaking down the infinite workday» от Microsoft затрагивает тему лишних митингов и отвлечений: почти все встречи приходятся на период с 9 утра до 15. Ещё отмечается, что в 11 утра корпоративная переписка достигает пика. 

А это самые продуктивные часы, которые у менеджмента и сотрудников забиты совещаниями и перепиской, а не работой. 

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

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

Тем более, что такой простой подход позволяет существенно улучшить работу и сотрудников, и руководства: оцениваемый прирост качества и продуктивности составляет до 60-80% для работников и до 200% для руководителей.

32. Отсутствие онбординга (особенно - для тимлидов)

Онбординг – это очень важно. Хороший процесс «приземления сотрудника» повышают шансы на то, что сотрудник останется в компании, на 82%. Но только 12% работников согласны, что в их бизнесе хороший онбординг, согласно Gallup, а 30% сотрудников уходят с работы в первые 90 дней, в том числе и из-за плохой организации их появления в компании.

Но самый проблемный онбординг - первое повышение до должности руководителя. Для большинства — это огромный стресс, в этом признались 84% менеджеров по итогам опроса «The Frontline Leader Project» в 2019 году. И главную причину вскрывает всё то же исследование: сотрудники просто не готовы к повышению в 90% случаев. Ещё раз, 9 из 10 новоиспечённых менеджеров признаются, что они не готовы к своей должности. 

Более того, в среднем своё первое обучение тому, как быть менеджером, люди проходят только через 4 года после повышения. То есть, большинство руководителей брошены на произвол судьбы и предоставлены сами себе, вынуждены самостоятельно разбираться с трудностями. Всё то же исследование прямо говорит: 55% менеджеров среднего звена не получают поддержки от топов. И, соответственно, вряд ли могут её оказать снизу своим директорам.

Плохой онбординг – массовый бич в современном ИТ. Особенно – для новоявленных тимлидов, которые должны за несколько месяцев и вкатиться в новые обязанности, и начать показывать результаты, словно они родились с полком в подчинении. 

33. Раздавать задачи сверху

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

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

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

34. Использовать метрики, ревью и прочие практики для критики 

На одной из HR-конференций выступающий рассказывал, как они попытались системно оценивать сотрудников и добавили к регулярной аналитике информацию о том, как ещё работники вкладываются в жизнь команды, помимо регулярной деятельности. Учитывалось многое: менторинг и коучинг, прямое обучение и разбор личных кейсов, помощь в систематизации знаний и актуализация инструкций. Вот только на выходе СТО начал требовать, чтобы команда комплексно включалась в каждую из задач. А за просадку в той или иной «общекомандной активности» - критиковать. И им даже не учитывалось, что все люди разные, что каждому лучше самостоятельно выбирать, как именно он совершает свой вклад в жизнь коллектива (см. предыдущий пункт). Нет, теперь каждый должен был делать что-то в каждом направлении. И новые метрики, которые должны были показывать особенную роль сотрудников в команде, превратились в инструмент для критики.

Я привык к тому, что перформанс ревью нужен для того, чтобы сотрудник мог развиваться, исправлять свои ошибки, улучшать свои сильные стороны. Просто потому, что это один из самых лучших способов дать обратную связь: качественно пройтись по выполненному и достигнутому. Оказывается, что и перформанс ревью становится таким методом критики. И довольно часто. 

Увы, согласно мировой статистике, 40% менеджеров управляют только через страх, а ещё какая-то доля руководителей по незнанию или неумению используют метрики, перформанс ревью и прочие практики для критики, а не более комплексно. Не надо так, это не молоток, а многогранные инструменты.

35. Неправильный выбор стека технологий и подходов

По разным оценкам, до 70% ИТ-проектов терпят неудачу из-за неверного выбора стека технологий. 

31% - просто проваливаются. А в остальных ошибки выбора стека технологий увеличивают цену проекта на 50-100%. Портал Full Stack даёт даже более пессимистичные оценки: в 52% случаев рост бюджета составил 189% от изначальной, а сама ошибка выбора стека технологий обходится бизнесу в 2,3 миллиона долларов. В среднем. 

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

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

36. Массовые сокращения

Фондовый рынок – довольно странная и не самая логичная штука. Он одинаково позитивно реагирует на объявления компаний как о расширении штата, так и их сокращений. Первое понятно: бизнес набирает людей, чтобы обеспечивать дальнейший рост, развиваться и двигаться дальше. А вот второе не очень.

Да, увольнения можно трактовать как урезание лишних расходов, как операционную оптимизацию, вот только многочисленные исследования прямо показывают, что сокращения примерно в 3 раза чаще приводят не к росту, а к ухудшению результатов и даже падению продуктивности. И даже сравнительное небольшое сокращения 5% штата повышают желание лучших сотрудников уволиться на 20-30%.

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

Я не говорю, что увольнять и проводить реорганизации не нужно. Нужно, просто нужно делать аккуратней. Потому что обычная практика в ИТ включает в себя отвратительную организацию, потерю фокуса, много лишней и бесполезной активности и прочие описанные в этой статье проблемы. И когда возникают проблемы, начинают бороться с последствиями или локально оптимизировать ФОТ, а не бороться с первопричиной.

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

Итоги и рекомендации

Мы с вами вкратце разобрали 36 организационных ошибок бизнеса. 

Я и не буду их повторно перечислять, лучше дам рекомендации по их исправлению.

Первое и самое определяющее. Фокус. 

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

Уже только на этом этапе вы можете отказаться от серьёзной доли своих прежних активностей, до 30-50%. В моей практике и вовсе был случай, когда благодаря моему вмешательству проект сократил более 75% своих активностей и сфокусировался на разработке единственного продукта, а не 3 сразу.

И, конечно, вы можете при этом делать ставку на хайп, но только если это чужой хайп, на чём вы и собираетесь зарабатывать.

Второе. Процессы и системы

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

Проще всего сперва убрать всё ненужное: избыточную бюрократию, лишние встречи. Затем - организовать, чтобы работало, с чёткими зонами ответственности, без совместительства и лишних “вовлечённых”. И потом - не забыть устранять накопленные долги: организационные, технические, коммуникационные.

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

Третье. Продуктивность

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

Нет, частично эти мероприятия вы можете реализовать и сразу. Например, дни тишины показывают свою продуктивность с первых же недель даже без прочих серьёзных изменений. Но самых лучших результатов, когда продуктивность сотрудников может вырасти на 30-50%, а руководителя - даже на 100% и выше, добьётесь только после более-менее внятных результатов по первым этапам.

Отражу этот комплекс идей на одной схеме для наглядности.

Agile и организация

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

Так или иначе, как только в IX веке викинги набили руку совершать такие вылазки, собрали определённую систему знаний и начали успешно передавать их молодёжи, как только восточное побережье Англии стало знакомо, а путь туда - предсказуем, датчане организовали серию миссий с целью колонизировать Британию и принести ей немного Одина на постоянке. Поначалу тоже строили свои операции на чистом Agile, и били бритов с переменным успехом. Опыт набирался быстрей посетителей Вальгаллы, и где-то с 865 года, когда викинги смогли от Agile перейти к более сложным формам планирования и организации миссий по колонизации, до конца IX века успешно завоевали примерно четверть острова Великобритания, между современными Лондоном до Ньюкаслом.

Потом, правда, в своих попытках выстроить государство Денло по Agile викинги провалились и были биты окружающими их и более организованными бритами, которые уже давно перевели управление государством с гибких и проектных рельсов на процессные. Потому были готовы проиграть в сражении, чтобы выиграть в войне.

Позже этот опыт раннего Agile активно применялся и в прочих случаях. Например, пиратами той же самой Англии, которые намного позже викингов устраивали рейды уже на заокеанские территории и прочие активы Испании.

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

Статистика из книги "Tercios de España: Una infantry legendaria" говорит о том, что за период с 1540 до 1650 год из 11 тысяч гружёных золотом испанских кораблей, которые плыли из Америки в Испанию, 110 было захвачено пиратами (разных флагов). В это же время самый большой удар нанесла погода и природа - из-за неё было потеряно 519 кораблей. 

Историк Сергей Махов даёт такую статистику за более полный период: британцы смогли забрать около 3-4% золота или даже менее, а всего в Испанию было доставлено свыше 80% от всего добытого золота. То есть, в пике эффективность британских пиратов не превышала 5-7%. А зарабатывали они чаще всего на грабеже и разорении приморских поселений и слабо защищённых городов.

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

Так что Англия на эти украденные "по Agile" деньги себе бы империю не построила, даже если бы очень хотела. Равно как ни одна страна с помощью пиратов не добилась каких-то значимых прорывов.

Причина подъёма Британской Империи была заложена в её островном положении и в стратегическом решении содержать минимальный уровень армии. Британии не нужно было воевать за прилегающие территории, как это активно делала Испания, на что и потратила практически всё добытое золото. Вместо этого Англия сфокусировалась на строительстве флота, чтобы сперва противостоять любым телодвижениям противников. А затем - организовала целую систему управления для основания колоний по всему миру. Взять ту же Индию, откуда было вывезено сырья на 30-45 триллионов долларов в текущих ценах, если верить исследованиям.

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

Agile - хорошая практика. Но не везде. И для строительства империй и крупных успешных компаний её не достаточно, на верхнем уровне должна быть хорошая организация. Со стратегическим фокусом, прозрачными процессами и адекватными условиями, чтобы сотрудники могли спокойно и радостно причинять пользу своим нанимателям.

В качестве эпилога. Это для всех

В названии статьи я спросил, не пора ли уволить СТО?

Но, если посмотреть на список проблем внимательно, почти все они так или иначе относятся напрямую к любому директору, включая CEO. 

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

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

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

---

Этот лонгрид - логическое развитие системы, описанной в двух бесплатных книгах.

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

И обе доказывают и описывают простое, но очень верное правило:

Счастливый сотрудник - успешная компания

Обе книги вы можете прочитать, перейдя по ссылке, бесплатно, без СМС и регистраций.

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

Если у вас есть возможность, делитесь материалами, статьями и книгами с друзьями, знакомыми, на конференциях и тем, кому они могут быть полезны.

Все эти статьи и книга пишется по мотивам заметок, которые я регулярно пишу в своём канале «Тру финансы». Если тема управления вам интересна, подписывайтесь на мой телеграм‑канал.