Умение делать чужую работу

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

Если создано что-то новое, а те, ради кого оно создавалось, не спешат это внедрять — можно встроить новое в их систему самому. Так поступила Intel: когда выпустила свой первый 32-битный процессор, её люди сами добавили поддержку этого процессора в компилятор Microsoft (я встречал кого-то из той команды Intel). Почему-то многие видят в таком подходе какую-то неуместную благотворительность, отказываются работать в чужих системах. Но интересно: Intel стала помогать бедной страдающей Microsoft, или же просто получала выгоду от успеха Microsoft?

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

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

Многие считают такой подход извращением — зачем же это делать? Я убежден: не просто 20% людей выполняют 80% работы. Вся эта работа достигает целей только благодаря менее чем 5% людей, которые делают то, что должен делать кто-то ещё, но не делает — по причинам, вполне законным в глазах организации. Однако накопление таких законных причин приводит к верной смерти всего предприятия.

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

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

Но не так вот

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

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

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

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

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