A couple of weeks ago, in response to the blog post about Yammer's uses I wrote, I got into what started as an interesting conversation with @JoshDeax. Long story short, he suggested that Yammer's functionality was lacking and there were other products that had more features. Apparently it wasn't enough for him that Yammer will easily integrate with other Office 365 products, though, as this was his response:
@scottnorberg It's been two years so far. Plus integration=wrong. Out of the box=right.
— Enterprising Josh (@JoshDeax) May 20, 2014
I suspect I'll be writing about integration vs. out-of-the-box at some point, since that's a fairly interesting discussion in itself. Instead, though, I'm going to write about the culture of IT, specifically as it relates to comparing one solution/approach to another.
(Disclaimer: Since you're only allowed 140 characters in Twitter, it's a hard place to hold a nuanced discussion. Plus, Josh may have been trying to get attention by posting a strongly worded opinion. Therefore, I am not trying to argue that Josh necessarily has this blind spot. This is a problem with IT in general, though, and as a result should be addressed.)
If you search the web, you will find a large number of stories of IT professionals who don't want to sacrifice quality for price or convenience. Like Josh above, too many people in IT don't understand (or don't want to understand) when sacrificing quality to reduce costs may be appropriate in some situations. In this case, Josh didn't ask questions about existing infrastructure or whether the more sophisticated (but integrated) Office 365 was needed to meet specific business needs. No, instead he focused on "integration=wrong, out of the box=right".
Aside from being dumb and annoying, this all-or-nothing approach alienates the very people that we are being paid to help. They just want to get their problem solved - they don't want to hear about the messy details about how we'll get it done. And they certainly don't want to hear people creating unnecessary obstacles to getting the "real work" done. And make no mistake, assuming you're a typical medium-sized business using the Microsoft stack, abandoning several existing Microsoft products, such as Lync, Outlook, and SharePoint, to take full advantage of an enterprise social network is creating artificial obstacles to implementing a solution.
So what should we as technologists do?
(Disclaimer: Since you're only allowed 140 characters in Twitter, it's a hard place to hold a nuanced discussion. Plus, Josh may have been trying to get attention by posting a strongly worded opinion. Therefore, I am not trying to argue that Josh necessarily has this blind spot. This is a problem with IT in general, though, and as a result should be addressed.)
If you search the web, you will find a large number of stories of IT professionals who don't want to sacrifice quality for price or convenience. Like Josh above, too many people in IT don't understand (or don't want to understand) when sacrificing quality to reduce costs may be appropriate in some situations. In this case, Josh didn't ask questions about existing infrastructure or whether the more sophisticated (but integrated) Office 365 was needed to meet specific business needs. No, instead he focused on "integration=wrong, out of the box=right".
Aside from being dumb and annoying, this all-or-nothing approach alienates the very people that we are being paid to help. They just want to get their problem solved - they don't want to hear about the messy details about how we'll get it done. And they certainly don't want to hear people creating unnecessary obstacles to getting the "real work" done. And make no mistake, assuming you're a typical medium-sized business using the Microsoft stack, abandoning several existing Microsoft products, such as Lync, Outlook, and SharePoint, to take full advantage of an enterprise social network is creating artificial obstacles to implementing a solution.
So what should we as technologists do?
- Focus on solving business problems. Always remember you're being paid to make someone's life easier, not write code.
- Keep in mind that guidelines are just guidelines, not hard-and-fast rules. Clean code, elegant solutions, and staying current with product releases are fine things to strive for, but sometimes a small but messy problem needs a small but messy solution.
- Focus on meeting needs, not fulfilling desires. Most business users aren't sure how their needs can be solved using technology. Therefore they often ask for a lot of things that aren't really needed. If you find out what is actually needed, then you're in a better position to know what corners to (or not to) cut.
- Communicate! Sometimes implementing a new solution really does involve upgrading a product or replacing a technology stack. But you'll be much better off if you communicate the difficulties early and talk about pros and cons rather than assuming that you already know the correct approach.
- Admit when you don't know something. This is related to #4 - if you're unfamiliar with a product, then the risk of using something new should be communicated and addressed. Too many IT professionals (and people in general) hide what they don't know for fear of looking ignorant or incompetent. If people are used to you delivering solid products, they'll appreciate your honesty. (If they're used to bad products and missed deadlines, then you have other problems to address first.) As a bonus, your co-worker or client will see you more as a person, not a "magic IT guy".
Can anyone think of anything else? Please comment below!
No comments:
Post a Comment