The Cost Center Trap

http://www.leanessays.com/2017/11/the-cost-center-trap.html

by nikolasavic • 9 years ago

128 73 9 years ago

bluetwo• 9 years ago

A good read. I believe the basics (internet, email, connectivity) of IT infrastructure should be a cost center, development of tools that assist the company in accomplishing their goals should not be.

rm_-rf_slash2• 9 years ago

The given “best” solution - change accounting/metrics - is also one that is most difficult to meaningfully change.

Everybody has a disagreement with metrics until it suits them. Metrics justify mid-level management to upper management, which then justify themselves to top management, then the board of directors, then the shareholders. “Look at the numbers!”

It’s similar to a grumbling slogan of fund managers in the 1980s about the then-consistently poor stock performance of IBM: “Nobody gets fired for buying Big Blue.”

mark-r2• 9 years ago

I've always heard that phrase used in reference to IBM products, never IBM stock.

stcredzero• 9 years ago

Let’s face it, unless there are mitigating circumstances, IT departments that started out as cost centers are going to remain cost centers even when the company attempts a digital transformation

AWS and the Google Cloud are evidence of the possibility of escape. Are there any writeups for how they came about? (Particularly in the case of AWS.)

rm_-rf_slash2• 9 years ago

I don’t know any write ups, but in short, AWS was a solution to the variable demand for Amazon’s, well, web services. Demand peaked considerably during holiday shopping months but otherwise remained far too low to justify keeping all of those peak demand servers running Amazon.com full time, so they were rented out to companies that actually had similar problems of peak demand. In particular, the Victoria’s Secret fashion show is a great example of extreme peak demand and scalability for a web service that otherwise attracts relatively little traffic most of the year.

wallflower• 9 years ago

Origin of AWS is quite famous.

https://news.ycombinator.com/item?id=12022915

Yegge's famous rant about Bezo's 2002 mandate https://plus.google.com/+RipRowan/posts/eVeouesvaVX

user5994461• 9 years ago

They came about because any fortune 500 has thousands of developers and critical software to run and they have to manage the hardware to run it.

You will find an in house equivalent of the cloud in every single big company. Except, the software and the UI will be terrible because they have much less resources and competence than Amazon/Google.

chasedehan• 9 years ago

This whole thing goes back to the accounting process of measuring "throughput" rather than some fixed number such as inventory.

This book "The Goal" was incredibly beneficial for me in understanding the concept of throughput. While the book is a parable focused on manufacturing, it can be easily applied to companies in tech. https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0...

Jtsummers5• 9 years ago

That book is next on my reading list, but also worth checking out is "The Phoenix Project". It applies the concepts of "The Goal" to IT (operations to start, but it gets extended to development through the book).

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

konpikwastaken• 9 years ago

Was just going to recommend reading this book, glad someone did already. Being in tech/IT, you will be able to identify each of the characters in your work environment at one point or another.

cjalmeida2• 9 years ago

Eli Goldratt is an unsung hero of modern management practice. Though the Goal is his most famous work, his other books are pretty useful.

And like this throughput accounting thing, his ideas can be quite heretic in some circles.

sidlls2• 9 years ago

I'm not sure many IT functions are not cost center functions. Almost none of them, including software development, are revenue drivers for most companies.

Like anything else in business this seems like a case where some hard, one size fits all rule is occasionally misapplied.

cm20123• 9 years ago

It's not a clear profit center like sales or direct marketing. But if you can clearly point to good engineering work leading to more sales (release happens, it's really good, lots of people buy the product clearly because of the good work) then it's more on the profit than cost side of the spectrum.

It's really just a matter of how easily can you see that A led to B.

kgwgk6• 9 years ago

release happens

Release of what?

sidlls2• 9 years ago

I'm not convinced. Using your description even high quality software releases are still "just" products: products that cost the company resources to build. The technical skills required doesn't change that.

rat_12342• 9 years ago

"However, accounting systems count inventory as an asset, so and any significant reduction in inventory had a negative impact on the balance sheet...successful JIT efforts tended to make senior managers look bad"

This shows a poor understanding of managerial accounting.

High "working capital" requirements, of which inventory is a big part, are a huge drain on free cash flow. Any company that sees its inventory as a % of assets go DOWN would view it as a positive by both its management and investors.

bluGill2• 9 years ago

You are confusing what the business leaders of today think with what they thought in the 1920s. In the 1920s and before nobody could think of a reason why large inventories would be bad: they were a buffer against surges in demand, and you got to build them at today's prices. A large inventory just meant you need to hire more salesmen (literally men, it was a sexist time), and/or hold a sale.

Of course now management theory knows of many reasons the above is wrong, it is entirely accepted that you want inventories low because of the advantages it brings.

kgwgk6• 9 years ago

The article is talking about the 80’s, not the 20’s. The importance of working capital management was well understood by then.

bsder• 9 years ago

it is entirely accepted that you want inventories low because of the advantages it brings.

Advantages ... until you have an earthquake in Taiwan and the entire semiconductor industry shuts down because nobody has any inventory ...

noir_lord• 9 years ago

Not to mention K-Factor (carrying cost) and that 200K in stock sat in your yard is 200K you aren't earning interest on/able to re-invest into you business.

It's a double whammy, you pay (in terms of utilities, rent etc) to hold stock that means you can't use the money elsewhere and for a lot of stock you also have depreciation (though I work for a company that makes stone products so at least our raw materials don't expire).

pwinnski• 9 years ago

Were you working in managerial accounting in the 1980s?

My own arms-length exposure at that time suggests that, however simplistic it might seem, the assessment in the article is correct. It might seem obvious that lowering inventory as a percentage of assets is good, but only if you look at that, rather than just seeing the top-line assets total go down.

This article seems to very accurately represent my experience.

rat_12342• 9 years ago

To be fair, no I wasn't working in managerial accounting in the 1980s.

Maybe what would help is if you could explain what metric a reasonable manager would measure that would get worse under JIT versus better.

I guess maybe if your assets go down you could look more highly levered, but financial leverage isn't really something that a manager can affect anyway (more of a CFO level metric).

All of the asset-oriented measures I can think of -- like asset turnover, working capital as % of sales, working capital as % of assets, WIP inventory as a % of total inventory, etc. -- would all improve.

jdlshore2• 9 years ago

Mary is talking about the transition from cost accounting to throughput accounting, which happened several decades ago. And yes, cost accounting really did resist attempts to decrease machine utilization, which resulted in increased inventory.

Look in the mirror before throwing stones at others' knowledge.

gaius• 9 years ago

The "cost centre" concept is so silly, and it only ever seems to be applied to the IT department. Why isn't HR a "cost center"? They don't generate any revenue. Why isn't Accounting a cost centre? How many sales do they bring in? It's just a stick other departments use to beat IT with.

kgwgk6• 9 years ago

Why do you think they are not considered cost centers?

Jtsummers5• 9 years ago

Sometimes they are, that's why HR and Accounting get outsourced at many companies (or portions of them).

See what companies outsource, that's what they see as cost centers.

selllikesybok2• 9 years ago

They are, actually. All your operationally necessary but not directly revenue generating business units/functions are cost centers, in this model. And they get beaten with the same stick.

disease• 9 years ago

R&D, in my experience, is viewed even more harshly than IT as a cost center.

dsign• 9 years ago

Don't see the point of this article. There are accounting mechanisms that allow to activate money put into IT infrastructure as an asset in the balance sheet, at least in my cold and dark part of the world.

Some IT expenses are indeed cost centres and should be just deducted from the profits immediately.

However, other "IT expenses", like creating "back office cost reduction software" and generally IT infrastructure are no different than acquiring some fancy machinery that enhances an industrial process. This also applies to companies whose main revenue model is building software and cloud services.

jdlshore2• 9 years ago

The point of the article is "accounting metrics drive company culture, which leads to damage." It's an important point that senior-ish managers need to understand.

NTDF9• 9 years ago

This is why employees of "cost centers" should just go on occasional strikes. Just don't work for 3 days, let the execs understand what the cost is of not having these "cost centers".

tboyd474• 9 years ago

This is a really profound point about software.

The ironic thing is that this "cost-center culture" has even affected the mindset of individual software developers and how we think of our own work.

Most developers ONLY look at their work in terms of cost. ALL pros and cons arguments are really about ways to reduce cost. Consider the term "tech debt" -- nothing could be clearer. Yet discussions rarely ever take place among engineers at a company about how to maximize profit or increase revenue. In fact, I would argue there is a heavy cultural bias on most engineering AGAINST optimizing for revenue, as it is seen as something that motivates sales or product people to rush timelines and sabotage sound engineering practices.

The obsession with cost is baked into programmer culture in such a deep and foundational way, I'm skeptical will ever change, even if the accounting of software projects changes. If you perform a search for the word "cost" on the eBook for the Principles of Object-Oriented Design in Ruby by Sandi Metz, you will find it dozens of times in various sentences about the urgency and critical importance of reducing costs, but the words "profit," "income," or "revenue" appear not even once. I'm not trying to make a point about POODR in particular, because this bias is only reflective of the culture as a whole.

You can certainly make the argument that it has to be that way, and engineering should be separated from revenue. I find it very interesting that, as a culture, we are only willing to speak about the monetary value of our work in negative terms.

paulddraper• 9 years ago

That's not specific to software at all.

Talk to any electrical, mechanical, or civil engineer and they will be focusing on getting this on time and under budget, not trying to increase "income" or "revenue".

HeyLaughingBoy• 9 years ago

It's far more prevalent in software though. Those other fields realize that incurring any technical debt is going to involve very expensive repayment.

One of Boehm's "fundamental problems of software" is that it's so easy to change, that it's easy to assume that you can always change it later at no cost. This is really why the problem is far greater in software.

aeorgnoieang6• 9 years ago

This is a really good point.

Something I've realized, tho it's, as you write, seemingly against my nature as an engineer, is that there are lots of situations where it's reasonable to 'assume' technical debt to reach a more important goal.

We absolutely should continue discussing technical debt, but also in the context of 'technical revenue' and 'technical profit'.

Interestingly, 'technical debt' works amazingly well as a concept. I suspect it's not even really a metaphor. Consider that probably the most important pragmatic consideration about whether you should assume a debt (of any form) is whether you can expect to make all of the 'scheduled payments' that it requires. And even if you can, will you still have sufficient slack to be able to pay-off or pay-down other currently un-expected debts or expenses that you might incur between now and whenever it is you finally pay off all of the original debt?

shados• 9 years ago

Tech debt works great when it's done on purpose, and when the people/management who take it on are the same one who eventually deal with it. It takes a level of organization maturity to do that though.

What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was).

Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch.

This level of industry immaturity prevents the tech debt concept from fully working.

In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.

subwayclub• 9 years ago

I don't think there is a "technical profit" to be had, though.

The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use.

For tech to be useful it has to succeed at creating enough leverage that you would use it over what was there previously, and plenty of technical projects get stuck on that point: they show an immense engineering effort but are solving the wrong problem because they don't optimize the desired workflow, or they expect everything to change around the product's workflow.

In that light, in a universe where most of these designs are bad and misguided and deserve to be put out to pasture, the cost-center mentality makes total sense because it asks the design to prove itself as early as possible. And the outcome of that in turn is the familiar rushed, unmaintainable prototype-in-production scenario.

New technology efforts always have this element of being a judo match: if you can find just the right time and place to strike and take the problem off-balance you can get an instant win, but the same strategy at a different moment doesn't work at all, no matter how hard you flex your coding muscles, and would leave you better off not attempting any new tech.

The balance-sheet model doesn't explain when and where to strike, though. It just says whether or not you're trying to do so this quarter, and any benefit will most likely show up on a different business unit's balance sheet.

nine_k• 9 years ago

This idea that "technical debt" is a misnomer appeals to me:

http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-...

KKKKkkkk1• 9 years ago

I always thought of technical debt as something that sloppy engineers knowingly or unknowingly assume on behalf of clueless managers. Kind of like a company accountant assuming debt without company officers knowing or caring. I guess I've never had the chance to see competent people make a knowledgable decision to write lousy software.

tboyd474• 9 years ago

I like to think there's a hidden mirror analogy of "tech debt," which is the "time discount," or the notion that the longer you wait to actualize a monetary gain, the less valuable it is. Both concepts are drawn from finance, and if one is applicable to software, so is the other.

I don't dare speak of this in engineering circles, though. I'd be chased out of the office with pitchforks...

mark-r2• 9 years ago

I'm not sure your thinking applies to the term "technical debt". It's simply a way of phrasing the downsides of crufty old code in a way everybody can understand. If you really want to stretch the analogy, you take on debt to get a tangible immediate benefit - wouldn't the benefit be maximized profit or increased revenue?

Terr_• 9 years ago

but the words "profit," "income," or "revenue" appear not even once.

That may be because those mechanisms are usually much more situation- and industry-specific, it's the X that software lets you do.

Conversely, software costs are the part that is more generalizable in a book about software.

tboyd474• 9 years ago

I would agree with you if the cost bias were only found in her book. But the bias is literally everywhere you go, on every engineering team. It's all we ever talk about.

At the CEO level, the money-making potential of software is clearly understood, so why, at the ground level, is it the exact opposite? Every programmer is paranoid about the costs they're introducing to an organization while totally ignoring the financial upsides. Every discussion is "cost now vs. cost later."

If our only goal at work is to minimize the cost to our companies, then our managers can do that better than us: he can just fire us and cancel the project. There, cost is now zero.

justinjlynn2• 9 years ago

Technical debt isn't debt, it's an uncovered short sale. The thing is, debt is controllable; it has interest, you can pay it down. When "tech debt" becomes payable and due, it's payable and due now; at any cost, or the project fails.

provost• 9 years ago

This is a clever analogy. Did you get this from somewhere? I'm curious what other finance analogies mix with IT/business?

CamTin• 9 years ago

Does anyone know of any further reading about how "software capitalization" works, with the audience of either a layman or somebody who is only cursorily familiar with real double-entry accounting? Also, do these rules vary significantly by country? It seems like the right way of accounting for software will be a huge structural advantage for countries as software becomes and increasing percentage of the value produced by the world economy.

pixelmonkey• 9 years ago

IT being a cost center at a modern information/product company is similar to doctors being a cost center for a hospital.

Only a deranged accountant thinks the cost center is the scarce talent that delivers outsize customer value, and that the profit center is the back-office filled with billers who "monetize" a relationship that wouldn't otherwise exist.

In tech, this flipped around in 2004-2008, I think. From 2001-2004, people thought IT was "over". Now, they realize software is "eating the world".

I am hopeful a similar realization will eventually come to medicine. Doctors deserve Google-style work perks and competition for their scarce talent. Insurance, back-office, and billing deserve to be turned into the AWS of medicine -- outsourced commodity.

Hextinium• 9 years ago

I think it will actually reverse in the coming years ( 2-3 decades ) as the education programs that mold programers over compensate for supply and people in medical fields decrease to where they are valued again.

uiri• 9 years ago

patio11 covered this in his career advice article.[0] I read that article around the time it was first published. The tidbit about cost centers and profit centers has stuck with me since. I have, for the most part, been able to avoid being attached to a cost center. Primarily by working at "tech" companies rather than more conventional companies which put software engineers in "IT" departments.

[0] http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

The Cost Center Trap

Related Stories