Dan Jones - Moving On-Prem Workloads to the Cloud, & Continuous Improvement

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Dan, the SVP of Product at Skytap, and we discuss how the structure of engineering teams change and mature over time, the unique intellectual property Skytap made to help solve problems of moving on-prem workloads to the cloud, and how to get continuous feedback from your employees about how to improve the company. All of this right here, right now on the Modern CTO Podcast. This is the Modern CTO Podcast.

(Joel Beasley at 00:00:41) Dude, I was really excited though when my prep team said that you were one of the program leaders at Xbox. I was like, oh, what did you do there?

(Dan at 00:00:50) So I worked on Xbox Live, on the service side, not on the console side. But the team that I was part of, we owned all the catalog infrastructure. So when you search for games or you search for movies or for music, that came through our team and our service. So it was pretty exciting.

(Dan at 00:01:10) The last thing I did when I was on the team, we were getting ready for the Xbox One launch and one of the key features there. So people kind of go, Xbox One, but it wasn't the first Xbox. Why was it Xbox One? And it was really a target to be input one on the TV. So that was the mission, and the goal was to take over input one.

(Dan at 00:01:32) So big push was around live TV at the time. So we worked on the whole interactive guide for TV, which required bringing in huge volumes of data. Because if you think on a worldwide basis, the number of cable providers out there that all have their own channel lineups, their own programming, time zones, all that stuff. So we worked with a third party to bring in all that data. And then one of the big tricks was, how do you make that all searchable very fast and present it in a guide very, very quickly? Low latency queries, et cetera. And then have all the artwork for the TV, for the channels with it, and all the artwork for the programs with it. So it's a really interesting problem and a fun space to work in. That was really my only foray in the consumer space in my career. I think at heart I'm an enterprise software guy, but it was interesting.

(Joel Beasley at 00:02:34) Did you get your start in enterprise software? Take me back to the early part of your career.

(Dan at 00:02:40) Yeah. I started my career in enterprise IT as a COBOL and JCL programmer. So way back, I was a dinosaur. I guess I was a baby dinosaur at the time. But yeah, I started at HP. I did eight years there. Everything from the COBOL JCL programming, all the way up through client-server stuff, and then got into BI. And I absolutely love data. Spending that time in IT really served me well as I developed a lot of empathy for being on the receiving end of enterprise software. And ultimately, when I made my jump to Microsoft and landed on the SQL Server team, I could see the equation from both sides.

(Dan at 00:03:30) So I could see the equation as, we used to joke in SQL that we weren't living on the bleeding edge. We were defining the bleeding edge of software, of database technology, and it was great. But we were always five, ten years ahead of our customer base. And I also had that empathy that customers can't upgrade software every time we do a release, even though we want them to upgrade it. You know, there's other dependencies that they have internally around the software that blocks that, and they work from tight budgets and other priorities than just upgrading software. But spent nine years at Microsoft, most of it was on SQL Server. I did that stint on Xbox Live. What I noticed when I would talk to people I would meet, and if I said, oh, what do you do at Microsoft? And I'd say, oh, I work on SQL Server, you know, eyes glaze over like, okay. I then moved to Xbox and if I said, oh, I work on Xbox, it'd be like, eyes wide open. Oh, man. That's so exciting. That's so cool. And I was like, yeah, it's cool. Like, SQL is cool too but, you know, okay.

(Joel Beasley at 00:04:41) I think Xbox wins at a party though. Right?

(Dan at 00:04:44) Hands down. Hands down. Well, I guess it depends on the party. So if you're hanging out with data geeks, then SQL will always win.

(Joel Beasley at 00:04:54) I don't know. I would challenge you on that one because I like to do the, I don't know. I guess I didn't spend that much time deep in the data. Like, I spent enough time in data to accomplish the business outcome I was looking to accomplish. So I didn't geek out in data. I just needed to learn enough to have a persistence layer.

(Dan at 00:05:15) I love how you phrase that, that you spent enough time with the tool to get the business outcome you were looking for. And that really, I learned that early on in my career at HP that technology is an enabler to some business outcome or business decision. It's not for the technology's sake. And that's kind of what I meant where starting my career in IT, I carried that empathy forward. So I've come across people who they always want to do the next computer science experiment. Oh, I want to do this. Well, why do you want to do that? Oh, because it's cool. Okay. But is that what customers want? Is that going to help them solve their problem or address their need? What are we helping them do? And then you get sort of the blue screen of death over their eyeballs like, uh, but it's cool technology. I want to go do that. And there's a place for that. Don't get me wrong. But you know, when you're in a for-profit business where you have a P&L, SQL Server was a P&L, we had a profit and loss. You had to be very mindful the bets you placed on computer science experiments versus introducing new features for customers.

(Joel Beasley at 00:06:30) Well, it's exciting to see the passion. Right? Because I'm thinking back to my growth and that's exactly what I would just want to do. I just wanted to build cool things. And then I wanted to make money, so I had to learn how to build cool things while making money. And that's a whole different thing.

(Dan at 00:06:46) Yeah. It definitely is. It changes the equation. But I think that the, you know, what I look at for doing cool things, those are my hobbies outside of my making money ventures. Right? I love to play the drums. I'm not a professional drummer. I don't make my living at playing drums, and I don't think I could. And it's probably not, I probably could get good enough if I played six or seven hours a day, but I like that to be a hobby. I don't want it to become a mission unto itself and have my world wrapped around it. And I love technology, that's what I do for my living. I don't actually do a lot of technology outside of my day job. I look to playing the drums or I love wine, I love food, I love travel. Those sort of offset those creativity outlets, offset some of the technology and analytical aspects of my job.

(Joel Beasley at 00:07:46) Exactly. I think it's absolutely necessary for you to be successful as a person for yourself. Right? Your own personal success. Because, man, if you just force yourself to hit that one note all day, every day of the year, you're just going to, your soul is going to die a little bit.

(Dan at 00:08:03) Yeah. Hopefully, not too much. But yeah. I know what you mean. I also firmly believe that those outside interests, even though they're not directly tied to technology, they influence what I do in my day job. You know, I can look at problems through different lenses or I like to call it background processing. If I have a work problem and it's like, okay, I just can't figure this out. Sometimes I'll just put it on the background thread and then play the drums or listen to some music or drink some wine. And lo and behold, like, it figures itself out somehow.

(Joel Beasley at 00:08:45) Oh. I had a guest on that wrote a whole book about that. Maybe Adam can remember. He's listening in. He's one of our associate producers. But it was a couple months ago and he had a slow create framework. And he was an excellent speaker, Sean Livermore. Yeah. Do you remember the name of the book, Adam? Oh, yes. It's How to Become. All right. So he wrote this book about like how an average Joe can become like an Elon Musk. Right? And so you go through the, he has this thing called the slow create framework and he partnered with a psychologist. He's, you know, sometimes when you're talking to people or you meet them and you're like, this person might be an alien. They're so smart. Like I don't know how many neurons more than me they have, but they are just on a whole other level. That's, this guy Sean Livermore, he's one of those guys.

(Dan at 00:09:29) That's cool. I'll definitely check that out because I'm a firm believer in that.

(Joel Beasley at 00:09:35) Oh, yeah. Because it works. That's why you believe it. Because you do it, and it works. I do it, and it works. And then Sean comes along and tells me how we met with this psychologist for a year and wrote a whole book about like why it works and how it works. I was like, oh, this is awesome. Because you get to work with bright people all day. Right? You get to hire these bright people and have them explain problems to you, and then help coach and mentor and guide and direct them. Is that what you're doing at work?

(Dan at 00:09:57) Yeah. And it's a ton of fun going through the recruiting process and just interviewing candidates with all different sorts of backgrounds, seeing what they bring to the table. And I, over the years, I've developed sort of a standard repertoire of questions that I'll ask people. And seeing the variety of ways that people approach these problems. And they're not like, what's two plus two? There's no right or wrong answer, really. It's more about how do they think through. And this isn't like, well, how many golf balls could you fit in a Sparklets bottle? It's not those sort of old school Microsoft types of questions that are tricky. It's more about like, what experience do they have in their background and how do they approach this problem and how do they pull on that experience to come up with their answer, not that answer, but their answer.

(Dan at 00:10:49) So that's a really fun part of my job. And then just growing and coaching program managers and product managers, no matter where they are in their career and no matter where they want to go, helping them look at problems differently, challenge themselves, helping them to connect dots. And I love it when I can just ask a question and you see the spark go off. Like, oh, my gosh, that was the linchpin question. How did you know to ask that? And I'm like, well, actually, I didn't know it was the linchpin question, so don't give me too much credit. But as I was thinking through, like, that's one of the questions I would ask myself, and it's probably based on my experience to ask sort of that question, but that's truly great. And then when I then sit as sort of as an audience member, when they're driving something or leading something and seeing it all come together and everybody else kind of who's watching a presentation or giving feedback and hearing their feedback of, wow, that was great. That was a really great presentation and well thought out or that design was amazing or that feature is incredible. Getting feedback from customers is terrific. And we don't get enough of it because we always hear what's bad. We don't always hear what's good.

(Joel Beasley at 00:12:10) I talked to this guy. He does TLDR. It's my favorite email newsletter thing. I get it in the morning. And so I connected with him, and he told me that he had just sold this other API company he had. And then he had started the newsletter. Right? And he goes, it's a night and day difference. He goes, the API company, all I get is comments and feedback about how it's not fast enough or this is not working the way they think. He goes, but on the newsletter, everybody just replies. He goes, that's so cool. He goes, because I much prefer this business.

(Dan at 00:12:44) I like a balance. I mean, it's nice to know when we're doing things right that we're making a difference with our customers. I also want to know when we've missed the mark because that's a learning experience. And it's not, we have, so I'm at a company called Skytap, and part of our mentality or our approach is really an RCA, a root cause analysis mentality. So whether if it was a feature that didn't quite hit the mark, or we had an incident with the service, it's not about whose fault it was, and why did they mess something up or not do something right. It's really about trying to understand from looking at it from three-sixty degrees, what went wrong? What did we miss? And how do we ensure the next feature we do, we don't make those same mistakes? Or, you know, whether it's from a functional design or from an implementation standpoint.

(Joel Beasley at 00:13:43) How do you store these? Do you have a favorite tool or something or Google Docs?

(Dan at 00:13:48) I laugh because you had to qualify it with favorite. So we have a tool. I don't know if it's my favorite tool. We use Confluence. So these get, every RCA gets its own Confluence page and goes through, there's a standard template we use of, you know, what happened, how was it discovered, you know, what if it was, if there was an incident involved, kind of what was the timeline from when we first learned about the incident, till resolution of the incident, what was the customer impact on that? What was the business impact? So the business, the impact to Skytap for that. And then what remediation steps did we take initially to address the issue? And then what do we need to do? Do we need to put more monitoring in place? Is there a process change we need to put in place to ensure that that same thing doesn't happen again? And then anytime there's a remediation, there's a Jira ticket that tracks the work for that remediation. So we're in a service team org model. So the lead for the service team would take ownership of those remediation tickets and ensure that it gets dovetailed in with the rest of their work.

(Joel Beasley at 00:15:07) I was just talking with the founder of Kentaba. They're like, incident management. This guy, so he was at Facebook. I think they had acquired his company. He was an acquisition hire. So they acquired his company. He was working at Facebook for several years. He is responsible for building out, I think it was Workplace, like the Facebook Workplace platform. It's a pretty big platform, but then he left and went on and was hanging out with some past coworkers that are now at Airbnb and Uber and all of this. And he's like, you know, what's the one thing you miss from Facebook? And they all referenced this internal tool that Facebook had for managing incident responses. But the bottom line was, he showed me what he was doing and it was pretty cool. I have no idea if it would be useful to you, but it's called Kentaba. You can check it out if you want.

(Dan at 00:15:56) Like K-I-N-T-A-B-A?

(Joel Beasley at 00:15:58) Yeah. K-I-N-T-A-B-A. I like sharing tools though. When I find really cool things that are new, this was a newer, I mean, they're large, but they're definitely newer. But when I find cool things that stand out to me, I love to share them because, you know, you want to see great tools get the attention that they deserve. Right?

(Dan at 00:16:18) Oh, absolutely. My team, so we use the, the engineering team uses Jira to manage all their work. So whether it's tracking incidents or tracking feature work and breakdown into stories and tasks. My team from the feature side, I still can't say this tool with a straight face, but it's called Aha! with the exclamation mark. I shall not judge the name of the tool. You and your audience can do that. But it's a fantastic tool. And it's sometimes painful that my team will manage stuff outside of Jira, but it from a reporting standpoint, and really it's like, what are the attributes on features, and what are the different ways we can slice and dice features, and pivot them around to see like when we're coming up with our quarterly plan or yearly plan. How do we look at this and how do we attach or associate feature work back to our business goals and business priorities? And makes it really easy to do that. So it's a super flexible tool, has really good reporting capabilities in it. It does integrate with Jira, so we have bi-directional integration going on, which softens the blow to some respect. But yeah. I love it when we find new tools that make our lives easier. Because, again, it goes back to what are the business outcomes. It's not because of the tool, it's what are the business outcomes.

(Joel Beasley at 00:17:53) Yeah. What's the business outcome Skytap achieves?

(Dan at 00:17:57) So, excellent. Our mission is to help our customers move traditional workloads from on-premise deployment into the cloud unchanged. So what do we mean by traditional workloads? Traditional workloads are applications that were not architected for the cloud. So they might still be in a very client-server type model. They may make certain assumptions on networking topology and IP address ranges, et cetera. Or they may be running on a platform that Azure or AWS or Google don't support, like IBM's Power Platform. So IBM's Power Platform has AIX, which is a Unix variant, has IBM i, which maybe some people remember as the old AS/400, and you can also run Linux on Power. Well, we allow customers, whether it's x86 or Power applications, to bring those to Azure or to IBM Cloud pretty much unchanged.

(Joel Beasley at 00:19:02) That's fantastic.

(Dan at 00:19:03) Once they move them, you know, there's lots of things they can do. They can start to extend them with cloud-native services. So if they want to front-end them with a modern front-end UI or mobile experience, or they want to tap into some of the rich analytics capabilities that Google or Azure have, now your data is being born in the cloud. You're not having to move it from on-prem constantly up to the cloud. Or in some cases, they just use it as a landing zone, leave it there for a few months as they rewrite it cloud-native. So all those cases, we're happy for our customers. They get value out of it. And most of the time, there's some compelling event that's causing them to make the move. Like, our CTO said, we gotta exit all of our data centers. What are we gonna do with these, you know, 100 AIX applications? We don't have the budget to rewrite them all. We'll use Skytap and we'll bring them all to Azure. Or we'll use Skytap and we'll bring them all to IBM Cloud.

(Joel Beasley at 00:20:03) You did all of that explanation without using the phrase lift and shift. I give you credit for that. Awesome. Is that like a taboo word in the industry, or is it just overused?

(Dan at 00:20:16) No, it's just overused. I think what happens is over time things lose meaning. And so, like, what is lift and shift actually mean? So you are moving it from point A to point B, but what's involved in that? So we try to say, move it largely unchanged. Which is what customers want. They don't want to have to rewrite stuff. They don't want to have to go through their source code and find hard-coded IP addresses. And, yeah. I left Microsoft and I went to a large retailer for a period of time. And people go look at my LinkedIn profile, they'll see who that is. And it just amazed me just bad practices over years and years and years of custom application development. And the amount of times we came across hard-coded IP addresses in source code, one time is too many for sure. But that's the reality that these shops are dealing with. And so when you lift and shift and your application doesn't run because it has all these assumptions buried in the source code, that's not what customers want to deal with. They want to lift and shift and have things continue to run without making those changes.

(Joel Beasley at 00:21:33) So have you built like proprietary tools to identify that?

(Dan at 00:21:38) No. We approached it a little bit differently. So for our SDN, our software-defined networking stack, we pretty much mimic what customers do on-prem. And so, what they do is whatever the subnet ranges they're using on-prem and however they've segregated data networks from front-end networks from mid-tier networks, they can replicate that pretty much as is on our SDN. So instead of going through all the source code, all they do is say, okay, our topology looks like this on-prem. Let's replicate that topology in Skytap and then we'll move the applications. So if a host had a certain IP address on-prem, it'll have the same IP address on us.

(Joel Beasley at 00:22:24) That's pretty cool.

(Dan at 00:22:25) So that hard-coded IP address, don't need to worry about it.

(Joel Beasley at 00:22:29) That's amazing.

(Dan at 00:22:30) So the company has some patents around our SDN. And that was one of the early design principles, was networking. Networking is hard. It just is. I think over the years it's probably gotten harder. And to try to simplify that for customers was one of the founding principles from the company even before I got there.

(Joel Beasley at 00:22:53) Yes, it is hard. There are so many details. And the moment that you think you understand it, you talk to a smarter person and you realize you have like an infant's grasp understanding of it.

(Dan at 00:23:06) Yeah. And every time I think I learn a new concept and I think I understand it and a month or two will go by, and somebody will ask a question and I'll be like, I gotta go look that up. I think it's this, but I gotta go look it up. And inevitably, there's one minor detail I get wrong.

(Joel Beasley at 00:23:25) Yes. Smart people that can make things really simple, they are worth their weight in gold.

(Dan at 00:23:31) And that's one of the things, like, when I'm mentoring junior PMs in their career, a lot of times they'll ask like, well, I don't need to know the technical details. I'm doing the functional design. This is what the users should see and how the system should behave for the users. But I coach them on, it always helps as a PM to know one or two layers deeper in the technology than you need to sort of deal with on a day-to-day basis. What that'll help you with is when you write a spec for engineering, it'll help you anticipate what questions engineering is going to have as they're coming up with the implementation design. And if you don't understand that, you're sort of going to come to—your spec will come to a certain point and there's going to be this big gap. And engineers are going to make all these assumptions on what you mean by that. They're going to implement it and you're going to get the wrong feature. So if you can kind of go a little bit deeper in there, even though it doesn't show in your spec explicitly, the way you craft a user story or a use case or a constraint, it'll show. And your engineers will love you for it. You will be their best friend.

(Joel Beasley at 00:24:53) So we have an engineering team over here. I didn't do it for a while. I did it for most of my life. And then when the podcast took off, I just stopped engineering for a little bit. But now we have a team again. And this is like what we're working on this week. So I've got this engineer that I'm working with, right? And I was explaining like this concept of momentum on the team, like the importance of momentum. Because if we have these really big stories and they're not sized appropriately, we can't build that like rapid deployment momentum. And so that's one of the things we are working on this week is better stories. I was going on—we use Pivotal Tracker. If there's anything better, let me know. But we were then like researching on YouTube, like how, tips on how to write great stories. Because once you get out of it for a little bit, you kind of need a refresher. Right? So if you've come across any great content on, you know, writing user stories or breaking up work, let me know.

(Dan at 00:25:52) Yeah. I find, like, when it comes to writing user stories, I always approach it from the—depending on what the feature is and depending on who the engineers I'm working with is going to dictate kind of how I approach a spec. So whether I use user stories and how do I break those up, or whether I use use cases and how I break those up, or whether I just do a straight set of requirements and break those up. To me, the spec is really a communication tool. And the judge of that communication is going to be the engineering team and your test team if you separate those two functions out. Are they able to implement the feature that the PM intended them to implement? So how it looks, it's situational in my book. So if you took a sampling of five or 10 specs I've written, you'll see similarities, but you're also going to see some pretty big differences in them. Maybe your audience doesn't want to hear that. Like, no, I've been telling my team, we gotta use user stories because they're the best thing on the planet. Don't tell me that they can use whatever they want. We need to standardize. And it's like, if you're getting the results you want by using user stories solely, go for it. My experience, it's not the case.

(Joel Beasley at 00:27:17) I think your experience that each situation needs to be approached based on the attributes of that situation is the right one. Right? Because I would say the most common question I would get, you know, back when we used to have events and like do public talks—

(Dan at 00:27:35) Oh, the old days.

(Joel Beasley at 00:27:36) Remember the old days? Yeah. Black and white film. But people would ask me about, you know, what's the right way to design the team. Like, you talk to all these people. Do we do Amazon two-pizza teams? Do we do, you know, Netflix tribes? I was like, look, your team structure should be dictated by your business model. Like, however you need to set up teams, if I'm an agency doing client work, my team structure is going to be vastly different than if I'm like an IT organization inside an enterprise company that's building internal tools. Like there's just going to be such a different layout, so you just have to pay attention to your customer and what's happening in your business and then structure. I mean, why do we hire roles anyway, Dan? We hire roles to solve problems. It's like just look at the problems, and then that will help dictate the structure.

(Dan at 00:28:25) Yeah. I got really interested in reorgs and that sort of thing when I was at Microsoft. So in almost 10 years at Microsoft, I probably went through 15 reorgs at least. Like, it was crazy. But what I learned from that, form should follow function. How do you want the team to function? And then what form is best going to allow them to function? And it's sort of in line with what you say where it's like, what business are you in? What are those business outcomes you want? And you should organize that way. I could always spot a reorg that was built around people because when somebody tried to explain why that particular org structure, it was a very convoluted and complex explanation of why that person is in that role and we have that team structured that way. Whereas if you approach it like, well, we're looking for this outcome or the team to function in this way and this is the org that supports that, people would go, oh, yeah, that makes total sense. Okay.

(Joel Beasley at 00:29:40) Yeah. Versus based off of, like, social requirements or, you know, relationships. I get what you mean. I've seen messy orgs, and I've seen clean orgs. And I've seen it enough to know that I won't work inside of a messy org.

(Dan at 00:29:56) Well, the one thing that is for sure is messy orgs are not durable. So whatever their—whatever it looks like today, it's not going to look like that for very long because they're not going to get the business outcomes that they want.

(Joel Beasley at 00:30:07) Yeah. They've got change going for almost just in a negative P&L way. I'll take a company that's that's either going down really fast or growing really fast because there's change happening at both. The stagnant companies are the hardest to deal with because they're, like, not doing anything.

(Dan at 00:30:25) Well, you always have that, the promise of change. Right? It's coming. Hold on. It'll be there. Just hang on a little bit longer. And then, you know, before you know it, you looked at your LinkedIn profile, and you've been there for four years. It's like, oh, okay. Time for a change. That's for sure.

(Joel Beasley at 00:30:45) Yes. Yes. What's got you excited right now as a leader? I'm sure you read some leadership content. You're always learning. I read in your profile that you even did some, like, you mentor, and then you were also responsible for some learning with some engineering managers. What was that like?

(Dan at 00:31:04) Yeah. So, wow, that's a big space right now because we're in sort of this weird world situation. And while in one respect it feels very stagnant, like we've all been working from home for a year now, it also feels very unsettled, like what is tomorrow or what is next week or what is next month going to bring? So let me put that aside. So at Skytap, I'm sponsoring a learning group around DEI, so diversity, equity and inclusion. And it's a small group of engineering leaders and myself. And we share industry material, we share what we're seeing internally, we share what we're hearing from friends and colleagues from other companies with the intent to broaden our understanding of the space because it is a very wide and deep space. But then to also help our teams kind of with ways to think about and approach DEI. In my leadership role at Skytap, I'm part of our executive staff. And so DEI comes up both with our current population, but also around hiring practices. And how do we incorporate this in our hiring practices? From what has me excited—excited probably from being a little bit nervous—is we're starting to see factions of our employee group that one faction like they want everybody back into a physical office because they love those interactions. They want to be around people, they love the impromptu discussions that happen in the kitchen, or waiting for the bus out front of the building. There's another faction that kind of, I like this work-at-home thing. It works for me. I can live anywhere in the world basically based on working hours, and I don't want to go to the office. And then we have this middle group that they kind of want to have a foot in both camps. So, I want to work from home three days a week, but then I want to work in the office two days a week. Well, this makes a very complex equation of how do you satisfy everybody because it's not clear delineations of team or who works with whom that falls in each of these buckets. You have teams that span the buckets. You have people who need to work with each other spanning those buckets. So it's going to be very interesting how this plays out over the next six months. And how do we evolve our thinking as a leadership team? And how do we evolve sort of workplace practices to satisfy each of these camps?

(Joel Beasley at 00:34:01) One thing that I saw before the pandemic that I thought was pretty interesting, I was at this large Fortune 500 company, and I was having a meeting there. And I noticed that, like, the way all our offices were, it was clear that, like, nobody had a permanent office location, right? It's kind of like a WeWork, but it wasn't a WeWork, it was their offices. And they said that, yeah, they have like a flexible—this particular team or group or department that I was in had a flexible style where some people would come in every day, some people would work from home, some people would come in one or two times a week, and they basically just created this environment and let people come and go as they please. And the people who wanted relationships ended up meeting other people in the org that also wanted to be there, and everybody kind of got what they want. So that's one thing I saw that just popped into my mind.

(Dan at 00:34:54) Yeah. It'd be really interesting to see what their employee surveys say about that. And are all the factions sort of feeling satisfied, you know, with—you think of Maslow's hierarchy of needs, we're a little bit higher up, but, you know, are they all feeling satisfied with that type of arrangement? And if they're not, where aren't they feeling satisfied?

(Joel Beasley at 00:35:18) How do you do surveys? Do you survey your engineering managers?

(Dan at 00:35:22) Yeah. We have our HR payroll benefits tool has, like, a TinyPulse type of survey. So we're always interested in what people have to say on topics, and we're always challenged with what's the right cadence to survey them because there is survey fatigue. And it's like, even if we wait six weeks, some people are going to feel like, you just asked me this. There's not enough time for this to change. Why are you asking me again? If you wait 12 weeks, then people are like, how come you're not asking me more frequently, et cetera. Company really doesn't want to know what I have to say. But anyways, so we try to keep very short surveys, so like 10 questions. And there's a couple of questions that we try to repeat every time, so we can monitor trends.

(Dan at 00:36:16) And there's other questions that are more sort of timely, like what's in front of us right now. And we review those as a leadership team. We have the executive staff, which is a small group of people, and then we have what's called our senior leadership team. And so that's a broader group of people managers.

(Dan at 00:36:34) It's not all people managers, but it's a broader group of people managers at different levels within the organization. And so we talk about it in a small group, we talk about it in a big group, and look at what types of programs or changes do we need to make to address some of the key areas that are beeping red on the radar, if you will.

(Joel Beasley at 00:36:57) Yes, you're involved, right? That's what it takes. You can't just set up an autopilot survey and be like, I've done that.

(Joel Beasley at 00:37:03) Check that mark off, right? You've got to constantly be paying attention to what people want. And that's the fun part of it.

(Dan at 00:37:10) You know.

(Joel Beasley at 00:37:11) That's the fun part of life. You could automate everything and probably be pretty boring.

(Dan at 00:37:15) And so surveys is one input. I think managers having one-on-ones with their teams or individual one-on-ones and then team meetings is really important. I think that's where a lot of the deeply insightful, valuable feedback comes from. When I'm coaching or mentoring people managers, we talk about how to run a one-on-one. And it's not about what's the status of your project.

(Dan at 00:37:45) That's important, but there also has to be time put aside for, how are you doing? What are you worried about as an employee of this company or as a citizen of this world? And making it safe for the employee to engage in that dialogue and capturing that feedback and testing multiple data points by asking multiple people the same question and looking for what are those trends or, at the very least, what's going on in my employee's life that may be impacting their performance? And is there something I can do as a manager to help soften some of that?

(Joel Beasley at 00:38:24) How does that actually go down in person? Because I just had this vision in my head of me sitting here typing like, okay, okay, and taking information from you. Do they just have a human conversation with eye contact, and then later they put some stuff into the system? How does that work?

(Dan at 00:38:38) You know, every manager is going to have their preference. Like, I have to type things because I won't remember. Like, as soon as we end the one-on-one Zoom call, it's like mine goes blank. I think the key is, we're humans. So it can't be an interrogation.

(Dan at 00:38:59) It has to be sort of a dialogue. And at the foundation of that dialogue has to be a level of trust. So as people managers, we have responsibilities to the company. We have responsibilities to our people. But at the end of the day, we're all human. We need to establish that trust relationship so that our employees feel comfortable giving us the feedback that maybe is uncomfortable to hear.

(Dan at 00:39:30) And they have to trust us with that feedback. So if I'm in a one-on-one with my boss and I think he's just banging away on the keyboard and I'm not sure if he's doing email or taking notes, I will say, Brad, I need your undivided attention for a second. I need you to—I need to be sure that you've heard this, and then you can take your notes. And we just have to be—it has to be a safe environment to be able to say that. Or, you know, as a manager, I'm going to say, I'm going to put aside my notes.

(Dan at 00:40:00) So we may have to talk about this a couple times, but I want to be sure that I'm giving you my undivided attention here. When we were all in the office, it was easier because we'd be in a conference room and you could see that I'm not doing email, that I'm actually taking notes. In this world, it's much harder because you don't—if I turn off my video, you have no idea what I'm doing.

(Joel Beasley at 00:40:20) Yes, you're exactly right. Which puts more emphasis on building up that social trust with your team, because you need more social trust to do this remote work stuff.

(Dan at 00:40:31) Oh, across the board.

(Joel Beasley at 00:40:32) Yeah. Okay. So coaching people. We're actually working on building a leadership training program for technologists, and so we're putting together—we've got all of this content, but we're trying to really figure out, what do people care about, right?

(Joel Beasley at 00:40:47) So you train your people, you coach them on one-on-ones. What are some other topics that are really close to you that you want all of your direct reports to understand?

(Dan at 00:40:57) Well, number one, it's individualized. So another aspect of the one-on-one is ensuring as a manager I know what this person's professional and personal goals are. Personal goals as much as they want to share with me, but I should know their professional goals. And so I'll give you an example. My UX manager.

(Dan at 00:41:29) One of his goals is to get a better understanding of the business. So in his role, he's working with the PM team, he's working with engineering, he works with customers. But he didn't feel like he had a sense of, how does Skytap's business function? Great. Okay. I can find somebody in the organization who's in a spot, whether it's in sales operations or business operations, who has that perspective. I can do an introduction and I can let them sort of build that relationship.

(Dan at 00:41:59) And now that person can mentor my UX lead on, what is Skytap's business? How do we function? How do we sell? How do we collect revenue? How do we report revenue, et cetera?

(Dan at 00:42:11) Another goal of his might have been, I want to go deeper on CSS. I don't know, I'm making something up. Great. Well, let's find somebody on our web front end team who's an expert on CSS, and maybe there's some projects that you can contribute to. So I can carve out a little bit of time in your workload that you could actually go do some implementation of some front end pages.

(Dan at 00:42:38) So it's going to be really specific and individualized, but it's helping that individual make connections. And that it's okay to have multiple coaches, it's okay to have multiple mentors. And it's okay for those to change on a regular basis as you're growing and learning and sort of achieving what you wanted to achieve in that area. Great. Hey, this has been a great relationship.

(Dan at 00:43:00) I learned a lot from you. Thank you very much. On to the next one. And in other cases, it may be somebody outside the company also. Depending on what the topic is, you want to be sure that you're creating a safe zone for your employee to have that relationship.

(Dan at 00:43:19) If you're doing it with other people in the same company, they may not feel safe to bring up, I don't know this, or I'm questioning this, or I have a problem with this person. Just the game of telephone. So, hey, I really want to get better at interpersonal relationships in the workplace. Oh, I know somebody outside of Skytap who's really good with that. Let me connect you with them.

(Dan at 00:43:40) Now they have a safe bubble where they can have candid conversations. My guy or my girl can share what's really going on in their own words and not fear any type of recourse.

(Joel Beasley at 00:43:53) Okay. So I have on my notes that in the prep call, you were talking about tool chains. And so Adam said, hey, he's got some interesting insight on tool chains. And I'm like, what? Tell me what tool chains are.

(Dan at 00:44:06) Yeah. There's actually—so what stems from that, this is what I get when my marketing group asks me for topics and I don't really understand the context. It ends up—I'm on a Modern CTO podcast and I'm writing an article about tool chains. So that'll teach me. So, what are tool chains?

(Dan at 00:44:27) And look, anybody can go out and Google and you'll find as many definitions as search results around tool chains. The way I look at tool chains is, in order to deliver an application that's addressing a business need, there's a set of tools that you need to create the application, to deploy the application, and to run the application, monitor it, secure it, et cetera. All those tools—there's not one tool. There's tools in each of those camps. There's tools that developers use.

(Dan at 00:45:05) There's tools if you have release managers or engineers doing release management. There's CI/CD tools that you'd use to deploy it. And then you're going to have a set of monitoring tools and tools to capture logging and monitor performance and availability and all that other stuff. That's your tool chain. When we're working with customers who are running these applications on premises, they have a specific tool chain.

(Dan at 00:45:33) And I say specific—not that it was deliberate. A lot of times it's accidental. Oh, we need something to do this. Let's go find a tool for that. Oh, we need something to do this. Oh, let's go find a tool for that. And so, but they have a tool chain that they're using on premise to deliver the application.

(Dan at 00:45:43) When they migrate to the cloud, most of the time they're just thinking, oh, we'll take our existing tool chain and instead of using it on prem, we'll use it in the cloud. What I try to counsel our customers on is, this is the time to reevaluate that tool chain. And maybe take a bit more of a structured look at it.

(Dan at 00:46:10) Do an inventory. What are all the tools your developers, engineers, support personnel, et cetera, using to deliver and run this application? Do they like those tools? Do they not like the tools? Maybe they inherited the tool from somebody that made that decision ten years ago.

(Dan at 00:46:27) Are all those software vendors still in business? So keep in mind that in certain cases, we're dealing with applications that are twenty, twenty-five years old. They may be using a tool where that company went out of business ten years ago. So there's risk there, right?

(Dan at 00:46:46) Are the licensing models for these tools—do you have perpetual licenses? We find this quite a bit in the IBM i space where tools are licensed to a specific server serial number. Let me restate that. Yeah, you get the big eyes.

(Dan at 00:47:02) The tool is licensed to a specific hardware serial number. So in order to get the license from the vendor, you have to have the serial number for the server that it's going to run on. You can't run that software on another server. It's on that server and that server only. These are some of the considerations they need to take inventory of it.

(Dan at 00:47:20) Then they need to think about, when we move to the cloud, do we want to use that same tool? Can we use that same tool? Is it going to be from a licensing perspective friendly up there? Do we have other teams that are doing stuff up in the cloud that are using tools? So should we standardize across teams and across tools?

(Dan at 00:47:39) If you're moving to AWS or Google or Azure, are there offerings, cloud native offerings, built in? So Azure has monitoring tools, they have log analytics tools, et cetera. Maybe you should use those tools and just sort of pay for the storage and not directly have a license cost for the tool. And then, one of the interesting things going back to we're humans, that's all very objective, if you will.

(Dan at 00:48:10) But there's a subjective aspect of this. I come across professionals in the IT space that they love learning new tools. So, yeah, we're moving to the cloud. Great. I want to learn a new tool because I can put that on my LinkedIn profile, on my resume, and this is really exciting and I love technology and I love being an expert on lots of tools.

(Dan at 00:48:30) I also come across a lot of people that they don't like change. And so going from on premises to the cloud is a big change, and that causes concern and worry. Am I going to lose my job? Is my job going to change? I really don't like learning new things.

(Dan at 00:48:47) And then you tell them this tool that they love, that they've been using for twenty years, can't use that tool anymore, you've got to use a new tool. And that's just a lot for them to take on. Maybe they're later in their career and they don't want to spend the time to learn a new tool. Maybe they're just scared. They haven't learned something new in a while and they don't really know how to approach it.

(Dan at 00:49:11) And they think this is some evil plot by their leadership to get rid of them. Oh, we'll change everything and then he doesn't provide any value to the organization and so we can get rid of them. So you've got to take into account the objective stuff, licensing, will the tool function, as well as the subjective stuff—what's going to be the impact on the team?

(Joel Beasley at 00:49:33) Yeah. My mind is running wild with all the analogies I can't use. Maybe they're inappropriate. But yes, there are all types of people out there in the world. And we're walking around with them, we're working with them, and they all have their importance.

(Joel Beasley at 00:49:48) Right? So you get two Fortune 500 companies, and your company is at a growth stage. There will be a time when all you want are the people who want to come in and punch nine to five and just do consistent work, and they don't want any surprises. There's a time, there's a place for those people, but there's also a place for the people that want it to be different every day, you know. So it's really about—at least my personal growth has been about self-awareness to understand who I am and what I like based on where I'm at, because it can change.

(Joel Beasley at 00:50:19) You can go through different stages in life. At some stages, you could want things to be chaotic. Like, for example, you could even go deeper to get a little bit off track. There can be some areas of your life that you don't want to change, but you could really love change in other areas, right?

(Joel Beasley at 00:50:33) Yeah. Like, I love my family. I don't really want change there. I want that family to stay together.

(Joel Beasley at 00:50:39) But at work, I like releasing new products and stuff, right? So you can have—yeah, it's just—I don't know. I'm getting too out there, but self-awareness, I think, is under-discussed in the context of professional advancement.

(Dan at 00:50:56) Yeah. And I think no matter what the change is, it can be hard. So have a dialogue, listen, see what's really important to the people and why there might be some resistance to the change, and what can be done to address that? I always think of auctions, and if you're going to bid on something, what's your reserve price? So I will not pay more than this.

(Dan at 00:51:20) And so you're going to bid up. You're not going to start there. You're going to bid up to that. And I sort of think a lot of that concept or methodology applies in the workspace just around negotiations. Know what's non-negotiable for you.

(Dan at 00:51:36) Know what is negotiable and work there. Find some common ground. Don't compromise all of your integrity, but also don't expect the whole organization to bend to your whims or your needs. You've got to find that common ground. And the only way you find that is through dialogue, discussion.

(Joel Beasley at 00:51:55) Yes. Yes. Well, we're coming up on time here. So I want to do a quick shout-out for the company. I mean, we got to talk to Brad, the CEO, right?

(Dan at 00:52:03) Yep.

(Joel Beasley at 00:52:04) And what's the call to action? How do we get people—maybe somebody's listening that is thinking about making this shift or moving their stuff. What do they do? How do they learn about you and get started?

(Dan at 00:52:16) Yeah. Well, www.skytap.com. I love—we just a couple of weeks ago, we had a customer migrate their production AIX workload into Skytap on Azure. And probably the best quote, we didn't have to pay for it, this was their quote, was, if we knew it was going to be this easy, we would have done it years ago. Sometimes things that seem really hard and complex, when you get into it, aren't that hard and complex, and the benefits are so wonderful.

(Dan at 00:52:48) And so they're out of their data center. They're running in the cloud. They're running on Skytap on Azure. They're starting to make use of Azure native services and they couldn't be happier. So don't delay.

(Dan at 00:53:01) Operators are standing by.

(Joel Beasley at 00:53:03) Yes. Let's do that. That sounds fun.

(Dan at 00:53:06) You can go to the Azure Marketplace or you can go to the IBM Cloud catalog, search on Skytap. You'll find us. You can provision an account and you could have an IBM i or an AIX LPAR spun up in five minutes or less.

(Joel Beasley at 00:53:19) Oh, they can do it without you?

(Dan at 00:53:20) They can do it without us. Yeah.

(Joel Beasley at 00:53:22) You're giving them control.

(Dan at 00:53:24) Yep. Absolutely. So, yeah, it's an exciting time. Like I said at the start, I love solving business problems and Skytap solves real business problems.

(Dan at 00:53:37) And helps some of these folks in IT be the hero, help with the data center exit, help with an application modernization. And when I get quotes like, this is so easy, I wish we would have done this years ago, that makes my job satisfying.

(Joel Beasley at 00:53:55) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.