Charity Majors+ Your Authors @mipsytipsy CTO @honeycombio; co-wrote Database Reliability Engineering; loves whiskey, rainbows. I test in production and so do you. 🌈🖤Black Lives Matter🖤 Jun. 20, 2020 2 min read + Your Authors

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...

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.


You can follow @mipsytipsy.



Bookmark

____
Tip: mention @threader_app on a Twitter thread with the keyword “compile” to get a link to it.

Enjoy Threader? Sign up.

Since you’re here...

... we’re asking visitors like you to make a contribution to support this independent project. In these uncertain times, access to information is vital. Threader gets 1,000,000+ visits a month and our iOS Twitter client was featured as an App of the Day by Apple. Your financial support will help two developers to keep working on this app. Everyone’s contribution, big or small, is so valuable. Support Threader by becoming premium or by donating on PayPal. Thank you.


Follow Threader