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

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

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

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

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

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

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

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

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

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

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

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

Вот те несколько советов от не по годам опытного менеджера, у которого пока еще нет седых волос.

Кен Хэнли — профессионал в области информационных систем. С ним можно связаться по адресу: isguerilla@hotmail.com