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

Как я перестал волноваться и полюбил менеджеров среднего звена Несколько лет назад я работал в Juno, интернет-провайдере в Нью-Йорке и мой шеф назначил меня на должность технического менеджера. Как и прежде, я руководил двумя сотрудниками. Juno пользовалась инвестициями из D. E. Shaw – компании, в которой работал Джеф Безос до того, как основал Amazon. . В компании Juno работало около 150 человек. По моему мнению число менеджеров было не рационально. Для интернет-стартапа, Juno имела устаревшую структуру. Это работало не так хорошо. Я замечал много ситуаций, когда топ-менеджеры охотно принимали решения, даже когда они были недостаточно квалифицированными, чтобы подобные решения принимать. Я не говорю, что они были глупее остальных. Большинство менеджеров в Juno были довольно умны. Но они были умнее людей, которые их наняли: дипломы, острый ум и многолетний опыт работы. И эти люди долго работают над задачей, выпускают очень хорошее решение, а потом с удивлением видят, как их начальство все отменяет. Руководители, не имеющие достаточных технических знаний, и недостаточно изучившие проблему опускаются на нижний уровень и выдают случайные указания, которые необходимо выполнять – нередко с печальными последствиями. Я назвал такой микроменеджмент «порулил и убегай». Подозреваю, что менеджеры Juno действовали так потому, что многие из них были молоды и видели, как поступают начальники только по телевизору. До прихода в Juno я работал в Microsoft, где обстановка была совершенно иная. Небольшая история из Редмонда: два дизайнера устроили спор по какому-то вопросу. Вопрос сугубо технический. Они не могли прийти к согласию, поэтому отправились к своему начальнику, парню по имени Mike Maples, который был вице-президентом и отвечал за выпуск этого продукта. «Что я об этом знаю? Из трех человек в этой комнате, я знаю меньше всего. Вы, ребята, спорили над этим несколько часов. Я – последний человек, который должен принимать решение. Разбирайтесь сами». Они так и сделали. Когда мой партнер Майкл Прайр и я ушли из Juno, чтобы основать Fog Creek Software, мы хотели нанять лучших людей, а затем только направлять их. Инстинкт подсказывал мне отказаться от менеджеров среднего звена. И в правильности этого подхода я еще больше убедился после того, как прочитал статью в одном бизнес-журнале. Статью об удивительном заводе General Electric в Северной Каролине, на котором собирались реактивные двигатели – на нем работали 170 человек и всего один начальник. Все техники подчинялись непосредственно начальнику завода, у которого просто не было времени для микроменеджмента. Не было расписаний, люди сами устанавливали себе планы. Оплата была справедливая, работники, собиравшие двигатели, могли переключаться между различными задачами каждый день, и поэтому их работа не была единообразной. Результат? С точки зрения качества, завод был практически совершенен. Три четверти двигателей, которые они выпускали, были безупречными. Оставшаяся четверть имела незначительные косметические дефекты. После Juno, обстановка на этом заводе GE казалась торжеством независимости. Я решил, что Fog Creek скопирует эту модель. Мы хотели обойтись, насколько это возможно, без менеджеров. У всех сотрудников были одинаковые названия должностей, и все они подчинялись мне. Ну, что-то в этом роде. Майкл был нашим президентом. И он, и я были равноправными партнерами, поэтому если нужно было обсудить что-то действительно важное, нужно чтобы присутствовали мы оба. Но все остальные были равны. И так все и было, все отчитывались мне (и Майклу), система работала прекрасно. Fog Creek рос медленно. Мы не нанимали пятого сотрудника до 2005 года, пять лет. Затем, в прошлом году, мы начали понимать, что ситуация изменилась. В Fog Creek работало 17 человек над двумя линейками продуктов, но менеджеров по-прежнему не было. И непонятно почему, люди стали раздражительными. Они стали периодически собираться в кабинете одного из старших программистов, чтобы поворчать. В конце концов, они поняли, что ворчание не принесет результатов, поэтому направили делегацию из двух старших сотрудников поговорить со мной и с Майклом. Переговорщики были крайне вежливы. «Мы беспокоимся по поводу карьерного роста», сказал один из них, объясняя, что на самом деле беспокоит сотрудников, и чего я не мог понять. Потом к нам пришел еще один программист. «Я думаю, вы должны знать, что люди очень недовольны», сказал он откровенно. «И получается так, что люди просто весь день жалуются, вместо того чтобы делать свою работу». Я провел неделю в долгих разговорах с каждым и узнал, что действительно происходит. У наших сотрудников были некоторые вопросы по поводу вознаграждений – как мы распределяем прибыль и опционы – которые мы разрешили. Но они также заявили, что Майкл и я фактически для них недоступны. Если вы хотите поговорить с руководством, то вам нужно найти время, когда оба руководителя свободны, и многие люди были слишком напуганы, чтобы делать это. Это удивило меня, потому что мои двери всегда открыты и человек может зайти и задать мне любой вопрос. Я не понимал, что наводил страх на некоторых новичков. Мы решили проблему доступности двумя путями. Во-первых, мы ликвидировали требование, чтобы обязательно присутствовали Майкл и я. У вас есть вопрос? Я – CEO. Поговорите со мной. Если я хочу проконсультироваться с Майклом, это мои проблемы, а не ваши. Во-вторых, мы назначили руководителей двух команд программистов – по сути, создавая тот слой, которого хотели избежать. И, кажется, люди стали немного счастливее с появлением менеджмента среднего звена. Не менеджеров, которые самостоятельно отменяют их решения. Не формальных должностей, которые придают важности. Но уровня, который создает полезный канал связи. Если моя работа – убирать препятствия, которые могут возникнуть на пути сотрудников, то теперь это еще и работа менеджеров; когда у сотрудника локальная проблема, в соседнем офисе есть кто-то, с кем он может ее обсудить. Финальная мысль: вы должны быть осторожны, когда речь заходит о новейших бизнес-идеях. Картина, увиденная глазами журналиста как новая классная философия для организации работы компании, должна рассматриваться в свете других доказательств, таких как опыт других компаний, которые внедрили ее. Может быть, завод GE в Северной Каролине исключение из правил. Может быть, в статье многое преувеличено. Может быть, статья была абсолютно точной, но такая модель работает только при сборке реактивных двигателей и не подходит для разработчиков программ. Или может быть, менеджеров на этом заводе заменили какими-то механизмами.


Карта сайта


Информационный сайт Webavtocat.ru