We communicate clearly, avoid complexity in our solutions and improve & follow processes so that it is easy to work with ICS.
What an industry we work in! How many emails did you send 15 years ago? How many web pages did you surf? For most of us the answer is zero. Can you now imagine a world without computer technology? So much has changed in such a small amount of time.
All of you techies will probably understand 100% of the following conversation.
Matilda: Whatcha doin?
Orpheous: Surfing the web.
Matilda: Did you know Google uses AJAX?
Orpheous: Yup, but they also use a lot of C.
Matilda: Man, they must be using a serious DBMS.
Orpheous: Yeah, I have a friend who writes SQL for them.
Matilda: They don't use ADO do they?
Orpheous: Yeah right. And their servers run on DOS.
Matilda: LOL.
Matilda: I just got a new mobile device!
Orpheous: A blackberry or a palm?
Matilda: Pocket PC. And it supports both GSM and CDMA!
Orpheous: Cool. Does it support WAP?
Matila: Oh yes! And straight TCP/IP!
Orpheous: Dude. That's sweet.
Matilda: Did you just call me dude?
Orpheous: LOL
Matilda: Is your PC still slow?
Orpheous: Yeah, I was in the middle of a DEFRAG and I got a blue screen.
Matilda: Whoa. Did you update your BIOS?
Orpheous: No, I couldn't find the EXE.
Matilda: Why were you using NTFS instead of FAT?
Orpheous: Hey, do I bug you about using AIX instead of Red Hat?
Matilda: No. But your company doesn't have the same ITIL requirements we do.
Orpheous: At least we're PCI compliant. What's that got to do with the OS?
Matilda: Nothing. Couldn't think of something better.
Orpheous: By the way who did you work with in implementing ITIL?
Matilda: IBM and HP.
Orpheous: Nice...
Read it again and think about that same conversation 20 or even 10 years ago. Many of these acronyms and names weren't even invented then. As our technology changes, our technical jargon changes.
And it's inevitable that some of that jargon makes its way into the consumer lexicon: IM, surfing the web, email, bugs, text (as in the verb).
Acronyms and short names are obviously useful. For people who already understand the technology you're talking about, they're easier on the tongue. But this friendly way of talking about technology belies an underlying complexity which we too easily foist on our customers.
Let's face it--engineers love complexity. I was conducting a new employee orientation yesterday. In going around the room introducing ourselves one of our exceptional new software engineers talked about one of his favorite home hobbies: aerodynamics.
?
I didn't even realize that could be a hobby. He enjoys learning all the math and physics involved with making stuff fly. Don't get me wrong--what a cool and admirable hobby, but it puts a fine point on the fact that engineers are perfectly comfortable with complexity. This fact has two unfortunate consequences, both of which lead to frustration for I.T. customers.
First, our complexity, while delightful and "fun" for us, is confusing and unnecessary to our customers. They want simple answers when they ask simple questions. They don't want technobabble. They want cheap, workable, simple solutions when they come to us with problems. We must shelter customers from complexity in any form. This is not to say we should hide the truth or cover up problems, but these things can be talked about in an easier-to-understand way.
Second, we often create complex processes and bureaucracy to protect ourselves and our customers from the complexity that comes with the territory. This irony is one which alienates our customers further, rendering us "hard to work with," "slow" and "imposing." Process definition and adherence is critical for an I.T. department of any size, but particularly so with ours, given both our depth and breadth of technology usage. But not all process is good process. We should be continually striving to simplify and measure our processes to make sure we're hitting the mark for our customers.
Simplicity. It's the name of the game in I.T. That's why our seventh and final cultural belief is "Make It Easy!"
I'm a business analyst in a county government. Many times I feel like I have to be bi-lingual. I speak with people about technology in human terms (no "technobabble" thank you very much), and then turn around and speak with the engineers who will meet their needs with technical precision. I believe the key is knowing your audience. The engineers (bless them) want - maybe even crave - the detail with exactness. The individuals with the need sometimes have a hard time expressing what they want. They know it internally, but don't know the technical explaination. But if folks feel like you are listening, and want to help them get to the goal, then the chances are everyone will succeed.
ReplyDeleteI'm often guilty of giving "too much information" when someone asks me "how do I do this on the computer?". Frequently my wife says I need to speak english not technogeek so she can understand me.
ReplyDeleteVery apropos, but I shudder to think where my life would be if I had sent zero e-mails, 15 years ago. It was just over 16 years ago that I first got online and fell in love with a girl that lived 800 miles away. Since there was no chat at the time, we communicated via e-mail—sometimes over 150 e-mails per day, just to each other! (Granted, many of them were only 2-3 sentences, but without chat, that’s how we conversed.)
ReplyDelete15½ years ago, this wonderful girl gave me a copy of The Book of Mormon and encouraged me to read it. I did, and was baptized on 31 August 1991.
By the time 15 years ago rolled around, I had been a member of the Church of Jesus Christ for almost six months—something that never would have happened, if I’d been sending zero e-mails.
(As an aside, that wonderful woman is now my wife and the mother of my children. See how things turn out, sometimes?)
…and I’ll follow this with an emoticon that we used all the time, back then: =)
[JOEL: Great story. Thanks!]
The natural world exhibits complexity that is layered and understandable. For example, thousands of leaves on a tree, but you can see the overall pattern in one glance. A child can understand it.
ReplyDeleteComputer-related complexity is man-made, an example of a problem that we have caused ourselves because of our own weakness and relative lack of intelligence. For example, having multiple names for the same thing, unnecessary incompatiblity, re-inventing standards, continuously creating our own towers of Babel that causes us to split up into different groups and go our separate ways.
I often ask myself, if Jesus were a software developer (like me), what kind of code would He write?
This is very good advice. I appreciate software that is designed with less complexity and ease. I did notice, however, how enormously complex the lds.org site got with its newest release. I have stumbled over and over again to find things that used to be 1 or 2 clicks away are now buried under mounds of menus that aren't obvious as to their content. I think the site looks really nice and professional but I preferred the lack of complexity and usability of the older site.
ReplyDelete[JOEL: Thank you for the feedback. We're looking into which are usability problems and which are discoverability problems. We value your feedback a ton. It would be useful for us if you used the feedback tool to give us specific issues. Thank you!]
Sometimes I wonder if we sometimes use jargon to conceal our own lack of understanding. If feel that if you can't explain something to any audience (e.g. young children), you probably don't fully grasp it yourself.
ReplyDeleteJoe's reference to "the Old New Thing" calls to mind a phrase from a song that I shared with a colleague just this morning: "Everything old is new again." We both have our IT roots in the "big iron" days of IBM systems. As we have worked to align our organization's processes with the ITIL "best practices" framework (mentioned in Joel's "conversation") , we have repeatedly noted that it is not really new at all - it simply describes core principles that were generally understood by IT practitioners in the 70s and early 80s. Somehow they were obscured by the advent of the PC in the mid 80s, and are just now again being discovered and embraced by a new generation.
ReplyDeleteWhat we have found most useful in adopting a process framework are two aspects: First is the establishment of a consistent vocabulary for the core processes (if you're going to have jargon, at least have just one!). Second is an emphasis on the needs of the business - which (if truly followed) will force IT to learn to speak the business' language - and find a way to translate the complexity of the technology into something to which the business can relate.
One thing that should be remembered is what I have frequently told the technical people working for me: "Don't spit alphabet soup at our customers!" This simple phrase helps us remember that there are a lot of folks who are our customers [not just those who purchase oru product, but users of our systrems, and even our own co-workers and management] that do not appreciate acronyms. I even started an award program in my division where I gave the one showing the most improvement an appropriate reward [a can of alphabet soup], which he displayed proudly at his desk for quite some time.
ReplyDeleteJoel, what eye-opening concepts you have brought up for me! Thanks a lot for sharing your insight with us and providing good discussion.
ReplyDeleteIt seems evident to me that pride unfortunately has a lot to do with our use of complexity and complicated processes in the I.T. industry. It can be difficult to give up the temporary sense of power and control that can be felt at times when using complexity and processes that protect us and help us look cool. It takes some of us real faith, humility, and hard work to jump out of our I.T. bubble world to understand the needs of others and in the business world around us.
For example, I have tended to stick religiously with establishing and following process. I would hound and expose other team members when they did not follow established process. After that, I've wondered why some people found it difficult or uncomfortable to work with me. As another example, I know it hasn't been unusual for me and for others to design a report or program without understanding very well how it is really used or why it has some of the logic that it does. Some of this may be because of all that is expected in such a short amount of time, but I'm confident that a fair amount of it is just from being comfortable in my own, little world.
After attending an LDS Tech Talks meeting with my dad, who has worked in the I.T. industry for quite some time, he and I were reflecting more on today's I.T. engineers compared to I.T. engineers from a decade or two ago. After recognizing some of the good and exciting things that are happening, we were sad to acknowledge that all too often today's I.T. engineers prefer not to communicate and ask each other questions. Unfortunately, many in the younger generation of internet-savvy engineers would never consider using the wisdom and experience of the older, pre-internet generation for I.T. practices and procedures (that don't depend on the internet), because the principles of the older generation are looked upon as being overly simple. (I'm speaking as one in the younger generation.) It's exciting to hear how the Church's ICS department is opening up communication with the technology community, setting the example and leading the way to the wise and humble path of simplicity.
Well, you probably got to know me more than you expected to, but I imagine there are plenty of others out there like me, and I'm grateful to acknowledge that I can change. On my part, I want to embrace humility and faith to overcome these challenges of pride.
I loved your tech person's hobby. People never understand why I can spend all day working on technology and then when I come home I want to spend it on the computer. I always described the difference is that at work I have to do certain things. At home I get to work on things that I enjoy like SEO, blogging, web development, etc.
ReplyDeleteSpot on Joel. Your message highlights a lot of challenges which exists within the industry. Those who recognise and accept them will survive and those who dont will fail. At the multinational software company I work for we now have 5 work principles we try hard to apply.
ReplyDeleteThey are Simplicity • Agility • Trust • Integrity • Innovation.
It is great to see how gospel related principles will always survive and the key is to create a perfect balance between all those (or similar) principles.
[...] member of my office reviews (and in the past has typically re-written) every one of them. We have a hard time talking without jargon and [...]
ReplyDelete