#44 Meet Douglas Squirrel: Insights from a CTO and Technology Expert

 Hello and welcome to a new episode of the C T O Show with MeMed. My name is MeMed. I share daily insights about lets trends in technology while discussing their business benefits. I also sometimes feature startup founders and entrepreneurs and what they are trying to solve . Today, it's quite different.

I have actually A C T O with me on the show. I have Doc Squirrel who's joining me from. England and it, we will be having, I'm sure, a very engaging and very interesting discussion. So before we start, thank you Doc for joining me on the show today. Can you just introduce us, uh, introduce yourself to, to the, uh, to the podcast listener and to the YouTube viewers 

as well?

I sure can. Hi, my name is Squirrel and I'm, uh, as I was just telling mema, I'm sitting in my 600 year old house in England, and, um, it's not the best setup for podcasting, but I think we figured it out, so it's working well. Um, my background is, uh, 40 years of coding, probably 45 now, and, uh, 20 odd years of being some form of technical leader.

The interesting thing about my history as an employed technical leader is I got fired every time over and over.  And it was in the nicest possible way, the founders would come along and say, squirrel, you've built this amazing team and they're building the software we need, and there's a leader you've trained, and that person's really doing great and the team is really functioning without you and there's really not much for you to do.

And gosh, you're always a very expensive squirrel. Maybe you can go and be wonderful somewhere.  And it was a really nice way to get fired. But the third or fourth time, I said, hang on a second there, there's a pattern here. So, and, and what was interesting was it got shorter each time. So the first time took about 10 years, and the second time took about two, and the third time took about one.

And I said, well, maybe I'm getting better at helping teams get better. So then I became a consultant. And so now I work with lots of CTOs and others, CEOs, CEOs, salespeople, you name it. I, I coach them and.  And what I do is I help them very, very rapidly. So I've worked with about, I think it's up to 185 in the last, uh, eight years or so.

So if you do the maths, I get through them very quickly. I help quickly, I get out of the way, uh, I transfer the skills and I help the team be much more profitable, uh, very fast. 

Oh wow. That's really an impressive history, I would say. Um, yeah, and I'm sure it's fun. It's fun. I'm sure you're doing the job very well.

So  , if they're giving you this feedback and then telling you thank you, of course you're doing the, the best. So I'm interested to know, because you know, you have a long history when I was, you know, checking, um, your profile. So what, what attracted you to technology back in, in the days? I would say that's the first. 

Wow. What a great question because it goes back to when I was six years old and my father gave me, my father and mother gave me a, uh, computer, one of the very, very first home computers, the t r s 80 for anybody who knows this kind of thing. The, the B B C micro was a similar kind. Um, apple One or Apple two were similar.

And um, the amazing thing for me at that time was the machine was predictable. The machine would always do the same thing, and the universe doesn't seem to do that. You know, I pick up a pen and half the time when I, cuz I'm very clumsy, I'd pick up a pen and I drop it or something else happens, you know, it's not predictable.

Whereas in a game that I might be playing on that computer pick up pen, which is what you type in at that time, it always resulted in you picking up the. So I really like that predictability, the, um, certainty that you got from computers. That's ironic because now what I do is I help people deal with tremendous uncertainty in their businesses and build software in a way that, um, allows them to experiment a lot when they don't know things.

But I still like the certainty that you get from the machine itself.  

That's a also like inspiring story, I would say. And I think when these generations of computers came out, I was still crawling, probably so, but yeah, I get 

We don't have to date you. That's okay. Or me,  . I feel old.   

I'm old as well. So  I have to agree with you because you know, one of the things that also attracted me to computers in general is that you give them the instructions and then you expect them to do the instructions. 

You gave them. So yes. That's, that's quite good. So  what was the first, I believe, was it like, uh, basic, the first programming language that you have ever used at 

that time? That, that's what I work in. Yep. Then assembler. 

Oh, okay. That's, that's good. What was the first, I would say program that, that you have wrote?

Uh,  First program now. That would've been a long time ago. Some Hello World or, um, you know, print my name on the screen, ah,  over and over again. But, but the first real program I actually, that this was the days when you would record things on a cassette tape. You know, a little thing that you'd push into the computer that could play music, but in fact you'd record these, um, uh, uh, tones on it as, as the, the program.

We didn't have disks. And, um, you would send these cassette tapes to someone trying to get it published. So I did this at the age of seven or. Uh, for a, uh, program. Uh, that actually, um, there were a couple, there was one that, um, you, you were a flying creature and you ran around and picked things up. Um, standard video game of that era and another that simulated a touring machine.

So, uh, nobody ever published my program strangely. Um, they, they weren't very good, but, uh, that it was, uh, interesting, enlightening experience and, and kind of like the internet today, nobody knew I was eight years old, so I would send these things off and all they were getting was the cassette tape and a little message that.

Hi, please publish my program. They didn't, and they'd write back to me as if I was an adult and, and that was a very interesting experience. Yeah, indeed 

it is. So  I'm now more interested to understand, because, you know, I'm also, the first thing I was exposed to was Pascal, and then basic.  So, but of course over, you know, the years technology changed,  language changed. 

So from a CTO perspective, How you were able to keep, you know, up with the trends? I would say up with the new technologies. And if you can give an advice, because I'm sure whatever we have today, maybe in, I would not say 10 years, maybe after five years, we will not have it.  

Yeah. Well, um, uh, in, in all of my adult life,  the web was, uh, available.

So, uh, I went to Univers.  Around the 1990 period and in there we were just developing the web. So it was, it was very new, but it had a lot of interesting things on it, which I would keep track of. I mean, I guess before then I read computer magazines and, and that kept me up to date. But what I noticed that was interesting was that back in the 1990s, you could literally list almost every webpage on the web.

It was, there was there, there were pages that were just lists of vix and, and I'd go and, and troll.  For the ones that seemed interesting nowadays, of course you couldn't possibly keep up. But, um, there were different, it continued to be these different filters. I mean, Craigslist came from a similar thing.

Craig would just send out a list of interesting stuff every week and people seem to like it, and that that's where he got his list from. Uh, so, but these have evolved. So, um, there was one called slash dot, uh, which was in, uh, named because it was intentionally hard to say. Um, and, uh, that was a place that people found information after some of those first, uh, listed links after it got too big to keep track.

Uh, then Hacker News came in and we got Reddit and, um, those are the main pla uh, hacker News is now the main place that I go for, um, anything important in tech, I, I will get there. I'm, I'm sure it'll make its way there, but I, I've noticed this evolution where the, the, the kind of the cognizanti.   appear in a certain place and, and then it'll become less cool.

You know? It, it, uh, nobody wants to go to that club anymore cuz everyone's, it's too crowded. Right. It's too popular. Yeah. And so then they'll go to someplace else. So, uh, it's about time for people to move on from Hacker News, I think, but I don't know what's coming next.  

Cool. Now I'll ask, uh, a different question.

So when we say C T O.  Many things comes to mind. So sometimes people think that a CTO O in a traditional organization is the guy who supervise all the technologies In other contexts, we see the CTO O as a co-founder for a startup, right? And sometimes the c t O can co-exist with a c o and you know, he just choose the technology while he gives the day-to-day operations to the c o. 

from your perspective, because you have this long experience, how do you define exactly what a C T O.  

I don't, um, although if you go to my website, you'll see if you, if you stick on the website for 15 seconds or so, you'll get a little pop-up saying, um, would you, would you like a, a document on what A C T O does?

What I say in that document is the CTO does kind of whatever a C T O does. Um, it is very funny. My, uh, very first role as a cto I got in a, in a unusual way, the company I was working for, Hadn't had any technology people in it. I just happened to be one, uh, doing another type of role. And they said, Hey, squirrel, you know how to do this thing called programming.

Would you do some of that for us? Because we're changing our business. We had spun out from another company and I said, sure, I'd be happy to. And they said, oh no, also, we'll, we'll get you a new business card because we need a new name on our business cards from not the old company. I said, that's fine. A week later, the founder comes to me and says, uh, okay, squirrel.

Uh, here's your new business card. And I looked at it and it said, cto. And I said, well, I don't know what that is, but I guess I better figure it out,  cuz I've never been one of those before. And, and that's how it normally is for almost any CTO O the traditional, super traditional model is, is one of the ones that you described where the, the CTO is mainly in charge of technology in some form that some CTOs manage a technology team.

Some of them manage a product team, some of them have responsibility for customer.  Completely weird, but I've certainly seen that some CTOs are more kind of the, the crazy guy in the attic, the one who knows how to do everything and, and knows where all the bodies are buried. But you wouldn't let 'em near any, um, engineers, you wouldn't let 'em near any, uh, management responsibilities.

And they have some VP of engineering who takes care of that. Um, and, and there are other more far field models as well. So, uh, I never know. When somebody says to me, I'm A C T O, I say, great. So if I followed you around all day, what would I see you?  And that's what tells me what they're doing. If they, if they say, oh yeah, I'm, I'm playing around with the hardware and I'm trying to build the next Internet of things, revolutionary product.

I'm putting chat g p t in a, in a lamp. Then I say, oh, you're the technological side. You're the one doing the art, research and development. If they say, well, yeah, you'd, you'd see me going to one-on-ones. And, uh, coming up with new processes and talking to customers that say, ah, you're on the leadership side.

Um, there're, and there are huge numbers of, uh, options in the middle. So, sorry, I can't tell you if I need, if somebody finds out, please let me know.  

Yeah, probably. I, I have to agree with you honestly on this. Uh, I've never been a C T O, but I met a lot of CTOs. And the context change, as you say, like it depends.

Are you the guy who's, uh, as we call them, the core techie guys, you know, the, they like to type and, you know, code, or are you just the, the guy who's managing teams and giving directions and so on? So, yeah, I, I think I agree with you. It depends on the context.  The role is driving them to to do mm-hmm.  now. 

But in all cases, and I think this will relate like at some stage, technical people even they become CTOs in whatever context they need to manage people. And this is something, cause I was also on your website, and I think this is one of the areas where you help  customers to overcome is how.  Someone who's really from a techie background.

And I shared something on another episode the other day  because I had a public speaking, um, coach as well, and we were discussing that usually techie people are introverts by, by by nature. So 

me for sure. Yep.  . 

Yeah, same here. So, so how do you think like this can evolve, like how they can become better managers in, in European Hmm. 

So, uh, surprisingly, the introversion is actually an advantage in certain ways. Um, because you have a sort of introspective nature, you tend to think before you speak, which is a very helpful characteristic. Uh, and that's true of anybody who has that kind of characteristic. US engineers, we have some particular positive characteristics, some particular things that really help us.

So, again, surprisingly kind of counterintuitively the, the discreetness or the concreteness, the certainty that we were talking about at the.   that turns out to be very helpful, um, when you want to be disciplined about your conversations. And, and I wrote a whole book called Agile Conversations with my co-author on how to use your technical skill, how to use, um, things that, you know, like test driven development to help you have better conversations.

And it, it turns out that if you work hard at this, if you are disciplined and thoughtful and, um, view a conversation as a, an entity that you can improve, almost like a computer program that you can debug, then you can improve it a lot. And I find when I coach salespeople  or operations or CEOs, uh, that they have more trouble with that, whereas the CTOs get it immediately.

They say, oh, great. So there's a recipe, there's a, there's a, there's a program, there's a step of set of things I need to do. Step one, step two, step. Well, I know how to do.  Uh, so that can be enormously helpful for, uh, the, the skills that cut for acquiring the skills that go into being a manager. The, the problem comes in, unfortunately, that if you don't, if you aren't disciplined, if you aren't thoughtful about it, and you try to deal with people the same way you deal with computers,  you will have a lot of trouble , because the computers, unfortunately, are the ones that are super predictable and the people are, um, really, uh, not something you can control in any way.

So, uh, many engineers that I work with say, I'm just so frustrated, why won't they listen to me? I know that the code is bad. I know that we need to address the technical debt. I know that we need to dis how a squirrel, how can I convince them? And I say, well, actually the first thing you have to do is stop trying to convince. 

Yeah, that, that's interesting. I like the part about the predictability. I agree with you. This is, again, machines you can, although they give some, they throw some bugs or errors 

from 

time to time, but there's always a reason. There's always something you can trace back. Human beings, you can't. 

Yeah. This is what I wanted to say.

Like you can't trace that back with the human beings. It's, it's a little bit of challenge now. If only 

we had back traces, stack traces for, for humans, it would help a lot. 

Yes. Yes. Um, Now from  coming back to, to developing, I mean, or writing software or producing software, um,  because I had also a discussion, another episode about what really  the main thing as a c o and whatever context you want to take it in. 

What really they need to focus on. So their  customers will say, Hey, you know what? You're doing fantastic job. Your, your, your product is really up to my expectations. So what are, you know, if you can give from your experience some hints for younger people who might be watching or listening to us.  

They don't have to be younger.

Unfortunately, old people make exactly the same mistakes as older, as younger people. So the age is, is not the issue. Uh, the um, thing that is absolutely consistent is the cycle time. If you can get a good cycle time, and I'll say what that is in a second, it's not what Jira tells you your cycle time is. If you can get a very fast cycle time.

You almost can't fail with your customers. You could find out you've got completely the wrong product and your customers don't care about it. But that would be good. I'd rather know that today than six months from now. The, the problem is that, uh, uh, because of this wish for certainty, this experience that we have with computers, that if we can just get everything right, we can understand all the things the computer program is supposed to do, then we can write the computer program correctly.

The problem is that the humans who are using our computer program are not specified in that way. They're kind of blobs of, of, um, uh, conflicting wants.  Getting a, a coherent set of specifications from them is literally impossible. Um, there, there are huge books in psychology on how difficult it is even to define what a piece of furniture is.

Um, humans just don't agree on that. If, if you're curious, uh, to ask yourself whether a clock is a piece of furniture, if you ask 10 friends, five of them will tell you one thing and five will tell you the other. Because humans don't define things that.  So the thing you need to do is get your cycl time down.

Cycle time is the period between when you, uh, uh, begin to work on a thing. When you say, I'm really gonna do this, not it's just kind of in my backlog somewhere, but it's here. I'm gonna work on it. It's the next thing we're working on, next thing we're gonna do, and the time when a customer sees it, and ideally that time would be one day. 

So the moment you think of it, you go, Hey, customer, what do you think? This is why, by the way, small startups are so incredibly productive because typically there's somebody who's a customer representative working right there. It's typically one of the founders. Often it's the C T O. So they can kind of ask themselves, well, would I want this?

Well, I'd want that. Okay, I'll do that. And so they go off and do this activity and the cycle times like three minutes.  But even a much, much larger organization you can get to cycle times of a day, two days. Um, even in my biotech customers where they're building things that, um, uh, deal with, uh, medical, uh, items, uh, uh, uh, those people are able to do cycle times of two weeks, which is revolutionary in that world.

Fantastic. Must to be able to turn around something that has a medical implication in two weeks. . But if you can, you get this incredible feedback from your customer and you find out very often that exactly what you were, what you were defining so carefully, what you were estimating, what you were working out in such detail is complete rubbish

It's not at all what the customer wants and it's much better to give them a bad version and let them tell you what's wrong with it and get that out quickly than to get them a perfect version that has been thoroughly thought through and makes them totally happy. Cuz guess what? It never does. 

Yeah, a hundred percent.

You cannot make everyone happy, but at least.  I'm a fan of the agile slash lean models. You 

know, notice I didn't say agile or lean anywhere in that. So, so there are lots of people who are doing lots of agile things and they, I'm sure they're doing great stuff and the, it's very valuable, but their cycle times are two years. 

Yeah. The speed is, is, uh,  is, is 

because remember it's getting to the customer. They might say, oh yes, we finished our sprint and now here's our new piece of code and it's, uh, ready for us to add to the big pile that we're gonna release at the end of.  Yeah, that's a very common agile, a approach. And it, it's, um, not what I'm advocating here.

Uh, a fancy name for this actually comes from a guy named Alistair Coburn, who's, who is one of the agile manifesto signatories. Uh, and he called it, and I call it elephant carpaccio. You take your giant piece of, of code, your giant thing that you're gonna build, and you slice it into pieces so thin that you can see through them.

They're just tiny, tiny, tiny slices, but they all look like an. Everything along the way is a successful customer, shareable customer, valuable piece. And, and that's, there's an art to that, but it's not that difficult. Yeah.  

Um, another thing I wanted to ask you about, like you shared that you have a podcast yourself, so what's the theme of your podcast?

Well, that's a funny thing. Uh, it, it has a, uh, an odd title, uh, it's called Troubleshooting Agile. And that's because, um, the, my co-author and I used to teach courses in, in this direction where we'd help people with their agile teams. And, um, in fact, we talk about a lot more things than agile development.

Um, and, uh, we are not only troubleshooting things, we also have new ideas. But it's called that, um, a, a possibly better title would be the same as our book, which is Agile Conversations. Mm-hmm. , but annoyingly, somebody owned agile conversations.com when we got started. So, uh, now we own that. So agile conversations.com is ours, but, um, at the, at the time, we had to pick something else and that's what we picked.

Oh, okay. That's, that's good. Uh, by the way, like, uh, I will be sharing, um, The profile, I mean, link it in profile. I'll share the podcast, uh, link as well with, uh, my listeners and my viewers. Yeah, sure. Before we wrap up, and this is a traditional question that I start, I'm starting to ask every single , you know, guest on my show. 

What is your view on what's next in tech? Whether the hype of ai, whether it's the, I know that maybe you would not like it, I'm just   thinking maybe the no code revolution. So what's, what's your view? What's, what's your expectations about the next trends and uh, directions? 

Well, sure. There, there's just too many to keep track of.

The, the main thing that's going to happen is that people will keep coming up with crazy innovations. Um, the main thing that's driving all this, by the way, is just the availability of compute power. So we've made it really a, a, a commodity and it's never an issue anymore, uh, to, when I look at, uh, companies in, uh, due diligence, for example.

So I'm assessing for a, a venture capitalist, how the company is.  When I look at one of those, we're never considering, well, how can we get the, the fanciest servers, which machines, which, um, uh, um, uh, manufacturers are making the fastest machines. That's what the concerns were. In 2000, I remember sitting in a, um, uh, in a scalability center owned by sun. 

Rest in peace, sun, uh, um, uh, uh, and we were, uh, exactly tuning which sun servers we were going to use. We were trying to build our software so it could run as fastest. You would never do that today. You would just say, okay, Amazon or Azure, or whoever you're using, yeah, uh, go, go give me another virtual machine.

And if it's a little bit too small, you get another one that the cost is nearly zero and you, you don't care. Um, uh,  anything about it except, uh, how many CPUs, um, uh, you know, whether there's a gpu and.  . So, uh, that availability of compute is what's driving things like chat G p T because we can suddenly do 10 billion parameters, where previously you would've had to work very hard to get a cray supercomputer or something to do that.

Mm-hmm. , um, the availability of, um, what literally are supercomputers in our pockets now, so your, your phone can do more than those machines that I was working with in 2000, uh, which is astonishing. And, uh, uh, the no-code revolution comes from the fact that we all have computers and people understand how to use them.

So you can actually give people, say, a Shopify front end or a WordPress, um, uh, login, and suddenly they can create things that, again, in, in 1995, uh, would've taken, uh, a whole team a year and, uh, a data center and a huge investment. So, uh, it, it's really the ubiquity of technology, I think, and the, the, um, commodification of it that's driving all of these. 

Yeah. 

Uh, last thing before we close. I know that you run a community. Is that right? 

Very good. I'm glad you mentioned that. I was trying to think of a way to mention it just because I think it would be interesting to your listeners. Um, and that's called the Squirrel Squadron, and that's my initiative, is my way to give back.

Everything's free. Uh, um, it's not part of my, uh, my business or my consulting, although you can talk to me about that if you want. But, um, the community is all about getting tech and non-tech people together and having conversations and astonishing there, there just doesn't seem to be a community in which that happens very much.

Now there are lots of tech communities and there are lot. Um, operational communities and founder communities and so on, but people who come together like that just doesn't seem to happen. So I run free events every week. Uh, I run, uh, a forum on which people ask, uh, pro probing questions about all these tech trends we've just been talking about.

And low co we were just discussing low code last week, um, and, uh, uh, do lots of other events and activities that are related to that. So that's at squirrel squadron.com. Uh, and I'd love, uh, for your listeners to check it out and come join, uh, come to some events if they'd like. 

Yeah, sure. I will be also sharing that link.

Um, thank you in, in both the episode details and on the YouTube details as well. Quill, that was a very nice conversation. Thank you for.  Jumping in today for this episode and happy to, it was fun. Yeah. So thank you  everyone for watching us. If you are listening from your podcast apps, thank you for listening to us today and we will be again together in another episode of the CT O Show with Mamed.

And until then,  we'll see you. Bye-bye