OTRS ITSM Part III(a): You’re a Business


ITSM really doesn’t make sense unless you think of your shop as a business unto itself. This is easy if you’re a consulting or services firm that does contract work. If you’re in the IT department of a company, you might be less inclined to think of your shop as a business or service center, which could mean that you’re in a very reactive shop that seems to shift focus at the whim of whatever VIP last touched base with your boss about what IT should be doing. For all your geeky powers and ability to ruin the entire business with 1 shell script, to a lot of folks outside of IT, you’re just another go-fer. So in the next couple posts I’m going to focus less on your geeky powers and more about having a business-minded approach to yourself and your department.

My Business Cred

I’m not an expert at business, but I’ve had a lot of exposure to running businesses. I’ve been part of a few start-ups; I have several entrepreneurs in my family; and my wife has shared with me pretty much everything she learned while getting her MBA. I’ve also had a lot of success employing the principles I’ll be writing about here, so at the very least I can verify that what I’m telling you has actually worked once.

You’re a Business

This is business 101 for everyone: You, yourself, are a business. Your name is your brand, and your face (or maybe your face tattoo or that weird fedora you always wear) is your logo. Your skill set and the benefits you can provide are definitely drivers of value, but your personality also plays a huge role. Yes, if you’re smart enough, strong enough, fast enough, or unique enough, you can get away with being a huge jerk and still be valuable. Pop culture is full of these figures. Most of the time, though, you can win a job not by being the most qualified candidate but by being the most desirable to work with. A company can teach job skills but generally doesn’t want to work on making you friendly or fun. So you have two major assets as a business: your job-related skills and experience, and your personality.

Managing Your Brand

You need to think about this. What gives your brand value? Are you the printer expert? Are you the ultimate OTRS guru? Are you the jack of all trades who can give the quick answer to any question and knows who to call for more advanced problems? Think about and outline what you offer and how well you’re selling that. If you don’t concentrate on what makes your brand strong, you’ll just be a random IT person. And if you’re a random IT person, you’re a “computer person.” And “computer people” aren’t always highly regarded. The reason is obvious: if you’re the printer expert, but the user’s problem is with their iPhone, to them it doesn’t matter that you can fix printers. You can’t help them with their immediate concern, and so you’re useless. And that’s what they’ll remember–and it will get reinforced every time they have a problem you can’t solve.

This isn’t fair to you, but how are you managing it?

Here are some rules I try to live by:

  • If you have no idea how to fix the problem, be honest.
    • “That’s not my area of expertise, but I’m going to run it by my team and do some research.”
  • Help the user understand the context of their problem and what you can actually do about it. This helps you build expectations correctly.
    • “Well, Sharon, it looks like this isn’t a printer issue. You’re actually not connected to the network at all. I’m going to try a couple basic troubleshooting steps with you, but if they don’t work I’m going to have to call in the big guns. I can help you with all your printer problems, but when it comes to networks, I’m about as much of an expert as Google allows me to be.” (Hey, look at that! Next time Sharon has a network issue, she either knows not to ask you for help, or she knows what level of expertise she’s getting.)
  • Don’t hand off–collaborate.
    • This doesn’t always happen because it can spread resources too thin, but no customer likes to be passed from agent to agent trying to get their problem resolved–explaining the problem over and over again. When possible, stay with the user until either the issue is resolved or your presence is a hindrance. This is a huge value add for your personal brand.


You might be wondering what any of this has to do with ITSM. “Great life advice, Tyler, but I really just need to know how to implement ITSM.” The next post will make clear how this discussion is relevant. Remember that my goal here is not so much to restate the technical details that are already available in the official documentation but to provide context for the implementation and the mentality that will help you design a successful setup.

Love and kisses,



On Being Self-Stupicient

I really like portmanteau words. I use them frequently in my writing, so this is probably already clear. Lately I’ve had a new one on my mind that I thought I’d share as part of the spirit of this blog… that spirit being that I’m usually a dummy the first time around. So today’s entry is on being Self-Stupicient. (Fair warning: this is not a technical post. This is more about personal patterns of behavior than a how-to or a tech share. But I’ve seen myself and others in my profession fall into this trap enough to feel like it’s relevant to share here. Also, if you haven’t figured it out by now, I’m kind of a goof. That side of my personality comes out strong here. Thanks for judging me in whispers behind my back so that I’m none the wiser like respectable people do, and not to my face or in the comments like reality-TV stars and teenage boys do.)

I feel a lot of pressure to be self-sufficient and to get my job done standing on my own two feet. I hate asking for help. I don’t know where that comes from, but I don’t like to feel like I’m bothering other people–especially if it turns out to be something really dumb. I don’t want to be that guy who asks for help looking for his glasses and finds out they’re on his head. I’m always embarrassed when I ask someone to see if they can pick out what I’m doing wrong in my code and they point out that I spelled a variable name wrong or left out a semi-colon. (C’mon MySQL… I hit “Return” six times! Why don’t you just get that I want to run my SELECT statement? Do what I want you to do, not what I’m telling you to do!)
I think part of this comes from thinking I’m a smart guy. I look in the mirror, and the fella in there says, “Gee whiz, buddy! It’s a good thing you’re smart!” And I think, “Wow! What a nice guy! And so handsome!” Since that guy is also extremely trust-worthy, I go about my day wondering when people are going to start referring to me as “Professor,” or say things like, “Watch out! Genius on the loose!” when I come down the hall–unironically… instead of ironically like they do now…The point is that when I come across a problem, I believe that given enough time and the proper resources, I can figure out the solution. On top of that, I’m a firm believer in learning by doing. So when I come across a problem or a road block, I often feel the need to prove (to myself… I realize no one else cares) how smart I am and how much I’m growing and learning. For this reason, I’ve had what I would consider a lot of successes academically, professionally, and personally. I’ve become really self-sufficient.
I’ve also wasted a lot of time being stupid so I can maintain my (extremely flawed and almost exclusively internal) reputation of being so self-sufficient. So I’ve been trying to identify the threshold where I go from being a useful guy that my team can count on to take a problem off their plate and keep it out of their way to a guy who comes to the daily stand-up and says, “I spent about six hours trying to figure out why I couldn’t connect using protocol Y yesterday, and I’m no any closer than I was when I started,” only to have the gal sitting next to me say, “Hey, um, Tyler… we’re using protocol H for this project.” Wah wah…When I’ve come to the conclusion that there’s no better way to do something, or that something can’t be done, I trust myself. This might be pride or vanity (sometimes I wonder about that guy in the mirror I told you about earlier), but I think it’s a pattern we all get into. When we’re given an assignment and we’re plowing through it at a steady clip, we feel good, smart, and successful. Then we come up against something we didn’t expect or that didn’t work even when we followed the instructions exactly (I’m looking at you, sample code!), it kind of baffles us. It does me, at least. And because I’ve hopped a long from A to P so well, smoothing out any kinks on the way, when Q doesn’t bend to my will, I get mad at myself, and I start to feel unsuccessful.
But I know I’m smart. I know I’m a problem-solver. So it’s not my immediate instinct to ask for help. It’s my instinct to kick myself in the butt for not already knowing the answer. Besides, I’m the one who’s been staring at this project for weeks. I’m the one who knows it inside out. If I can’t figure it out (okay… there’s definitely at least a little vanity there… I see it now), how can Adam or Brian help? (Adam doesn’t know anything. He thinks Michael Keaton was miscast as Batman, for cryin’ out loud!)
But you’ve been there, right? You know where this goes. The longer I go without asking for help, the more convinced I become that there’s no help to be found and that this is an unsolvable problem. But I’m smart! There are no unsolvable problems for me! So I keep going… Then, at some point, I realize I’m wasting time. I start performing the same tests or trying the same things three times over just to confirm that I did what I thought I did and got the results I thought I got. I start taking more breaks from thinking about it, because that’s what they tell you: as soon as you stop thinking about it, the answer will come. So I switch tasks, go for a walk, chat with my cube-mates about the merits of Michael Keaton’s outstanding performance in Birdman. (No one else in the office has seen it, so I get to always be right about everything when we talk about that. Builds my self-confidence back up.) Occasionally, this works. More often, I’m too embarrassed or too mad at myself to admit to anyone that I’m stuck and need help.  Sometimes I even stop people from helping me. I won’t show them what I’m doing. I don’t want to be proven stupid. That’s when I think I’m being self-stupicient. I’ve made this all sound pretty silly, but it’s easy to get to the silly point. It’s easy, if you don’t take yourself too seriously, to laugh at your own dumb mistakes and not make them again. But it’s hard to know when your efforts take that turn from working toward a solution, to firmly securing the problem. I don’t know how many times ten minutes or an hour of “bothering someone else” has saved me days of wasted effort. On the other hand, I don’t know how many times I’ve felt as if I’ve stolen someone else’s time because I didn’t read instructions carefully enough, or because I didn’t look at the fifth web search result before I asked for their help. So I worry that if I ask for help too soon, I’ll look like an idiot. But I’ll also look like an idiot if I wait too long to ask for help. Where’s the sweet spot? Wish I knew. But I’m starting to watch for it, and it’s getting better. Time-boxing definitely helps as a strategy to combat self-stupiciency. This is where you give your self a certain amount of time to solve a problem. If you can’t solve it by then, you ask for help or move on to something else. If you lack self-discipline, though, it’s tempting to give yourself 15 more minutes… then 15 more minutes…
I’ve also learned to go to the forums quicker. And by that I mean posting to forums. I’ve always been quick to search them. Posting questions helps me in a couple ways. First, articulating my process and questions in writing often leads me to the answer. I will realize in writing out my question or framing my problem that I missed something, forgot to try a recommended solution, or that there’s another way I can approach the problem. Second, people are really, astonishingly helpful. This makes sense. One of the main reasons to become a software developer or join an IT department is because you like to diagnose and solve problems–specifically technical problems. It’s fun for us! It’s really satisfying. And a lot of the time, something that’s hard for you is someone else’s bread and butter. If I just stop being so self-stupicient, I get to benefit from their marvelous experience and goodness.I also try to check out of my own head a little more often. When I’m really hammering out a problem, I often get extremely focused. I lose track of time. I don’t hear when people are speaking to me. I don’t notice that everyone else has gone home. Sometimes I also don’t notice that I’m getting tired, or that I haven’t eaten, or that I’m getting anxious and fidgety. I’ve made very few situations better by skipping lunch or losing sleep to work on them. I’ve also never gotten closer to solving a problem by getting agitated. So every now and then I have to give myself an honest assessment of whether or not I’m still thinking clearly about the problem, and if I wouldn’t be better off getting a disinterested third-part to lend a hand. Because if I hit that point where I’m mad at the problem and I’m mad at myself for not solving it, and then someone points out to me that it’s a tiny, stupid mistake… well, then I’m going to be mad at everything. That’s easy to cut off. I just turn around and say, “Adam, I’ve hit a wall here. Will you take a look at this and see what I’m missing?” Then, if Adam doesn’t see anything I’m not seeing, I know I haven’t crossed the self-stupicient threshold. Plus, I get to say, “Well, thanks for nothing, Adam!” which is always fun for everyone.I know this post was a little off the beaten path for this blog, but thanks for indulging me. I’ve been wanting to articulate that for a while for my own sake. In my next post, I plan to turn my focus back to OTRS.  Love and kisses,Tyler