TB-FTE Ratios Explained, or, why storage management isn’t like Starbucks (Part 1)

Coffee-BeansI have been putting off this article for years, even though it is the most frequently asked question I receive.  I’ve hit a breaking point, though, and plan on answering this question in two parts.  This is part one.  Usually the question comes to me in the form of:

How many terabytes per storage administrator is the industry standard for IT Operations?” or “what’s the right TB:FTE ratio?

I am asked this by my own colleagues in sales and delivery just as often as I am asked by my clients.  I’m not favoring storage here, either, since the same question pops up for servers, virtual machines, networks and even data centers.  Storage is just a handy proxy for all infrastructure.  The context is that the enterprising, cost-cutting IT Director/VP/general busybody wants to compare his or her operations either to some indisputable benchmark or their best in class competitor.  We spend an awful lot on storage, so why not divide the amount of data storage by the number of people we pay to manage it?  It’s simple, easy to compare two shops against one another and the analysts publish survey data on this metric every year.

It’s also a completely bogus metric.  Here’s Jerry Thornton, one of the best storage guys on the planet:

Basing your storage FTE requirements on the amount of terabytes under management is like Starbucks hiring Baristas based on the number of coffee beans in their store room.

And that, in a nutshell, is why I hate this artificial metric.  I am hereby starting a campaign to rid the world of this evil measurement and supplant it with something more accurate, like the correlation between the number of Pirates vs. Global Warming.

I put off this response in part because the answer is complicated enough that I do not believe there is an answer anyone can reasonably support.  We’ll get to that in part 2 of my answer because the other reason I keep putting off my response is that this is a stupid question with (most of the time) even stupider motivations for asking it.  To wit-

  • Motivation #1: I think my people are overworked and I need this TB:FTE metric to justify hiring

This is at least an honest reason to look at a dishonest metric like TB:FTE but it advertises quite plainly that you don’t really understand the work your people do.  You should just ask them if they’re overworked.  That, or learn how to manage.

  • Motivation #2: I think my people are milking me and I need this TB:FTE metric to justify firing/RIF/headcount reduction because they’re lazy

This is the same as the first, except you should not so much learn how to manage as do all of IT a favor and resign immediately.  This justification screams “we have a crappy place to work and probably monitor our employees in their sleep.”

  • Motivation #3: I want to compare my IT operations efficiency to others in my industry as a benchmark, starting with TB:FTE

This sounds reasonable at first, but when asked “are you also measuring the amount of IT innovation and development your competitors deliver?” or “what about your groundskeepers?  Are you measuring their mowing acreage per person, too?” the phone goes strangely silent.  What you really mean to say is “am I squeezing the last drop of blood out of my people as efficiently as Cheapskate McSlavedriver?” You probably work for one of those companies that crows about its “world class talent” but bases its salary decisions on “industry averages.”

  • Motivation #4: I want to assess the training and development needs of my people.  Comparing my TB:FTE ratio to the published research will tell me something useful about where we need more skill development.

No, it won’t, and I think you’re lying about #4.  It’s probably more about #3 for you and to that I’ll flash you a big #1, if you catch my drift.

  • Motivation #5: Seriously though, TB:FTE has to be a good benchmark; I’m [a major retail chain] and [the other major retail chain] uses it.  We have the same industry, the same basic applications and we’re in the same city.

This is the “I can’t take no for an answer” motivation and it is an honest failure to understand just how complicated this simple measurement is to construct.  There’s no such thing as “sameness” when it comes to two different organizations.  You don’t both have the same e-mail hoarders, the same crazy DBAs, the same outstanding lawsuits or core business culture.  The only company for which TB:FTE can be used to compare itself is, well, itself.

  • Motivation #6: OK, wise guy, I want to compare my IT shop’s TB:FTE today to my own shop over time (last year, for example) so I can see how my evolving storage infrastructure impacts my team’s ability to service the business.

Pure hogwash; there’s no way you can- wait, what?  Yes.  THIS.  The TB:FTE metric is great for this purpose.  If you want to know how a new deployment or some change over time has impacted your personnel, this is a great use of the metric.

And it’s the ONLY use for which I can recommend it.  TB:FTE is a point in time measure of staffing.  Taken with other measures of productivity and updated over time, TB:FTE is a wonderful anchor point for an IT shop to gauge its staffing, innovation and progress to goals (hopefully, one of which is to deliver as a service provider might).

When I am asked by sales people, consultants, clients, executives and analysts what the magic number should be for storage administrators I always hedge.  To tell you how many people are needed to manage storage, servers, networks or anything else means understanding a LOT more about the specific client situation than just the raw measure of resources under management.

It’s a lot like Starbucks, except that Starbucks doesn’t count the beans in the storeroom before staffing up.  They do a whole lot more research, first, then they expand.

If Part-1 of this TB:FTE smackdown has left you with more questions than answers stay tuned for Part-2.  I’ll explain the 9 variables that go into measuring a proper staffing ratio for IT (storage, just to keep it consistent) and show you why measuring (and managing) this beast properly is a lot harder than downloading a Gartner study.

Update: hey, Hu agrees with me.  He’s just a lot more polite about his feelings on the matter.

This entry was posted in Driving Transparency, The Nature of IT, Transformation and tagged , , , , , , , , . Bookmark the permalink.

4 Responses to TB-FTE Ratios Explained, or, why storage management isn’t like Starbucks (Part 1)

  1. Pingback: TB-FTE Ratios Explained, storage management isn't Starbucks | The Practical Polymath

  2. Pingback: I am the Kinzua Kid | The Practical Polymath

  3. Pingback: The art of the FTE and how it’s misunderstood |

  4. Pingback: The art of the FTE and why it’s commonly misunderstood |

Leave a Reply

Your email address will not be published. Required fields are marked *