Announcer: This episode of TechPod is brought to you by THWACK.com, the SolarWinds community for IT pros. That’s where you’ll find the Monitoring for Managers forum, where we look at monitoring from a manager’s point of view. Join the conversation at thwack.com/m4m.
Chrystal: Thanks for tuning to another episode of SolarWinds TechPod. I’m your host, Head Geek Chrystal Taylor. It’s important to us to share our learnings with the world where we can, so we can all benefit. Today, we’re excited to bring in some internal guests for a special chat about the internal workings of our own IT. Senior directors of IT here at SolarWinds, Brad Klein and Dr. Humberto Amador. Welcome to TechPod. Before we kick things off, I’d love for you to tell us a little bit about yourselves and your careers.
Brad: Brad Klein. I’m the senior director of IT here at SolarWinds. I’ve been with the company for a little over a year now in the role of the IT operations director position. My history, I’ve been in IT overall about 25 years working in a lot of different positions and for a lot of different industries and companies that have given me a nice general round knowledge of the different industries and how IT can play a role.
Humberto: And I’m Dr. Amador, I’ve worked in it for about 15, 16 years at this point. And I’ve had the opportunity to really see IT from a bunch of different lenses, not just from a technical perspective, but also from a business perspective. At SolarWinds, I spend most of my days here running technical program management and focusing in on our bigger, more complex global programs.
Chrystal: Excellent. And for those new to TechPod, I have been in IT for a little over 10 years now, previously to being a Head Geek here, which I do a lot of content creation and that kind of stuff. Hosting this podcast sometimes, whatever’s called upon really. And then previously to that, I worked as a contractor with a bunch of different companies of different sizes and different industries to set up their monitorings. So, I’m very passionate about that.
Chrystal: So, this is neither of your first visit to TechPod, but our conversation today is going to be following up on a conversation that Humberto had with Liz Beavers previously. So, I want to continue that conversation around IT better aligning with the business and building the bridge between IT pros and management. We’re going to dive deeper into the importance of communication and share some internal experience. So, I know this is a passion for you, Humberto based off of your previous visit to TechPod. And I’m happy to continue carrying that torch.
Chrystal: Anyone who has experienced me talking about anything will know that I am also very passionate about the importance of interpersonal skills, or self-skills, or non-technical skills or whatever I’m calling them that day of the week. But I think that they’re really important to improving ourselves and improving the relationship that we in IT have with the rest of the business. So, something you said in the previous episode, I think will carry us forward into the discussion we want to have today, is that we need to think of technology in not just technical terms as in what we are doing, but we need to think about why we were doing it. So, this is a place where we get to align business and the technology goals. You want to talk a little bit more about that?
Humberto: Sure. So, technology itself can be very complicated. And depending on which lens you’re looking at technology from either a data lens, an infrastructure lens, a business application’s lens, IT comes with its challenges. So as people, as technicians, as engineers, we definitely spend a lot of time within the environments and we start speaking and communicating to one another in ways many people would find it foreign, they’d find it technical, they’d find it jargon. They really don’t understand some of the context that’s being driven in those types of conversations.
Humberto: So, this is where we lose the opportunity to align if we don’t treat it cautiously. And what I mean by that is when we look at alignment from a business perspective, most people think from-the-top-down type from approach, meaning the business requirements are coming from the top and the technical team is trying to facilitate those requirements and translate them into actual work that they’re completing. But in many situations, that’s not where the conversation ends.
Humberto: We need to turn that back around and align, not just from the top down, but also from the bottom up and make sure that we understand when we say we’re taking these business requirements and breaking them down into incremental value streams that we can deliver from a technical perspective. What does that mean to you from a timeline perspective? What does that mean to you from an objective perspective? Are you going to get what you want in the end of this? How long is it going to take you to get that deliverable within that scheduled timeframe?
Humberto: And those are the questions that come into play when we start translating the two. And so, this is why I’ve spent a lot of years focusing really on how do you bridge the gap between business and technology in order to create that true level of alignment and visibility that not only helps us accomplish our desires, but also helps us communicate along the way and holds us accountable to our actions, not only just to ourselves, but also to the team itself.
Chrystal: That’s excellent. You hit on something there with the jargon. I think that we as IT professionals live in our world all the time, so the jargon becomes the norm for us, even in normal everyday conversation. So, whether I’m talking to my mom or someone else in IT, I will automatically assume that they know what I’m talking about because normally the person I’m talking to does know what I’m talking about. But when you talk to someone who’s outside of IT, those technical terms, and the jargon, they don’t mean anything to anyone not in IT especially if you’re using… Think about like military personnel. How many acronyms do they have? And it doesn’t mean anything to anyone outside of the military.
Chrystal: I don’t know what that means unless I have previously learned it for some reason. And I think that focus on learning how to communicate without just using technical jargon. I think the technical jargon is important but learning where to use it and how to say what you need to say and explain what you need to explain without using just technical jargon will really help you on your way to improving your communication. And its communication, I think is key. I think that’s the big thing.
Chrystal: Communication is key. Not only between business leaders and you’re IT managers, but vice versa. You need to be able to communicate those things. They don’t understand the importance of your network. They understand it on a vague level. We need this to function, but they don’t understand the importance of the day-to-day operations that you’re doing. They don’t understand why you do certain things at certain times, or why they take certain amount of time or why you do… They don’t need to know any of that either. So, learning how to communicate, I think is really important.
Chrystal: So, when you’re talking about it, oftentimes leaders think of IT as a cost center. Like that’s the history, IT is considered a cost center. I don’t necessarily think that it should be considered just a cost center. There are ways that you can save money by doing things correctly in IT in the rest of the business. And I think that having that communication back with them in a way that makes sense to them. We need to translate to dollars and cents. How is this going to save money for them? That’s one way of translate of communicating with them in a way that they understand.
Chrystal: They understand money. They don’t necessarily understand why you’re going with this specific technology that you’re using. It may not make sense to them. So how do we communicate up? How do we communicate the other way? They’re very good at communicating down. They don’t use the technical jargon, they just assume you’re going to understand, same what we do. But we can’t control what they’re going to do. What we can do is control what we’re going to do. So how do we communicate up to get buy-in on what is considered a cost center?
Humberto: So, following that term that you used earlier with regards to correctiveness. I think that’s actually a term that I’d challenge in an IT environment mostly from the aspect of correctiveness is really cultural. It’s really built by the team that’s come to together, decided the processes that they’re going to follow and then ran through those processes as a team to see what the output was on the other side. So, when we’re talking about how do we bridge that gap between the business and technology, a lot of times its really understanding what framework are we going to even use or what’s the basis of our communication foundation.
Humberto: And there’s researchers in the past that talked about communication being a common language that’s adopted across the team, or that’s understood by the team. And that’s very true. Lots of times even inside of highly rigorous environments, scrum environments, agile environments, where teams are forced to communicate following one specific structure. You find that within the team communication is high. But as soon as you start leaving the team where you start interacting cross-functionally, especially in a globalized setting, you start diminishing that communication between the two groups highly.
Humberto: So, this is where program management really has stepped in over the last couple of years and gotten some maturity from an external factor, from a market perspective. Because lots of times program managers are coming into a business setting and trying to understand what are the business requirements, ask some of the questions regarding that business requirements, helping to understand the level of risk associated with those requests and then working with the technical team to really digest and translate those requirements to something that the team can actually pull together.
Humberto: And oftentimes we see inside the engineering teams, this is what they usually call some form of response document, some technology response document or engineering response document, which usually takes the requirements that the business is imposing and puts a technical spin on them to try to really understand what value they’re going to be providing, incrementally, over what period of time, and how much is they going to cost to your point earlier. Because cost usually is that big factor in IT as to how I’m going to do it? Why I’m going to do it? And how long it’s going to take me.
Humberto: A lot of times in project management, we ask those questions upfront. What’s your budget for this program or for this project that you’re expected to run depending on the budget. We can talk through different trade-offs that can be given. “Okay, well, do you want this done faster?” And meaning we’re going to spend a little bit more money up front, but then we’ll be able to spread the cost over the next couple of increments at a less diminished rate. Or do you want us to really just manage the cost from start to finish?
Humberto: So, depending on these strategies that are imposed by the business, program managers can in essence translate those and figure out ways to execute on those strategies in a way that’s effective both to the technical team and to the business. Because in the end of the day, the technologist doesn’t want to be distracted by the business. They really just want a set of deliverables and requirements that they can work off of and then turn around and deliver those requirements to the business in an effective manner.
Humberto: And the business doesn’t necessarily want to get into the technology and or the jargon either in its place either. It really wants a funnel an input point where they can submit the request and then turn around and check on it every once in a while, and see what’s going on. So again, increasing that communication, that output of what’s going on within the technical team, within the scrum, within the sprints. Trying to put some data behind it, rationalize the data and correlate it, and triangulate it in a way that it tells a story.
Humberto: Whether it’s positive or negative, has been the best way that I’ve been able to connect the top to the bottom and more so the bottom to the top. Depending on that story, there’s different actions that come into play. If the story is positive and the executive team is pleased with the output that the team has provided so far, then usually it’s more of a process improvement. Is this meeting your need? Is it meeting your objective? And we’ll take the feedback in retrospective.
Humberto: In situations that are a little bit more negative where we need a little bit of influence, either we’re missing requirements, we’re missing an understanding. We don’t have a clear objective or we’re not really fully understanding or embracing the complexity that’s involved in something. That’s where we really need to have those straight focused and forward conversations with the team to talk a little bit more about reality. What can we do today that’s gonna actually impact the plan and give us something positive as an output? Not what we can do tomorrow, not what we can do in the future, not what we could have done yesterday. Those things become very irrelevant when you’re trying to work through those conversations at the executive level.
Chrystal: Yeah. So, you hit on something a little earlier on in that, which was communicating cross-functionally. But I heard in my brain, I’m thinking about how prevalent IT has become. It’s no longer just, “This is where you get your workstations and then you do that.” Everything is getting technology these days, everything. Everything is getting digitized and so IT is more important than ever. And it’s going to continue to gain importance and relevance within all functions of a business, all functions. So, what I’m hearing there is also cross-departmentally. And Brad, maybe you have something you’d like to say to this, how do we communicate cross-departmentally? And how important is that communication?
Brad: Yeah, it’s always one of the major challenges we face from being in the operational side of IT for all my career is translating what we’re doing on a daily basis back to the business. The business doesn’t really understand tech debt. They don’t understand operational overhead of from a standard, if we’re talking to an exec, they generally just don’t understand that. And so being able to go say to them what that actually means, what tech debt means, what means if it’s going to fail what it means if we’re not following the extra security steps that are requires to really be extremely secure and on the cutting edge of security and those other investments there.
Brad: Getting that across to leadership can be a very difficult thing, especially I think for most IT pros. If I came up as an engineering track, which is how I came up, you don’t necessarily have a marketing jargon or an executive jargon in your back pocket when you’re interfacing with the e-staff. And so, learning how to translate that as a standard IT professional or IT engineer that’s been behind keyboard, behind the closed doors oftentimes, that’s a big leap in a lot of people’s careers. And sometimes they may be a great leader and they may be a great technical leader but being also at a great executive facing leader is a very tough thing to translate. And that’s where I think IT has problems oftentimes.
Brad: Is that translation as Humberto was talking about from the executive side to the IT jargon and to what it really means because the company wants to make more money. That’s a company’s job, that’s the whole point of its purpose. That’s why it’s there is to… It may have a bunch of other goals as far as enhancing the community and things like that, but its general purpose is that we’re there to make more money than we’re spending. And also, to be more efficient as we’re doing that. And when you look at IT it’s very expensive. But you mentioned earlier that it’s everywhere and it’s in everything and it’s getting more expensive because you have to have more and more layers of IT.
Brad: It’s in everything from our pens nowadays to the lights in the building are connected IT. And all that incurs operational overheads, security risk, you name it and tech debt to go with it. And so, without ramping up a massive amount of people to do that is where the sufficiency starts to come into play. And then also balancing your priorities, which I think is what Humberto was sitting on there is being able to take what the company’s objectives are, where we’re trying to go as a business, translating that to IT, and then also translating back up from IT, what we are facing back to the executives.
Brad: And I think we’ve made a lot of strides in that over the last six months, nine months, that we’ve had actually had a dedicated project management team with Humberto. The ability for us to go, “That has to go to a backlog.” We currently have 85 projects and 100 people. So how do you take 100 people and run 85 projects? You can’t. So, we have to prioritize that down to 10, 12, focus on that, increase our velocity, and get the right information back to the executives so they understand why we can’t turn certain things on a dime. We’ve made some great strides on doing that, and obviously, executives aren’t unreasonable people. They didn’t get to where they were by not being collaborative or not being great leaders. It’s a translation issue is usually where you have a problem. Communication and translation. Not that you’re dealing with somebody that’s unreasonable.
Chrystal: Right. Yeah. And oftentimes it’s not a matter of intelligence, which I think can be a mistake that some people make. When you live in that jargon, whatever it happens to be if you’re in marketing and its marketing jargon, you live there every day. You take for granted that people understand that those terms you take for granted that they know what they’re talking about when they use those terms. And I think you hit on something there which was that it’s a leap up to move to the part where you’re talking to the executive level in IT.
Chrystal: As an IT pro, when you move up to a position of being able to speak to executive level, it is a move up in the world as far as responsibilities go. And I think that can be intimidating, especially for someone who spent their whole of their time not interacting with as many people outside their team or something like that. Once they move up, especially in the early days of management, when they’re responsible for translating that stuff to the executive leadership. I think maybe that can be challenging in a whole nother level for them, that people don’t consider as being challenging because it’s not technical.
Chrystal: But I think that is a mistake. It’s very difficult to teach interpersonal skills versus technical skills, because there’s not a lot of classes out there that teach you how to talk to executive. You can’t just go to school for it. In a way you can, but it’s a bit of a different challenge. You have to approach it differently. So, do you guys have any advice?
Humberto: Well, I think you hit one of the main topics there. As young technicians, I remember early on in my career, I was taught by my leadership like, “Your job is to say, yes. No matter what your job is to say yes in IT, we can figure out how to do it. Technology is very flexible. Say, yes. That’s what you say to executives.” And then to Brad’s point, as you grow up within IT, you realize that you got to learn how to say no. And there’s an art to it. Not just science, I think there’s an art to it.
Humberto: You want to keep the business productive; you want to keep the business on task and focus, but there is a level of diminishing returns just like in everything where I can either put more money in it to get more things out of it faster, or I can slow things down in order in essence to speed things up. And so, we can pull these different levers within IT to try to build that strategy. But as we start growing in our careers, really what’s growing is our rhetoric. How can we say no? How can we say yes? And when should we say yes? And when should we say no? And how should we say no? So that we can manage the priorities of the business.
Humberto: And this is where exercises like OKRs, KPIs, all these different exercises are really valuable to us on the delivery end. Because a lot of times, you have marketing, you have sales, you have finance, you have these different departments within the business that all have conflicting priorities. And they’re all number one priority across their division, all hitting one team. Those requests are all coming in one direction and that team has the burden to figure out, “What am I going to do today? What am I doing tomorrow? How am I going to organize this work? And where am I going to deliver across the most valuable work streams that the business needs to be successful tomorrow?”
Humberto: That’s a lot of decision-making on one team, if I can say. So, I try most of the times to create those collaborative settings for us to really through data. This is where I inject more of the science, trying to show the executives, trying to talk to the senior leaders across the organization and around, “Okay, this is based on the OKRs, based on the highest priorities of the organization, here’s where our resources are currently applied. Both people, money, time, etc. And here’s where we have a little bit of capacity of reserves.”
Humberto: If the reserves are not enough to meet the new business requests, then we need to in essence have a conversation around what do I stop or slow down on the activity side in order to accommodate the new request coming in? Or how does my budget expand or increase in order for us to be able to facilitate all of this work at the same time? So, this is going back to how we grow through within IT, to our careers. It really goes to that point that you’re making on learning how to speak to the executives in a data-driven conversation, and to Brad’s point around the executive team not being unreasonable. They just really need to understand the situation that we’re driving, or the problem that we’re facing in order to help us unblock or remove the impediment and unblock the blocker in essence.
Brad: Yeah, that was a good one, Humberto. One of the things that you hit right there that just triggered something for me was the personal aspect of it. When I look from a leadership standpoint and I think of my own journey, and I try to tell this to my managers and those that are coming up and looking at leadership positions. It’s not usually in the DNA of a lot of engineers to be a very big people person. I wouldn’t say that you’re generally an extrovert and drawn to IT. It may be a few of us, but it’s few and far between. Majority of us are extreme introverts. I, for 10 years of my career, I was locked in a data center, and I loved it.
Brad: I could go a week without even interfacing with anybody in my work life which was awesome. But as I changed and they moved me into leadership, I had to change my entire way I looked at communication and it sunk in after a little bit, and I had some good mentorship. But to Humberto’s point on saying, yes, that was the same thing I was taught. It was you’re given a task and you went and did it, and you’re given another task and you went and did it. Especially as you’re coming up as an engineer. It wasn’t until later on where I had a larger team and more responsibilities that I realized, “We just can’t say yes to everybody.”
Brad: And that was where it became very difficult or very important, and also a difficult part of the process to get the priorities right as Humberto was saying. And also, being able to communicate well. And one of the things I had a mentor tell me, an executive at the time was that I need to be a little more of a hard case. To skip the hard language, but just a little bit rougher around the edges with people sometimes because I was a little too nice whenever people were asking for things that realistically we just didn’t need to add to our plate. And then also when it came to like security type matters.
Brad: You’re used to somebody asking for a thing and you know we need to be able to do X, Y, and Z, but the business is going well, we’ve got to do this. And so, we’re going to do this. And you end up getting pushed to the side. But where you’ve got to stand up and especially nowadays with the current climate of the cyber-attacks and threat actors being extremely sophisticated, us standing up at a business level and going, “We as a business should not do that.” And this is a major risk falls onto every IT professional as part of their job to raise their hand every time they see something that may be a bad practice or even close to a bad practice.
Chrystal: Yeah. You both hit on something there that really speaks to me personally, which is that at a certain point, you have to learn how to say no in a way that doesn’t get you fired. Neither of you said that part, but I feel like that’s implied. You have to learn how to say no, that is a mark of being put into any management position. You have to be able to say, “No, we can’t do this and here’s why.” You have to have the here’s why. You can’t just say no. It’s very important to understand. You have to be able to tell them why this is too much. Or we can maybe look at this again in six months or whatever it happens to be.
Chrystal: You can do it in a nice way. But if you’re saying yes to everyone, you’re overwhelming your team. You’re overwhelming your… You’re creating a bottleneck and that bottleneck is you. And you don’t want to be the bottleneck. No one wants to be the bottleneck. So, it’s really important to figure out how to say no. And it’s challenging, there’s going to be some give and take. There’s going to be some learning there. And the beautiful thing is most people are quite understanding of humans’ abilities to make errors.
Brad: Yeah. I was just going to say just a quick thought from what you were saying there is, I’ve never seen… I know there’s bad leaders out there and we’ve all dealt with our share of a bit of bad leaders, but there’s always a counter influence. There’s always a stabilizing force. And that’s why you have a staff of leadership. You don’t have a single guy that’s walking around axing everybody in the company. I’ve always seen from an HR perspective or else that’s not going to work for very long. One thing I’ve I think we’ve been really fortunate with is I’ve always had the opposite.
Brad: Leadership that listens and is very thoughtful and all the teams I’ve worked with, they want to hear from every layer, every tier. And I’ve seen that through multiple companies now, I’ve been in four or five different big organizations throughout my career and across all of those, I’ve run into that. And so, it’s funny when I am talking to a junior engineer, even one in a senior lead position and they’re very intimidated to speak up and stand up. But what’s amazing is my leaders above me are asking, “Why doesn’t so and so say something, why did it have to come through you?”
Brad: So oftentimes people I think would be surprised to know that, and I try to tell everybody like, “You don’t always have to go through the chain of command. It doesn’t always have to trickle up. If you see something, hit the right person that you know. That doesn’t mean that we should be pinging everybody all day long, but when you have relevant information, definitely stick your hand up.” And I always encourage my team to make sure they’re putting their hand up every chance they get.
Humberto: Well, this goes back to the cross-functional side of the house too. When we start talking about teams that are in different locations and different settings and different environments in general. Effective leadership comes into play here. And how do you become an effective leader? Well, you need communication in there. There has to be an evolutionary type of mindset in the different life engagements or life scenarios that you’re presented as a leader throughout the organization. And you’ll notice that as you’re growing in your career, the challenges that facing earlier on in your career, different than the challenges you faced later on in your career.
Humberto: And how you manage those communication channels and set expectation across teams is important. Poor communication in general has been identified as what are the earliest signs of IT project failure. And it has been for many, many years because once the team stops communicating, it’s really hard for the team to come back together, unless somebody is really forcing that communication. And in that effective leader perspective, especially when you’re working with cross-functional teams, you really need to have the experience and the exposure of the different environments in order to call out or identify areas where you need to intervene a little bit closer.
Humberto: To Brad’s point, in our DNA, culturally, depending on where you’re from and what part of the world you come from, you may see as challenging authority as something that you don’t want to do on a day-to-day basis. It’s not in your DNA and it’s just so culturally not acceptable. So, for you, the chances of you actually doing that in your day job, maybe a little bit lesser than, let’s say a society that is routinely challenging authority in that aspect of it. So, there are a lot of dimensions that come into being an effective leader, communication and understanding how to drive a message forward.
Humberto: But even in that show, as you’re aligning your career to your next steps, you got to evaluate your personal as well. Are you that type of person to Brad’s point that can leave the data center, take off the headphones, take off the hoodie and go in front of an executive team and try to articulate values and needs and circumstances accordingly. Or do you really prefer to be in the data center, working on machines, and really that’s what drives your passion. So, I think that there’s a little bit of soul-searching that comes into play here as well.
Chrystal: Yeah. This really makes me think that it’s increasingly visible that it’s important for leaders, whether they be mean and just general managers or executive leadership to admit when they make their own mistakes, we’re human, none of us stop making mistakes. The important thing is to acknowledge and move forward from those, learn something from it. And I think that really can open the door for some of those junior and even senior level people to think, “Well, I can speak up. They were able to admit their own flaws.”
Chrystal: And I think that’s really important. No, it’s not often that you have a project that goes off flawlessly throughout the whole thing. I think that’s maybe a dream we all have, but not necessarily a thing that actually happens in real life. And so, when you think about those things, talking about those errors in a constructive way can really improve interpersonal relations. And the only other thing I wanted to bring up is that with the workforce going more and more distributed, working remotely and all that.
Chrystal: I think it’s important to point out that that doesn’t change the need for communication. It actually enhances our need for communication. You just have to learn to do it in a different way. I know internally we use teams, but we have other methods of communication as well. And it doesn’t always have to be a meeting. It can still just be a ping on teams or a channel or whatever group chat. All of those things are super important to maintaining that communication.
Brad: Just piggybacking on your thought there and what Humberto said, we definitely have… We’re talking a lot about interfacing to execs and leadership and the business alignment there. One of the things I had seen you triggered a thought there was, and it’s not just the vertical communication that’s oftentimes problematic, when I’ve come into teams that I would consider bad IT, or just not running really well. Oftentimes a lot of the communication problems are laterally between the teams.
Brad: Particularly, when we’re having operational issues. It’s not that you don’t have good engineers. It’s not maybe that budgeting problem or an executive priority problem. Oftentimes I’ve seen problems between the teams where they’re not communicating well for whatever reason may be there. It can take as small as one person in a group that can cause walls to be built and silos to be built and communication across collaborative communication across the engineering staff to start to stall out.
Brad: And once that happens, you lose a lot of the synergy between those groups, and I hate using that word. But a lot of the synergy between the groups it’s really necessary for IT to just really hum internally and work out those problems without it having to go all the way up and back down. And everything shouldn’t be a conflict resolution to get a decision made. Two engineers across teams should be able to ping each other and get something done. But when that falls apart, it’s when you start to really see some problems. So, we just wanted to point that out. I know executives are obviously important and that’s what we’re here to provide back to the business. But for a team to hum, you’ve got to have that clicking in between all the different leaders at a lower level.
Chrystal: Yeah. I completely agree. I think that in the past the blame game and the purposeful siloing of teams has hindered efficiency in IT and what we’re working towards I think more now is to breaking down those barriers between teams. We have to be more collaborative. Applications are moving towards more collaborative. We cannot as escape it. There’s no thing where you can just be… There is still out there, but we’re moving away from it. Where you can just be doing one single job. More often, you’re going to have to be communicating with other people and other teams all the time. Because that is the way that the technology is going. And if we don’t follow the technology, well, you’re going to get left out of IT. That’s how it goes.
Humberto: Yeah, I would add to that. In my opinion, communication influences everything. And when we look at these program management software’s and these approaches, these methodologies around program management, if you really peel the layer back and look at it from a scientific approach. You start realizing that it’s really two things. Imperial control theory, meaning you’re learning through observation and communication. Establishing formats and frameworks for people to come together and communicate.
Humberto: You can see that through task management, you can see that through program management, sprint management, all that stuff, really just all it allows us for us to create solid and fluid forms of communication for us to hold each other accountable on what we said on this day, on this time, the commitment that we made to the business, to the team, to the project. Whatever it was, it’s essentially a form of communication that we’re documenting, holding for true value, putting some data around it, and saying, “Did we deliver on that commitment ultimately or not?”
Humberto: So, this is where I really lean on the aspect of communication influences everything. It not only influences the relationships and the engagements that we have on our day-to-day, but it also influences sometimes the metadata. The world around us, both from a body language perspective, as well as what we say, what we don’t say, our facial expressions. There’s lots of different ways that communication really does play a part in everything that we do and every single day.
Humberto: And as far as forms of communication or tools for communication, I think this is where technology has really made leaps and bounds over the last 10 years or so. I remember, I don’t know, 15 years ago, at some point ICQ was a thing. Everybody was jumping in on chatting, channels to be able to just communicate with somebody across a different continent. And now it’s a normal thing for companies to be every single day talking to somebody across oceans, across geographies, working together to problem solve, to decision make, to progress a topic, a research, whatever it is. People come together globally through these tools that are available to us today.
Brad: I think ICQ may have been further than 15 years ago.
Humberto: I’m not trying to age myself 100% here, Brad.
Brad: Just a little bit.
Humberto: Just a little bit.
Chrystal: You’ve brought up documentation a couple of times now, and I really want to talk about this because I know that internally we have some supreme documentation going on and it’s not just technical documentation, because I think a lot of times people can focus on documentation as it’s just technical process documentation. It’s just the documentation that helps our apps run. What have you. I don’t think that’s the only documentation that we need. Do you guys have any flavor you’d like to add to that?
Humberto: Documentation’s everywhere, in everything. We call it artifacts in my world because it really is that. It could be a data model. It could be an illustration. It could be a document like a research article that we’re reviewing. I think in our world especially when we’re looking for data-driven conversations or fact-driven conversations, a lot of times we try to find existing evidence or existing data to help us support it. Or we try to bring data points together to tell that story, going back to triangulating and correlating data to tell that rational story that you’re trying to put forward. But documentation’s an essence.
Humberto: I think that throughout my career in different various of experiences and different companies that I’ve worked for, that’s usually one of the first questions you ask. It’s like, “Hey, I’m coming into this technical environment, where is your technical documentation? Where’s the IT Bible?” I want to pull it up and just get to know what IP scheme are you running? What subnets are we running? What protocols are we running within the environment, etc. Just to get a sense of the architecture that was used in this environment or the way that the environment was brought together and how we can maintain it and support it going forward.
Humberto: Same thing on the business side. As we’re trying to document these requirements and understand the deliverables for the company or the objectives for the company, lots of times the executive team will build an artifact or a document at the top that says, “Hey, I want you all to read this, digest it, align to it, and make sure that you’re contributing to this on a weekly or monthly basis in order for us to maintain that cohesion.” So, I’d be bold enough to say that if communication influences everything, then documentation is the how.
Humberto: Document documentation is how we can hold each other accountable, how we maintain connectivity, how we maintain positive traction, how we call out negative traction, how we action around the certain scenarios that we have to engage. So really, they’re each other’s sidekick in my opinion, documentation, and communication.
Brad: Yeah. The one thing with documentation, I put that down there with tech debt. I don’t think I’ve ever walked into a place that had 100% great document practices for every one of their configs and change management and everything else. It’s always difficult because if we rewind to the beginning of the conversation, that overhead on an IT team, an operational team, not a lot of companies run the different silos of like a design build run. They’re generally you not quite that size. And so, you generally have a team that’s balancing everything.
Brad: They’re doing the architecture design; they’re building it and then they’re trying to run it. And the problem there is they’re always so burdened with a high backlog that stopping to write a document for half a day or for a couple of hours just doesn’t flow well with the way that they’re working. We internally you changed the way we do some of our process there. So, a project isn’t done until that documentation is done. And until the old documents are removed or are put into an artifact, moved into an artifact type position.
Brad: And so that way we’re always keeping those up to date. The other part of it is making what we’re actually running off of from a daily perspective from how we’re triaging an incident or triaging an outage is that people are going to that documentation. It’s not just inherited knowledge from somebody that either built the thing or still working it. And that’s where sometimes a bit of those separation of the duties can be good is tiering the workload.
Brad: So, response is done by maybe one tier of a team and another tier of a team and in certain incidences actually handling the design, even if you’re not fully broken in or large enough to do a full silo run model. Because that forces the documentation to be good, or somebody else can’t help because they can’t go to the documentation to get the thing done. And so, it’s very tough, but if we’re talking about operational documentation, it’s an ongoing plague. I think it’s tough for IT teams to really get that thing 100% right. But forcing those mechanisms can help.
Humberto: I love documentation as well, just from the aspect of, if you’re trying to bleed communication or you have language barriers and such that are… Or even time zone challenges that are in place, you can put a document or an artifact out there and most people can either get Google translator to translate it from English to another language or vice versa, or they can understand pictures. And they understand the illustration that you’re trying to make. If they’re part of the same team in the same company, they speak very similar language as far as what the internal culture is in the organization. So, lots of times a document can actually be the bridge between cross-functional teams.
Chrystal: I love that. Making your documentation be the accessibility point. If we’re having a conversation like this and we’re all speaking English and someone else is with us that doesn’t perhaps speak perfect English. Because there are people that don’t, let’s be real. We’re Americans. We like to think everyone speaks English, but that’s not true. So, we work in a global corporation and everyone that’s listening isn’t going to work for global teams, but English may not be the first or even a language that another person speaks or reads.
Chrystal: So, having documentation available where anyone could use that to improve what they’re doing is fantastic. I also like the thought of having that documentation available for other teams. There is someone else that may not… They may be trying to troubleshoot something without getting IT involved because IT is already overloaded or they’re not going to have time to get to it right now. If you have an FAQ, if you have documentation on these things available to them where they can do a little bit of work themselves, they may solve their own problem without ever having to come to IT.
Chrystal: Because how often do people who don’t know anything about IT, come to IT as something like, “I need this right now.” Because to them, it’s priority like you said earlier. To them, it’s priority number one. But to IT, it can’t be priority number one. So, I think that those are really important. And to that point, I know internally our team is working on a new project, the SWOC as we like to call it, which I’d like to hear more about. But one of the things that they’ve been working on diligently with this project while they’ve been standing it up is documentation because it’s been prioritized by us.
Chrystal: And the documentation work that they’re doing with that is incredible. It’s incredibly detailed. It includes runbooks and includes all kinds of other things that go with it so that anybody can know what’s going on in this project. Anybody that has access to this documentation can just jump right in. If a new person joins the team, they have it all right there at their fingertips. And it’s kept updated which is incredible.
Brad: So yeah, it’s been one of my passion projects for a few years now from when I was first with SolarWinds and then now that I’ve been back for the last year is to build out a SolarWinds observability center. And the goal there was twofold. There was an internal goal for IT-focused operations. When we talk about the run build type model, is taking some of that run function, what maybe some of the chattier Tier 1, Tier 2 type ticketing and moving that out to an operation center that was focused on that.
Brad: And that’s where, what I was talking about a forcing mechanism for our documentation, that’s where that came in place. Is that where would have that forcing me mechanism. And to your point, yes, the team has built amazing documentation around that. And the impetus there is if you look at it as an engineer, I’m a network engineer. I get this alert maybe randomly every couple of weeks or months, depending on how things are running. I now have to go and do a thing. If I’m on call, well, potentially that alert’s going to wake me up while I’m on call.
Brad: But if I write the documentation for it, where somebody else can read it and actually respond to it, all of a sudden that gets taken care of by our SWOC. It gets taken care of by that center. And so, documentation, yes, super critical there. But even more than that, when we stood this team up, the goal was that we could tell the story. What was the story of? Because the manager running it, he came in new to the company, he was a little bit familiar to run Orion in the past in NPM, but he hadn’t run Orion in a few years.
Brad: And then the team that we hired is also new, has a little bit of familiarity with our products, but isn’t necessarily working in Orion every day. And so, they came in as a team being viewed as, “What does it take for us internally to stand up zero to 90 days, a full operational knock or sock?” And so how do we turn that and turn the SWOC into to a thing that we can tell and share with our customers of how did we do it and how did we get there? Because I’ve tried to build out a NOC before, and it’s not the easiest thing in the world. It takes a lot of manpower. It takes a whole change of the way your team’s doing. It takes a lot of time and money.
Brad: And not every company’s willing to invest in it. So how do you make a return and how do you turn that back into something as quickly as possible? And all that speak to our two earlier points was around documentation, of documenting everything we did and communication, because we had to sell this to the business. How is this good for the business? How is this good for IT? And how do we make this something that we can sell? And that was probably one of the initially harder points. How do we make this something that’s a sales thing and it’s more than just IT is? How is this a business improvement?
Chrystal: Yeah. I love it. I love everything that I hear about that project. And I’m fully supportive of the project itself and everything that’s going on with it. Every time that Howard talks about it, he’s so invested. And I think it’s wonderful to see because if you’re that invested and you’re working it on the day-to-day, it’s easy to translate that enthusiasm to anyone that you’re talking to in addition to having all of that documentation and everything to back it up to the business leaders.
Chrystal: And to your point of using monitoring and observability, I think that’s a way to get executive leaders to not think of IT as only a cost center, because I think monitoring and observability can be used to do resource optimization and do cost optimization in a way. If you’re constantly looking at the data, you’re looking at the data of what your business is doing, all of the IT infrastructure in your business, you can prevent outages in this way. You can prevent things that would cost you a lot of more money if it was a problem.
Chrystal: So, I think that if we use that into our language in discussing things with business leaders in IT, we would find that there’s a lot of ways that we can help save money. The challenge is in communicating that to those leaders in a way that makes sense. And I think that we should think of it in a way like risk management. Risk management are people that are employed to tell you how much money this thing could cost if it went wrong. It’s the same way with monitoring and observability.
Chrystal: If you’re looking at it and you can see that, let’s take a SQL server, this SQL server is going to run into a problem in 30 days. You can provision those resources ahead of time so that whatever is reliant on those databases, isn’t going to crash and could potentially cost you more money. If that database was linked up to a customer facing portal somewhere then, in that crash, if that was your storefront, well, your storefront is now down for X amount of time until it’s brought back up.
Chrystal: So being able to do a more preventative measures in that way can be viewed as resource and cost optimization rather than just cost. So, with this observability center that you’re working on, taking our typical monitoring, and improving it to observability. How is that taking us into the future?
Brad: And I said, it was twofold earlier, and that first one being internal facing IT operations. And you know that there as far as seeing a thing before it happens, so. And I’ve walked into shops before that we didn’t have any monitoring. We didn’t have anything going and being blind is scary. You walk in Monday morning and the manufacturing systems are down and people can’t produce and can’t make money and everything’s broken loose and it’s a bad day.
Brad: So, whenever that stuff sneaks up on you, especially, to your illustration there of SQL Server. Yeah. If you don’t have monitoring on there and you’ve got 300, 400, 500 servers. Are you really going to be checking every time something’s running low on memory or disk space or running optimally? Definitely not. So that’s a key part of it, being able to serve internally IT and making IT more efficient was a big part of it for us.
Brad: But the other part, and we’re lucky to be part of SolarWinds. And part of a monitoring company was our ability to tell this story externally and actually make it a bit of a sales tool. This is how IT at SolarWinds uses more products and how IT internally uses it and being able to tell that story. So, the monitoring part there, and being able to convey that up, Humberto, I think will love this is it has to be data driven.
Brad: So, we have to show utilization, we have to be able to show age of systems. And when something’s going to age out, when you’re talking about hybrid and hybrid cloud, you have to be able to… Before you just jump into the cloud, what is your egres model going to look like? How much is your data charge going to be? I’ve heard of a lot of companies moving back down from the cloud because they go up just being told, “This is the holy grail in the future of IT.”
Brad: And they get there and then all of a sudden, they get 100K a month in egres charges because they didn’t expect it. And so not always jumping to the next thing, you definitely can’t jump blind, but oftentimes people do. And I walked into one of those shops where they had moved fully into the cloud. We ended up going into a hybrid model and then shifting our cloud in between one vendor and another to get a little bit better rates. But if you’re not doing a data-driven and you’re making decisions for the business, then I think you’re headed into a world of hurt.
Humberto: Yeah. You got to look at it from the data perspective. I agree with Brad on that highly. And that’s really the value that I’ve gotten out of monitoring systems in the past. I was a SolarWinds customer about 15 years ago, myself in the hospital side of it managing hospital ITs and it provided visibility in the environment that I didn’t have before. It helped me identify of troubles were and where I needed to put my focus. A lot of times from a reactive perspective, that’s how you’re using it. That’s the value that it’s driving. It’s helping you identify the problem and solve it as quick as you can and reducing that meantime objective type deal.
Humberto: But it also from a strategic sense, right? And that’s really where the big value at least from my perspective came from, being able to look at the different data points and being able to capture those and tell a story with those data points, “Hey, you know what CIO, I need to go out and buy all this extra memory and all this extra hard drive space because we’re going to run out of resources here soon. We’re not going to have enough compute. We’re not going to have enough horsepower in systems to be able to drive the business load.” Those are all things that are data-driven based on the outputs of these systems. So, this is where I highly agree with Brad’s side of it, is that we shouldn’t just use it as a reactive tool. It’s actually a proactive tool as well if you use it right.
Chrystal: Yes, absolutely. Well, we’ve reached the end of our time here. So, any final thoughts that you want to share? We’ll start with you, Brad.
Brad: IT is an interest in career. I think we have a lot of… I’ve been able to work with a lot of amazing people over the years, whether from the engineering side, but also interfacing with the business and watching the way IT can shape a company is really interesting because I’ve been in a few companies where IT was just a utility. We were just keeping the power going and the lights on. And those were companies that I saw not changing and not really turning with the times.
Brad: And then I’ve been in companies where IT was at its core and up at the executive C-Suite level, they were listening and listening, it’s not completely dependent on them as Humberto talked about earlier. It’s dependent on us telling the story right and being able to convey it right. Those companies that did that in the leadership and IT was able to do that.
Brad: I’ve seen even small shops be extremely cutting edge with how the business was running the efficiency and I’ve seen IT be able to contribute millions back in EBIDA due to the way that they were focused in the way they were assisting the business. So yeah, just to go as IT pro to go, “I’m just here to do this one thing and keep the computers running or keep this technology running.” That’s just a mindset that I think we have to look for more and to be more and be part of the business in a bigger way.
Chrystal: I agree, Humberto?
Humberto: So, from my perspective, just wrapping up a couple of different topics that we’ve covered today on this episode, cross-functional communication, establishing that business-level alignment, and really working through monitoring as a service for the organization are really the key value areas that I would highly recommend any IT professional really dive into. If you’re trying to tell a story, lots of times you don’t want to be the person to tell the bad story, usually you just blame the data and just lean on the data going forward. And in essence, try to have the data tell the story that you’re trying to tell within your environment.
Humberto: This is where monitoring not only becomes a reactive tool to help you troubleshoot through your day-to-day, but also a proactive tool to help you plan for tomorrow in a more effective way, especially when you’re trying to prepare for a conversation with the CIO or different technical executives and you’re probably going to ask for money. Lots of times, most CIOs I’ve worked, will typically scrutinize their dollars pretty well unless you can give them a really good, detailed plan as to how you’re going to use it and the value that’s going to be introduced into the environment because of such.
Chrystal: I agree completely. And if you are a listener intimidated by approaching this communication with business leaders, or even just your management. Data-driven is where you already live in IT. And you can use that, lean on the data to help you grow in that aspect. It’s going to be a challenge, but if you don’t start you won’t ever improve. So, I encourage you to think about this as you move forward. So, thank you so much to Brad and Humberto. So, this has been such a great discussion I think, it’s been quite illuminating as far as talking about the importance of communication and documentation and all of that in improving our alignment with the business.
Chrystal: So hopefully we’ve given our listeners something to mull over to improve their own communication and alignment with the business and improve their own day-to-day work lives in the process. So, it’s past time IT was thought of being just a cost center. I think that with the way that technology is trending, we have to reach for more, as Brad said. We have to go for more. We can’t just be a cost center. We have to go for more. We got to align with the business, we’ve got to improve things, improve efficiencies, optimize, and make sure that we’re not just considered a cost center.
Chrystal: If you enjoyed this episode of TechPod, please rate, follow, subscribe wherever you get your podcast. And until next time I’m Chrystal Taylor, and thanks for listening.
