Having a Good Tech Strategy – Digital CxO Podcast EP99

Hello and welcome to the digital CXO podcast. I'm Amanda Razani. I'm excited to be here today with Douglas Squirrel.

He is of Squirrel Squared Limited, and he's an author and a tech consultant. Hello. How are you doing?

I'm doing great. And you know, it makes me sound, uh, awfully, uh, fancy and important to be called to be, uh, the leader of Squirrel Squared Limited. The thing I gotta tell you is squirrel squared limited consent in my life.

So, uh, it's not like a massive enter enterprise. We're, we're here in my 600 year old house, which is our headquarters. Well, awesome.

I think that's so neat. So can you share a little bit about your background with our audience and a little bit about your company? I certainly can, and they're gonna be the same thing since the company consists of me, my wife.

Um, the, uh, background for me is that, um, I, I was a CTO VP of engineering, all those kinds of titles for many, many years in a series of companies. And I kept getting fired in the nicest possible way because, uh, a board member or a founder or somebody like that would come to me and say, squirrel, you built this amazing team and they have a super process and they have a great leader. You've trained and they have really good processes and tools and everything else.

And gosh, you know, 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? And it was this really nice feeling to have to get fired that way. But when it happened again and again, I said, you know, maybe I should plan for that.

And that's when I started the company and started doing consulting first as a fractional CTO. So I'd work with multiple companies, uh, at a time, but for two, three days a week being essentially a, almost a, a, a part-time employee. But then, um, as I, uh, did more and more of that, I kept getting faster.

'cause I noticed this also that I kept getting fired faster too, that it would take me a shorter time each time to, uh, sort of start out the team, get things running well and get out of the way. And now I do that for six or seven or eight clients all at once, um, on a very, very limited basis so that I don't need very much time with the team at all to have a significant impact. And, uh, I've gotten to do that for about 350 companies on every continent except ITAR Kai.

Wow. Well, sounds like you made a great decision there and now you're able to use all your amazing skills to help others Help. It is fun to do.

And the the key is, uh, conversation and people. Absolutely. Well, you wrote a book, which I'd like to hear a little bit more about, and that's called Squirrels Tech Radar.

Yes, there it is. So, you Know, book book is kind of a strong word, right? It's pretty short booklet.

Share a little bit about this with our audience. What is it about? And we'll go from there.

Excellent. Well, often people will come to me and they say, just tell me about my tech team. I can't figure out what they're doing.

They're kind of hidden over there. Sometimes they speak clinging on to each other. You know, I really don't understand what's going on over there and I'm spending an awful lot of money on it.

And so I do these, excuse me, evaluations for, um, venture capitalists, for investors, for the company itself, for the board, um, for, for different audiences. But I'm always looking at a team and assessing it quickly. And the secret to doing that well is not to ask more questions or read more code.

It turns out, and I got good at this, I've done it about 150 times. And, uh, when I sort of realized what the process was, I said, you know, lots of this someone could do without being technically minded themselves. So these people keep asking me what's going on in my team.

I could write down for them what they could do, and that's what's, uh, in the booklet, and it didn't take very long, right? So, uh, that's, uh, why I wrote it and, uh, I'd love to tell you more about how it works. Wonderful.

Well, so you're a person to speak with when it comes to technology strategies and technology implementation. So my first question would be, when it comes to having a technology strategy, who should be involved? Uh, all the same people who came up with your company strategy, because in fact, your company strategy is no different in, in form or in content, really, from what your technology strategy should be.

I mean, think about this. If you come up with a marketing strategy, are you going to ask sales? I think so, right?

What are they, what should they market? So we get good leads? And if you're smart, you're probably also going to ask customer service what kinds of people actually buy our product and where should we go look for more of them, right?

And you're also going to ask your board of directors, Hey, what direction should we go? I mean, if we're headed into China, we might wanna find some Chinese people and market in Mandarin, right? So, uh, the difficulty is that, um, uh, often people think technology is a special language.

It's a special different world in which you have to do things a particular way. And, um, if you don't speak clinging on and know all about Star Trek and and know, know all these geeky, uh, kinds of things, then you're gonna have a lot of difficulty. Now, the, uh, truth is actually, you don't need to know any of that.

And if you start with your company strategy and you really get that clear, you can apply a lot of the learning and the ideas and the methods, uh, to your technology strategy, and in fact, they're gonna look very similar. Wonderful. Good to know.

So next up, when it comes to implementing good technology, what are some of the key things business leaders should consider? Well, the first one, as I was saying before, is your people. So, um, if you have folks, now I'm joking about Cleon, although I actually have had people that answer, answer zoom calls in Cleon to me.

And I, I get very confused. I don't speak it either, but, you know, super duper geeks are wonderful to have in the corner doing their own thing. And, uh, you may not have folks who have that much difficulty with communicating, uh, in a non-technical language, but most of us do.

Most engineers kind of speak the special wizards language. And so one of the key things you want is for people who are good at translating, you don't need everyone to do it, but you definitely need to have an understanding of what the business value is of what they're doing. So if you've got people who can explain that to you, even if they can't explain quite what they're doing in a comprehensible way, we'll talk about that.

That's the first step. Now, I can say a lot more about it, but that if you had to do only one thing, that would be it. Have a great translator, have a great understanding of the business outcomes, and have them be accountable for reaching those outcomes.

Communication is always key, and that is a difficult issue for many companies. So how do we improve upon that communication and, and find that good project manager to kind of lead? And I wouldn't say it's necessarily a project manager surprising, although many project managers are great at this, there's nothing wrong with that.

But it might be someone with a title like product manager, technical lead. It might be the the intern who just showed up and is so confused by what's happening. They asked a lot of questions.

And that's the key thing, is it's really important to ask as many questions as you can and not be shy about it. You know, another thing I have, I'd be happy to send it to your listeners if they want. One, is a certificate that I just sent to someone.

Like he was opening it and he was very excited about it. He sent me a video. Um, this certificate is official, you know, has a gold seal, my signature, you know, it's officially, uh, issued.

And it gives you permission to ask technical people questions, even dumb questions, like, why are you doing that? Or when will it be done? So, uh, you know, I I really feel so strongly that it's important to ask those kinds of questions.

And one of the things I talk about in the booklet is what kinds of questions you can ask. So for example, you might ask, how quickly do we get feedback from customers? Because frequently people will say, oh, yes, well, we release our software once a quarter on a rigid schedule, and then we kind of hope that people tell us whether they like it or not.

That's a really negative sign. The very best teams release new software every single day, and they hear from customers whether the work they did in the morning was actually valuable in the afternoon, and they can throw it away and start again tomorrow if they realize they're doing the wrong thing. So that cycle time, that speed of response is another really good signal, and that's a great one to ask about because you can ask about it as I just did with you in non-technical terms, right?

You don't need to be a, a, a fantastic expert in, um, uh, uh, obstru, uh, techno babble in order to understand. Yeah, it usually takes us about a month and you can say, great, what would it take to get to a week? And suddenly we're having a useful discussion about getting business value.

That's very different from the kinds of conversations your listeners probably have most of the time. What are some other key metrics business leaders should consider? Uh, let's see.

So, um, one to look at is, uh, uh, how much the, um, engineers know about what's happening in the, the production system. So when the software's operating, do they, uh, wait until a customer phones them to say, Hey, wait, I can't log in. And that's another question you can just ask them, and you can also observe it.

How many kinds of bugs do we get? What kinds of responses from customers? Are we on things right away?

Do the co the engineers come and tell us we have a problem, we know what we're doing about it, here's the, uh, mean to their, their expected time together. Uh, uh, an, uh, an answer. If you've got that kind of active monitoring and operational information, you're doing pretty well, and they could actually show you graphs and charts and talk you through them.

Another is that, uh, uh, you can actually look at the code that they're writing of a particular type. And this co code that they're writing, they should be writing. This type of code is called a unit test.

And a unit test just takes a little piece of the software. It might be the part that just, you know, in Zoom, it might be the part that lets you, uh, leave the meeting, right? So there's a button on the screen that says, leave meeting.

I'm not gonna do that right now, but if I wanted to test that, I would, uh, I could actually physically go and move my mouse and, and click on the button, or I could write this thing called a unit test. And what they should be able to do is, again, talking through it, creating a conversation again, and you say, I'd like to look at the code. Oh my God, you wanna look at code?

Oh my, Amanda, how could you possibly just don't worry, just show me and, and tell me what each piece does. And first of all, tell me what the tests verify, what do they test? You know, I did this with, uh, a client of mine who does a safety, um, checking.

They, they actually look at video and they tell you when there's a safety issue. Very important, right? High quality, uh, high high value stuff that people really want to buy to keep safe and get warnings about problems.

And, uh, it turned out that there were tests that actually used video that you could watch. So I said to the non-technical people who were wondering, Hey, what's, what are those guys over in the corner doing? I said, go watch the videos, then you'll know which things they actually support, what kinds of problems and errors and difficulties show up on the videos that are actually in your software.

And if it's not there, don't delete it. Now, some of your listeners might go to us, their engineers, and they say, oh yeah, tests. You know, we kind of, kind of know we should do that.

Yeah, we haven't been doing that, which is kind of like not going to the gym, right? You're likely to get a little fat and not so healthy, and you know, the doctor's not gonna like you when you see that. So that's another great answer, at least, you know.

And so you say, great, could you write some? And then how about we look at them on Thursday? So again, you're having this non-technical conversation about a highly technical activity.

And you know that just like if you, uh, you know, you wanna win a marathon, you better start by running a few miles every day, right? So it's the same sort of thing where you can check on the, uh, outcome and you can actually read the code. I talk about it in the booklet of how to do that, uh, and you can get information about what they're doing in the same way as those that, uh, company could look at the videos.

So those are a couple of the key metrics. There are six in total, and they're in the booklet. Uh, and they're all that simple.

You know, nothing is, uh, uh, abruce. You don't need to go to school. You don't need to learn, uh, ones and zeros and binary code and all that kind of fun stuff.

But you don't have to have all those high level skills. No. And, uh, that's surprising to people because what they often say to me, and that's why I send them that certificate I showed you, is, you know, I, I shouldn't ask these questions.

I wouldn't understand the answers. It wouldn't be helpful for me to go in there and start asking my team questions. Nothing could be further from the truth, right?

You wouldn't say, oh, uh, those folks in customer service, they have special knowledge. You know, they know how to answer phones and I'm not so good with that. So I won't ask them any questions.

I'll just, uh, kind of wait and see if customers complain. No, you go over there and say, show me your scripts. Show me how you onboard people.

Show me, uh, you know, let me listen in on some calls because you want to know if you have a customer service problem. Same thing in tech. You just have to get over that, um, kind of recalcitrant and, uh, that's the sort of thing I can help your listeners with.

When it comes to implementing any newer technologies, and we're seeing quite a few of these days, including ai, what advice do you have for business leaders as far as getting people on board and agreeable to using that new technology? Uh, don't do that. And the reason I say that is you don't wanna get people on board with using new technology for new sake.

There's some reason you're considering adopting ai, and it's usually in their interest as much as it is in yours. For example, um, I, I was just talking to some folks in New York when I went over to visit some of my clients and, um, and, and, uh, people in my community, uh, uh, and I was talking to them about adoption of ai and they were saying, you know, we're thinking of adopting it in lots of our different organ parts of our organization, and people are nervous, they're scared that it's gonna take their jobs. And I said, you don't wanna let a robot answer your phone calls.

That's very dangerous. As we all know. It sometimes makes things up that even worse.

It's terribly boring and you don't like it when you get a robot answer to your email or you have to talk to a chat bot. You wanna talk to a human being. So what you want is to augment the people in the team with the skills that the technology brings.

And guess what you're doing there? You're making better responses and you're making them more efficient. Well, that's what your team should want to do.

They don't want to answer routine questions. They don't want to deal with, um, uh, boring situations that a bot that a, uh, a machine could do for them. Instead, you, uh, describe it to them as a movement forward in your drive for efficiency.

And one of the things you're gonna try with their help is giving them new tools that could help them with that. And if you do that in that, uh, the fancy name for this is joint design. I talk about that in my, in my thicker book called Agile Conversations.

I if you have that kind of conversation with them that, and you're not selling the technology for the technology's sake. You're describing how the technology might help you solve a problem and enlisting them to help you evaluate. Wonderful.

Well, one key reason that business leaders would want to implement new technology is they expect to see some sort of return on investment. This can be difficult. So what are some tips you have as far as tracking that return on investment?

You want to see actual delivery, same. Uh, you know, if you look at your operations team, it might be that they ship packages or that they, um, uh, answer customer questions, whatever they do. Um, you would be looking at those metrics of what the outcomes are.

Guess what? Your technology team has the same kind of metrics, but they're metrics of actual things you can see. And if they, you go to them and they start talking about abstract things like sprint, uh, goals, velocity, and um, you know, lines of code written and so on, that's the wrong metrics.

That would be like your, uh, customer service team saying, we're gonna, uh, tell you how many phone calls we answer. Now you don't care how many you answer. You care about how many you actually solve, right?

I could answer 'em all day, but I couldn't answer the questions. That's the key thing. So, uh, the metric to hold your team to, the key one is, uh, how much are they shipping?

And like I mentioned before, the very best teams produce new things. Now it's very small, new things. They produce visible outputs that somebody can measure and say, yeah, we're on the right track.

Or, oh my God, that's terrible every single day. And if your team's not doing that, they're probably in trouble to one degree or another. Uh, and even, you know, you might be in a highly regulated industry or in healthcare or something like that.

My biotech clients release every two weeks. Now that's lightning fast in the biotech world, right? Where they're building medical devices, you have, uh, got huge safety and compliance concerns, but guess what?

You can get round those. You can get to the point where you get meaningful feedback very, very frequently. And that's something you can then look at, well, is this on track?

Does this give me the business value I was expecting? It might be only a tiny piece of the movement in that direction, but yes, I can see how we're going to be translated into Chinese by, uh, next quarter because we have the first two pages already done. And it look, that's Chinese.

If you just have some graphs and charts and some burn up things and other stuff that the engineers kind of snow you with, you might have nothing at all a quarter from now because they don't produce anything that actually works. That's the metric to hold them to. All right.

Well, if there was one key takeaway you could leave our audience with today, what would that be? Ask questions. It's so great to ask questions.

If you do it in an open and interested way. If you ask what are called genuine questions that really, uh, uh, invite the surprising answer, like, no, we're not actually trying to translate into Chinese, what are you talking about? That would be great to know 'cause you're busy flying to China to get your business expanded over there.

That's the kind of thing that, uh, really supports your team. It makes the non-performers really nervous. Good, because you don't want them not performing.

And it makes the high performers feel cared about and included in the company strategy rather than being separated off into their special IT department that, um, is just a cost center and has nothing to do with the output of the business. Typically, those folks should be moving the needle more than anyone else. You're paying them more.

All right. Well, thank you so much for coming on the show and sharing your insights with us today. Fantastic.

Glad to be here. com. Wonderful.

Well, thanks again. It was a great conversation and thanks to our audience. Stay tuned.

There's more.