Wednesday, May 15, 2013

So you can speak geek. Big deal, can you speak business?


If you ask your VP of marketing what you need to look for in your next firewall purchase, what will he say? It needs to work? It needs to keep us safe? It needs to not interfere with our sending and receiving legitimate attachments? That hardly amounts
to a technical specification.



On the other hand, if you ask your network engineer what to look for, what will he say? High throughput? Configurable Bayesian content filtering? Better SMTP relay protection? That hardly amount to a business justification.

So who do we ask, and what do we ask? 

Often, technology purchases either start with management saying "fix this problem" or they start with the tech guys saying "hey, this thing isn't working well anymore, we need to replace it". In either case, there is likely to be a gap between what the suits (management) and the glasses (techies) think are important.

The suits will look at the ROI, the depreciation level of the existing equipment, the cap-ex or op-ex ramifications, and will want to know what this new expenditure will "do" for the business. The glasses are more likely to look at the technical specs, reliability, and bells and whistles. In the end, we often end up with the glasses not getting the budget they wanted (meaning they cut back on features they thought were important) and the suits feeling like they just spent money on who-knows-what-or-why.

Real-world (made up) example

To illustrate the conundrum, let's talk about Jake. Jake is the IT Manager for Awesome Stuff LTD. Jake reports to the CFO, Ritchey (the financial guy is named Ritchey, like RICH-ee - see what I did there) who knows almost nothing about technology, but handles the department's budget. Jake notices the company's firewall needs to be replaced. It locks up and has to be bounced a few times a month, it's throughput is barely keeping up with the load during peak times, and he gets constant complaints about the email content filtering "not working properly". Further, he sees the need to upgrade the company's bandwidth in the near future, but knows the firewall will be a bottleneck. So, he goes to Ritchey and says, "we need a new firewall". Ritchey says, "why?". Jake says, "because the flibbity-boppity multiplex protocol initiator is in a constant state of routing flux, and if we don't replace it soon, we could easily have COBOL RAM application OSI malware" (that's not actually what Jake said, but that's what it sounded like to Ritchey).

Jake puts together a proposal to spend a modest $20,000 on a new, high-end, loaded with bells and whistles, firewall. That price tag comes with 5 years of 24x7 support, next day replacement, free software updates, content filtering, email spam filtering, and has consistently gotten A+ reviews for quality and reliability. He knows that this will solve problems for his department, save lost time for employees, improve the network's reliability, and simply make things better at work.

Ritchey gets the proposal and sees 20 grand to replace a whatchamathingy that's not even broken, won't increase sales, won't decrease costs, and doesn't improve our business at all? The budget gets cut. Jake drops the service agreement, the ongoing support, the content filtering and spam filtering subscriptions, and downgrades by a few models.

The company has just missed out on an opportunity to solve a business problem, reduce costs, and improve efficiency and productivity just because Jake and Ritchey weren't speaking the same language.

What's the solution?

I think we have to get the suits and the glasses to speak the same language. So, we either teach our MBA-educated business people the ins and outs of software development, network engineering, systems design, and data security (not likely), or we start teaching our tech guys how business works.

How would the conversation have been different if Jake had made this proposal to Ritchey:

Look, our firewall is getting to the point of being unreliable. I'm concerned that we're quickly heading for a hardware failure, which would mean an expensive quick-fix plus crazy-expensive downtime. The existing firewall is fully depreciated anyway, so it's time to look at replacement. I've evaluated a new product that will meet our technical requirements. It will also give us the risk protection we need with a service contract and free software upgrades to make sure we get the most out of our investment. The purchase will cut my departments time spent managing the existing firewall by 40 man-hours per month. That's 2,400 hours over the expected life of the product which means a $72,000 opportunity code reduction. We also get complaints from users who spend a lot of time fighting with improperly blocked email attachments, filtering through SPAM email, and fighting with the content filter. We expect $46,000 in improved employee productivity over 5 years by eliminating those issues. We also get better protection for our data, and we know from our recent risk assessment  that exposure of our intellectual property would be disastrous - this purchase will help mitigate that risk.

Now, we can make the purchase up-front out of Capital or we can use their managed firewall service and keep it in Operating expense - which do you prefer?

Conclusion

My point here is, if you're a techy, learn how business decisions are made. Learn what things are important to the suits. You might not like it, but you'll be able to do your job much more effectively.

What do you think?

No comments:

Post a Comment

I'd love to hear your comments, as long as they're nice. If they're mean, I wouldn't love to hear them.