What about a 5k engineer org. Having 10 finops people would make it 0.2% of the workforce. Those people help surface the information for other teams to act.
Start with educating architects and developers on how to measure and optimize costs. They are the first point (and probably cheapest) to optimize costs.
Later, FinOps role can evolve but expectations will mostly be reactive.
I don't care for this paradigm because the architects and developers likely have very little context upon which to base decisions. There are tradeoffs between time to develop, cost to run and reliability that it runs at. Where you want to make those tradeoffs is more of a business decision than a technical one.
A high margin product might want to launch quickly and reliably, costs be damned. Another product may need to run as cheap as possible, even if it's unreliable and takes a long time to develop.
FinOps translates business goals into technical requirements. It's not just cutting everything down to as cheap as it can be.
at even $70/hr of employee cost + $200/employee per employee training cost + at 20% annual employee churn + added salary payout to hire devs who are cost conscious.
Lets see how long that is cheaper than just hiring 2-3 finops folk and just put them in every room where the software architecture is being designed for new services and make them drill down hard into team on what to avoid.
Not to mention it’s a better way to do things in the Single Responsibility Principle that most great teams follow
if everyone is responsible for cutting costs and optimizing.
Comments
What about a 5k engineer org. Having 10 finops people would make it 0.2% of the workforce. Those people help surface the information for other teams to act.
Start with educating architects and developers on how to measure and optimize costs. They are the first point (and probably cheapest) to optimize costs.
Later, FinOps role can evolve but expectations will mostly be reactive.
I don't care for this paradigm because the architects and developers likely have very little context upon which to base decisions. There are tradeoffs between time to develop, cost to run and reliability that it runs at. Where you want to make those tradeoffs is more of a business decision than a technical one.
A high margin product might want to launch quickly and reliably, costs be damned. Another product may need to run as cheap as possible, even if it's unreliable and takes a long time to develop.
FinOps translates business goals into technical requirements. It's not just cutting everything down to as cheap as it can be.
at even $70/hr of employee cost + $200/employee per employee training cost + at 20% annual employee churn + added salary payout to hire devs who are cost conscious.
Lets see how long that is cheaper than just hiring 2-3 finops folk and just put them in every room where the software architecture is being designed for new services and make them drill down hard into team on what to avoid.
Not to mention it’s a better way to do things in the Single Responsibility Principle that most great teams follow
if everyone is responsible for cutting costs and optimizing.
Then no one is….