Communication between technical and business sides

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 of interviews and we're continuing our interview with Douglas Squirrel. This will be part two. We will wrap up our conversation with him and we're going to continue looking at how he got to where he is. This episode though we're going to get a little bit more into how do we solve some of the problems and answer some of the questions that we were asked when we were trying to communicate and link between the technical and the business side. The suits as he calls them. How do we handle working with them and communicating in a way that makes sure that we are heard, that our expertise is properly used, but also that we are hearing from them what they know and what they need to impart to us. And yes, it does come back to this whole idea of the more we have a understanding of business and how it works, the better we're going to be able to make those bridges of communication. Let's go ahead and get back to talking with Douglas. That actually touches on something we've hit on a lot. It's the Pareto principle or the 80-20 rule. You can get 80% there fairly quickly and yeah, it's not going to be perfect, but you've got something and this also goes in the idea of like a minimally viable product and things like that where you just say, hey, we're going to get this across the finish line first and then we're going to clean up these things. I guess there's two questions in this. You're going to clean up those things that technology-wise as an engineer, we see that yeah, this is technical debt. These are things that we are going to have to clean at some point. So there's two things with that is one is an engineer feeling comfortable enough to go into it and say, hey, I'm going to give you this, but it's not going to be 100%. So there is always that, but I don't want to get burned for it. I don't want you to point to me and say, hey, you didn't do this right because I'm telling you I didn't do it right. And then the other thing is it is always that, hey, we'll fix it in the next release that customers know that that may never happen. But even engineers are like, hey, if we kick this down the road, they're never going to come back and give us the bandwidth basically to correct it. And so we're going to be building a house of cards. Wait, wait, wait, wait, wait, I got to stop you there. And I know I'm not stopping you. I'm really you're very hopefully illustrating what I often hear from especially young engineers. We should and it's a word I ban. I don't let my coaching clients use the word should. But these folks do. They say we should fix that. This is the best practice. This is how it should be. We should fix the technical debt. They never get they it's always the ones in the suits. Right. So we're back to the suits. The suits never give us enough time to do the stuff we should do. We should fix this. It should be better. Just drop the should because the danger in the should is that you're not taking into account the business context. There's some you're appealing to an abstract notion of how engineering should be and how a technology team should function and how an architecture should be built. And there is no should. There's no arbiter. There's no law of nature that says you can only build software this way. Yes, tons of software has tons of bugs. Right. Facebook was a terrible mess under the covers, I'm sure, because Zuck hacked it together in his dorm room. Right. So I'm sure there were tons of bugs and people were getting the wrong feeds and the wrong information and signed up the wrong way and other kinds of things. It seems to have been a pretty successful company, whether or not you agree with its morals. Similarly, when when listeners are thinking about what should what should I fix, what what direction should I take? What's the right thing? What's the best practice? You want to edit that out. You want to get rid of that from your thinking, because that mindset is not going to help you. It's only going to help you to build something that's abstractly perfect, but not something that matches what customers actually need in the real world. And that was I love that you cut me off right there, because that's like a perfect time to and a perfect approach to that. So then this swings back around to does this maybe also tie back to the engineers need to understand the business and understand that business thinking versus what they were taught, their engineer thinking, we'll call it. Yeah, the simple answer is yes, that's exactly what we need to do. And that's, I think, what you and I have been talking about the whole way through, Rob, is that if you don't have that business context, then you're just going to build something that's abstractly good and abstractly good is no good for anybody. It's good for ideal people. And I haven't found any ideal people. I'm not one. You're not one. I've never met them. Actual customers have actual needs and actual feelings and actual demands, which you need to understand, not some abstract picture of what a perfect authentication system looks like. What do people actually do? What passwords do they actually enter? That's what you need to be working with. So then how do we as an engineer, speaking to an engineer like this, as they'll say, you know, those go back to there's these best practices. And if we don't, I hate buzzwords. It's physical pain here. Go on. So you have this you have these things and they the goal for me, you know, the engineers can tell you that these will help you have better software in the long run. This is how it's going to reduce. I'm not going to let you do that one either. Better software doesn't exist. There's no abstract notion of better. There's no software metric. There's no rule where I can stick down and say, OK, well, Rob, you're at a three and I'm at a four and she's at a seven. There's no measurement like that. Are we getting business results that are meaningful to customers? Are they willing to pay us more? Those are the metrics. There's nothing else. Sorry, I'll let you ask me the question. Sorry, but I can't let you get away with better software. So I think this is a good conversation because I think this is where a lot of times we get stuck from an engineering point of view, you get stuck mentally. It's like, OK, how do I get through this brick wall? And so then it becomes sort of a thank you run into this sort of almost a frustrating thing of like, OK, do I just do I just write whatever code the customer asks for or where does the engineering side have where does it introduce itself into building software? Because it is I mean, because there is if you it's a balance, I guess, in a sense, because if you go all the way to the customer side, they're going to ask you to do stuff that may not even be good. You know, sometimes they'll ask you to do things and you say, wait, you don't you're asking for that, but you really don't want it. So that's that's something that drives non-technical people absolutely wild. But it doesn't have to, because when you say quite properly, I don't think this is actually what you want that nails on a chalkboard. Right. It's very frustrating because the non-technical person definitely knows what they want. Look, I want this to handle 200000 transactions a day. I want to get more load. I'm ready to sell to customers. Customers want to do it. You're not letting me do it. Don't tell me that I don't know what I want. I want more volume. You may know that that's going to overwhelm the servers that they actually have in the data center and that they're never going to be able to pay the Amazon bill. You may know that, but if you present it to them as that, you don't know what you want. You're going to be in a world of trouble from the first from the first go. On the other hand, the tremendous thing. So this has a very negative impact if you take it with a with a certain attitude, with the attitude of I know better. You don't know what you want. On the other hand, you have this tremendous pent up demand, pent up potential, potential energy built up here from the knowledge that the customer actually has or what they actually want, which you can fill almost certainly much better than they can, which is why we get this classic thing which people misunderstand a lot. It's very common. All product people know this and almost all of your listeners will have encountered it, that the engineers understand how to build something and will bring out a new idea that the product person, that the non-engineering person will not have come along with. They'll come along with some plan like I just need a button here. I need this button to do this thing and put the button there. And if you put it there, it'll work. You know, there'd be better if it was just automatically done for you. And you got the report an hour later. They don't know that. They can't conceptualize that. They don't understand that that's possible. And that phenomenon doesn't illustrate that they don't know what they're talking about. It means that there's a gap in knowledge which you can fill. And that's the tremendous benefit that you can give. Wouldn't it be wonderful if they walked away saying, man, Rob had these seven great ideas. They were really interesting. Two of them would actually solve our problem and we're going to have one of them on Thursday. And it's so much better than the button I was asking Rob to build. That's the kind of conversation you can have rather than what's very natural. I agree with you. It's exactly the instinct that you have is to say, now, actually, you don't want that. But let me tell you what you do want. That's not going to work. However, if you offer better options for the results that they want, they get the same results, but even better, you're going to be in a very positive position. Wow. And that almost sounds like it reinforces that whole idea of if you understand the business and what they're really doing, then you can bring that engineering to white. You can leverage that and help them understand where they can take the technology to solve their problem. It's like, I get your problem, but technology doesn't fit this solution. But hey, technology can do the A, B, and C. Maybe they're going to blow up your server or something. So it's going to be either less cost or it's going to be easier to maintain or we can get it for you Thursday instead of in three months. And which one would you like? Options are great when you can say, look, I can do the fast way or I can do the way that handles more load, which would be more important. Do you think we're going to grow a lot in the next month and we're going to have a lot more demand or is it better for us to be stable for our current customers? Those are great questions. And if you get that kind of dialogue going, you have a much more successful interaction. So now we're going to switch back a little bit, go back to the beginning. One of the things you mentioned is that you have been coding for 45 years and you've been CTO and consulting for 25 years, basically. How I feel so old. Go ahead. That's why I don't use numbers very often for those guys. I just say, hey, it's been some time in the past. The hair isn't gray yet. Go ahead. I just ran out of hair. So it doesn't. I that's how I've dodged that problem. See, it's an option. You can do it. I went the other direction. How do you answer? This is sort of a combo question is, is how do you keep that technical side? And it sounds like, and I think you probably do still have to have that as part of your job. How do you keep that technical side from getting rusty? Because, you know, we're not doing punch cards anymore. So your punch card feeding skills don't really apply. And I guess how much do you think you're going to be able to do? And. I guess how much do you how much is that a part of your job and how much have you transitioned from what brought you into this, what got you started, where you said, I want to be an engineer to now you've changed into these different roles, but to still keep your I will say that childlike wonder of what your job is. Oh, man, it's just a blast to talk to so many people in so many industries. You know, I was doing in the last couple of years, I've done companies that put satellites in orbit and analyze rainforests, companies that train surgeons using game technology and gloves that can actually simulate the surgery. The sense of childlike wonder that somebody else is curing Parkinson's disease. It's insane that the variety that I've managed to work with and the exciting things that are coming in technology. Well, I got to say one more. There's a company that's using our old friend that we've all been playing with, GPT-3 to write manuals for ovens because they can take the manuals and chat scripts. So if you if you write to the company and say, you know, my oven is broken, you might be hearing back from GPT-3 because it's read the manual, it's read the technical documents and it can say, OK, we'll push this button. Mostly, it's going to tell you to turn it off and on again. But isn't that great that customer service people don't have to do that. So childlike wonder, no danger there. I will say I nobody pays me to write code anymore, which makes me sad. Somebody paid me to write code. I'd be a very happy person. But there's so much more value to be had from using my experience and the techniques and tools I've developed to make the people who are writing the code more effective in ways we've just talked about, like having these conversations, like changing the dynamic to be talking about trade offs rather than demands from customers. There's so much more benefit there and it's a tremendous amount of fun. So I don't miss it too much that I don't get to write code. The way I stay technically relevant is at one remove. So I do these reviews of companies all the time. They do health checks to verify they're doing what they should and to give them suggestions for what to do in the future. And then sometimes they have me come and coach them throughout all of that. I wind up having very technical conversations, reviews of architecture and designs and other great things. And I learn tons. I've never been afraid to go into something that I technologically don't understand and to find out a lot about it. There's nothing really new under the sun. If somebody brings me quantum computing, I'm probably going to have to spend a little more time learning about that. But I didn't have any trouble with cryptocurrency. I didn't have any trouble with the satellites or the haptic surgery. Those were all new and very interesting applications of technological tools I had worked with and knew very well so I could detect where the fault lines were and where the problems were. So I don't find any difficulty in that. I will say somebody hired me to write code. It would be great. Okay. If anybody's out there looking to hire somebody to write code, then I'm pretty expensive for that. You know, if you want to. Yeah. It may cost a lot per line of code, but this is somebody with a lot of experience as we've discussed. It may be the prettiest codes you've ever seen, but of course, you know, X equals X plus one, there's like only so many ways you can do that. There's only so many ways to do it. That's right. So before we wrap it, because you touched on a couple of times your book, I want to swing back around to that is what in your community. So talk a little bit about that process, how you got to writing a book and then tell us a little bit about your book and who it's for, you know, and sort of like sell us a little bit on us or if they, because obviously they've listened to you now and they're like, I love this guy. Squirrel is awesome. I want as much as I can get of him. I'm going to like curl up with his book at night. Well, first of all, I'm not here to sell books. My publisher is most interested in selling books. If you're, if you're nice to me, I can certainly offer to send you a copy or find a way to get you copies of the book. It's from IT Revolution Press. It's called Agile Conversations. And the way I got to write it is that my co-author, Jeffrey and I studied this dusty old academic set of tools developed by a guy called Chris Argeris. And they turned out to be tremendously applicable to all kinds of businesses, but especially to technical businesses and engineers, us folks who don't necessarily like to have conversations. So it turns, it turns out there are these great tools for, I'll just tell you about one, which is really relevant to this trust building that we talked about. And that's called test-driven development for people. So you get the same experience that you have if you do test-driven development, whether or not you like it. Some people think it's great. Some people don't, I use it, but you know, it's up to you. But the benefit of test-driven development is, as you know, if you will have tried it, if you've tried it is that you have a lot more confidence in what you're doing. It's like taking small steps instead of big leaps and you're less likely to fall down. So you have the same experience when you're having a difficult conversation with someone that you're building trust in small steps, you're understanding their story. And there's a whole mechanism of tests that are very similar to the red green refactor kinds of tests that you use in TDD that you can use with people. And so we kind of rediscovered all of these methods, developed a few of our own. We said, we really ought to tell people about this because it's so beneficial. It's making such a difference for us and in my case, for all my clients. So we decided to write a book. IT Revolution was kind enough to help us with that. And it's been out for a couple of years now selling reasonably well. The interesting thing about it is that people who read it fall into two categories and they're both fine categories. I'm perfectly happy with anybody who reads it gets benefit. But one group kind of says this is a nice book. It's kind of fun to read. It was enjoyable. I got some nice ideas. And those folks, I say, you might want to read it again because the people in the second category say, my God, this was hard. I had to do an awful lot of work. I had to go write up things and analyze stuff and understand things. And they're the ones who really use it as a workbook because it gives you new and difficult tools. These are not easy things to use, but man, are they powerful. And when you apply those techniques, you get to have these very difficult conversations in a very successful way that makes a huge difference very quickly. And it's astonishing how much impact you can have, whether other or not other people are using the same techniques, whether or not they adopt the same principles as you, you can have a tremendous impact just by yourself. So that's the techniques and ideas in the book. What I've moved on to now is a community I have called Squirrel Squadron, which is tech and non-tech people working together. So there's plenty of communities of CTOs and CFOs and people who are interested in the latest version of React. There's great communities, but they're all kind of fractured. So my vision is that we should get these people together interacting, discussing. I'm going to be in London live this week as we're talking on the 12th of January. This podcast will be out after that, I'm sure. But I'm going to be live in London talking with operations people about how technology can help them and things like GPT-3 making a big difference for them, changing how we deal with oven manuals. Right. That's the kind of conversation we should be having much more, not discussing within our kind of parochial tech groups and our finance groups and our other groups, how we can do better in our own disciplines. How do we get these people talking to each other and making a huge difference, finding new techniques, finding new tools that really help them? So SquirrelSquadron.com is the place to find out about that. And you can join and come to free events and be on a forum I have where we're discussing these kinds of things. Lots of material there. And of course, if you want to find out more about me, because I have this unusual name, it's easy to find me. I'm DouglasSquirrel.com where you'll find all kinds of resources, free videos, all kinds of other things, all about me and what I do. Excellent. So that does raise a question. As you stumbled across this ancient text and found all of these valuable gems, was this something while you were, I guess, as you were developing the book, as you were putting some of those pieces together, is this something that you were sort of working through it at the time and you were sitting there going, wow, this thing is, I'm going to go try this. And then. For sure. It actually came the other direction is that Jeffrey and I and some others like a gentleman named Benjamin Mitchell, who introduced us to these social science ideas, we were practicing this continuously and screwing it up. Just as we've been saying all the way through, making a lot of mistakes and then evaluating them, part of the technique, part of the tool is a very powerful method for analyzing your conversations and improving them, kind of like a code review. And so we were doing these conversational code reviews over and over again and learning from them and developing new techniques and ideas. And they found their way into the book. So it actually went the other way around that we were developing it, learning about it, trying and seeing what value it had. And then it all wound up in the book. Excellent. So this is this is like it's probably better than peer review. This is we've actually this has been run. This is actually real world examples kind of things. This came out of the real world and all the conversations in the book that we analyze are our actual conversations disguised. I've anonymized them, but they're they're from life. And that's I think the technology world, as you say, because we don't normally spend it that much time having conversations. That's not typically our our strong suit. Now, we can have taught in computer science courses. I don't know why. I know it should be because that's I think and I think some places are getting better about that is that they're starting to realize that as you can build the coolest application in the world, but if it has no use, if it doesn't have an application, then nobody's going to care. Nobody's going to buy it. It goes back to that. That's right. Best practices in a vacuum are not best practices. That's right. Sometimes you got to tell people about it, about it, a little bit of that marketing kind of thing. And then it's got to have some application to the business side of it. Exactly right. So with it, with your wealth of wisdom and genius that's come through making a few mistakes along the way, what would be like a parting, a parting thought or maybe parting suggestion to to the audience of people they're starting out or whether they're just starting out or are really starting to get their feet underneath them and figure out where they want to go? What is maybe something to would either advise yourself as a younger person or since things have changed since then, what's some advice you have to people that are they're getting out in this modern world? Oh, well, the advice has changed. The situation is not changing any meaningful aspect. You know, we didn't have smartphones, but we had people using software and being just as confused by it as they are by their smartphones. I was watching my mother-in-law trying to use hers and it's not her fault that it's difficult. It's absolutely not hers. It's the fault of the designers. So and with that in mind, I'll offer something that's a little bit different to what we've talked about so far, just to give one more angle on the same thing. Spend as much time as you can with ordinary people who use your software, observe them, watch what they are doing, understand their lives and issues and what's happening for them. It's usually massively, massively different than you think. I'll just give you one fun example. I had a client who had a very, very manual process. It was something that they did every day. They had to mark things to market and update things and so on. There was a whole host of things that they were doing. And it became so evident that this process was horribly broken and slow and inefficient and all kinds of other things that we came to them over the proposal to make that process much better. And we said, wouldn't this be better? They said, no, actually, that wouldn't be better. The people who do this are people who are learning about the business. They are not that expensive. It happens overnight. So we don't have to worry about it too much. We get the results in the morning. So we're happy for those people to learn by doing a process that's inefficient. Sure, in a perfect world, we would probably fix it. But you know what would be much better for our business is if you made these reports even slicker and shinier and even more attractive to our customers who are the ones who are going to be using our services. So could you work on that, please? And boy, was that an education for me to have spent time with the actual customer rather than in my ivory tower where I thought this process is horrible. Look how many errors and problems and things they have to do. It didn't actually matter to them. And you're going to find out all those kinds of things if you spend more time with the people who actually use your software. So try that. That should make a big difference as well. Yeah, that goes back to that reminds me of the story of way back some of the discussions around, you know, are you you'd save something and you get a little are you sure button or do you really want to do that button? Yeah. And there were there people that complain and say, well, I want to just be able to get rid of that really quickly. And the whole point was, no, you need to think about that before you do it, because it's really easy to just, you know, mindlessly go through it. And I think we've all done that. We've had that interface where we say that's a problem of design as well. The fact that you can whiz through it and you can just click the same button every time. If you actually want people to stop and think and people who design systems like for airplanes and nuclear plants and things like that, where they do need people to think they don't do it that way, they do it in much better ways. I know designers, so don't ask me the details, but they certainly it's not. What would you like to are you really sure you want to land the airplane now? It seems kind of windy, right? You don't get a pop up like that in the airplane. You get something else that tells you you really should think about this. There's some danger here. Maybe you should try another airport. But it's presented to you in a completely different way. And you can't just click it and say, go away. There is some there's some intent behind that. There is. Then there's good design. That's the main thing. That's true. I want to I want to be respectful of your time and thank you for your time. This has been, as I expect, this is a great, been a great conversation. And that's what happens is when you start having conversations with people, you get their experience, you get their perspectives. And I don't care whether, you know, yes, you've got a wide, a long experience, but even people with sometimes a very short time of experience still has. It's it's new. Like you say, it goes, this is something new to you. And so you can you can learn from it. So thank you for for advancing the education of the audience here and for for reinforcing a lot of, I think, very important ideas, particularly the the communication and getting out there and understanding what it is that you're what it is that you're building and who it is. More importantly, who does you're building it for? Absolutely. Well, it was a blast, Rob. Great questions. Thanks so much. All right. Thanks a lot. Well, you have yourself a good one and hopefully we'll catch you again soon. Thanks. Take care. And that wraps up our conversation with Mr. Squirrel. You've got plenty of links that are in the show notes. If you want to spend some time talking with him, get to know a little bit about what he does in his squirrel squadron group. I think one of the things that you need to take away from this is in this this second second episode, we really sort of tore apart the idea of ideal software or even best software. There is definitely a practicality, a pragmatism to building software in a way that is going to be most useful for business. And that is really it comes back to solving problems. It's not doing them in a vacuum. It's not doing them from an ivory tower. It's let's find a solution to your problem. And then along with that, we do want to do things like find the best way to do it so that it is scalable, stable, maintainable. But there are a lot of things that are recommended approaches that we don't necessarily need to do. Or we can kick those down the road and maybe they don't have to be done at all. Or maybe they are better done somewhere further down the road, much like the now commonly embraced concept of an MVP. Which we have mentioned more than a few times. But before I drag this on too long, I'm going to let you going to dismiss class and let you get back out into the world. 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-Noor 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.developa-noor.com. That is where we are starting to pour 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.