Working effectively in a rapidly changing tech industry

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we're talking to a bunch of different people. This episode, we start a new interview and we're going to be speaking with Douglas Squirrel. This is going to be one of those that I think is going to scratch your technology itch. We're going to talk to someone in Douglas that has been doing tech for a long time. Yes, we will bring up the mention of having to do things via punch cards. That's the kind of history we're going to talk about. We are going to spend a lot of time though talking about how he has evolved professionally, how his career moved from coding into what he's doing today. I think you're going to find this very interesting, regardless of whether you're just starting out and wondering where maybe your career might go or whether you're further into your career and maybe looking for some options, some changes or just trying to see how some other people have evolved into their particular positions. That being said, I think it's time for us to go ahead and kick this one off. Here we go. We're speaking with Douglas Squirrel. All right. Today, we're going to start a new conversation. We're speaking with Douglas Squirrel. This is going to be a little bit different because we're going to have a conversation about where things have been. This is somebody with a long experience, has been through IT, has been through the trenches on all that worked his way up, has seen quite a bit of change over the last couple of years or just last few decades. I think this would be very insightful to see where those of us that are further in our career are, what we've experienced, and maybe some things for you to look forward to as well. I will start with allowing you, Douglas, if you could just give a little bit of introduction in your background and we will go from there. Sounds great. Well, most people call me Squirrel, by the way, so you can call me Douglas or Squirrel. They both work, but you'll hear me using that name. I've been coding, I was just calculating it and trying not to get too depressed for 45 years, so a very, very long time. I've been a CTO or senior technical exec leader or something like that for something like 23 of those years. So it feels like a long time. Certainly I've seen a lot of things change, but a lot of things that haven't changed. As far as background, during that time as a CTO, I got fired from every job that I had as a CTO in this very nice way where the founder of the company would come to me and say, Squirrel, you've built this amazing team. They're doing a super job. You've trained someone to be a leader. You've got all these amazing tools and processes and things are just humming along and there's not much for you to do anymore. And gee, you're kind of expensive, so why don't you go be wonderful somewhere else? It was a very nice way to get fired, but the third or fourth time I said, maybe I should plan for this. So that's when I became a consultant. And so now what I do is I've worked with, it's now over 180 different companies in the past seven or eight years. And I helped them very quickly to improve their technology, their skills, their conversations, their leadership, their processes. And then I get the heck out of the way. And I've been getting faster and faster at that throughout that whole experience. Wow. That's a, we've got it. We've got like a whole episode of conversational topics right there alone. Great. Give me. Let's start with the, start with the back, the last part there, because I think this is something that some people are a little scared about the idea of working yourself out of a job effectively. I think this is the sort of maybe how I was raised or how I've gone through my career is that the goal is to come in, sort of like a helicopter landing, like come in, fix stuff, make sure it runs smoothly, and then move on to your ride off into the sunset. Very much a, which makes it very much a consulting kind of a gig, even if it is as an employee, much as yourself, you're an employee, but short term, you're there for a year, a couple of years, maybe. Once you get things moving, there's not, ideally, there's not much for you to do. You've sort of, you've automated stuff, you've got processes in place and it just runs. So how did you, did you, was this something that was always sort of in the back of your mind or is it one of these things that as you, as you went through your career now, it's like, you got booted a couple of times. You said, all right, I've got to, I've got to change my focus or my thought process as I go into these. Oh yeah. I got angry the first time. Man, I was so angry. I thought I'm getting kicked out of this company. It's a terrible thing and I built this and how can you get rid of me? I had a very negative reaction. And now when I look back on it, I think it's the best thing that ever happened. So you're exactly right that you don't necessarily get kind of acculturated to think that you're building something that should live on its own. You're kind of thinking, how can I keep having a job here? How can I keep having something to do? But that's exactly the wrong way to think. It's thinking like an employee rather than an investor. And if you can move your thinking into that of an investor, somebody who's sitting on the board of directors who says, I want this company to be more valuable, somebody who owns the shares, then you think, well, would it be better for me to keep paying this person to keep doing the same job, to keep manually doing whatever it is that they're doing, building the team or doing the releases or whatever it is? Or would it be better for me to have that all automated and I'd have a kind of money machine and I can just turn the crank and money comes out, customers buy more. That would be clearly the second one is much better when you think about it as an investor. The first one's better for an employee. This is why the employee relationship is a complicated one. What I coach people to do and I coach tons of CTOs, CEOs, CFOs, you name it, I coach it. I coach them to think like an investor. And part of the trick that some of your listeners might find this helpful to do, go meet some investors. They're actually pretty friendly. They will take meetings with you, especially if you're listening to this podcast, you're an entrepreneurially minded person. You're young and energetic. You've got great ideas. Investors want to meet you. So go find yourself some interesting investors and find out how they think and then try to think that way yourself. That will help enormously in building this muscle, this instinct to think, gosh, how could I get out of the way here? How could I make this automated? Because there'll either be another opportunity inside this company or somewhere else. But whatever it is, I'm going to have a much better result for the investors, for the people they're putting the money in, people paying my salary if I can automate. Yeah, and that's that really is the thing that you have to go into it, realize that even as an employee, the goal is that whatever they pay you, you're actually it's an investment in you as an employee and they're expecting you to generate a greater value. If you go in there and they pay you a dollar an hour and your value is 99 cents an hour, they're losing money to do it. Even if it's a dollar an hour, then they can if they can find somebody that brings a dollar and a cent an hour, then hey, it's a better investment to get that to get to that other employee. But one of the challenges, particularly I found in the in the technology world, when you're going in and you're building this stuff, is that like you sort of refer to that's my that's my product. That's my baby. And how did you sort of shift or how do you how do you work with people and say, hey, you want to go in, but try not to get too personally attached and realize that this is something that you are going to have to at some point let it go and go on its own so that you're not depressed every time you move on to that next project. Yeah, I never got detached from the work that I was doing with two of those employers. I came back and did more for them and interacted with the company and cared a lot about it and also benefited in one case from a sale of the company. So I didn't become detached. But the crucial thing that I push people on coaching to do is to get a much broader business perspective. So you see what the benefit is to the whole business of whatever evolution is happening, which might change things for you, might have you leave the company, might more less drastically, might mean that you move to a new product or you retire a product that's no longer making money for a reason that's not related to you. There could be a lot of things that are happening that are positive for the company that with a parochial view, with a narrow view, you might think are negative for you. But if you can adopt that broader company view, see the benefits to the company. Ideally, you have some shares, so you actually are an investor and you can benefit, in fact, from those results. But even if you don't, if you can adopt that point of view, first of all, it's much easier to say, well, this is better for the company. So I'm going to take this new role and try out this new thing, even though it's really different and challenging for me. And it's going to be easier psychologically for you to think about the benefits for you. What am I going to learn in this new experience? What am I going to do differently? What's going to be good for me as well? If I understand how it's beneficial to the company, it surely must be beneficial to me to say goodbye to a product that's no longer successful, to move on to something new and exciting, a new initiative, whatever it is. If it's good for the company, it's probably good for me. That's a good perspective. And I think a lot of people get a little, it does, it becomes almost an us versus them kind of thing. It's like, maybe if it's good for me, it's not as good for the company or vice versa. But then that leads to, especially now as you shift your mindset from, I'm going to go work here for a long time and this is where I'm going to grow and things like that. I'm sort of now detaching that so that my career, my growth is a little bit separate. Although I've got these stepping stones, these companies I'm working for, I'm helping them, they're helping my path. And it may be units within one company. So it's very possible for you to start off in, and I know great examples of this, people start off in customer service, wind up in QA, then wind up being developers. People move around within a company from project to project or role to role. That's a very good thing as well. That's true. And it's, I think it's, it may be a little less common now, unless you get into the, you know, the larger companies like your, you know, your Amazon, your Google, your Apple system, sometimes companies are big enough by themselves that you can live your entire career there. And work through a whole bunch of different areas. And sure. Almost nobody does that. You're right. Except at those very large companies, even at those, they've been shedding people like crazy. So there's a lot of people in the market right now, getting snapped up by the smaller companies. So the market's still good. But the point here is that for me anyway, is that those situations where you're able to move from one role very flexibly and fluidly into another and do something very different and try something new, those create tremendous value for you within the company or outside. It's great on your CV. Whenever I see somebody who's a history major and then was a product person and then became, went into QA and then was in customer service, man, I want that person on my team right away. Because the breadth of knowledge, the breadth of understanding, perfect for your audience, right? The people listening to us are the kind of people who should know about all aspects of a business if they want to be entrepreneurs. Yeah, I find that often people get, I was just talking to somebody the other day about that, where you get into a job role or a title and you think that that's where your value is, as opposed to looking at some of the background. An example I use a lot are people that were career military and they did their 20 years and then they got out. And now they're technically, people can look at them as like a newbie to the job market, but no, they've got incredible experience behind them. Sometimes, up to various levels of an organization, all the way up to like a CEO type experience. And tremendous value. I mean, nobody's shooting at you and me as we're doing this podcast, but they have experience with doing whatever they do in very difficult circumstances. That's true. That's like, they're doing it under a little bit more duress than we do. Our hardest thing is like, is my coffee getting cold? Exactly. Yeah. Am I going to run out of water? Exactly. They've got a little bit different perspective there. So then how would you, and I know you talk more to the, at the CTO CEO level, but for somebody that's sort of going through, let's say that somebody, a younger you, how do you step into that next job thinking about one, the company and the project that you're working on, but also doing it, looking at your long-term roadmap or career? Well, here's one that I picked up from my co-author, Jeffrey Frederick. You want to think about especially moving from a individual contributor to anything with more managerial components to it. And I include there are things like a staff engineer, system admin, or something like that. Someone has responsibility outside their team, whether or not it's directly management in formal terms. When you do that, you should think of that as taking on a new industry. You should think of that as like moving from being a gardener to being an airplane pilot, or from being a teacher to being a politician. You're moving to a completely new type of job. It's not just your business card changes. Everything you're doing changes. If that's your mindset, if you're thinking, I am really starting over here. I'm doing something new and different. It'll be exciting, I hope, for the kinds of people listening to us are going to be excited by change. I trust. And also, you're going to take that kind of beginner's mind, which will make you much more successful, rather than thinking, oh, okay, now what I need to do is what I was doing, but even more. It's almost certain that that's not going to work. So if you're used to writing code, and you're moving into a role where now you have to influence other people and review their code and improve their code, I coach a lot of people who are making that kind of transition. The job isn't to write even more code and do even more, become an even more super duper expert on everything to do with code. You now need to know things about leadership and influence and culture and feedback and a whole lot of different skills you probably didn't have before. Hallelujah. That's great news. That's the kind of beginner's mind to take into a new role like that. So then sort of flashback to when you got to that, because you started with a very, and it sounds like you've been technical all the way through coding for decades now. How did you, or maybe what was the genesis of that mindset change to go from, I'm a developer, I'm writing code, to I have to learn these, you know, basically these soft skills. I have to understand leadership and I have to understand management and influence. Screwing up over and over again and learning from doing that. So I became a CTO when the same founder who fired me years later at the beginning came along to me and said, oh, squirrel, we needed to print new business cards. Here's yours. And mine said CTO. I said, gosh, I guess I better figure out what this is because I have no idea. And I made every mistake in the book. I remember calling the people who were our customers, who were kind of our bosses, the people who were driving everything that we were doing and paying our salaries. Remember calling them, oh, those are the suits. Yeah, those are the suits over there. You know, they tell us to do stuff, but we're going to do it our way. What an idiot, man. And boy, did that burn me when then the suits came along and said, well, actually we like it this other way and maybe you aren't the right company for us and please go away. Then I felt a lot stupider. So making mistakes over and over again has been consistently my way of learning and it's worked out pretty well. And that's the sort of mistake I made often. But what I tried to do was not make the same mistake again. So I remember another time our company was beginning to do a little marketing. We'd had a lot of referral business that we needed to now get people who didn't know us to know we existed. And the founder came to me and said, you know, score, we're going to start some marketing. You need to talk to the marketing people and we're going to start marketing. I said, marketing is bad. We shouldn't do any marketing. Again, what an idiot thinking like an investor. Why wouldn't you market? Why wouldn't you tell people what you're doing? But I thought of it as kind of slick salesmanship of fooling people into buying something that wasn't what we really had. Why didn't we just show them the product? Obviously it would sell itself. That's evidently not true. We're selling B2B to big banks. You know, you needed to do a lot of marketing to get anybody to pay attention to you to even know who you were. So those are just a couple of examples where I made really dumb mistakes. But I learned from them. Once I understood what marketing was good for, man, I'm a big fan of marketing. I do a ton of marketing. Here I am marketing myself with you. So I changed my view. I was willing to learn something new from mistakes. And that was the only way I really learned it. Well, that's unfortunately, I guess, mistakes and errors tend to be the greatest teacher. We tend to learn, you know, it's the old, you know, once you get burned, you know, put your hand on the oven stove and get burned, then you learn. And it can be painful, but it does leave its mark and you will remember such things. So as you've done this, you know, you've done this a few times, you've made a few mistakes along the way. What would be some advice you have to somebody, especially because you've mentioned, you sort of touched on, I think what we run into a lot in the technology world is you start off in a very different, and maybe this happens in other careers as well, but you start in a very different way. And as you move up and progress, there are paths that are very different from what you, it's not like you just do more or better what you did in the past and you're now doing different things. So what is maybe some advice as you've made these mistakes that you can, or maybe some things you've learned how to go into often, like you said, it's a whole new thing. It's like, you know, a pilot to a teacher. How do you step into that? Maybe try to avoid a few of those mistakes, the rookie mistakes that are likely all of us will make if we don't, if we don't get a good mindset, I guess, going into it. And even then you're still going to make the rookie mistakes. Well, I was going to say that is don't try to avoid the rookie mistakes because actually those are valuable. What you want to do is plan for them and plan to recover from them quickly. I'm talking to someone who wants my services, wants me to coach them later today. And they're in the middle of some massive shift. They're changing platforms and doing a ton of different things. And I was asking, and this is going to illustrate by the way, so I'm going to come back to directly your question, but I want, I wanted to cover this kind of the value of mistakes here. The CEO was saying, gosh, how can we move faster? Why can't we get to the new platform? Why can't we get to the new benefits? Look at all these customers that are frustrated. And what I'm going to tell them tonight when they ask me about this is it wouldn't it be better if you could make more mistakes, but recover from them more quickly. Because the reason they're going slowly is they're trying to avoid mistakes, but they aren't building a nuclear plant. They aren't shooting rockets to the moon where, you know, if you launch a millisecond too late, you miss the moon. This is not their world. And so I'm going to suggest to them that they look for ways to make sure that the cost of error is low. And if they can do that, then, hey, we had an outage for five minutes, but don't worry, we queued all the requests. And so here they are, and you're still getting your report. It's just five minutes later. And you're not going to read it for an hour anyway. That's the kind of thing I want them to do. And that's what listeners should do as well. Make the cost of your mistakes low, because you're going to make them. And if you can learn from them quickly and not be too harmed by them, you're going to be in a much better state very quickly. Now, one of the best ways to make the cost of mistakes low is to build relationships, because typically what happens when you make a mistake is somebody gets annoyed with you, right? They get upset. There's some people who don't like what you're doing. Those people are going to be less upset if they know you're trying something new. They know that you're new at it. They know that you've put in place contingencies for it, and they trust you that you're going to be able to recover quickly. How would you build that? Well, my favorite way is to have conversations with people who are outside technology. So if listeners don't take away anything else from me, it's that I've written a book about it. I talk about it all the time. The most important thing you can possibly do is to have more conversations with the people who are not in your team and build trust with them. If you can do that, the cost of error is low. The information flow is much higher. The trust in you is much greater. Many, many benefits will flow. The problem is us engineers don't tend to like to talk to people. So that's one of the challenges I can often help with that, and there are some methods we can get into for how to do that. But if you can overcome that barrier of not wanting to, the benefits are tremendous. That's true. We talk about that a lot, is the idea of setting expectations and communication. I went through a bunch of career mistakes I'd made not too long ago, and it was amazing how many of them came back to the best way to have avoided this or to correct it was that relationship, was communication. It's just as long as everybody knows what's going on, it's a lot easier to say, oh, okay, yeah, we're going to do this. It may or may not fail. If it doesn't, great. But if it does, we're going to take it in stride. We're going to not really assume, but we're going to be prepared for it. It reminds me, I was saying about this the other day, you'll know, I don't know how many of the listeners will have a deep enough or a history enough in the world of coding, it used to be that you would spend a lot of time as a developer examining your code and working through all of the logic and stuff like that versus modern tools, almost whatever you're building, you can hit a button and it'll go through, kick through something pretty quick and tell you that, hey, you've got a typo or you've got a logic flaw. It goes to the idea of you fail and that's a sort of a buzzword of fail fast, but it's a low cost. You hit a button, it costs you three seconds, and then you can see that your code works or doesn't work or it passes a sniff test at least so that at least it'll move forward. So now instead of having to spend that time and slowly crawling through your code, it's faster and easier to just say, okay, tell me if it's right and then the computer will do that for you. And now you've seen where things can, so there is things where you can, you can go create code and crank out an application in an afternoon as opposed to in the past. It's like, if you had a typo, especially go back to feeding cards into a system, then you had a whole lot of loss. I remember kicking off compiles, it's like you kick off a compile, you come back in 45 minutes or an hour. So if you screwed something up, you've just lost an hour in your day versus now a simple thing, you can correct it faster and then you can step into it. So I think it's even from a personal point of view, we've now changed, we have a different perspective. We have that set of expectations that it's like, hey, it's not going to cost me much, so I'm just going to push this thing through. And we can do that, that can extend to others as well, where it's like, hey, you know, this may not work, but it's specifically to your customer, it's like, but it's going to be less overall cost for us to do this, break it, fix it, return it to the state it was, than it will to assess everything and analyze everything and be that much more confident that it's going to work properly and it still may not work. Yeah, it doesn't usually. It's usually wasted effort. But I'll give you a historical perspective here. Smart people, and I definitely was not, as I was illustrating before, not one of these smart people, but I worked for some. But smart people, even 20 years ago, were keeping compile units small, were running automated tests. None of this stuff was something you could get off the shelf. That's the thing that's changed is I hardly ever talked to a company that has no test framework at all, that has no idea how to run any automated tests. Sometimes they don't have very many, but that's a different problem. But usually there's a framework, there's a mechanism, there's a release process, there's CircleCI, whatever you want to use. Those things exist now, and you can get them off the shelf and most companies have them. But the smart ones had it before. And you can even go back to ancient books. My father had a book on his shelf called The Mythical Man Month. And boy, does that have some insights. You have to kind of translate from the bunch card days. And a lot of them are the same things. Keep your unit small, make sure that you have tools in place to help the engineers be as efficient and get rapid loops and feedback as you can. All that stuff is in there. So this has been around and known for a very, very long time. What's really changed is how popular it's become, how much has become kind of the fabric of our work, which is a huge benefit. So now translating that from, in our technology world, that has become very much part and parcel to who we are and how we advance. How have those conversations been outside? We talk to these non-technical people. How does that conversation translate to them? Is that something that's very understandable? Is it something that you have to do some translation for? I'm not going to be an unemployed consultant anytime soon, because those folks and us tech people, I bring them together as much as I can. I run weekly free events in my community, Squirrel Squadron. When I'm coaching, I try to help bridge that gap. I was just giving homework to one of my coaching clients. You must talk to this person in the CEO and this person in product. I want to hear from both of them what the story is. How is their view of what you're doing relate to what you're observing? The problem is that these non-technical folks, actually the main problem for them, it's very interesting, is not that they don't have the right instincts or understanding. They have the idea that maybe it would be good to have more iterations. They have the idea that it would be good to have good contingent actions and contingency plans and so on so you can recover more quickly when you do an experiment. They've got all that, and their instincts are right, but they're terrified of us. What I find over and over again is that I have to really reassure them as I'm coaching them that they're not being too demanding, they're not being unrealistic, and most frequently they're not demanding enough because they're then not clear enough with us. I tell them, look, when those engineers like our listeners, when those engineers tell you that something is impossible, ask them what they would do if spaceships were parked over every city on earth. If you've seen Independence Day, you'll know what I mean, or any science fiction movie. Spaceships all come, they park themselves over all the cities on earth. Now, on Independence Day, they just started shooting without asking, but suppose they said, and by the way, could you release this on Friday? If you do that, we'll leave. Otherwise, we're going to start shooting. If that happened, what would you have to do? Well, I mean, if I did that, we'd have to throw out half of the user acceptance testing, and man, we'd have to launch with a manual process over here, and we probably couldn't get the certification that we normally get from security. And the CEO keeps nodding and says, that sounds great. I can do all those things. How about if we launch it on Friday? And the problem is the engineers typically don't believe the CEO when he or she comes along and says, can you please do this? Because they think they want all the other stuff. And the CEO isn't brave enough to say, I really do want this, and I'd like some compromises, please, and can you talk to me about trade-offs? This is the sort of language, this is the sort of conversation that you create when you start talking regularly to these sorts of folks, and you understand where their fears are. And that's why I say the root method to improvement here is more and more conversations, more and more understanding of the context for the folks who really are frightened of you. And that seems like as good a place as any for us to pause this episode. We will come back and we will follow up with the conclusion of our interview with Douglas. Hopefully, as you see, there's a lot of content, there's a lot of history there, quite a bit for us to talk about, and we've got plenty to go in the next episode as well. We will continue right where we picked off, but for now, I'll let you get out there and embrace your own day and your own career path and working your way through your roadmap. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Please check out school.developanor.com. That is where we are starting to put a lot of our content. We've taken the lessons, the things that we've learned, all of the things that make you a better developer, and we're putting it there. We have a range of courses from free short courses up to full paid boot camps. All of these include a number of things to help you get better, including templates, quick references, and other things that make us all better developers.