Business, tech, and life by a nerd. New every Tuesday: Splitting Light: The Prism of Growth and Discovery.
Share
Splitting Light: Season 3 - Episode 14
Published about 18 hours ago • 3 min read • Season 3
Splitting light
Season 3 Episode 14
Attribution
If you are no longer interested in the newsletter, please unsubscribe
March 2019
The object storage product is both a user facing product and an infrastructure product. The compute team used it to store images and client virtual machines backups. The registry used it to store container images. The databases team to store client database backups. And so on for nearly every product and service at Scaleway.
Both direct and indirect usage of Object Storage
Each of these customer facing features were billed by their respective product teams. They booked revenue selling data stored at rest. Yet, at the end of the chain, for us it was lost revenue. We had no attribution of revenue. We had to dedicate part of our capacity for both these internal and customer facing features that brought no revenue to us.
This was a highly contested issue for me. For me, part of their revenue should be attributed or shared with us. Their features could not work without our service. Our total revenue was lower than it should be. I even made a dashboard called: “Revenue other teams owe us”.
You might think this is nit picking but I assure you this is not. Budget allocations, hardware allocation and other business decisions are taken on business metrics. One of these metrics is revenue. Our total revenue, and thus our ROI (return on investment) ratio was lower than it should be because we did not have the revenue attributions.
I didn’t just do it for us, the storage team. In my mind, even us, storage, should attribute part of revenue to the network team for external and internal bandwidth. We should attribute revenue to the team assembling the racks. Even the billing team should attribute a processing fee to us.
Financial flowchart for Object Storage. Dotted lines where not formally attributed
The importance of the products and teams in a company ultimately depends on revenue. When you want or need to invest. You look at ROI. But you can only have an accurate estimate if you take this into account.
A product selling a feature at a lower gigabyte per hour than what object storage bills is not sustainable. It just creates revenue holes. Even in other cases, for example, a commercial or marketing campaign that discounts the customer cost by a percentage ultimately lowers the ROI of the products. The difference in revenue needs to be attributed (withdrawn in this case) from the commercial and marketing teams.
Going back to the Donad Knuth quote: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” You cannot optimize a business if you don’t understand its inefficiencies.
Evidently it’s very hard to do. This requires a lot of effort. Dependency tracking and constant oversight. But for me it’s necessary.
At the time, my mistake was believing that this was only a tech problem. While ultimately, this is a human problem. This requires careful communication, change management, onboarding everyone into the boat, and being sponsored by someone in leadership. Essentially human interaction.
I didn’t have the right vocabulary nor the right methodology to explain this. I had a hard time advocating for this. It ended up being an extremely frustrating experience for me. I retreated back and resorted to standing my ground. This was a tragedy for me. Human interactions were an increasing portion of my role and attributions. Unlike tech, which flowed easily for me, human interaction required a disproportionate amount of effort. My understanding of the importance of this was trailing by far the acts and impacts I was having.
At Epitech we were taught how to program machines, how to work in teams, how to build complex systems, but we were not taught how to evolve your career. In a sense we were not told how to “program” our career forward. But this lesson is only available to me in hindsight. I wouldn’t know who to make this relevant to my 20 year old self. Food for thought.
As you climb energy orbits, you emit different light waves (1). What carried to a point is not necessarily what will carry you onward.
In the midst of all this accounting and billing, Covid19 fell upon us all.
Image from https://ganymede.nmsu.edu/tharriso/ast110/class13.html
If you have missed it, you can read the previous episode here
Splitting light Season 3 Episode 13 Bills reconciliation If you are no longer interested in the newsletter, please unsubscribe January to March 2019 When you have a complex system there are always going to be discrepancies between them. In our case the discrepancies were in the billing systems. We had five different data sources. None agreed on the numbers. Let me introduce our five systems. Observability of the disk usage as well as the incoming and outgoing bandwidth. The client...
Splitting light Season 3 Episode 12 Warsaw If you are no longer interested in the newsletter, please unsubscribe End of January 2020 to beginning of February 2020. In January 2020, we had a new challenge. A new opponent to ring in and control. Let me introduce him. It was the Warsaw region! We had to deploy object storage in Warsaw. Back in September 2019 we had selected the hardware setup and had done a brief discovery of it. Then the whole region’s hardware had been shipped by truck. Once...
Splitting light Season 3 Episode 11 OpenIO reaching out If you are no longer interested in the newsletter, please unsubscribe End of 2019 While we were dealing with the 500k object problem in object storage, Jean-Francois Smigielski (a), OpenIO’s CTO reached out to me on their community Slack. They were looking to hire more engineers and several people that they trusted had told them I was what they needed. Most likely I had also done a good impression when we had worked together to bootstrap...