073 - The journey from software dev to CEO with Kelby Zorgdrager

We talk with Kelby Zorgdrager, CEO of DevelopIntelligence about his journey into tech, from software developer to CEO. We talk about the journey and the challenges and techniques of managing tech teams in 2021.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Jeremy Morgan:

Hello, and welcome to All Hands on Tech, conversations with top voices in tech. I'm Jeremy Morgan. Today, I'll be chatting with Kelby Zorgdrager, the CEO and founder of DevelopIntelligence. Kelby has been a software developer, manager, CTO, and now CEO. And his mission has been helping developers get better at tech for a couple decades now. We're going to talk about his journey and what he's learned along the way that can help you on your tech journey. So let's welcome, Kelby Zorgdrager. How are you today, Kelby?

Kelby Zorgdrager:

I'm doing great. We're supposed to get about three feet of snow in Boulder this weekend, so pretty stoked about that.

Jeremy Morgan:

Three feet all at once?

Kelby Zorgdrager:

Yeah, that's what they're saying. They actually are predicting one area of Colorado to get 90 inches of snow.

Jeremy Morgan:

Wow. That's incredible. I don't know how you would leave your house with that much.

Kelby Zorgdrager:

It's incredible. Yeah, you don't. I think you just hunker in and call it a weekend.

Jeremy Morgan:

Yeah, about 10 years ago, we got around 12 inches of snow in Oregon, and it shut down the entire state. We're not prepared, whatsoever, for it. Three feet.

Kelby Zorgdrager:

Three feet, yeah. If we actually get that, it's going to be interesting.

Jeremy Morgan:

Definitely. So, Kelby, tell us a little bit about yourself and what you do.

Kelby Zorgdrager:

Yeah, so I currently run DevelopIntelligence. And as you as you probably know, DevelopIntelligence was acquired by Pluralsight in October of 2020. We're really focused on delivering what I would call practitioner led, live training courses. Generally, the way that our services work is that we'll work with a team of engineers that need to learn a new skill. And then over the course of two or three days, we'll teach them whether it's angular or react, or go or some other technology. We'll teach them how to use that technology, primarily focused on the hands on kind of learning.

Jeremy Morgan:

That's awesome. So how did you get started in tech?

Kelby Zorgdrager:

Yeah, so interesting, interesting story a little bit. When I started college, this is early '90s. When I started college, I really wanted to create software for cars. So I thought you could write a software and have your cars be self-driving and all those cool things. So I studied mechanical engineering and computer science. I was a dual degree guy for a while. And about the third year of my pursuit, I met a guy who was an executive at a car company. And he scoffed at my idea of having software in cars. His name was not Elon Musk, obviously. And so, I'm like, well, fine.

I don't really like mechanical engineering anyway. I'm just going to quit that and focused on computer science and graduated with a CS degree. But I got into the field that I'm in mostly because I had some bad experiences with professors in college where learning how to program and learning technologies was much harder than I thought it should be. And so, I'm like, I think I can teach people how to program better than my professor taught me. And so, that's how I got into it. It's like one bad experiences like, I'm going to fix this.

Jeremy Morgan:

Yeah, that's awesome. Usually, it's either a very bad professor or a very good professor that will inspire somebody, like [inaudible 00:03:50] words.

Kelby Zorgdrager:

Right, exactly. Exactly. Exactly. I didn't have any inspiring professors, unfortunately.

Jeremy Morgan:

So one of the topics we're going to talk about today is heroing and hoarding code. And for those who haven't experienced it or are unfamiliar with the terminology, what's it like to be on a team with a hero, which is like someone that just jumps in last minute to fix everyone else's work?

Kelby Zorgdrager:

So, it is interesting to watch. If you are the guy who is not the hero and you see somebody come in and push you aside and take over your keyboard and it's like, hey, let me let me do this, let me fix this for you or you did it wrong, let me make it better. That's an interesting feeling as a developer because you don't really want to give up your keyboard. That's like you're driving new steering wheel for your car, so to speak. For me at least, it makes me feel like, mm, I'm not that smart. Or do I really suck at writing code that bad?

Or did I not understand the problem that I'm supposed to be working on? For me, at least creates these feelings of doubt. And then on the flip side, some other times, you get all pissed off. You're like, why doesn't this guy trust me more and guide general terms? Why doesn't this person trust me more? So it doesn't leave you, as the person, who has been zeroed down feeling good, would be my way of saying that.

Jeremy Morgan:

Yeah, that makes perfect sense. That's a huge erosion of confidence, I think, for somebody. And confidence is one of those things that's incremental, where you build up confidence slowly and it just starts building on itself like a snowball and unfortunately, works the same way in reverse, I found.

Kelby Zorgdrager:

Right, right. Exactly, exactly.

Jeremy Morgan:

And so the pattern of hoarding the code is the same thing. And it stems from trust issues and lack of collaboration. So somebody start saying, this is my code, this is my section, this is my class, method, whatever. This is my whole entire project, don't touch it. And they hoard the code, how do you resolve that at the individual developer level, or even at the manager level?

Kelby Zorgdrager:

I've seen this in my career happened in two different organizations. One was I was an interim CTO at a startup, early stage startup in Boulder. And the founder, who is also the CEO, who is also their first programmer wrote a fair amount of the code. And when I joined, he still wanted to write code and he still wanted to control and dictate the direction of the code, and he still wanted to control and dictate the architecture of the software we were building.

And he had hired me to be the CTO to build the engineering team and actually build the true MVP of their product. And so, it was, needless to say, creates a lot of conflict. I would say, in the first six months, we probably lost half of our engineering team because he wouldn't just get his fingers out of the cookie jar.

Jeremy Morgan:

Wow.

Kelby Zorgdrager:

So that was a very negative experience. And then I'll get to the resolve piece in a minute. But then the other experience I had was working for a really large Telco. And I was working on what you and I would call, basically, software enabled void services today. It wasn't called that, but ... And there were engineers that had been there for 30 years and they would not share. And that was frustrating because as a younger person working in the tech field, you're like, I want to create something cool and invent something cool.

And they wouldn't give you the secret sauce, they wouldn't share the secret sauce. So that was frustrating because it limited innovation. So those are two experiences that I had. But for me, the resolving piece, the best way that I've found a resolve that is to have a conversation and not have a conversation saying, hey, Jeremy, quit hoarding your code. Or, hey, Jeremy, quit heroing. It's more about having a conversation around how the person's actions impact you, personally, and how it makes you feel and how it impacts your ability to do your job. I feel like, for me, that has been a more productive conversation than trying to say, hey, you shouldn't do this.

Jeremy Morgan:

Yeah. That actually makes a ton of sense. And I've been in that position before on both sides of it, so definitely understand the frustration. Do you think heroing and hoarding have gotten worse now that teams are going hybrid or even fully remote?

Kelby Zorgdrager:

I don't know actually on that. And the reason I say that is, even when I was writing code 20 years ago, my teams had flexible work environments where we could work in the office or we could work at home. And so, I don't know if it's gotten any better or if it's gotten any worse. What I would say is that if you're on a team today and you feel like it's gotten worse because we're working remote or we're in this hybrid environment, my guess is that it probably was going on all the time, you just didn't recognize it when you're in the office. That would be my take on it. But I don't know. I don't know if it's actually better or worse. The customers that we interact with today haven't really said it's better or worse, so I don't know.

Jeremy Morgan:

Yeah, it'd be interesting. I know that the lack of face to face contact can sometimes change the way developers communicate, especially when you're doing a poll request or something. When you're on site, you'll do a poll request. And if someone has a question, they'll just come over to your cube and say, okay, explain why you rejected this or whatever. Where, nowadays, I think it would be a lot easier to just deny it and put some nasty message in there and go about your day.

Kelby Zorgdrager:

Right. Well, I 100% agree with you on that. And I think the quality of candor has probably gone down as well. In your scenario, I could walk over your cube and say, hey, Jeremy, why'd you do this? And we could have a normal conversation. And now, there's probably more of the snarky comments being left.

Jeremy Morgan:

Yeah, absolutely. Developers love snark.

Kelby Zorgdrager:

Exactly, exactly. That's right. And if you can't understand the snark, you're not snarky enough, I think.

Jeremy Morgan:

Yeah, [inaudible 00:11:43].

Kelby Zorgdrager:

Your badge of honor. How snarky can you be without totally getting fired?

Jeremy Morgan:

Exactly. So one major solution is better communication, like we talked about communicating with people, letting them know how their actions are affecting other people. And do you think that looks a little bit different in remote situations as far as across the board for leadership?

Kelby Zorgdrager:

I do, yup. My take on this is that in our true remote world, we end up doing one of two things. We either have conversations on Slack or an email that should be over the phone or in-person. So that what you would call the conflict conversations or the hard conversations or ... and we end up doing that in some type of text form instead of spoken form. So that's not great. And then the other thing that we end up doing is we have meetings on Zoom, where I still don't think we've gotten to a place where everybody's comfortable with video.

So we don't necessarily say the emotional things that we need to say. So it's like, we're in this weird space where, historically, if you and I are having a conversation, we can read each other's body language and pick up on that in those crucial conversations that makes it easier sometimes to have that conversation. I think it's a challenge all around.

Jeremy Morgan:

A lot of developers, they don't like things that interrupt them or pull them out of their flow. One of the jokes I used to make as a software engineering manager is I would come over and as soon as I took their headphones off, I would say, "Hey, can I ask you a question when you have your headphones on?" Just joking around because I know what's going on. Do you think that's changed a little bit as far as when things have gotten remote? You mentioned that now things are over text. Do you think that might be actually better for developers who are in the zone and very focused?

Kelby Zorgdrager:

I think it could be better. I also think, well, my ... I want to say, yes, it's better. Knowing when I'm working in my home office, I literally can just shut the door and keep my kids and my wife and dogs out and I can have my own little space. So I want to say, I feel like it's better. And then on the other hand, the amount of notifications that I get from Slack or from Gmail or I use a Mac or my Mac, it's ridiculous. I don't know. I want to say it's better. For me, I know I have more productive time now when I can just close my home office and block everybody out. And I would assume that's the same for most people.

Jeremy Morgan:

Yeah, absolutely. I get Slack messages all day long. And I don't mind them a bit compared to people walking into my cube or office, and mostly because I would want to talk to them longer than we probably should have talked about whatever it is. So the interruption seemed much smaller on Slack, I would say.

Kelby Zorgdrager:

Right. Yeah, I agree. And that's your thing, the question about flow. That's always something that I feel like is to you, is if you're in that state where you're banging out code or you're solving a problem or you're in a different role that's not technical, but you're in that zone where you're just really focused and focusing on what you need to get done. And then somebody interrupts you and then you have the conversation, and it ends up being a really awkward conversation because you're like, I just need to get my work done. Because I'm in the zone, but you feel obligated to talk to the person. And that just creates this weird dynamic. But that's where things like Slack are nice because you can read it or address it when you want to in and amongst that zone time.

Jeremy Morgan:

Okay. And as a leader, how do you make certain kinds of communication effective, like one on ones, stand ups, things like that? How do you make that a little more effective so it doesn't seem as much like a waste of time for them?

Kelby Zorgdrager:

Things that I like to try to do or keep my meetings short. If I could imagine a world where meetings were anywhere from 10 minutes and no more than 20 minutes, that would be awesome. If it could be seven minutes, that'd be even better. But keep my meeting short. The other thing I like to do is have agendas prepared. So if I'm having a meeting with you, I like to send you my agenda prior to the meeting so that you can read it and review it. That way, the time together is the most productive as possible. And then within our culture, we have the reverse as well.

And that is if you schedule a meeting with me, my expectation is that you're going to prepare an agenda and share any information that I need to have before the meeting. So those are some things that I like to do the other. The other thing that I learned along the way and you probably did, too, in your career. But sometimes when you're in meetings with developers and you're brainstorming something, that brainstorming can overtake the meeting. And so, what I've found is that it's better to just call the meeting at that point and say, hey, this really only needs to be two or three people and let's do this at a different time. Just having the voice to call the meeting instead of letting it spiral out.

Jeremy Morgan:

Yeah, that's definitely helpful. Because a lot of the times, developers are problem solvers. So they want to solve the problem right now while we're all here in this meeting. That makes perfect sense.

Kelby Zorgdrager:

Right. And there's usually two or three people. Let's say you've got a meeting with A, there's usually two or three people that are really passionate about the point that you're debating and everybody else is like, alright, guys, let's move on, come on. And so, just isolating the group so that the passionate people can hash it out, is definitely more productive.

Jeremy Morgan:

Yeah, definitely. So how do some of these behaviors such as like heroing and hoarding that we talked about earlier get in the way of things like digital transformation?

Kelby Zorgdrager:

Yeah. I mean, I think the challenge in a large scale digital transformation is that if you have this heroing or you have hoarding, it's going to limit innovation. It's like that example I share when I worked at the Telco where we were trying to create a new product. You end up creating these almost knowledge silos within people. And if you're trying to do a digital transformation, that's going to impact like, let's say, 2000 IT folks, you're not going to be able to scale at the pace that you need to. So you have that on the one hand.

And then in the other hand, organizations sometimes will use like tiger teams or like little center of excellence teams to create an MVP. And then once those guys create the MVP, they end up actually recording all the knowledge and sharing it. And so, it's like sometimes organizations actually create the behavior that they're trying to avoid through this tiger team structure. So it's definitely going to limit the advancement and the impact of the transformation.

Jeremy Morgan:

And so, as a leader, like a CTO, how can you prevent the entire project from being dependent on a single person with a bunch of knowledge? Like you mentioned, the 30 plus year engineer, who probably knows far more about the system than anyone else, but how do you prevent your projects from being ultra-dependent on that person?

Kelby Zorgdrager:

I mean, as a CTO or as a leader, you have to be intentional about it, is one thing. I feel like as a leader, part of your responsibility as a leader is to make sure that you're looking forward to understand and define where you're going. And the other part of your responsibility, as a leader, is to make sure the stuff that you're producing can be maintained, longer term. And so, I think we can get caught up either focusing too much on looking forward and not focusing enough on looking back, or we can get too focused on looking back and not looking forward.

So I think you have to be intentional about it. And for what it's worth, the one guy that knows everything, you would think that it's only in a small company, maybe a 30 person dev team. But I literally have seen it in some of the world's largest companies, where an engineer, like the telco example I gave, there's another example at a financial services company that I worked with. The engineer was the guy that invented the first database for the company and he was the only guy that knew the data structure 30 years in the future. So it's all over the place.

Jeremy Morgan:

Yeah, that's what I would call a knowledge silo if you're the person that invented the database.

Kelby Zorgdrager:

Yeah, exactly. In that organization, that person was at the age of retirement. And so, we were tasked with the effort to help basically codify the information that was in his head and translate it into a training program so that we could create about 100 on the ground experts so that they can continue to maintain and grow the database after he left.

Jeremy Morgan:

Okay. That sounds like probably the best strategy, is getting some of that tribal knowledge or that knowledge in somebody's head down on paper, so to speak, which was probably more likely a Word document.

Kelby Zorgdrager:

Right, right, right. Or a Wiki. I think the interesting thing there is that if somebody has that much history with the organization and they have that much knowledge and nobody along the way has said, hey, we need to create some redundancy of knowledge, it almost creates this self-perpetuating scenario where the person just wants to hold on more and more and more of the knowledge because nobody's ever asked or said or encouraged the sharing. So it's an interesting thing.

Jeremy Morgan:

Yeah, definitely. And that that relies or ties in closely to the bus factor, which is basically how many team members would need to get hit by a bus before the project is completely done, which is a little dark. But what are some strategies you've seen for improving that, for improving the bus factor of your team?

Kelby Zorgdrager:

The bus is just a dark question, right? It's like, how many people ... Yeah, anyway.

Jeremy Morgan:

You could say win the lottery. You could call it the lottery.

Kelby Zorgdrager:

Right, win the lottery. Yeah, exactly, right. Maybe we should call it the win the lottery factor. Or your startup just went public and now you're retired, something. I was going to say, for me, very early in my career, one of one of my mentors shared with me that I should always be thinking about who my number two is. And then once I've identified my number two, who my number three is. And so, my mentors point was that you always, as an individual, he was talking to me, he's like, "You always have to think about who you can build behind you because you never know where your career is going to go."

And so, I probably got that advice when I was like 24, so pretty early in my career. And I think for me, that's the most lasting advice and the best strategy that I've I found. And that's really just making sure that you're pouring into people around you. So that if you were to get hit by a bus or you win a lottery or you want to take a different job, you've left the business or the team or your peers in a better spot. That's my strategy. I mean, it's not like rocket science, but it's worked for me.

Jeremy Morgan:

Okay. And you had personal experience with a team, with a bus factor or lottery factor type situation?

Kelby Zorgdrager:

Yeah. So going back to the Telco example I shared where I had the 30-year plus engineer with all the knowledge, what we actually ended up doing on that team was formalizing code reviews and architectural reviews. And I know in some teams, that's the concept of code reviews seems negative. But on that particular team, we set it up as a way to have the really experienced engineers teach us what they knew. And so, we set it up as a more, hey, this is what I'm thinking about doing. Help me understand if this would work. And so, that worked really well.

So that reduced the bus factor on that team. When I was leading software teams, the other thing that I would do to try to reduce the bus factor is in meeting, and you know this, Jeremy, when you were leading teams, too, you could see where teams were struggling, either with concepts or with a design decision or a technology. Maybe you'd have more bugs in that area or defects in that area. And so, one of the things that I used to do is when I would find a trend like, hey, we're struggling as a team, we're struggling in this area. I would find an engineer on the team.

And I would pull the engineer aside, and I would say, "Hey, next Friday, do you want to run a 90-minute session and teach the other team this concept?" And the answer I would always get would be like, "I don't know this very well." I'm like, "Yes, that's exactly the point. Nobody else on the team knows this very well." But what I was trying to do is level the playing field in terms of knowledge. And again, my hope was that, instead of having one person that knew the concept really well, everybody in the team would have at least the same general level knowledge. So those are some things that I've done when managing a team to try to reduce the bus factor.

Jeremy Morgan:

Yeah, that makes a lot of sense. And I think a lot of it is just framing, like how you frame the message, when you say, something like you mentioned, code reviews. If you tell a team, you have to do code reviews, you get pushback from both the junior and the senior folks most of the time because they just don't want to do. But if you frame it as this is an opportunity for you to teach someone or like you just said, rather than saying, hey, you need to show everybody how this interface works. The first response might be, hey, I don't have time for that.

I've got to keep working. Where if you frame it as I'd like you to teach these folks something new so that they could learn something new and you'll get a chance to share and teach, I think just framing that message in the right way can change the response quite a bit.

Kelby Zorgdrager:

Yeah. Totally, totally. Plus, on the teaching side ... Well, I feel like anytime ... Maybe not anytime. But most of the time, when a developer gets an opportunity to get a little bit of limelight and fame and share their knowledge in a more formal setting, they enjoy it. So setting it up properly is definitely important.

Jeremy Morgan:

Yeah, absolutely. So how can teams or leaders empower developers to get in the zone and get in the flow? We all know what the zone is like and the flow where, at the end of the day, feels like 10 minutes has passed, but you've been working all day and you've completed all these things. How can you, as a leader, encourage and empower that sort of thing?

Kelby Zorgdrager:

Yeah. I mean, as a leader, first things first, you got to acknowledge that people need it. So that's an important thing. And then it's like whatever they say, the first step in recovery is acceptance or something like that. So acknowledge it. And then the second thing I think you can do as a leader is you can encourage what I would call certain work behaviors. And what I mean by that is either decide to have meetings in the morning or decide to have meetings in the afternoon, guide the behavior of the team and prevent what I would call Swiss cheese meetings throughout the day.

I read somewhere, it takes something like 20 minutes or 30 minutes to work on something before you actually really feel like you're in the zone. And so, if your day is Swiss cheese meetings, you'll never get there. I would say, try to influence the behavior and how scheduling a meeting goes. And then the other thing that I would suggest, something that I use myself, is just a little routine, where at the beginning of the day, I write down or organize what I think the most critical, important things are in the day, just to help me think through the day.

And then I try to intentionally put time blocks on my schedule. For me, a two-hour time block is pretty good. I know some people need longer time. So maybe they'll need three or four hours. But I would say just like the manager needs to be intentional about behavior in scheduling, I think we, as individuals, also have to take some responsibility in that walking our schedule, so that we can actually get into the zone. So those are my thoughts on that.

Jeremy Morgan:

And have you seen positive impacts from that, from developers being able to get into the zone and really have a lot of focused work? Have you seen how that impacts digital transformations? Are they something that's directly impacted by that?

Kelby Zorgdrager:

I mean, I think when developers can get in the zone, you're going to actually produce better quality work faster. And I also think your teams are going to have a much higher level of engagement. And so, those two things, when you put them together, you're going to actually move the needle on the digital transformation. The flip side is that if your schedules are broken or engineers don't feel empowered to have time blocks to get in the zone, what actually ends up happening is that you start to demoralize the team.

And then they get frustrated, and then projects start to slip, and then that creates more frustration. So not creating a behavior is actually more detrimental. Not creating a behavior for kind of that flow work is actually more detrimental than blocking time and letting people do their job.

Jeremy Morgan:

Okay, yeah. That makes perfect sense. Have you seen higher customer satisfaction with engineering teams that are able to do that? Is that something that you've seen directly impact the customer?

Kelby Zorgdrager:

I mean, I don't know if I have personally seen a metric that shows higher customer satisfaction. I will say one of the clients that we work with does a really good job supporting the flow concepts. And they are able to push updates to their app, their mobile app, much faster than some of our other clients. And so, for me, they have a consumer oriented mobile app. And so, for me, if they can actually push updates that faster, at the end of the day, they're making the customers happier. Again, I haven't seen a metric. I can just share anecdotal observations.

Jeremy Morgan:

Yeah, absolutely. And what are some other things that leaders can do? Let's say, you are working on a consumer focused type application where the amount of features to be released needs to increase in order to remain competitive as opposed to software that drives cars where it needs to be reliable, software that focuses a little bit more on adding features for customers. What are some different ways to manage your teams when that's the case?

Kelby Zorgdrager:

So I have a slightly different answer to your question, but I think it's related. And that is, how do you make sure that your product is competitive with features? And where do those ideas for features come from? Typically, those ideas are going to come from the engineers or they're going to come from product marketing. And engineers love to invent things for engineers, we all know that. And sometimes product marketing does a really good job doing research and saying, this is where the industry is going, and so we should create these features. We did.

And those are both fair. But at the end of the day, like in the mobile app scenario, your best input is going to come directly from the user of the app. So the closer you can get to that customer and the closer or the tighter feedback loop you can create for that customer, the better. And so, I'm leading up to something. So in our world, we're focused on helping teams learn new skills and developers learn new skills. But at one of the companies that we work with, this producer of a consumer grade mobile app, they wanted to make their app more competitive in the market.

And they wanted to drive deeper adoption with their app. And so, we help them create basically a two-day hackathon experience where there were developers in the room, product marketing in the room, our instructor in the room, and lo and behold, some customers. And so, in the room, over two days, we help them basically iterate the next version of the app. And the customers were there sharing firsthand whether or not they would like it or didn't like it. I mean, again, it's not rocket science, but that was a scenario where we took a slightly different approach.

We use the hackathon, which was intended to build an MVP, but we use the hackathon as a way to teach some new skills. And because we brought in some outside customers, it really made the app cooler. I could share what feature we introduced, but it would tip the hand too much on the company, so I won't do that.

Jeremy Morgan:

Yeah, definitely. That customer feedback is really important, and some of the new tools that I've been seeing emerging in the DevOps field are just observability and measurement of things like that, like feedback as it comes in. Have you had any experience with that? And do you think that works to measure your feedback? Because as you said, there's different things that come from engineers, different things come from product marketers. And it seems like the trend is going far more towards the customer these days in a lot of applications. So do you think that's something that's important to measure, or at least try to measure in some way?

Kelby Zorgdrager:

I think it is important, for sure. I also think where feedback is anonymous. Even if it's a product feature request, if it's anonymous, we do have to take it with some skepticism. It's not the right word, but we have to think through the feedback. That's why I like the personal conversation around feedback. So I feel like we have to do it. We have to watch it. We have to measure it. And we also need to have conversations with people.

Jeremy Morgan:

Yeah, absolutely. That hackathon sounds like a great idea. I know that it's usually those ideas that seem the most simple after they're done that are the greatest when it comes to that, just sitting down with a customer seems like super obvious after you hear about it, but we don't think about it enough in software teams, I think.

Kelby Zorgdrager:

Yeah, yeah. I think so, too. I think so, too.

Jeremy Morgan:

Another aspect of digital transformation is reducing operating costs. So can you talk a little bit about how some of these engineering habits we've discussed, can they help or hurt with operating costs?

Kelby Zorgdrager:

So I have one thought on the operating cost piece, and then I'll answer your question. I know large organizations are looking at digital transformation as a way to reduce their IT overhead, I think that's a great business goal. The thing that sometimes gets forgotten is that once you've gone through the digital transformation and you're starting to realize the additional dollars dropping to your bottom line, if you don't keep innovating after the transformation, you're going to have the same problem in three to five years.

I would encourage folks, when they're thinking about reducing costs, to also think about how they take some of those savings to reinvest in innovation to drive them forward. So that's my little soapbox on that. But in terms of what we're talking about, I will say that if we don't address the hoarding and the heroing and we don't address the siloing, and we don't address the I won the lottery, got hit by a bus problem, digital transformation will become very elongated.

So if the goal is to do a transformation over two years and you don't address some of those cultural issues, you should really expect the transformation to take twice as long. I've seen that in a number of our clients that have tried to go through major transformations and had some broken engineering cultures, and it has taken them much longer than it should have.

Jeremy Morgan:

Yeah. As some developers move from individual contributors into leadership roles, some of them have concerns, and I went through this myself, I'm sure you went through this also, concerns about giving up and not being able to keep your technical skills up and polish as often as they'd like as you start doing more managerial duties. Was this something that you experienced on your journey from being a developer up to manager or CTO, et cetera?

Kelby Zorgdrager:

Yeah. I mean, I think everybody probably has that. It's like whether you're technical or not, anytime there's change in your responsibility, there's some fear of letting go. For me, I got to a place in my career where I just had to make a decision on what did I think I was going to enjoy more. Did I think I was going to enjoy writing code more and I was going to be content with that in my career? Or did I feel like I was going to enjoy helping others succeed in their careers more? And for me, it was the latter.

And once I got clear on the latter, it was much easier to let go of the technical chops. But that's for me. And not everybody has to ... If you're an awesome coder and you love it or you're an awesome developer and you love it, there's no playbook that says you have to go and become a manager, you can do that. But you just have to be clear on what do you ... Again, I think you just have to be clear on what you want. And of course, I still think you're on the side. I'll pick up a book and I'll teach myself a new programming language just to see how it works. So it doesn't go away. You're never going to lose that. It's just, what do you want to do?

Jeremy Morgan:

Yeah, that's what I was curious about, like your personal approach to it. That makes a lot of sense, just focusing back to why you're doing what you're doing and what your goals are long term. You've been focused on a mission of making learning technology easier for a very long time. What's the next frontier out there or the next barrier that we need to break through for making technology more accessible?

Kelby Zorgdrager:

So, Jeremy, right now, there's the trend, I'm sure you've heard about this, but the trend to teach everybody to code, code.org, learn to code. You've heard of those, right?

Jeremy Morgan:

Yeah.

Kelby Zorgdrager:

So I think we actually need to step back and focus more on two things. First and foremost is technology is becoming more complex and the amount of tools that you need to know to actually produce and ship software, much different today than when you and I first started in our careers, so it's our jobs have gotten more complex, the languages and the features and the interactions are more complex. So technology is getting more complex. And unfortunately, I feel like we're letting some of that complexity bleed into the actual user experience.

So we're forcing our end users to become more technical, which was good or bad, wasn't really intensive software. Software is trying to make our lives easier and more productive. Just by the nature of where we are today in the technology world we're in, we are asking our users to be more technical than we probably should. So that's the first thing I think we got to figure out as an industry. And then the second is, I think we got to drop the everybody needs to learn how to program.

Everybody owns a car, but not everybody is a mechanic and knows how to fix the engine of the car. So we got to drop that as a society. And instead, I think we got to focus on how do I increase the literacy, the technical capability of our society. So in other words, there are people today that are functioning in corporate America that struggle with using Excel or struggle with using a browser or struggle with using Outlook. We should focus on helping them be better at their job, instead of trying to teach them how to program.

We're going to get a much better return on that investment and we're going to have much happier and healthier employees if we do that. In terms of making technology easier, those are my two things. We got to make the user experience easier. And we got to focus on helping non-technical people function in their job because they're being asked to do relatively technical things.

Jeremy Morgan:

Yeah, thank you. That's very interesting viewpoint. Thank you very much for sitting down with me and doing this.

Kelby Zorgdrager:

Yeah, yeah. Thanks for the time.

Jeremy Morgan:

That was a great conversation with Kelby. Check out wwwdevelopintelligence.com for custom solutions to help upskill developers fast. Thank you for listening to All-Hands On Tech. If you like it, please rate us. You can see episode transcripts and more info at Pluralsight.com/podcast.