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

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

• Имеет ли значение 9:30 (или любое произвольное время)? Или ваша команда должна убедиться, что они не мешают работе других команд своим отсутствием?

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

• Является ли неформальность проблемой? Или гибкость является преимуществом?

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

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

Представьте проблему как вызов команде и посмотрите, что они придумают. Ответом может быть установленное расписание или что-то другое, что решает проблему. Это может быть понедельник, среда, пятница — рабочие дни в 9 утра, а вторник и четверг — гибкие дни. Хотя план может быть не идеальным и не таким, каким вы его себе представляли, найти золотую середину где-то, что порадует как команду разработчиков, так и решит актуальную проблему, не даст вашим сотрудникам ожесточиться и увидеть в вас врага. .

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

Моя команда не появляется вовремя. Я пытался заставить их, и это не работает.

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

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

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

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

Для вдохновения см. Интервью Сета Година о разнице между лидерством и менеджментом . Я настоятельно рекомендую всем и каждому, занимающим руководящие должности, посмотреть это короткое интервью.

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

Если единственная причина, по которой вы внедряете политику, заключается в напряженности в отношениях с людьми из других отделов, ваша задача — справиться с этой напряженностью, чтобы ваши люди могли работать наиболее эффективно. Хотя я не думаю, что это единственная причина. Например, что, если разработчику требуется решить срочную производственную проблему, которая возникает в 8:00, 9:00 или в любое другое время? Однако вряд ли вам нужно всеваши разработчики присутствуют, чтобы исправить эту проблему. Что если бы у вас был чередующийся (если кто-то не добровольно) «ранний» график, так что каждый разработчик по очереди должен быть там в 8:00 (или 9:00 и т. д.)? Такое решение, скорее всего, удовлетворит как потребности бизнеса, так и желания ваших сотрудников. Все «разделяют боль» (или причиняют ее тому, кто не против). Люди могут приходить и работать большую часть времени, когда они чувствуют, что будут наиболее продуктивными. Это всего лишь одна из возможностей, но она может вызвать дискуссию с вашими сотрудниками о том, как решить настоящие проблемы и удовлетворить интересы всех здесь.

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

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

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

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

Более конструктивно я бы предложил вам рассмотреть следующее:

• У ваших разработчиков было гибкое время. Теперь вы хотите забрать его

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

• Какова природа этого "беспокойства", о котором вы говорите? Это а) в первую очередь ревность или б) законные проблемы межведомственного общения, такие как трудности с планированием встреч / общего общения.

а) Разработчикам не нужно взаимодействовать с клиентами или другими предприятиями. По моему опыту, чем жестче структура компании, тем более посредственны ее разработчики. Хотя большая часть разработки состоит из основ и болтов, это также творческий процесс решения проблем, который требует от людей максимальной проницательности. Это также непредсказуемый процесс, связанный с крайним сроком, который иногда приводит к очень, очень поздним часам. Побочным эффектом этого является то, что к разработчикам часто относятся «творчески». В компании из 30 человек не должно быть сложно настоять на том, чтобы люди были взрослыми в отношении сотрудников, которые должны быть на высоте, когда они присутствуют, и, вероятно, в конечном итоге проработают гораздо больше часов в течение года, чем работник с 9 до 5. обычно собирают вещи каждый день в 16:55.

б) В компании из 30 человек не должно быть так много совещаний, чтобы это стало проблемой. Не считая таких вещей, как спринт-встречи или другие встречи по планированию, проводимые раз в два месяца, привязывать своих разработчиков более чем на 30 минут каждый день к собраниям — это абсурдная и крайне некомпетентная трата денег. Так же и с общим общением. 30 человек означает, что вы подходите к другому парню и разговариваете с ним. В сценариях с гибким графиком разумно установить промежуток времени, когда все находятся в офисе одновременно. Я не могу придумать вескую причину, по которой этот промежуток должен составлять более 3-4 часов рабочего дня, и почему он не должен быть как можно ближе к середине дня.

• Почему утренний стендап?

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

• Ваши разработчики не справляются со своей задачей?

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

Обзор вопроса: Отсутствует много контекста и информации

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

1. Насколько новый технический лидер?
2. Почему вы навязываете чисто нетехническую управленческую политику?
3. Каковы ваши управленческие полномочия?
4. Какой предыдущий опыт управления персоналом у вас есть?
5. Вы заслужили уважение команды технически?
6. Вы заслужили уважение коллектива управленческой манерой?

TLDR: моя команда не появляется вовремя. Я пытался заставить их, и это не работает.

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

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

Фоновые данные:

Небольшая компания, 30 сотрудников, 5 человек в моей команде. Предыдущий руководитель по-прежнему работает штатным разработчиком.

1. Ушел ли предыдущий технический руководитель?
2. Был ли предыдущий технический руководитель понижен в должности?
3. Было ли предыдущее техническое руководство эффективным?
4. Есть ли у большей части существующей команды более личные отношения с предыдущим техническим руководителем?
5. Действительно ли предыдущий технический руководитель по- прежнему отвечает ?

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

1. Тогда он должен был работать?
2. Удалось ли команде создать полезные продукты, когда они обещали?

Из-за этого большинство людей в команде появлялись между 10:30 и 11:00. Другие отделы, в силу характера своей работы, установили время начала либо на 8, либо на 9. Это несоответствие и непредсказуемость вызывают много беспокойства между моим отделом и другими отделами.

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

Таким образом, я усадил команду и указал время «не позднее» 9:30. Я объяснил свои рассуждения и объяснил преимущества такой схемы и недостатки текущей схемы. Это был долгий и спорный разговор, и 3 из 5 человек в команде были крайне недовольны.

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

Излишне говорить, что люди не приходят вовремя (и 9:35 не вовремя).

Это не похоже на очень позитивное или эффективное отношение.

Я запланировал нашу ежедневную встречу в 9:30 в качестве дополнительной мотивации. Зная, что для перехода к началу встречи требуется немного времени (с учетом поездок на работу и т. д.), я сначала ждал, чтобы начать встречу, пока все не появятся, но теперь я просто начинаю встречу (и часто заканчиваю встречу) с кто бы ни присутствовал. Похоже, это тоже ничего не меняет и делает команду менее сплоченной.

Таким образом, односторонние действия , которые вы предпринимаете, делают команду менее сплоченной. Подумайте об этом .

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

Мы слышим и можем экстраполировать то, что они не принимают, вы их слышите ?

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

Католическая церковь имела такую ​​же власть во времена инквизиции, посмотрите, чем это обернулось!

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

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

Прогнозируемый результат вашего текущего подхода

1. Вы потеряете всякое уважение со стороны всей команды, они будут все более и более неэффективными, вас будут воспринимать все более и более неэффективными, поскольку производительность остановится.
2. Ваша неудача с изменением политики и навыками управления персоналом приведет к тому, что начальство будет считать вас неэффективным.
3. Вы потеряете уважение со стороны людей , не входящих в вашу команду, из-за межофисного общения. Это также саботирует любые будущие возможности технического лидерства с ними.
4. Вы наверняка навредите своей репутации в компании, вверх и вниз по цепочке.
5. Лучшие сотрудники уйдут первыми.
6. Даже лучшие сотрудники тихо уволятся вслед за ними.
7. Малоквалифицированные могут уйти, а могут и не уйти, в зависимости от причиняемой вами боли.
8. Неквалифицированные будут цепляться, как клещи, и терпеть все, что вы им навязываете.
9. Компания в конечном итоге проигрывает и получает плохую репутацию из-за ушедших сотрудников.
10. Восприятие решает все! Никогда этого не забывай!

Некоторые предлагаемые подходы

1. Как их менеджер, вы должны бороться за то, чтобы изолировать их от решений высшего руководства. Вы должны бороться за то, чтобы их голос был услышан. Вы должны помочь им коллективно сформировать ответ, оттолкнуть и поддержать их своим ответом.
2. Это не техническое решение, а чисто корпоративное. Почему вы имеете дело с этим и его реализацией? Иметь превосходную сделку с этим, это их работа.
3. Не ведите себя как диктатор или тиран. Сила не равна правде.
4. Возьмите некоторые навыки работы с людьми, обучение навыкам общения.
5. Двигайтесь медленнее. Такие вещи не меняются за ночь.
6. Вам нужно привлечь предыдущего технического руководителя на свою сторону, если у него есть взаимопонимание с командой.
7. Есть альтернативный компромисс, как насчет того, чтобы люди, которые не против прийти пораньше, сделали это, другим людям это не нужно?
8. Перенос времени стендапа произволен, все это видят и воспринимаются не как практичные или разумные, а как диктаторские.
9. Попросите внешние команды, с которыми вам приходится иметь дело, принять участие в обсуждении и помочь вам продать изменения политики.
10. Отойди, согласись с ними, будь Хорошим Копом. Попросите своего начальника издать закон. Это проблема управления, а не техническая проблема. Вы технический руководитель, а не менеджер, верно?
11. Пусть внешние члены команды и члены вашей команды просто выработают время, чтобы встретиться, когда им нужно встретиться. Заранее определенные дни и время доступности были бы хорошим компромиссом. Разработчики не хотят, чтобы их постоянно отвлекала внешняя команда, и кажется, что они присутствуют исключительно для того, чтобы прыгать на встречи по их требованию.

Заключительная мысль:

Мой стиль управления, как технический, так и нетехнический, основан на принципах У Вэй из «Дао дэ цзин».

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

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

Косвенное прозрачное лидерство

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

Будьте недирективны, сделайте несколько слов ценными. Когда работа сделана, цель достигнута, все скажут: мы сделали это сами, естественно.

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

Первое, что вам нужно сделать, это прочитать «Peopleware» .

Было бы ошибкой пытаться изменить это сейчас. Я был менеджером в компании, где у нас был довольно гибкий график работы. Один из наших самых продуктивных разработчиков пришел в 11 утра. Он докладывал мне какое-то время. Мне сказали заставить его изменить часы. Я боролся с этой просьбой. Жесткий. Я был отвергнут.

Результат:

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

Все из-за какого-то глупого понятия «вовремя».

Больше внимания уделяйте продуктивности.

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

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

Как «новый технический руководитель» вы не сможете быстро изменить корпоративную культуру. Особенно в том направлении, которое вам кажется нужным. Сделали ли вы что-нибудь для улучшения ролей/должностей в вашей команде?

Сначала работайте над установлением доверительных отношений с ними. Так много начинающих менеджеров/лидов совершают подобные ошибки.

Узнайте, что ДЕЙСТВИТЕЛЬНО нужно другим группам. Не «они должны быть здесь в 9:30». На самом деле выяснить, в чем проблема. Тогда найдите решение для этого.

Вместо того, чтобы указывать своей команде, что делать, объясните проблему, а затем ПОПРОСИТЕ ИХ ПРЕДЛОЖЕНИЯ/ОТЗЫВЫ.

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

Я пытался заставить их, и это не работает.

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

Еще раз прочтите "Peopleware".

Вы не пойдете далеко с такими идеями, как ежедневные встречи или отправка людей домой, или с идеей, что они ваши миньоны, которые должны делать то, что вы говорите, «или иначе».

Кто сказал вам, что им нужно быть на работе в 9:30? Другие группы? Ваши боссы? Ты? Выясните НАСТОЯЩУЮ проблему и решите ее. Когда они появляются, НЕ должно быть проблемой.

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

По сути, вы просите их сократить общий компенсационный пакет.

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

Судя по вашему описанию, основной причиной является зависть со стороны других отделов. Рассматривали ли вы возможность дать другим отделам такую ​​же привилегию?

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

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

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

Нравится вам это или нет, но вы унаследовали культуру гибкого графика, что является огромным преимуществом для большинства разработчиков. Лишение этого у них в одном из ваших первых действий в качестве лидера не только покажется им тираническим (когда вы объясняете им, что 9:30 не так уж и рано, вы навязываете им свой собственный график, произвольно в их мнение), но на самом деле это вычитание существенного бонуса. Вам может нравиться работать по определенному графику, и вы не считаете это значимой привилегией, но они, вероятно, считают это неоценимым. Считайте это наравне с заявлением, что вы отбираете у них неделю отпуска или урезаете их зарплату на несколько процентов.

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

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

Короткий ответ: вы НЕ должны этого делать. Члены вашей технической команды достаточно умны (или, по крайней мере, должны быть ), чтобы понимать, что нет никакой ощутимой выгоды от присутствия всех в офисе в произвольное время; единственный важный показатель — это то, выполнена ли их работа.

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

Часть вашей роли как лидера состоит в том, чтобы изолировать вашу команду от тривиальных отвлекающих факторов и критики, вызванных внешними источниками. Если ваша реакция на то, что другие люди жалуются на членов вашей команды, состоит в том, чтобы передать жалобы членам вашей команды и/или диктовать изменения, основанные исключительно на этих жалобах, то вы терпите неудачу в своей работе. Я бы посоветовал, предполагая, что ваша команда на самом деле выполняет свою работу (а это звучит так, поскольку вы не жалуетесь на их производительность), лучший способ отреагировать на такую ​​критику — это сказать жалобщик: «Да, мои ребята усердно работают и постоянно добиваются хороших результатов, и это единственное, что имеет значение; так почему бы вам не перестать беспокоиться о том, как моя команда справляется со своими задачами, и вернуться к своим?».

И, конечно же, если вы придерживаетесь обязательной политики «вы должны быть в офисе к времени X», справедливо будет дополнить ее политикой «вы должны покинуть офис к времени Y» и политикой «вы должны не работать из дома в нерабочее время». Это справедливо только как способ сохранить баланс между работой и личной жизнью вашего сотрудника, так как я уверен, что многие члены вашей команды, которые не появляются до 11:00, вероятно, либо остаются допоздна, либо проводят дополнительное время дома.

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

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

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

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

Похоже, вы сделали правильные вещи:

• ты четко изложил

• вы говорили о причине и необходимости перемен

• вы занимались один на один (и, я полагаю, продолжаете это делать), чтобы исправлять отдельные случаи по мере их поступления

• вы оставили отзыв

Я думаю, вы дошли до "он действительно это имеет в виду?" момент, когда это в основном доказывает людям, что вы настроены серьезно и что это действительно нужно изменить. По моему личному мнению, опоздание на 5 минут в офисе в моем регионе не имеет большого значения, и что встречи, которые имеют короткий промежуток времени (например, стендапы в agile-спринте), не должны быть такими неприятными в начале. рабочего дня, что пропущенное автобусное сообщение или плохой трафик станут регулярной проблемой. Но это несколько регионально — в разных местах ситуация с дорожным движением сильно различается. Так что это все равно, что знать свой регион и знать из индивидуальных жалоб, что разумно.

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

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

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

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

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

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

_{(Личное примечание: мне приходилось приходить в назначенное время, поскольку, с точки зрения сотрудников, без веской причины, и это действительно крайне немотивирует. Очень важно убедиться, что люди понимают причины и не думайте, что вы просто меняете политику по прихоти или потому, что не доверяете им.)}

Раньше я работал в некоммерческой организации, у которой была эта проблема. Встречи всегда начинались поздно, опоздание на 10 минут стало «стандартом».

Затем у нас появился новый менеджер проекта для крупного ключевого проекта (и еще один с фиксированным графиком). Она созвала первую встречу. Люди вошли, как обычно, с опозданием на несколько минут и небрежно болтая. Она сидела в кресле и молчала, совсем ничего не говорила несколько минут. В конце концов болтовня «утихла», пока не наступила тишина. Мы все ждали услышать, чтобы говорить. Она позволила тишине продлиться еще немного. Она огляделась и сказала: «Мне нужно внести ясность. Встречи начинаются вовремя. Если вы собираетесь опоздать на 5 минут, не утруждайте себя приходом, просто зайдите ко мне позже. делать на этой неделе [что угодно]...". Это произвело БОЛЬШОЕ впечатление, и люди приложили все усилия, чтобы вовремя приходить на ее встречи.

Примечание. Добавлен дополнительный ответ ниже.

Учет работы, выполненной удаленно.

Часто лучшие производители все равно выполняют большую часть своей работы удаленно , поэтому иногда они проводят на удалении столько же времени, сколько и в офисе. Это важный момент, который следует учитывать и сообщать другим отделам. Это общение должно быть ненавязчивым — не созывайте собрание, просто начните искать способы показать «да, Джо не спал прошлой ночью, работая над x» и «да, Мэри исправила это в воскресенье, она не спала до полуночи». '.

Откровенно говорите о дороге. Если кто-то приходит в 10:30, его поездка на работу может занять 15 минут. Если им нужно быть в 9 или 9:30, их поездка на работу может занять час. Кроме того, это было бы то же самое, если бы они работали по 8 или 9 часов, возвращаясь домой. Многие люди считают, что это большая потеря их жизни. Они предпочли бы немного поработать удаленно, а потом вернуться. Постарайтесь объединить этот факт с вашими потребностями при назначении времени и убедитесь, что другие отделы тоже знают об этом, опять же, часто упоминая об этом.

Убедитесь, что вы используете технологии , чтобы помочь. Например, я работаю виртуально - 100% времени. Так что наличие Skype, отображение моего статуса в сети, видеокамера и т. д. тоже могут помочь.

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

Самое практичное и простое решение...

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

На самом деле команда понятия не имеет, что происходит с другими отделами и что им ДЕЙСТВИТЕЛЬНО нужно делать.

Наличие вашей команды, прибывающей в 9:30, что, я могу признать, не рано, однако не является решением этой проблемы. Вы пытались и потерпели неудачу, так что перестаньте настаивать на этом . Хватит биться головой о кирпичную стену. Мой единственный совет: всегда цените общение, а не произвольно назначенные встречи.

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

• Ходите на встречи и собирайте цели и требования от других отделов
• Выясните, что было закончено со вчерашнего дня
• Управляйте ожиданиями и обязательствами с другими отделами в отношении того, что необходимо и что можно сделать в течение рабочего дня.
• Сообщайте хорошие новости и плохие новости другим отделам
• Обновите любые планы, относящиеся к команде, если таковые имеются.
• Выясните, какие проблемы кода и архитектуры программного обеспечения требуют внимания сегодня
• Говорить «НЕТ» запросам, которые не представляют никакой ценности для бизнеса.
• Примите критику от других квартир и извинитесь с уверенностью, что проблемы будут исправлены.
• и т. д. (всегда есть что-то, что нужно решать)

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

Во время встречи с командой от них нужно две вещи:

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

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

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

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

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

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

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

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

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

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

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

Вам по-прежнему доступно несколько способов решения этой проблемы, одним из которых может быть изменение роли, которую играет отдел, например: если вы работаете с разработчиками программного обеспечения, вы можете изменить роль для определенного или людей в течение недели. чтобы они оказывали поддержку другим отделам, что требует, чтобы 1 или более пришли в 9 или раньше, и если это не сработает, вы всегда можете применить пункт о неповиновении, который обычно присутствует в любом справочнике по трудоустройству в США . Лично я всегда был против использования этого пункта, который дает менеджеру возможность объявить выговор и даже уволить кого-то по уважительной причине , но в вашем случае это может быть уместно. Итак, просмотрите руководство для сотрудников .и обсудите это со своим начальником, если у вас есть какие-либо сведения о том, что вы будете это делать.

Основная идея заключается в следующем:

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

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

• BlogSpot
• Дюэм

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

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

По сути, вы должны решить, что важнее: выполнить работу как следует или просидеть за своим столом 8 часов в установленное время?