Q: Yes, undergraduate.

 

A: So 2011, so about seven years ago.

 

Q: Okay. And did you attend graduate school?

A: I did. I attended the College of Idaho for undergrad, and the University of North Carolina School of the the Arts for graduate school.

 

Q: Could you tell me what you have your undergrad and graduate degrees in?

 

A: So my degrees– [laughter] this is funny, usually for a job interview or things like that, the funniest thing going through my resume is like, “Okay, I see these Cisco certifications, and job experience” – and then they look at education, and it’s like, “Hmm, Bachelor of Arts in Voice and Masters of Music in Opera Performance.” That, it’s probably the weirdest thing when looking at my resume, like, “That doesn’t exactly square with everything else!” [laughter] – that’s why it’s at the end!

 

Q: Gotcha. Is all of your – we’ll get to this in more detail down the line, but – is all of your background in IT networking sort of learned on the job? Or do you have specific training toward that since your degrees aren’t related?

 

A: So, basically the path I took – and not to get too much into my life story, or whatever – but basically the path I took is I finished graduate school, and wasn’t quite at the point where I could embark on a fabulous career as an opera singer, so I wound up getting in touch with a teacher who lived in Tulsa, Oklahoma, and moved out there to continue studying with him. Over the time I was in Tulsa I was singing with Tulsa Opera, doing some chorus work and smaller roles with the company, but it wasn’t ever to the point where like, I was a full time opera singer. It was more a aspiration and a source of income on the side while maintaining a day job. I wound up getting an administrative position at Tulsa Community College, and one of the perks that they offer for working there on staff is they allow you to take a certain number of credit hours per semester for free. And I was in that position for about a year and a half, and it got the point where I was getting some success in singing, but I was also thinking about, “Do I really want to do this for the rest of my life? Will this give me what I want, vis a vie, geographical and financial stability. I want to have a family at some point. Is this necessarily conducive to that?” And finally the decision I had to make was, you know, it really isn’t. And I managed to get out of two degrees in the arts without any student loan debt, and maybe that’s enough of a success story and we should start looking at other options. So at that point I had gotten the A+ certification, which is a very basic, it’s almost kind of considered meaningless at this point, because it’s so generalized and it’s not really specific to any one company or manufacturer. So it’s one of those things that basically it just says, “I have an interest in computers and can Google better than the average bear to solve problems.” So I had gotten my A+ because that was kind of like the foot in the door trying to move into an IT role with Tulsa Community College, but then I started to look at, “Well, I could take classes for free, so what are the options here? Oh, well there’s a class based on the Cisco certified network associate certification. Well, I’ve always liked networking, so let’s maybe explore that.” So I wound up signing up for the course, took the course. They had broken it down into two tests at that point so I took the first test and passed it. Shortly after I took that exam, I came out to Washington, DC because my brother and sister-in-law live here – they both work for the government – and he made me the offer around that time of, “You know, even if this works out the way you want it to, Tulsa is going to have pretty slim pickings for IT positions, even though IT is a growing field, still you are in Tulsa, Oklahoma. Do you want to maybe move to DC and you can hang with us, not have to worry about rent while you are looking for a new job.” It was a god send! And so I was like, “You know, yeah.” The thing about Tulsa is it’s not close to any of my family, it’s not really convenient to, like it’s not a major airport, so trying to get anywhere else in the country is kind of difficult. So it was like, “I don’t really have any ties here, and we’re kind of shutting the door on going any further with music, so yeah, let’s do it. Why not?” So I took the second half of the the second class and the certification path, took the second exam, passed the second exam, moved out to DC, and started looking for jobs, and I actually wound up finding a staff singing as a singer at a church in downtown DC and then shortly after that, found a position on the help desk of the company I currently work for. I was on the help desk for three months as a contractor, and then they brought me on full time at the start of 2016. About four or five months in, someone pointed out that, “You know, networking, if that’s what you’re into, has a few open recs.” And so I applied for the job, got an interview, got a second interview, got offered the job, and moved off of the help desk and into networking about a month later as a technician, and then this past March I made the jump from technician to engineer, which means, you know all those extra hours that I was happy to take on when I was hourly, suddenly I’m salary, and it’s like, “Hmm, I’m not actually paid for this extra time,” [laughter] but it’s a great field to be in, I think, because computers in general, it’s constantly growing. Technology is just changing and there’s always something to learn. If you let it be, it will always be intellectually stimulating. There’s always something new to learn.

 

A: That’s a great way to think about it, yeah.

 

Q: That is one thing that kind of scratches an itch that the music world didn’t, because if you look at the opera companies that are out in the world, most of their season is going to be things from the 1700s and 1800s. It’s not to say you can’t find something new with every production, but for me, seeing the same thing put on, I’m like, “I know this story – no really, I know this story! And if you presented it in a new way, I still know this story.” And with technology changing the way it does so frequently, it really appeals to my more intellectual side more so than I think opera did.

 

A: That’s great. Oh, that’s such an interesting path. So can you give me sort of a very brief description of your primary job functions?

 

Q: That’s actually kind of a hard question to answer because, networking-wise, you’re talking about the entire internet. So if a ticket comes in saying “I can’t access site X,” well, we only see our half of that transaction, so it’s like, “Well, I can tell you it’s none of our equipment.” And then at the end of that transaction, the customer’s like, “Okay, well I still can’t access site X.” So, most of my job at this– actually it’s changing, since I’ve moved into a more engineering-heavy role, there’s less focus on like the day-to-day handling tickets from the help desk, and more we’re building new things. Like one of the things I’m actually working on right now is a small office/home office router solution for teleworkers because the typical employee will go home and they have a client on their laptop that allows them to form a tunnel back to the company. And that works for the average end user, but some people are more of what we call “power users” and they have like a lab they’ve set up in their home, they’re a full time teleworker, and they need to have, like for example, they need to have a phone on their desk that’s connected back to our infrastructure. So the small office/home office router solution that we offer, it’s not new, it’s been around for a while, but there are certain new requirements in terms of network security and segregation that we’re having to adhere to as part of – it’s called The National Institute of Science and Technology 800-171 Guidelines – not that that anyone really needs to know what the exact guidelines are, but essentially, what it entails is we have to seperate devices on a network. So in order for something in zone A to talk to zone B, it has to pass through a firewall which will make a determination as to “Is device A allowed to talk to device B? How can device A talk to device B? In what ways is it allowed?” – so on and so forth. And what we were offering for the small office/home office router solution just, the hardware was not up to the task. So things were kind of limbo for a while as to, “Well, are we going to move fully to just client software on people’s laptops? Or is this service going to expand?” And finally it was decided, “Well this service is going to expand.” So what I’ve been working on and what we’re hopefully going to start sending out next week – this is what I was talking to you about that fire that I’m trying to put out [laughter] – what we’re hopefully going to start putting out next week is the new hardware for the small office/home office routers which, instead of just being one box, it now has to be two, because the requirements of 800-171 basically requires to use some of the more advanced functionality of, instead of doing routing and switching on one box, we’re using advanced switching and advanced routing functions, so now we have to do them with two boxes. And the advantage of it for the power user teleworker is they have multiple devices that they could plug in, and it’s like extending the network out to their home, as opposed to the client on the desktop making a tunnel back just for their laptop or desktop. So because it’s being handled by this box that has a bunch of ethernet cords that you could plug in any arbitrary device, suddenly you could plug in a phone, you could plug in a video teleconferencing unit. So it’s basically a more fully featured teleworking solution, which we’d hoped we’d be able to accomplish it just with a client on a laptop, because that’s a much simpler way to do it, and it’s much easier to do deliver in terms of, it’s just a piece of software that’ll run on any hardware you throw it, versus we’re now having to actually put together a hardware solution and be putting boxes in people’s homes. So that was sort of the back and forth until finally it coalesced this week and I’m now putting that together. I’d more or less taken ownership of the service prior to this, but the actual building it from the ground up, so to speak, which, I didn’t build a lot of the infrastructure, but I’m now putting together the configurations for the equipment that’s actually going into people’s houses. So that’s sort of what I’m working on right now. But to get back to your actual question of what are my daily job duties, it’s either you’re doing design, or you’re doing troubleshooting of an existing design, and I’m kind of seeing both sides of that now. The tricky thing about networking in particular is everything’s writing on the network in your average enterprise, so oftentimes when a ticket comes through, the first determination we have to make isn’t, “Well where’s the problem?” it’s, “Is this actually a networking problem? Or is it something else? Or is it some other component of this particular service or piece of software, and the network is just tangential to it?” And oftentimes we wind up solving the– because we’re in the best position to troubleshoot that sort of thing, but oftentimes we will get things sent to us, where it’s like, “This isn’t really networking, but sure, I’ll take a crack at it.”

 

Q: I see, okay, okay. That’s right, that makes a lot of sense. How frequently are you required to write?

 

A: So, I would say a good portion of my day is reading and responding to emails, and it is one of those things where, you get stuck in that school mentality, “Well, how many pages did I write? What were the requirements of this particular– how would I grade this? Where’s the professor scoring this for me?” And it really doesn’t boil down that simply, but I would say I write, if we do like a page equivalent writing, I would say I write anywhere between two and four pages a day.

 

Q: Awesome. Could you give me a percentage of your week, ballpark? Like time that you’ve spent?

 

A: Ballpark writing? Twenty five percent.

 

Q: Okay, awesome. How long do you typically have to complete a writing project? So you talked about that a lot of it is email– are there other sort of larger scope writing projects that you complete too?

 

A: There are– like documentation, for example, of a service, or a piece of hardware, or like one of the things I still need to put together is, I recently went to Cisco Live, which is Cisco’s big, it’s their big trade show event that they do. They do them all over the world and it’s usually once a year. I still need to write a trip report for that just to talk about what did I learn, what new things are on the horizon, what classes did I attend. So, not quite a book report, but along those lines, along those lines. Then there’s, if we’re putting together a new service that I’m in charge of, here’s the documentation of how it works. I would say that that rolls into the twenty five percent as well.

 

Q: Okay. And how long, let’s say for that documentation, like how long, start to finish, are you given, and I’m sure it varies project to project, but are we talking hours? Days? Weeks? Months?

 

A: It really does vary, it’s hard to put a firm number on that, but I would say the expectation is at the conclusion of, for example, an eight week project, you would have probably 5-10 pages of documentation and you’d present– what we tend to do internally, is have a quick 45-60 minute meeting just talking about, “This is the service, this is how it works, this is where you could go for troubleshooting instructions documentation,” that goes into more depth, because yes, I am the service owner, but no man is an island, and if I get hit by a bus tomorrow, someone needs to be able to go through this and figure this sort of thing out. Or if I go on PTO, and someone comes in saying, “My widget doesn’t work,” this is the relevant documentation of how that widget is tied into our services, what we manage, and here’s where you would start troubleshooting it.

 

Q: Gotcha, gotcha.

 

A: So you don’t have to call me [laughter] while I’m on an island somewhere in the pacific.

 

Q: Right, right, okay. And again, this will vary between the types of documents, so you could maybe just pick one or two to talk about, but who are the primary audiences you’re writing to, and what are the primary purposes of the documents that you create?

 

A: I would say the primary purpose for all of our documentation is mostly going to be troubleshooting, just because when you’re putting together an, “as built, this is how service X works,” what you’re really kind of saying is, “This is how service X is supposed to work, and depending on the thing that went wrong that you’ve now got a customer asking you about, this is where you need to start looking. These are the threads you need to pull on. These are the foxholes you need to chase down.” And the audience is generally going to be at least for the majority of my writing, the audience is either my peers, other folks in the networking department, or tech end users. And oftentimes, I think in a sideways sort of way, having studied a field that is very far, far field from technology actually helps in some ways, because I’m kind of having to relate to people who don’t necessarily have the background of– they have no idea what the OSI model is, they don’t know what TCP and UDP are, and they don’t care. From their perspective, it’s just “Service X doesn’t work. Why no work?” and you have to be able to relate to them in a way that’s approachable, that they can understand why service X doesn’t work, how to fix service X from their side, what they would need to do, steps that they can take, and it’s a situation where you have to know what level of detail to give them. Not that you obfuscate or conceal truth or anything like that, but you try and discern from customer to customer how much background that they really want, or do they just want, “Click X, type in Y, and your problem is fixed. Have a nice day.” And that varies from person to person. I tend to be probably more verbose that maybe is really necessary. But that’s kind of my own bug bear of, I really want to see how things work. Like when I was on the the help desk, one of the things that I found frustrating was, you know, we would escalate tickets to the team, or person, or group that owns it, and it just goes into a black hole and I have no idea what happened with it. And I could pull it up after the fact and see their clips (?22:34) notes of what I did to fix it, but that’s never really as satisfying as actually going through the process of, “What steps did you take to resolve this?” So, because of that, I tend to be more verbose and perhaps get a little more technical than is really necessary for the average person, but the reason is I have a personal preference of knowing is better than not knowing.

 

Q: Yeah, exactly, exactly. When you think about the types of writing that you do in a typical week, how did you learn or how did you know how to perform those types of writing?

 

A: Honestly, I think most of my writing ability, if you could call that, or my writing style, comes from written a lot of papers in highschool and beyond, and having– honestly, my mom go through it [chuckle] and correct it and give me her suggestions and revisions. I think that’s honestly where most of it reprised from. Totally from parents [chuckle].

 

Q: Has there been a time in your work life that you’ve felt unprepared to tackle a writing project?

 

A: I would say yes, at times, because even like when I was on the help desk, there are oftentimes where you’re stuck in the position of, “Well, I know this is an answer they’re not going to like, so how do I word this in a way that’s not just going to anger someone further?” or like, you know, get the, “I demand to speak to your manager!” kind of thing. How do you de-escalate? How do you phrase things in such a way that you explain the problem, but you don’t put someone in the position of being dissatisfied with your answer?

 

Q: And how do you approach that?

 

A: Honestly, I’m still trying to figure that out sometimes. But I think the most important thing is to come from a place of empathy. Like, you know, “I understand your problem, I understand why you’re upset. I don’t think we can fix this on our side.” Like, for example, if there’s a problem accessing a particular site and it’s completely upstream of us– coming back and just telling someone, “There’s nothing we can do,” – you’ll run into people who just won’t accept that as an answer and they’ll want an exception to be carved out, or “if you can’t bring me to the mountain, then bring the mountain to me” kind of thing. And oftentimes it’s just, just coming from a place of understanding and telling them that, “I’ve looked at this as exhaustively as I can and I’ve ruled out everything within our infrastructure, it’s not on our side,” and at least giving them a path of, “Here is the number for the help desk of the place you’re trying to get to, I think it’s an issue that you have to raise with them.” Rather than just saying a flat, “There’s nothing we can do,” you’d say, “I’m very sorry, there is nothing we can do, but here is at least a path where you could pursue this further.”

 

Q: Perfect, perfect, okay. What did you do to overcome early writing challenges? Like what you talked about, you know, you’re still sort of managing this very specific sort of diplomatic writing, when you know that someone’s not going to like the only answer there is– what did you do, were there practical things that you did to improve, or to get a handle on that kind of writing?

A: It’s one of those things that, for me, is just you have to do it over and over and over and eventually, you’ll start to get better and better at it, at the diplomacy side of the house. And if you build the rapport with someone to– and it’s building that rapport that I think, that’s oftentimes hard for especially people in IT to do, because the stereotypical IT guy is– like they’re in a room in a building somewhere and the door is always closed to that room, they’re very unapproachable. And I’ve always, you know, I end every email with, “Please feel free to ask if you have questions, I will answer them as best as I can.” Just something that lets them know that I’m not just shutting the door on their face, “I’m approachable, please tell me your tale your woe and I will listen!” So that’s been something of a learning experience because it’s one thing to go to, like an explanation path of, we’ll just say, “No, that’s not something that we’ll support,” and come back with, “No, that’s something that we’ll support,” and it’s another to deliver that message but in a way that helps the person understand that you’re not doing this out of meanness, you’re doing this out of an honest inability to assist them further.

 

Q: Right, right, okay. Is there a person in your organization who oversees your writing, specifically?

 

A: Um, not specifically my writing, no. In terms of accountability, it would be, like if I said the wrong thing, it would be, you know, going to like a manager, someone above me, to say, “Hey, your employee said the wrong thing,” or, “Your employee said the undiplomatic thing,” sort of thing. But it’s not like someone’s auditing any messaging I put out there. But I’ll often seek that out and ask– like if I’m advising someone on a service that I don’t own, that you know, I’m vaguely familiar with it but not necessarily, I’m not the subject matter expert, I will try and find who the subject matter expert is and say, “Hey, this is what is my understanding of the problem, this is how I’m describing it, does that look good to you?” and ask them if there’s any wording they would change or things of that sort.

 

Q: That makes perfect sense, yeah. And in general, everything from emails to these documentation processes, or to your sort of post conference travel writeup– how would you say the success of your writing is judged? The quality of your writing is assessed, if it is?

 

A: I would say the success– I need a moment to parse that bit. One of the things that in general, not just as it relates to work but–I tend to be as exacting as possible in my writing, like for example, even when texting, I tend to use full and complete sentences, which, that’s just a personal preference. I have no problem with people who abbreviate and use the letters “u” and “r” for the words “you” and “are”. But I tend to just write very, as often as I can, complete sentences, and things that flow well, and not to bog down in the technical details too much, but to, again, know your audience, and explain things in a way that reads well, that are nonequivocal, that gets the message across in a way that can be understood. You do get emails every now and then where it’s like, it’s a run on sentence, or capitalization, spelling mistakes, and all that sort of thing, which, as long as you’re still understood, then it’s really not big of a deal. But personal preference on my part is to always be as grammatically correct and make as few typos and that sort of thing as possible, because I think there’s a professionalism in that, and I think that’s a thing that tends to garner you more respect and rapport with the person you’re speaking to. I hope that sort of answers the question.

 

Q: Yeah, absolutely it does, absolutely, yeah. What is at stake in your writing? In terms of what’s at stake, what are the repercussions if your writing isn’t effective?

 

A: I don’t think there are any horrendous repercussions, like if I get a technical detail wrong, then chances are it’ll be corrected by someone who actually follows that through and is like, “Oh, no, you’re wrong.” And it’s like “If I’m wrong, I’m wrong. That’s fine.” There is the, you know, someone getting upset and wanting to take things up the chain. There’s the risk of, you know, if I write something undipolmatically, then it’s like, I’m saying someone else’s work is incorrect, or they’re wrong about something, and there’s a chance that you might, you know, feelings will be hurt. So you try to avoid that as best you can and just say things like, you know, “I disagree and here is why.” You present a cogent argument where it’s like, “I’m not getting on you as a person, I’m just saying that what you said about service X isn’t quite correct and here’s the evidence to back me up.” Like one of the things I always strive for is that, whether or not people like me personally, my work will always stand for itself, and my writing will always be consistent with– I maintain a consistency across– make sure I’m telling the same story to everybody.

 

Q: Yeah, absolutely. What would you say is the most difficult thing about writing in your field or in your specific position, even?

 

A: We touched on this a little bit earlier – just the knowing your audience. Like this person wants to know the A-B-C-D-E-F-G-H-I-J of their problem, whereas this person just wants to know, “Did you fix it? Yes? Okay, great.” That’s the trickiest thing to judge I think.

 

Q: Perfect, yeah. Has anyone helped you with your writing formally or informally?

 

A: Not particularly. Informally, I would say it’s more the reaching out to a subject matter expert and saying, “Hey, there’s this problem X, which is with a service that you’re closer to than I am. Here’s how I understand the problem, here’s the verbiage I’m using. Does this look kosher to you?” And taking any revisions or corrections they make and incorporating that. And that also helps me better understand the underlying technology behind a particular product or software or service. So I’m very proactive about seeking that sort of thing out, as opposed to just making assumptions. And oftentimes Google is your friend, but Google will teach you about a service or product generally, but how it’s been specifically implemented, you have to go the people that implemented it, and that’ll often give you a more complete understanding.

 

Q: That’s great. Okay. This is especially interesting for you because your degree isn’t related to the work that you do. But what kinds of writing do you remember being asked to do as a student and do you think that writing prepared you for the writing you do now?

 

A: I do remember my freshman year, we took a class, it was like Writing 101 or something like that. And the gist of the course was, it was based on six papers, and they were all on like a different tack: like one’s strictly a research, one’s a passion paper, one’s a persuasive essay, so on and so forth. And I remember in another class, my sophomore year, was a poli-sci political economy course, that every two weeks or so, we would have to write a 500 word – exactly 500 word – like two pager on either, I want to say it was some topic in class as it related to some ongoing news story, or I honestly have to go see if I still have some of those papers around to remember what the specific subject is. And then as I moved into– the professor who taught that political econ course, I wound up taking several of his classes. Not so much because I really enjoyed political economy, although I did enjoy learning about the history of politics and how that translates into things that are in the news today, but I wound up taking his classes specifically because I liked the way he presented them. And through all of it, it taught me that how you have to vary your writing style based on, not just what the audience is, but what your intent is. What are you trying to accomplish with this? That I think is one of the things that’s helped me a lot is getting that. Because I took a lot more classes than I strictly needed to in undergrad, and getting that sort of wide-ranging exposure to a lot of different subject areas wound up being very helpful in terms of teaching me how to write both about things are very near and dear to me, and things that are not. And writing about trying to accomplish a particular goal, versus writing to explain something that I’d done, without any, like I’m not trying to get person X to do something, I’m trying to say, “I did thing X, this is why you, person X, should care.”

 

Q: Right, right. That’s really interesting. Is there anything that would’ve been useful for you to learn as a student that would’ve helped prepare you?

 

A: I don’t know that you can necessarily make a formal course out of– because most writing that the average person does is informal. And I’m talking about things like email, texts, and I don’t know that you could formalize that into a class of, “How to communicate in the real world.” But honestly I think public speaking, like a Toastmasters sort of thing, maybe a heavier emphasis on that in undergrad would’ve been helpful. Because the best writing to my mind is writing where you can hear the person’s voice and envision them standing in front of you, speaking it to you. Because that’s the way most of us communicate, and I think that translates into our informal writing more so than like a research paper, or an essay does. Because oftentimes research papers and essays are written with a clear understanding that the reader is going to have a lot of background knowledge about the subject matter, whereas the informal like stand and speak, stand and deliver kind of thing, that does away with assumptions and there’s a lot more of a, you know, “I’m going to present this in a way that’s approachable to anybody,” as opposed to an essay, which if you’re reading essays about a specific subject matter, then you already have an interest in that subject matter, so. A course that goes over like more informal writing, which I think the closest thing would be, you know, public speech, might have been a lot more helpful. Like the last speech class I took was in like freshman year of highschool, actually, so I think things that get more towards informal– how to accomplish whatever goal you’re trying to accomplish with informal writing might actually be very useful for kids coming into college.

 

Q: That’s really interesting. Absolutely, yeah. I want to be mindful of your time, I just have a couple of questions left. To what extent do you think writing is valued in your organization?

 

A: I think almost any organization, writing is going to be incredibly valuable because you have things like documentation, you have things like making– if you have a whole department that works on a particular service area, the quality of your writing is going to directly translate into how well each of those people understand the aspect of that particular service area, which the writer is a subject matter expert in, or is talking about it in any particular email. The quality of your writing – how well you make yourself understood – is going to directly translate to the effectiveness of the team that handles that service. And of course, the strength of your documentation after the fact – how accessible and how readable it is to people who might be experienced with this service area generally, but not this aspect of it specifically – I think that’s going to be incredibly valuable and you see often enough the pitfalls of not having documentation. So when you suddenly have a service in front of you, or a network in front of you that you have no idea how it’s set up, it’s not documented anywhere, and suddenly you have to go on a scavenger hunt through every single device in the network and map it out, versus, if you’d had a map, then you could have zoomed in and immediately gotten to the root of whatever problem you’re trying to solve, versus having to, “Okay, we have this problem with this service, with connects to router A, switch B, which switch B is on the other side of this wide area network link, which goes through ISP X’s infrastructure, which–” and if you don’t have that written down somewhere, then suddenly anyone who approaches that problem – and it’s not going to be the same person every time, because again, people go on vacation, people leave the company – if you’re documentation’s not there, then the next guy who has the problem is going to have to do this whole process of rediscovery. Whereas if you wrote it down once, and you kept that updated as time went on, it cuts down on the amount of rediscovering you have to do.

 

Q: Right, right. That’s really interesting. That actually leads really nicely to this last little set of questions, which is this distinction between how you would define successful writing in your specific workplace in your job, as opposed to how you would’ve defined successful writing as a student.

 

A: Successful writing as a student would be, you got an A or better on the paper. Successful writing is you did not fail the class [chuckle]. Successful writing in the workplace is, I don’t have to write the same thing more than once.

 

Q: Interesting. That’s great.

 

A: Like if– a problem that comes up often enough is– I’ll use an example. In our offices we have phones that are, they’re voice over IP phones, so they’re connected to the network, and you’re delivering voice services over the network. In addition to being connected to the network, they also draw power from the cable that you plug in the back, the network cable that you plug in, it’s called power over ethernet. We’ve run into an issue where the switch that they’re plugged into stops granting power over ethernet. And it’s really interesting how it manifests because, we’re not sure what triggers it, but when you plug a phone in, or if a phone’s already plugged in and getting power, it’ll continue to get power. But if you disconnect it, and then try and plug it back in, it won’t be newly granted power over ethernet. And there’s a negotiation that has to take place of, “Hey, I’m a device that needs power,” and the switch has to say, “Okay, you’re a device that needs power. How much power do you need?” and so on and so forth. And that negotiation, that transaction just doesn’t happen, we’re not entirely sure why. And the fix winds up being, is very simple, just go and reboot the switch that it’s connected to. But it’s one of those things where I’ve had to explain that same problem multiple times. And it’s never, I will say that, I’ve never had to explain it multiple times to the same person. So that sort of a kind of limited success, in that it’s an easily understood thing to the point where you don’t have to tell a person more than once, “Did you try rebooting the switch it’s connected to?” But that’s just an example of a problem that comes up often enough that, “Oh, have you tried rebooting the switch?” and more generally in IT it’s like, “Have you tried turning it off and on again?”

 

Q: [chuckle] Would you say that you’re a successful workplace writer?

 

A: I would say the reason that I’ve been able to climb from going as a contractor on the help desk, to full time on the help desk, to moving over to networking as a technician, to a year and a half later, moving into an engineering role– I think a lot of that success has been on the strength of my writing, because I feel I explain things well, in a way that’s approachable to the audience that I’m writing to, that I handle customers fairly well, and can gauge like what level of detail they want, what solution will be satisfactory to them. And a lot of that is just being able to communicate effectively.

 

Q: Yeah, absolutely. Great! Thank you.

 

A: Yep.