Justifying Engineering Headcount: The Language of Budget Conversations

Запит на інженерну чисельність є одним з найважливіших комунікаційних викликів для інженерних менеджерів і директорів. Ви робите бізнес-запит, а не технічний запит. Фінансовий директор і виконавча команда думають з точки зору фінансової віддачі, ризику і стратегічного пріоритету - а не розміру відставання або швидкості спринту. Цей посібник надає вам словниковий запас і мовні шаблони, які допоможуть вам створити переконливу аргументацію.

Бухгалтерський облік

Зрозуміти і використовувати правильний фінансовий словник означає, що ви продумали бізнес- наслідки вашого запиту, а не тільки інженерні.

Headcount — кількість працівників, які працюють на повну ставку в команді або організації. У обговореннях щодо бюджету, кількість працівників завжди означає вартість, а не просто число. « Я прошу додати дві додаткові посади у команді сервера на третій квартал. »

** Норма виконання** — річна вартість поточного стану або прогнозована річна вартість запропонованих інвестицій. « Додаток двох старших інженерів з середньою загальною вартістю 90 000 фунтів стерлінгів означає збільшення норми виконання на 180 000 фунтів стерлінгів на рік. »

** OPEX (операційні витрати) ** — періодичні витрати, такі як зарплати, надбавки і ліцензії на програмне забезпечення. Кількість працівників завжди є OPEX. « Це запит OPEX; немає капітальних інвестицій »

** CAPEX (Капітальні витрати) ** — одноразові або великі інвестиційні витрати. Іноді це важливо, коли йдеться про значні інвестиції у платформу разом з кількістю працівників. « Вартість інфраструктури є елементом CAPEX; інженерна команда, яка її обслуговує, є OPEX. »

** Backfill ** — заміна від’ їжджаючих співробітників новими. Запит на заповнення кадрів, зазвичай, легше схвалити, ніж запит на нову кількість працівників, оскільки бюджет вже існував. « Сара покидає роботу у червні; я запитую схвалення на заповнення її посади старшого інженера негайно, а не чекати на щорічний перегляд кількості працівників. »

** Чиста кількість нових співробітників ** — найм над існуючим схваленим числом співробітників, тобто збільшення команди. « Це чистий запит на нове число співробітників, а не на заповнення — я прошу збільшити команду з шести до восьми інженерів. »

Повний обсяг витрат — загальна вартість працівника, включаючи зарплату, надбавки, податки роботодавця, обладнання і офісне приміщення. Зазвичай 1,2 × -1,4 × базова зарплата. “Повний навантажений вартість інженера середнього рівня в Лондоні становить приблизно £ 95,000; бізнес-цінність, яку вони генерують, набагато перевищує це.”

** Час підйому ** — період часу між початком роботи нового працівника і моментом, коли він буде повністю продуктивним. Зазвичай від трьох до шести місяців для досвідчених інженерів. “Фактор у чотиримісячному підйомі; зростання продуктивності буде помітно не раніше п’ятого місяця.”

Мова для переконання для наймання обґрунтувань

Обґрунтування обліку персоналу повинно відповідати на три неявні питання: Яка проблема вирішується? Яка фінансова сторона справи? Що буде, якщо ми не наймемо?

Розв’язування проблеми в бізнес-термінах:

• «Команда інженерів в даний час є в’язкою, що перешкоджає нам відправляти два пункти дорожньої карти, які безпосередньо пов’язані з цільовою прибутковістю Q3»
• «Ми зобов’язалися до корпоративного контракту, який вимагає сертифікації SOC 2. У даний час ми не маємо можливості доставити це разом з дорожньою картою продукту»
• «Наша ротація на виїзді становить чотири інженери; нижче п’яти, ми знаходимося поза нормами безпеки промисловості і бачимо підвищений ризик втратити»

Оцінка доходу:

• «Кожен додатковий цикл випуску приносить приблизно £ X в прирістних доходах на основі наших поточних показників конверсії»
• «Додавши одного інженера до команди платформи, ми зменшуємо наші витрати на інфраструктуру на приблизно £ Y на рік за рахунок кращого використання ресурсів»
• «Ця найм розблокує три функції дорожньої карти, які в даний час заблоковані; ці функції, за оцінками, генеруватимуть £Z в ARR, коли вони будуть жива»

Описуючи вартість не найнятих:

• «Якщо ми не найняємо, нам доведеться зробити вибір: зменшити обсяг дорожньої карти, прийняти ризик доставки на контракті підприємства або продовжувати вигоряти існуючу команду»
• «Ризик втратити працівників, якщо ми не звернемо увагу на здатність команди, є значним — втрата одного старшого інженера коштуватиме нам 3-6 місяців продуктивності і приблизно £ 30 000 в оплату за найм»
• “Без цього найму, ми пропустимо термін виконання, що ставить під ризик контракт підприємства.”

Функціональний рівень CFO

Коли ви говорите безпосередньо з фінансовим директором або фінансовим комітетом, будьте короткими, ведуть з цифрами, і пов’язують кожен запит до стратегічного результату або ризику.

** Структура, якої слід дотримуватися: **

1. Визначте проблему бізнесу одним реченням.
2. Визначте запит у фінансових термінах (вплив на швидкість виконання).
3. Вкажіть очікувану прибутковість або ризик, якого вдалося уникнути.
4. Зазначте вартість бездіяльності.

** Приклад висловлювання голови фінансової служби (згорнуто):** «Ми в даний час не можемо надати функцію платежу, необхідну для нашого корпоративного договору. Я прошу двох старших інженерів з повною заробітною платою 190 000 фунтів на рік. Доставка цієї функції розблокує £ 500,000 в контрактному ARR. Без цього найму, ми пропускаємо строк дії контракту і ризикуємо втратити клієнта»

Приклади прикладів прикладів прикладів прикладів прикладів прикладів прикладів прикладів

1. «Я хочу чітко розуміти, що це чистий новий запит на кількість працівників: я прошу збільшити з шести до восьми інженерів, тому що поточна команда повністю використовується на присвяченій роботі і не має можливостей для трьох функцій дорожньої карти, які бізнес потребує в H2»

2. «При повній вартості в £ 95 000 на інженера, два найми представляють збільшення витрат на £ 190 000; дві функції дорожньої карти, які вони доставлять, оцінюють у £ 400 000 в новому ARR, що дає період окупності менше шести місяців»

3. «Я рекомендую нам схвалити заповнення негайно, а не заморожувати роль — кожен місяць без старшого інженера на цій посаді коштує нам приблизно пів спринту потужності, що швидко складається проти терміну Q3»

4. «Ризик, який я хочу позначити, це втрата працездатності: два члени команди сказали мені прямо, що їхня робоча нагрузка є нестійкою. Якщо ми втратим одного з них, витрати на заповнення і втрата продуктивності значно перевищать інвестиції в додаткове число працівників, про яке я прошу сьогодні»

5. «Я розумію тиск на OPEX; в обмін на ці інвестиції, я зобов’язуюся до вимірюваного результату: дві корпоративні функції, відправлені до кінця Q3 і зменшення частоти інцидентів на виклику принаймні на 30%, як виміряно в наступному кварталі»

Необхідно уникати помилок

** Розмова про розмір відставання: ** Фінансові керівники не знають і не переймаються кількістю квитків Jira, які у вас є. Перетворює елементи відстрочки на результати бізнесу.

** Використання показників швидкості без контексту: ** « Наша швидкість — 40 пунктів за спринт » не має значення для фінансового директора. « Ми можемо створити одну важливу функцію на місяць за поточних можливостей » має значення.

** Показувати кількість працівників лише як вартість: ** Кожен запит на кількість працівників повинен включати очікувану віддачу або ризик, якого вдалося уникнути. Вартість без прибутку легко відкинути.

Національна мова: мова, що використовується для спілкування між ненаціональними групами

Обґрунтування інженерного штату не просто про те, скільки розробників вам потрібно. Це тонкий танець чисел, стратегічного обґрунтування, і, що найважливіше, чітке спілкування. Метою є вийти за рамки «ми потребуємо більше людей» і сформулювати * чому * ці люди є необхідними для досягнення конкретних результатів бізнесу. Зрозуміти основну фінансову мову - такі терміни, як OPEX, темпи виконання і заповнення - є фундаментальним, але не менш важливо освоїти фрази, які використовуються для переконливого оформлення ваших аргументів, особливо при презентації старшому керівництву. Часто прямий переклад «ми потребуємо більшої підтримки» не буде добре сприйнятий; його потрібно ретельно побудувати з контекстом і виправданням. Розгляньте, що Фінансовий директор, ймовірно, буде оцінювати ризик проти винагороди - демонструючи, як збільшення кількості працівників * зменшує * майбутні ризики, часто набагато ефективніше, ніж просто підкреслювати потенційні прибутки.

Складання графіків: графіки для звичайних завдань

Давайте розглянемо деякі конкретні сценарії, де обережна фраза може зробити або пошкодити ваш аргумент. Уявіть, що ви отримуєте коментар перегляду коду, який говорить: «Ця функція надто складна і важко підтримувати. Розгляньте рефакторинг. “Проста відповідь на кшталт “Гаразд, я розумію” не достатня. Замість цього спробуйте щось більш точне: « Дякую за підкреслення складності — я ціную ваші відгуки. Для того, щоб вирішити цю проблему, я буду впроваджувати модульну конструкцію з чіткішим розмежуванням питань, заснованих на вашій пропозиції. Це покращить підтримку і зменшить потенційний технічний борг, відповідно до мети нашої команди, щоб приоритизувати якість коду. ” Зауважте використання таких термінів, як « технічний борг », « модульний дизайн » і « відокремлення питань » — вони демонструють, що ви розумієте стратегічні наслідки зворотного зв’ язку і активно його вирішуєте.

Інша ситуація виникає під час створення опису запиту на звантаження для нового найманого працівника. Замість того, щоб вказати « Додавання нових можливостей до системи », що є неясним, спробуйте: « Ця PR реалізує [Назва можливості], підвищуючи залученість користувача шляхом спрощення процесу для [Особливої дії користувача]. Це відповідає нашій дорожній карті Q3 і сприяє прогнозованому зростанню активності користувачів на 15%, як це описано в останньому аналізі ринку. Додаткова функціональність буде підтримуватися спеціальною архітектурою мікросервісів, що мінімізує вплив на існуючі системи. Ключовим тут є зв’ язок вашої роботи безпосередньо зі стратегічними цілями і кількісне оцінювання її потенційного впливу - навіть якщо це кількісне оцінювання засноване на розумних оцінках. Використання фраз на кшталт “прогнозований приріст” і посилання на попередні аналізи додають довіри і демонструють, що ви думаєте не тільки про негайне завдання.

Нарешті, обговорюючи потребу у « заповненні » після того, як співробітник залишить компанію, не скажіть просто « Нам потрібно замінити їх ». Замість цього, сформулюйте це стратегічно: « Після відходу [Ім’ я співробітника] нам потрібне заповнення, щоб підтримувати операційну стабільність і запобігти будь- яким перешкодам у наших ключових зусиллях з розробки [Назва проекту]. Це забезпечить постійний прогрес проти цілей спринту і зменшить потенційні ризики, пов’язані зі зменшеною потужністю команди. Нова роль буде зосереджена на [Специфічних Відповідальності] і безпосередньо внести вклад в нашу загальну дорожню карту продукту. ” Використання таких термінів, як «операційна стабільність» і «зменшення ризиків» сигналізує проактивний підхід до вирішення проблем, підвищуючи вашу цінність як інженера.