Кризис роста: в команде «что-то не то». Что с этим делать?

Привет! Мы — ИТ-компания CodeInside! Разработчики программного обеспечения.
Когда-то наша история начиналась с 4-х человек. С течением времени, команда росла, нам удавалось преумножать ту теплую атмосферу, которая была создана в самом начале. И вот, спустя 14 лет, число клиентов стало сильно больше, команда выросла в 25 раз, а теплая атмосфера, царствующая на протяжении десятилетия и даже больше, начала ощущаться как-то иначе. Но как — объяснить сложно.

И от ребят, заставших CodeInside в самом начале пути, все чаще стала звучать фраза «КодИнсайд уже не тот».

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

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

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

Ламповость — термин собирательный и у каждой команды может быть свой, например:

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

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

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

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

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

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

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

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

Часто, когда мы говорим про «ламповость», мы говорим про отсутствие формализма. А формализм — это зло? А ТЗ — это зло? Как вести разработку, когда нет технического задания?

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

Ламповость в растущей компании возможна хоть в какой-нибудь форме?

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

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

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

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

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

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

Как мы это поддерживаем ламповость в CodeInside? Создаем тёплые отношения в команде:

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

Важно сохранять человечность.
То, что мы делаем с душой, получается качественнее и это хочется поддерживать.