Supposing a hypothetical organization that sold a product whose feature set and COGS closely followed a typical CSP like Amazon Web Services. That organization allows its customers to change products at will but must manually invoice a significant percentage of those sellables, therefore it needs a robust system to track changes to those sellables and ensure that they are properly charged at each turn of the billing cycle.

I'm picturing reporting format that reports on 2 different types of metrics -

• Accruing (non-temporal)
• Static (temporal)

Accruing metrics are easy, they're things like outgoing bandwidth. These are capped monthly and overages should be trued up, therefore 2 measurements could be helpful on these -

• Month to date sum (this will end up being your billable, since the bounds of the billing cycle are likely set at the calendar month)
• Rolling 30 day average (typical month's usage, helps you notice a customer who is tracking above what you sold them)

Static metrics require a bit more understanding. These are things like CPU cores in a given VM that you're selling. The tin says “8 CPUs” and gives you a monthly rate for those 8 CPUs but you're allowed to upsize that 8 core machine any time you want. Those 8 cores might become 16 for a week, then back to 8. That means you're charging for neither the 8 core machine nor the 16 core machine, but a blend of both.

This is what I mean by “temporal”, you have to generate a time component, divide your 8 or 16 cores into that time component, prorate the usage by that time component, and ultimately arrive at a piece of usage that accrues just like the other.

Given the example of 8 cores to 16 cores and using a 30 day month (720 hours) we get something like this:

You're actually charging for CPU/Hours, firstly. If an 8 core machine is $720/month ($1/hour) and a 16 core machine is $1440 ($2/hour) then your hourly CPU rate is $.0125/hour. This makes it very simple to track (and bill!!) the changes to your sellables that your customers are using.

The metrics you might want to watch on these types of sellables/COGS are almost the opposite of the accruing type:

• Month to date average
• Rolling 30 days average

The monthly vs. the 30 day average would tell you if they are tracking above or below recent historical averages. It would be trivial to compare the two and throw an alert if the month to date or shorter term rolling average is trending significant above the 30 day average.

Note: I'm on vacation and just want to remember some stuff for when I get back so don't dock me on this, I'm just spitballing

#business #analytics

First day of my job at my current employer (almost 7 years ago now) I crack open the company handbook to start onboarding. I remember it saying something like “Reservations are the lifeblood of this company” and thinking “wow, what does that mean?”

I'd had a job prior to this one that had some Stuff on AWS so I was familiar with the concept – something something pay upfront get reduced prices – but it as far from the lifeblood of the company. It was something the IT head took care of, and he didn't seem that pleased to do it either. So, six years after that I find myself in charge of FinOps here and it has a lot to do with reservations. Indeed, reservations are the main lever that you have to pull on the job. Let's talk bout it…

What are reservations?

I recently heard reservations described as a “forward contract”, which Investopedia (one of the most useful resources in this leg of my career) describes thusly

A forward contract is a customized contract between two parties to buy or sell an asset at a specified price on a future date.

The promise of the cloud is that you, developer, can push a button and spin up a VM or any number of other network-connected computing resources that you didn't have to ask IT for. It's why the default pricing model for these resources is called “On Demand”. AWS invented this idea several years ago that if you committed to running that resource for a year or more, you could receive a reduced price. You could pay for the year either entirely upfront to receive the deepest discount, entirely over time as a monthly payment for a shallower discount, or somewhere in between – the “partial upfront”, which mixes an upfront payment with a monthly payment for those resources.

At this point, you might be starting to learn concepts like “amortization” and “the time cost of money” to distinguish why you would choose one of these, but if not I suggest looking them up.

Uh, ok

There is a balancing act in place with reservations. Obviously you want to receive those lower rates wherever possible, but your resource usage might be, indeed probably is, rather variable. “Elastic”. Suppose you overpurchase a reservation, all upfront so that the entire year is paid for, but then the resource is turned off after 6 months. So my latest analog for what FinOps is largely about is a double ended inventory job. You have an inventory of resources to cover with reservations and you have an inventory of the reservations themselves. One can be created or turned off in an instant, the other lives for 1 or 3 years.

#business #finops

I've been kicking around this thought for a year or so now – to the outsider a career in data looks like a technical path. The data practitioner learns SQL, how to query data stored in a database somewhere using SQL, and if you know enough SQL you can answer any question whose artifacts are stored in that database somewhere.

The reality is that SQL is the very last mile. SQL is code, and so it looks to the non-practitioner like the act of creation, like code written in any imperative language creates motion and process and a webapp or piece of automation that didn't exist before. SQL does not create. SQL encapsulates that which already exists as a business process.

SQL is a contract. SQL puts business conditions and processes into code. If the business processes are ill-defined, then the SQL that has to be written to handle all the various cases will sprawl. (Most business processes are ill-defined as it turns out, made up in a time of need by a human, and probably one who doesn't spend their day thinking about data modeling.) If the business process is well-defined, but the SQL author's understanding of it is wrong or incomplete, then you'll end up with a poorly written contract that spits out wrong or incomplete answers.

That's what makes Data the hard part, because to write that contract down always requires the author to have spent time reverse-engineering the business process. I view this as an inherent good for the business as a whole – it forces the business to reckon with itself and to better define how it operates. The road to get there is tough though and in my experience it's often the data analyst who is actually pulling the cart.

#analytics #business #databases

I had a really organized map of things in my head I'd like to tell my younger self about FinOps last night. This morning it is gone. Let this be a lesson to me – jot some notes down. It was a primer course, from the point of view of a data person who was placed in charge of a FinOps practice – how to think about FinOps, what data are you going to need, what do the terms and costs mean, etc.

So what is FinOps?

Well, it's the driest sounding topic that I've ever found incredibly interesting (so far). Essentially, the cloud has upended what used to be an agreeably distant relationship between Engineering teams and Finance teams.

If an Eng team needed to launch a new thing to the young internet in the year 1999, they went through a procurement process with their employers Finance team. A server was purchased and placed in a rack somewhere and the interaction was largely done – Finance depreciated the hardware as they saw fit and Engineering optimized the workloads on that hardware as they saw fit. It was paid for, who cared after that?

Well, The Cloud screwed all that up. The cloud allows engineers to directly spend company money by pressing a button. Pressing buttons and launching resources without asking anybody is fun af, so Eng did it, lots. Some time later the bill comes to the old IT team or to Finance and friction entered the chat.

Finance could no longer control IT outflows. Engineering could no longer be totally ignorant of the company money they were spending. Both sides needed more information to do their jobs and make better decisions and into that dysfunctional gap grew the practice of FinOps.

How does FinOps Op?

“Financial Operations” is, I guess, what it stands for. See, cloud vendors – AWS, Google Cloud Platform aka GCP, and Azure (Microsoft's cloud) – don't make their money by making it easy for an Engineering team to understand the impact of their hardware decisions. They don't make their money by making it easy for Finance teams to surface anomalies in spending. They don't make their money by generating understandably reporting and forecasting tools. They make their money by selling Moar Cloud. And turns out one of the easiest ways to sell Moar Cloud is by making all of the above as difficult as possible!

I'm being cheeky and slightly humorous, or so I tend to think over my morning coffee. Truth is, these are huge suites of very complex products, upon which the largest companies in the world are:

• running their enormous, heterogenous workloads
• across dozens or hundreds of products within the cloud vendor's catalog and
• asking to be able to report on those any one of these workloads in a manner that fits their organization.

So what pops out of these requirements is typically a very granular bill with millions (or billions, so I hear) of line items. Those line items were generated by the various teams that built the products within the suite, so they tend to be pretty heterogenous themselves in terms of data points and consistency.

This is where FinOps finally steps in. It's basically a heavily data-backed job of informing both sides of the equation in as close to realtime as possible about the workloads and the financial impact of the workloads.

I intend next chapter to talk about “reservations”, which is part of the bread and butter of the cost management and therefore FinOps domain.

#business #finops

I read an article earlier this week about lessons learned between $5MM and $100MM in ARR. To the layperson – this means growing a small company into a larger company, as measured by its yearly revenue.

One of the points in the article (maybe more, I don't remember) was about hiring, and it referenced the old adage

A players hire other A players. B players hire C players…

While this sounds like one of those BS businessisms that some capitalist dude came up with, I absolutely believe it to be true. The HN comments section had multiple threads with commenters asking the totally reasonable question “Who's hiring these B players anyway?”. After all, if all you have to do is only hire A players, why would anyone hire a B player in the first place?

I went for a jog yesterday and decided to imagine some of the scenarios that might lead to B player infiltration of a company..

—————————

I imagine a common scenario is known in some circles as the Peter Principle. A talented IC (individual contribute, ie not a manager) is promoted into management. The IC work that came naturally to them is no longer their job and they have to learn a new set of skills to be an effective manager.

These skills are, frankly, not their thing and so they don't pick them up as readily and as hungrily as the more fun thing they used to do. One of those skills is learning how to hire good people. Their responsibilities and workload are growing every week, so eventually they have to hire but due to circumstance they rush through the process and hire a less than great teammate.

The formerly A player has committed a B player mistake. Will they learn from it and grow, or will they just put their head back down and keep moving?

——————————

Sometimes B and C players actually do hire A players. B players aren't dumb, after all, they do want to hire good talent. They just don't possess the skills or the confidence or the humility to grow their potential, so they set about micromanaging them into C players.

——————————

I personally think this one is very common, but I've never seen it discussed – the B player founded the company. They were born into a wealthy family, they raised their first round off of family connections or their last name. They look the part, they belong to the right social circles and at the end of the day that counts for a lot in this society.

The B player founder is never challenged to do better, indeed they are surrounded by evidence of their skill and business acumen. They hire B player after B player into the senior leadership ranks and because they are already rich, and because they are smart enough to avoid running the company into the ground, the company keeps going.

The company thus has an entire leadership culture of B players and the last thing a B player wants is to let an A player anywhere in the room. Money has its own gravity, and so these companies end up succeeding anyway. It's depressing if you think about it too much.

————————————

So the answer in all 3 scenarios above to the question “who is hiring these B players in the first place” is your leadership.

#business #management

“Run your data team like it's a product team” was a common refrain at the DBT conference for the last two years. What does that mean? I am still figuring that out, but I have had an aha in the last few weeks about what a “data product” is, exactly.

Your standard software development process requires two main components to deliver the Things – a software developer and her wits. She takes those wits and expresses them into a text editor, and thereby makes something from truly nothing.

Data products differ in 1 key way – they require raw materials in the form of data. The process of building a data product therefore requires at least 1 additional step that standard software product development does not – refining that data into something consumable by the system that is delivering the product.

There can potentially be an additional step even before this one, which is to get the data in the first place. My current employer built an Observability suite and stack to be able to deliver metrics to our customers about their projects that they run/host here. This process took multiple quarters because the entire metrics creation and delivery pipeline had to be built from scratch. Once the data existed, it was then a process of refining the materials and building the product.

The good news is that many data products can be consumed in a standard way through some kind of BI or reporting or data visualization tool, we use Metabase. It has taken me a while to understand that the method of delivery of the products is the more standardized part, whereas the gathering and refinement of the raw materials/data is where the action is.

#analytics #business #data

Just thought I'd drop myself a line here and remind me about that time that I was getting FinOps certified, because it's so much more interesting than I would've thought.

Basically, back in the old days, there were data centers and if you wanted a new resource in one of those data centers you had to go through a procurement cycle involving finance and probably a procurement team. You'd buy the resource and that would count as Cap Ex in your P&L or whatever. It'd get installed and then you could use it. That Cap EX would be depreciated and the world would keep turning, pretty predictably, just like the Finance teams likes it.

This meant much longer planning and procurement loops for most technology teams, loops that are gone now in the era of “Cloud” and “devops” generally. This is mostly great. It also meant that the old methods of controlling costs are gone and that the ability to spend company money has been handed directly to development teams. This is potentially bad.

This should require much more feedback between the two teams – Eng and Finance – and much greater visibility into the company's resource usage for the Eng teams spending the money.

This is FinOps. A continual process of building, monitoring, and optimizing that allows companies to move SO much faster than they used to be able to.

#business #finops

My wife is a Glennon Doyle podcast listener, and on a recent trip she put her on for a little while. Plenty of good stuff, but the phrase that's stuck in my head right now is

The intention doesn't matter. What matters is the impact.

One expression of micromanagement is the inability to sit and let your teammates (possibly) make a mistake on their own. The way I caught myself doing this just now was an innocent question being asked between two teammates for which I knew the answer. I am also on vacation, so I shouldn't be there. They were talking it out and I jumped in and answered it.

Implicit in this action was that I didn't trust them to figure it out correctly for themselves. It's not that I didn't trust them, but it probably comes across that way and what matters is not my intention but the impact. I'm potentially stunting the ability of this team to think on their own and that is something I am totally grossed out by.

So peace out and do better next time, Self.

#business #management

This is one of the aspects I didn't consider. A bit of background:

I'll have been here at Platform.sh for 5 years this July, which is crazy because it's now the longest I've ever held a single job in my life. Last summer I was poised to propose that we start a new team here around Data and Analytics right as someone else, much higher up then I, proposed that we start the exact same team. I raised my hand to start this team.

Prior to this I was leading a team of 15 in charge of onboarding and the post-sales $stuff, account management or Customer Success if you want. It was a young-ish but maturing team in terms of processes and to be honest I feel like I'm better earlier when the magma isn't really cooled and the direction isn't set. I enjoy solving problems. Once a set of problems gets “solved” it turns into processes that need to be implemented and refined. This is the natural lifecycle of a business or a department, but I take less joy in those later operational refinements than I do the initial creative period where you're trying to figure it all out.

So I raised my hand to do it again, this time with my dream project – our Data and Analytics story.

It's also the natural lifecycle of a business that, if you're lucky, you get to a certain point where things are still going up and to the right, but you've gotten there largely on feel so far, and your investors are starting to ask questions about things like The Margin. Or the COGS. Or your customers show up in more and more places so it's tougher to keep track of all of them and make sure they're staying happy.

In short, you are much further from where you started and the navigation of the vehicle starts to become much more important, because all the landmarks you once knew have faded from view. This is where precise measurements about the direction and velocity of the vehicle start to take over from, or at least assist, your instincts. Having already identified about 500 questions I wanted to be able to answer with data (broadly) I still can't believe my luck, that I've wound up here.

It is not without its downsides, however...

---

One thing that I didn't take into consideration was the rather extreme sense of isolation that I feel in this new role. The team really has two missions, though from the outside they look like one. To borrow my own analogy, it's like catering a large event. The groceries have to be procured before they can be prepped and cooked and served to all the diners, but all the diner sees is the dish in front of the plate.

So, getting the data into The Warehouse is 1 job. Cleaning, prepping, cooking, and serving the data to the clientele is the second job. To do them sequentially would take a very long time, so while the procurement side has largely been handled thanks to my new data engineer teammate and Fivetran, it's a very lonely and rather stressful job to handle everything after that. I don't really have anyone to talk to about any of this part of the job and it's ... it sucks, frankly.

I'm not sure how this could've been different except if I'd considered that I was moving from an established team of 15 to a new team of 1, and that there would be little to no collaboration, which is a thing I really enjoy and thrive on. I'm feeling the burn for sure.

#business #life

Hello, me. This post is to jot down what I think I know about the AWS CUR bill at this point in time. There are entire companies built around helping other companies understand this bill, so this should be considered a primer.

There are several columns that matter in this giant bill, and many dozens that do not matter, and about a hundred or so that fall somewhere in between. The ones that I know about so far that really matter when you're trying to decode a bill AT SCALE are:

• line item unblended cost
• reservation effective cost
• public on demand cost
• savings plan effective cost

Line Item unblended cost

Basically everything that is not an EC2 instance that is covered by some sort of reservation or Saving Plan is going to show up in this column – storage, network costs, etc.

Confusingly, line items that have a Saving Plan applied to them will also show up in this column, making it necessary to check against the “Line Item Type” column to see if it falls under plain old “Usage”, in which case you're paying the on demand price. If the Line Item Type column says anything other than “Usage” then it's not what you're actually paying for that resource.

For resource usage line items that have a Reservation applied to them this column should be $0, but for resource usage line items that have a Savings Plan applied to them this column will contain the full, undiscounted price and you need to look elsewhere to find out what you're really paying.

Reservation Effective Cost

Any resource usage line items that have some sort of reservation applied to them will show up in this column. This column and the Unblended Cost column are, afaict, mutually exclusive. A line item can have a cost in one or the other, but not both. From the documentation:

The sum of both the upfront and hourly rate of your RI, averaged into an effective hourly rate.

These line items have a Line Item Type of “DiscountedUsage“

Public on demand cost

This column is mostly useful just for sanity checking as you do your math against the other columns. If you correctly sum up your Savings Plan Effective Costs, your Reservation Effective Costs, and your on demand Unblended Costs then you should have a number that is lower than the sum of this number.

Ideally it should be much lower, and I have not yet figured out if it is possible for the sum of all your discounted effective costs to be higher than this number.

If you incorrectly forecast your future usage and purchase discounts in excess of what you actually use, then you're potentially throwing away more money than what you'd be paying on demand. This is the nightmare scenario of course, and the Finops practitioner makes their money by avoiding this for their liege.

Savings Plan Effective Cost

The proportion of the Savings Plan monthly commitment amount (Upfront and recurring) that is allocated to each usage line.

This cost column is mutually exclusive with the Reservation Effective Cost, but not with the Unblended Cost. The Unblended column will contain the full, on-demand price for the resource in question but for those with a Line Item Type of “SavingsPlanCoveredUsage” the Saving Plan Effective Cost should be used.

I haven't tried this yet, but off the top of my head it would look something like

CASE 
	WHEN line_item_type = 'DiscountedUsage' THEN reservation_effective_cost
	WHEN line_item_type = 'SavingsPlanCoveredUsage' THEN savings_plan_effective_cost
	ELSE unblended_cost
END AS actual_cost,

CASE 
	WHEN line_item_type = 'DiscountedUsage' THEN 'Reservation Effective Cost'
	WHEN line_item_type = 'SavingsPlanCoveredUsage' THEN 'Savings Plan Effective Cost'
	WHEN line_item_type = 'Usage' then 'Unblended Cost'
	ELSE CONCAT('Unblended Cost: ', line_item_type)
END AS actual_cost_source

Good luck!

#business #finops