the problem with amortization

What's happening is obvious: you're paying extra to subsidize something else. In order to have a clean lobby or repaired runway or a life-saving but little-used machine on hand, institutions charge some people extra and spread it out over some of their larger costs.

via sethgodin.typepad.com

One of several interesting posts from Seth Godin in the last couple weeks. We spend more on the things we pay for (products, services), in order to get the things we're not directly paying for (rent, staff, etc). And, by doing that, we're masking the cost of those indirect fees. I find this fascinating to think about in the sense of operations.

For instance, at SAY Media, my team hosts/runs/manages multiple services -- internal and external facing. And there's a lot of shared services: the base cost of the datacenter (before we put the first machine in there), the cost of the network equipment, the cost of monitoring services, the cost of the ops team's staff ... the list goes on. None of those costs are allocated to any particular product; they get the benefit of the shared infrastructure.

But imagine if we went nuts and allocated every little detail of everything -- down to the bandwidth and power costs to each particular product. If a product's GM knew how much he was spending on bandwidth, or power, or staff, and was held responsible for those costs, then they get the ability to make better global decisions -- should we have a developer spend time minifying their JS/CSS to save on bandwidth costs, or should they build a feature that customers have been asking for?

This sort of awareness ties into a perpetual struggle for sysadmins and development teams: the cost of up-front work versus ongoing maintenance. "Spend two days debugging and fixing a memory leak" versus "Restart it once a night until forever". I don't believe that one side is inherently better than the other, but I do believe that it's easy to discount the cost of ongoing maintenance. Unless you explicitly take on the up-front work, you're implicitly choosing the ongoing maintenance. It feels like it costs nothing. And even when it's considered: up-front costs are known, ongoing costs are more nebulous, and so it's easy to believe that up-front costs are more expensive. 

Knowing what gets amortized can scare a lot of people, especially if they weren't aware of it before. But it also puts them in a position of power and control, to make the right decisions in a more global context. And assuming that's understood, I find it hard to be upset with any outcome because I'll know that any cost or inconvenience to the ops team (or any other team) is actually understood and accepted -- as opposed to happening by default.

Comments

[Jeri]

Are you guys taking steps to figure the costs of each product? I ask because Robin just completed a major project for his company to better understand the loaded costs of their products. It's something I have always found interesting because of my accounting background. Another is doing a report on help tickets based on department but this tends to be skewed by the drive-by phenomenon. :-)

[Tedr]

This actually reads like an IT business idea. A service that can value any task OR value the cost of the technical debt if it's not done. (I;m not saying it would be an easy business idea, but one that every company would want)

[Kevin G.]

I once dated a girl who worked in organic produce, and she pointed out that part of the reason regular produce is priced lower is that the price isn't accounting for the long-term costs of the way it is grown. You start thinking like that and you start noticing a whole lot of behaviors in the wider world that are subsidized by innocent third parties, or are amortized way out into the future.

[Matthew]

._ Im impressed. I dont think Ive met anyone you never know as much relating to this subject as you do. Youre truly knowledgeable and very intelligent. You wrote a thing that people could understand and made the subject intriguing for everyone. Really, great blog youve got here.