Thread by @mipsytipsy

This is a little less mysterious to me now that I have been through the budget sausage-making process a few times, although sadly no obvious solutions come to mind. Hm. 🤔

A few of the reasons, good and bad...

https://twitter.com/rahulj51/status/1273492883962769408

In an ideal world (for this purpose), an engineering org might be given a mission or a mandate, plus a single budget to cover people, infra, and tools.

This ought to result in an efficient distribution of resources between writing new code and outsourcing, with minimal NIH.

... With a few BIG assumptions;

* we do not underestimate how long or hard it will be to build the new tools
* or support or maintain them
* we know how to value our time and that of others
* we understand our needs and they do not substantially change

Engineering leaders vary widely in their understanding of the business needs.

I suspect this way of preprocessing the budget into people+tools can be the finance team's effort to exert early biz influence onto where eng resources are being spent.

I wonder how many engineering managers and directors would truly prefer to have a budget given to them instead of teams and a number of people. My gut says.. not many.

We are scarcely better than random guesses when converting between engineering cycles, impact, and dollars. 🙃

One big reason for the lack of budget fungibility, btw, is the friction of moving off of a tool, which pales next to having to let someone go. Moving budget from one category to the other is like ... they have very, very different denominators.

Finance departments are hardly well versed in the details of when engineers ought to buy vs build, either.

I've also heard them object "if we spend that 200k to hire a person, the person can build whatever tool we need; if you spend it on a tool, you're stuck with the tool."

I feel like most engineering managers are functionally innumerate when it comes to the literal cost of their team and its time.

If I were running a bigger company I think I would make all new eng managers sit down and calculate/estimate some basic stats, like:

* Estimate how much you and your team cost. Show your work.
* Add up the hourly $ for an engineer's meetings over a week
* What is the ratio of spend, engineers to production infra?
* What % of your infra budget goes to not-AWS?
* How much infra $ does your biggest user consume?

The point is not to obsess over these numbers, or to get too exact. The point is to make them think it through every now and then, so they have an actual reference point grounded in reality.

Most will probably be astonished how much help they need just assembling a decent guess.

And for the record I do think that this is solidly the sphere of the engineering manager: tethering engineering goals, practices, identity, and drive to the _business needs_.

Translating back and forth between dev/biz worlds so that each understands the other. That's the gig.