Software is so intrinsically rewarding that many people write programs just for the joy of it. The best engineering teams bring this excitement and sense of fun to the workplace—and when you have it, your developers are motivated, creative, and profitable. Join me on this livestream to find out why and how to harness fun for your tech team!
Join the Squirrel Squadron now to get access our live weekly events, weekly email and exec forum!
Here’s the transcript:
DS Is it on? Oh, yes, it is amazing. Usually it takes longer than that. Hello, folks who are here for the Squirrel Squadron event on having why you need to have fun in your technology team and why that's a reason that you're going to make a profit from them. So, uh, I hope, uh, everybody can see and hear me okay. Um, my, my swell community manager, Laura, will tell me, if not, we'll give people a moment or two to connect and figure out where they are and, uh, be startled as Laura was by, um, uh, me appearing as they, uh, as they log on and, and connect. Um, uh, I will note that this is recorded. So, uh, if you can't stay for the whole thing, that's great. You can always come back here to wherever it is that you're, um, uh, watching this and, and listening, uh, on that, uh, same, uh, uh, location In that same, um, uh, URL you will find, uh, a full recording of this event.
So don't feel you have to stick around, uh, in order to, to get all the value from it. And you can also tell your friends, uh, speaking of telling your friends, uh, this is in case you don't know it, the Squirrel Squadron. So this is a group of, uh, thousands now of, uh, fantastic folks, uh, around the world, uh, who get together once a week like this, uh, to discuss interesting topics. And, um, uh, it also includes a forum where we're always, uh, bringing up things and, uh, arguing and discussing and debating, um, the forum we had, uh, what did we have? Um, I just had the list up here and it went away. I just wanna note for you what we've been discussing, 'cause it's been some pretty cool stuff. Um, oh yeah, why you should stop hiring engineers. 'cause you don't need more of them.
Instagram was getting by with, uh, three, uh, I was just, uh, hearing that, um, mid Journey has a similar number. So, uh, you don't need as many engineers as you think. Um, uh, we were talking about Startling software. What's some software that surprises you and, and changes your mind and, and amazes you? Uh, so we're talking about all kinds of topics like that. Oh, centaurs, while you need, uh, half Horse, half Human in order to make your AI most effective, uh, I can explain more about that if somebody's curious. That's all on the Squirrel Squadron Forum. You can join that at squirrelsquadron.com, as well as sign up to more of these events. Uh, we're doing things like, um, uh, holding, um, uh, uh, these events, uh, every week. Um, there's a, uh, live stream with Colleen Francis, an internationally known sales expert. And we're talking about ai, speaking of AI and sales, why, um, people are using AI wrong for sales, uh, and what they can do about it.
We are talking about, um, uh, um, uh, why you, you, uh, what testers should be doing. So in your tech team, do you need testers? What should testers do? How do you find testers who aren't zombies? Uh, 'cause that's one of the biggest problems with testing. Um, and then I'm live in London, so this is my first, um, time announcing that, that's mid-November. Uh, it'll be up on this, uh, it actually is up on squirrel squadron.com now, uh, I believe. And, uh, so you can sign up to that if you're in London. Uh, and you'd like to come along and talk about, um, uh, how to measure your tech team. So what's on the radar? This is a technique I use called the tech Squirrels tech radar, uh, and how to measure really quickly, uh, how your tech team is performing. So, uh, that's my little advert.
DS Get everybody settled. I hope everyone's sitting comfortably, 'cause I'm gonna blow your mind with, um, some new ideas about, um, uh, why your tech team should have fun. Um, would you mind, uh, just popping into the chat of wherever you're listening to this and just saying hello and what brought you here? What's interesting to you? What questions do you have? Uh, what was provocative about this for you, or, or what do you disagree with? That would be great. Uh, and feel free to do that all the way through, as many of you know, who see me regularly, um, not usually sitting in front of a bookshelf like this in North Carolina. Normally I'm in England. But, um, uh, when you see me regularly, you know that I interact, I do better with, uh, uh, interruptions, arguments, debates, questions, uh, and, and we get more from it.
Of course, this could also just be a short, uh, uh, shorter, uh, event. And, uh, I'll just talk to you about all the cool stuff that I'm excited about that'll be fun for me, that I think we'll all get more and we'll learn more, uh, if you bring up some ideas. So go to the chat, type something there that tells me what brought you here, what's making this interesting to you. I can see that and comment on it. Um, so although I can't hear you, I can definitely listen to you, right? So, um, uh, as you see, I'm, I'm in a different location. Hi, Simon is here, of course, Simon is here. Uh, uh, wonderful to see you. Uh, and he's here to learn. I'm glad to see that. So, uh, I'm in a different location. I'm visiting family in North Carolina. Uh, and so I don't have my normal 600 year old house background.
Uh, that's because my 600 year old house is being taken apart and put back together. So there's <laugh>, lots of holes in it, and, uh, people are filling up those holes frantically now, uh, and I escaped from that by coming to North Carolina. But if I look a little bit disheveled as well, if I look a little bit, um, you know, tumble dried, uh, that's because I took a nap before having this, uh, stream with you. And I, I did that in order to make sure I was fully relaxed and having fun. So, uh, I want you to know that I live, uh, by these values. I do these things. And, um, now I'm not necessarily saying your team should, should have a nap. I'm gonna talk more about that, um, about how that progresses and where the balance is. Um, we did a very nice poll on the, on the forum.
Speaker 1 00:05:16 Thanks for those of you who participated on, on, on how Relaxed is your team. But the crucial thing is that if your team is looking all stressed out and worried, and manic and panic, that's not going to be good for lots of reasons beyond morale and retention. So, um, you're, you're not gonna hear me say a lot about morale and retention. Of course, that's important for any team. But in knowledge work specifically, there's some real benefits to, for example, being well rested. And my day started at four 30 in the morning here in the, uh, North Carolina because I was working with a client, um, uh, uh, in the uk. And so I got up early to work with them. Uh, and, uh, if I had not had a nap first, uh, you would not see the energetic, um, having fun squirrel that you, that you do.
And that's the sort of thing you should be seeing from your engineering team. Uh, so we have lots of comments from people saying why they're here, which I really appreciate building a new dev team. Want to learn how to make dev fun and make it more efficient. Excellent. Uh, Jim, an old friend, um, uh, give a lot of technology freedom, which might affect productivity. A haha. Okay, Jim, I want you to keep me honest here. Make sure I come back to that one. So it's a super point that I don't think is in my notes, um, is, is how do you make sure that the team remains productive and focused on the right outcomes without, um, uh, stifling their creativity? So, really good point. Thank you. Uh, so I never see the names, uh, or some of these, um, chat things, don't tell me. So a mysterious, anonymous person says, um, that <laugh>, they're in Charlotte, North Carolina.
Hello. You're down the road. I know. Come, come, come visit sometime. Um, uh, increase the level of fun in the team that they've just recently joined. Excellent Roland, old friend, uh, always here. Um, uh, interested in developer productivity and measuring it. So Roland, you're in London, so you should definitely come to the London event, which is all about measuring. Um, here we can definitely talk about productivity. So you and Jim, you keep me, uh, keep me honest that I make sure to cover that. And Adam says, uh, how to create high performing development teams and other types of teams. Excellent. Um, because, uh, it's not only software developers who have the level of complexity that I'm about to talk about. So I'm gonna talk in, in, um, in terms of technology teams. But, uh, Adam, you helped me remember that I should also talk about data teams, about customer service teams, about people who are doing complex, um, enterprise sales, um, where there's heavy levels of knowledge and complexity.
All of these, um, comments are going to apply. Wow, we have so many people, uh, Dmitri also, oh, wonderful to see Dmitri, very old trend, how to drive and shape this in the wider team. Excellent, because, um, you're gonna like the story I'm gonna tell later about chess. So, uh, listen out for that story. All right, great. So, um, let me start with, um, an old joke. Um, which many of you will have seen if you've ever watched a wonderful program called the IT Crowd. And these, um, uh, the, it's kind of the prototypical, stereotypical, uh, engineering team in the basement, literally, of a building. And, um, they're dealing with the IT issues and the software issues and so on, and lots of humorous things occur down there in the basement. One of the key things is that they, uh, always answer the phone the same way.
<laugh>, they pick up the phone when someone phones them with a, an engineering problem, a software problem, uh, and they say, uh, have you, uh, hello it, have you tried turning it off and on again? Now, you have probably noticed that often US engineers, we tell you, try turning it off and on again with your phone, with your, uh, car, uh, you know, sometimes my car, when I get it started, it, it has a, a one of those beautiful displays that shows you where you're going and, uh, you know, what the temperature is. And, uh, where, you know, if Mars is an ascension, I dunno what it does, but, um, uh, it does these clever, amazing things. Sometimes it doesn't turn on and what's the solution? Turn the car off <laugh> and turn the car on again. And that gives it a chance to, to actually start up correctly.
DS 00:08:59 Now, this seems like it's a bug. This seems like it's a failing of us engineers, that we should build software, uh, that we should build tools that don't require this turning off and on. Again, thing it seems goofy, right? Um, when's the last time you had to turn off and on again? I don't know. Your, your coffee machine. You might have a very smart coffee machine. I think they're very clever now. They, they have computers in them, but, um, you know, when's the last time you had to turn off and on again? Um, your shovel, right? Uh, would, would we, would we use, uh, bricks that had to be turned off and on again before they could form a wall, right? Simple machines that have, um, uh, predictable states don't need this. But, um, there's this, this, uh, the reason for the humour, the reason that this is a funny thing in the it crowd, I'm killing the joke here by explaining it.
But the reason it's funny is because it's un it's unusual, it's different. It's not how, um, we're used to physical objects that we work with, uh, behaving, uh, that they require this off and on again, thing. But here's the secret. Uh, and this'll be kind of in intuitively evident to engineers and maybe not at all to others. Um, I always try to make sure it's clear to both audiences. Um, uh, we are building when we build pieces of software, the most complex machines that human beings have ever created. Um, now here's another place where I have to be clear. Um, in the Britain, we have Heath Robinson. And in America you have Rube Goldberg. These are both people who made drawings of extremely complicated machines. You've probably seen the kind given you don't know the people. You know, there's a fan that's running and it blows a ball, and the ball rolls along.
And then a cat is surprised by the ball falling on a, a plate. And so the cat jumps up and then it lands on a mattress, and that makes some, and on and on and on. And eventually then it turns on a light or starts the, the, the mower or something like that, and does some very simple thing in an extremely complicated way with all these different pieces, those machines. And, uh, their, of course, their humour is all from their incredible complexity. Those are super simple. Those are as simple as a shovel, uh, compared to the pieces of software that we use that are very simple ones. So, um, a very simple piece of software, um, that, that really doesn't do very much like your text editor, right? So you might bring up notepad or, or word pad or something like that, and it's just got a, a box and has a, a space, and you can type in some words.
You, you think that that might be very, very simple and not have a large number of states. In fact, the number of states you can get even a simple piece of software into vastly, vastly exceeds the, um, uh, the, the number of states in the complexity of any other machine ever built by humans. And when we think about all the moving pieces that are, uh, connecting me to you, here I am in North Carolina, people around the world are watching me on video. Uh, and that has huge amounts of complexity and co collaboration among, uh, uh, bits as diverse as the chip inside my computer that is handling the video and the firmware inside it, and the micro code that's, um, executing the, the software that takes my video and sends it out, all the machines in between us that are sending their messages back and forth to each other and doing so robustly.
You know, that that system, the internet was designed to, uh, withstand a nuclear war. So it's, uh, you know, rerouting itself all the time and doing very complex things just to get the information to you. Um, and then there's a, a complex video, um, uh, service and audio service onset your computer that is showing me on the screen to you. And we see this as simple. So we think of this as, uh, well, gosh, I just turned it on, and I certainly, I didn't think about all those pieces when I turned this on and got going with you a couple minutes before this stream started. But those, um, steps, all those pieces have to work correctly and be in the right state. So, um, uh, engineers will know about things called state machines. Uh, don't worry about it if you don't know that concept. But the idea is that, um, uh, uh, a any piece of software, any com, any, um, uh, uh, piece of code that's running, um, can be in many different states.
It can be, let's take that simple, um, text editor. It can be in edit mode. It can be in save mode. It can be, um, showing you the list of, uh, documents you can open. It can be, um, changing the format. So those are just a few of the states it can be in. And then of course, there's all the input. So it might be that you have one line on the screen, or you have a hundred lines on the screen, or the screen is blank, or the screen has, uh, Japanese on it, or the, uh, the screen has, um, pictures in it, maybe that particular piece of software, let to insert pictures. So when you add each of those, there's a geometric effect. In other words, each of those states can operate with each of the other states. And so you, you know, you can have lots of text and your saving and, uh, the text is, uh, right to left language like Hebrew.
And you think of all the possible options for each of those, and those multiply together. And so you have this huge number of, um, uh, states that the, the, um, uh, system can be in. And the problem is that it's physically impossible to test all of them. So in many cases, it would take more than like the age of the earth to actually exhibit, uh, um, get into each of the possible conditions. Now, engineers are very clever, and especially testers is what I'm gonna talk about in a couple weeks. Testers are particularly clever at finding the really tricky ones. And they think, aha, if it's right to left language and I type one more character, that takes us over to the next line, it might not know to go around to the next line. It might go around the wrong way. So I'm gonna type one whole line and then one more character.
And they know how to do that kind of clever stuff. So they get into one of the states that could be a problem. But what happens when very frequently, you know, I had a problem, um, just now when I was trying to get on a call before this, uh, where Google Meet, uh, just wouldn't open, just wouldn't, uh, it was no Google Calendar wouldn't open. So I couldn't get into my Google Meet event, and it just, it was in a funny state, and I know what I need to do is restart my browser, which I'm gonna do after this, um, because it'll get into a better state. And it's been in one of those states that the engineers who built that browser, who built Google Meet and so on, did not think of, they didnt come up with it. And so, um, when I get it back to its original state by restarting, that's when I, um, uh, effectively, uh, get into a state that the engineers actually knew about <laugh> that somebody cued for.
And it's a recognised state. Um, so you could, uh, uh, think of it. Uh, another place you've probably encountered this is in games of any variety. So you've played any kind of game, like Alders Gate or, uh, I don't know, um, uh, uh, what's the Tom Clancy one? I can never remember. Um, you know, uh, uh, there's a whole bunch of different ones. Call of Duty, uh, these sorts of things. Um, if you've played any of these kinds of games where, um, you know, you can move something, uh, person around the screen and shoot at stuff or, or, uh, talk to people or whatever it is, um, you know, that there's, uh, funny little glitches and, you know, you kind of get in a corner and you can't get out and you have to kind of jump in order to get out and other sorts of things.
That's because again, there's many, many places your character can be, many, many things. It can be saying or doing many different weapons. It could be carrying, uh, you know, the number of things that can happen all at once. So they all multiply together, is more than any tester could possibly, uh, exercise. And the game's still fun anyway, just like I managed to get into my meeting one way or another. I found the link someplace else, and I got in, um, uh, and, and I worked around it, and I still had a really great meeting. Um, so what's the point of all this? What's this have to do with fun? Well, the point is that, um, uh, we are building incredibly, incredibly complex systems and to, to Jim's and, um, uh, I think it was Adam's point. Um, we, uh, we want to watch out for as Roland who was saying that, I think.
DS Um, but to those points about, uh, this matters for non-tech teams as well, um, the, uh, uh, they're, because we're tech enabled, now, many other groups can get into these complex states. So it used to be that customer service people who answer the phone and talk to them, maybe they'd look something up in a book, but now they might have an AI assistant who is helping them get more of the information. Maybe there's a complex, um, phone tree that happens before the customer service person answers. Um, and that's part of the system that gets the person to the right, uh, agent who can really help them. Um, and all of these pieces have their own states. So you have the human who has certain number of, certain amount of complexity to start with, um, and then all these, um, uh, associated systems that go with them.
And so, uh, that leads to huge amounts of complexity. And my point is, if you take nothing else away, I know I've spent a long time on this complexity point, it's because I want you to remember that people who are operating in a complex system like this need to be relaxed and comfortable and thoughtful. And, um, if you get them, uh, really, uh, frazzled and, um, frantic and, um, uh, operating, uh, right at the edge of their capacity, they are not going to build good, robust, uh, competent systems. 'cause they need to creatively reverse engineer. Boy, it could be that the, um, call centre got the call, but it was just at the time when we were switching over to our system that we run overnight, and therefore, this call went to the wrong person. And because it went to the wrong person, then, uh, this customer is getting the wrong advice.
So I need to go and help that person. That might be the call centre manager, thinking that way. And, and that complexity, uh, and that ability to think, um, in, in creative ways doesn't come about when you're running at, um, at full capacity. Um, so I'm gonna talk a lot about those, um, uh, those methods, uh, in a, in just a moment. Lemme look. There's been a few more comments coming in, so I wanna make sure to cover those. Uh oh, somebody was having link problems on LinkedIn. Oh, no. Okay. But, uh, Simon says he's back. So good. Uh, I hope everybody's, I've seen comments on LinkedIn, so I hope, uh, all is working. Um, Simon says that LinkedIn was down globally. That doesn't sound very good. So, perfect example of, uh, excess complexity. Uh, LinkedIn was probably in a bad state, and guess what?
Somebody probably restarted a server in order to get back in a good state. So, um, if you're turning things off and on again, that's normal. It's also a signal that you should relax and help your engineers, uh, to be more creative to deal with these complex systems, right? So, um, let's talk about, um, uh, oh, I wanna tell my chest story, uh, 'cause that's relevant to the, um, uh, the relaxation point. So, uh, I was working with a client who, where we were tripling the size of the engineering team, we were just moving at incredible pace, and the engineers were handling it really well. Uh, we were expanding the market. It was really a buoyant time in this particular company's market. And they were taking over and doing really well. And, um, what the, uh, the, I got a very funny complaint. The complaint was from sales.
And the salespeople said, you know, we're really being annoyed by the chess. I said, the chess, what do you mean by the chess? What are you talking about? They said, well, you know, the engineers, they go have lunch. Well, we are busy on the phones. You know, we eat lunch with one hand while we're on the phone selling with the other. But these engineers, these lazy engineers, they go off and they have lunch, and over their lunch, they're playing chess loudly, and they're banging the pieces down. They're shouting, and they're, oh, yeah, isn't it fun? You know, we're having a great time, you know, beating you and, uh, let's, you know, Brooke takes night and whatever. He, let's, uh, let's win the game. So they were having these kind of raucous games of chess, if you can imagine, uh, and annoying the salespeople. And it wasn't simply they were being annoyed by the noise.
DS 'cause if, you know salespeople, they kind of like a noisy environment. They like lots of energy and activity and so on, says, yeah, yeah, the, the noise doesn't bother us. What bothers us is those guys being lazy. I mean, we need them to build the software. We need 'em, get the pieces out that we need in order to sell. And here we are working our fingers to the bone. And those developers, they're, they're, uh, having fun. Uh, there's something wrong with that. We're, we're not happy. And so I went and investigated, and I, I tried to figure out why the engineers were doing that and what was happening. And it turns out that, um, what the engineers were doing was actually doing quite a lot of work at home in the evenings. That was not visible to the salespeople, by the way. I'm not saying you necessarily need to do this.
Speaker 1 00:21:03 I'm just saying this is what those engineers chose to do. I didn't ask them. Um, and, uh, they, uh, needed social time, uh, to get, uh, uh, um, uh, collaborating well with their, with their peers. And they used lunch for that, which was a very effective way to, to build team, uh, coherence and communication and so on. And, uh, so they were relaxing by playing chess. And then that gave them more energy to be, continue being creative and continue to think up stuff and have good ideas at nine o'clock at night, and add them to the software without being exhausted. Uh, and this was actually very healthy. So I went back to the salespeople and I explained, actually, chess is gonna continue. This is actually very healthy behaviour. Um, because what we should be focused on is what's the outcome for the engineers? And this is a way that works for them of, um, having a, a good collaborative experience that builds their team, uh, bonding.
But not only that, it gives them the opportunity to relax a little bit, think about something other than code, still be very structured. So it was very structured thinking. They weren't going and playing racketball or something with different type of activity, could have been good, but they, they wanted to stay in kind of thinking mode, um, uh, complexity mode, um, thinking about, uh, the complexities of chess. But, uh, doing so in a different environment gave them a break from what they were doing. So, um, uh, it, uh, uh, an experience you might or might not have, but it's a very important experience. Uh, if you haven't had it, try to have it, it really can help you. And that is that you wake up from, say, a nap like I was taking before this, um, uh, this stream or, uh, uh, an overnight sleep, and suddenly some problem you had becomes much simpler.
You say, oh, man, I know what to do. That happened to me this morning as it happens. Um, I owe Laura my community manager. She's very patient with me. I owe her something, and I've owed it to her for weeks. And I, I really need to get it done. And I saw a way to simplify it. Uh, this is setting up a website for, um, working with investors. And I thought, oh, man, I have to make this complicated website. I make this page and I have to conclude all this stuff. And I had this simplifying idea this morning about how I could do an easier version of it, which I hope to do later today. I know Laura's watching She'll, she'll be glad if I get that done. And, um, that insight wouldn't have come to me if I had stayed up later last night trying to solve it.
Um, uh, and, uh, it was because I relaxed, uh, because I actually slept, and my subconscious was able to operate on the problem. And when I came back to the problem, I was able to solve it a different way. Uh, so this happens very commonly in mathematics, in computer science, um, uh, in engineering disciplines. I'm interested if you've had this experience, if this has happened to you, put it in the chat. I'd like to hear, uh, other examples, especially outside technology. Um, 'cause I, I know it from a kind of technical point of view, um, but I have the feeling that, um, many of you have had this experience, say with a, a complicated sale or a difficult customer, or, um, uh, looking at a, a marketing problem. 'cause I've heard people talk about those as well, uh, as places that they get inspiration. So what you're doing by say, having your engineers play chess, or by making sure they have some opportunities for fun, and that they are, uh, doing things that are, uh, give them a break from their normal work, is you're giving their subconscious a chance to catch up with the complexity.
Remember, we talked about the multiplying states and how complex the software is. Uh, one of the things your brain can do is make surprising connections. It's only gonna do that. You could go look up the neurology of this, right? If it has the right, um, uh, if it cleans out the acid, I forget which, uh, it's not lactic acid that's in your muscles, I forget. But the, there's, there's a cleansing process that happens overnight so your brain can think better, and it makes better connections between this side of your brain and that side of your brain. And it says, aha. Well, this solution with, I couldn't have thought of before, uh, is one we should try. So, uh, that kind of, um, connection and thinking and creativity only happens when your team is having fun, when your team has some level of relaxation. Uh, and I did a nice little survey on, uh, the forum.
Thanks for those of you who, who participated. And we saw like, half the people said, oh, people are pretty, pretty relaxed. It's, it's pretty good. Uh, they're, they're doing what they need to. They're, they're in the middle. Um, they're, uh, and, um, uh, some folks said, man, they're manic. That's frantic. Everything's collapsing. And, and my team is, uh, is frazzled. That's a team that's not gonna have these creative solutions. It's actually gonna be less effective. So, uh, you can, uh, hark back to the chess story. You can tell that to other people if you want, quote that, uh, liberally if you want. And, um, uh, the point is that you're going to help people make better connections, deal with the complexity better if you give them a chance to, um, have something that is fun, have some kind of break from what they're normally doing now, there's a way you can go too far.
DS This goes to Jim's point, um, about making sure people stay productive. Um, I've seen teams that are kind of catatonic <laugh>. They're so relaxed that, uh, they're not paying attention to what's happening in the business and in the market. And that's the other way. You, you don't wanna go, uh, too far. So, um, uh, that's usually pretty evident. It's not, it's not hard to diagnose. Uh, actually, one of the nice things about fun as a metric is it's pretty easy to to measure. You can see it on people's faces. You can see it in their behaviour. Are they playing chess? Are they running from one place to another? Are they frantically typing and panicking and, and causing bugs? Um, these are things that you can observe. Um, cata, cata, autonomism, I dunno if that's a word, but when a team has really gone too far in the relaxation phase, um, looks like, uh, they're, they're just so relaxed.
They, they don't feel any hurry whatsoever, and they don't feel any pressure to, to work on something. They're doing things because they're kind of interesting. And, and, um, that call that I had trouble getting on was, um, with an investor, had me look at a company, um, that is just a little bit that way. They're not too far. I've seen much worse. Um, but they're, uh, kind of academic in their approach. Uh, you often see this in data engineers, for example. So if you have a data team, you might look out for this. Um, they tend to be quite academic in their thinking, and you know, in academia, you have a certain amount of pressure to publish. Uh, I, I get that. Um, but the pace is very different from, uh, uh, your typical software team in any industry, whether it's a startup or a large established firm, software engineers are under a quite different level of demand from customers than, uh, say, teaching calculus or, um, uh, uh, publishing the latest, uh, research on, um, uh, uh, haemoglobin or whatever it is you might be doing.
And, uh, you can kind of follow your wishes. And when your engineers get super relaxed and they're not in touch with customers, uh, I call that, uh, the walled garden. Uh, you kind of have this beautiful garden with, uh, unicorns and roses, and everything's comfortable, and everyone's very happy. And they say, everything's just smooth here. It's really great for retention, right? This is why I'm not talking about, um, uh, fun as a perk, as, uh, something that you do to, to reward people or keep them happy, because it's very easy to fall into this kind of <laugh> unicorns and roses, and everything's happy inside. But outside, there's a, a, a nuclear war. It's, it's post apocalyptic. You've got, uh, angry customers, uh, uh, you know, chasing after customer service people and yelling and screaming, and sales are tanking and everything's horrible, but the engineers look fine.
DS Everything's okay. We're all very happy. Uh, we're doing what we're supposed to, we're following our rules, and, and everything's beautiful here in the garden, whereas outside, there's, there's a, a nightmare happening. So that's the, the thing to watch out for. Um, however, uh, I've only seen that, um, in, in a few cases where it's really pathological and it's really easy to diagnose. It's, it's easy to see. So, um, what you wanna do is you wanna get enough relaxation so your team is, um, able to make those connections, able to think clearly, able to collaborate effectively, uh, take breaks when they need to play chess at lunch, for example. But then also feel appropriate pressure from customers so that they're, uh, responsive to, uh, to, to needs. And they're, they're feeling that they's something they need to do and make progress with. And the fun is part of that.
The fun is in service of that. Excellent. Uh, let's see. Uh, Jim says we should automate turning it off and on again. Uh, so they don't, they don't require a creative solution. Absolutely. That's actually what the it crowd people did, is they, they made a little, um, they machine and it would actually answer the phone for them and to say, have you tried turning it off and on again? Um, so absolutely no question that, um, the mechanical bits, um, and this is why another good point. Um, Jim, when, um, engineers say they're automating something, or they're making their releases repeatable, or they're, um, uh, using infrastructure is code. There's all these different names for, for this sort of behaviour. And what they're doing is removing complexity, and they're automating the complexity and giving it to the computer. So, uh, any place you can do that, it's very valuable.
For example, we talked about the complexity of the, the bits and bytes, you know, passing over the wire to get to you. Um, there's not a human there directing traffic and saying, go this way, you know, change the package. That's all completely automated. And if there's a blockage, if there's a, a problem, LinkedIn, for example, is a couple folks we're saying, um, I, I should hope that the bit where it goes off and on again, is automated and there's something that says, Hey, server X is not working, turn it off and on again, and, and move on to the, um, to, to server y. Uh, so absolutely that's the right thing. And what you wanna do is reward your engineers for that automation. Again, coming back to this complexity notion that, uh, the com, the complex system requires taming. And, um, by automating, they're freeing up more of their brain capacity, uh, to, uh, to, to work on it.
DS 00:30:27 Okay, great. Uh, I'd love more questions. Google calendar was down. It was down. I see, okay. It wasn't LinkedIn. Alright. I, I was feeling very confused. Uh, 'cause definitely Google Calendar wasn't working, um, but it wasn't me. Excellent. Um, and restarting did help me. So, uh, uh, uh, proof that, uh, off and on again, definitely works. Alright, so, um, the next thing I want to talk about is, um, an idea called Slack. Now, there's a terrible thing that has happened with this word, which is it, uh, it used to have two meanings, and I had to give you a, a kind of a caveat of a warning, health warning about one of the meanings. Now it has three meanings, and I only mean one of them. So, uh, your engineer should have slack, and I do not mean, uh, the kind of slack where you put your feet up.
I'm not gonna try to do it here, but, you know, I put my feet up and I lean back and I think, oh, man, you know, nothing much to do around here, we're gonna be relaxed. That's the walled garden again. That's, um, uh, having, uh, that's being a slacker, right? Where you're, you're not doing very much and you're, um, uh, you're, uh, lying down on the job. That's not what I mean. Um, the new meaning, which I also don't mean, is this tool called Slack, um, which I actually think is somewhat counterproductive, and maybe we'll do another session on that. Um, that there's way too much communication. It gets very, it increases complica, um, complica complexity and, and communication challenges rather than decreasing them in many cases, if you used incorrectly. So I don't mean that, but I do mean the kind of slack you can get.
Now, do I have a cable here I can use? Uh, maybe I can, maybe I can do a, here I have a mouse cable I can use. So this doesn't have any slack in it, right? This is very taut, TAUT, um, meaning that it's, uh, very tightly wound. It's, it's, um, uh, there's no, uh, extra space in this, uh, in this cable. However, if I give itself a, a little bit more wiggle room, then I have more flexibility right here. I can't move it either the ends, any direction. I have to keep them like this. Here I have more flexibility. So slack in, um, your engineering team is very important because it makes room for, uh, this creativity that I keep talking about. Uh, when your engineers are, um, able to spend a little extra time, not a lot. So we don't want to go over into the walled garden, but when they're able to spend a little extra time exploring a different idea or reading about something that might help them, or, uh, experimenting with something, um, uh, we're gonna talk more about experiments in a second.
Uh, what, when they're able to do that, they're able also to be more creative, have better ideas for you, be be more effective when they're, uh, not slack, when there's nothing left. When they're taught TAUT then, um, uh, you're running at the edge of what they're ca capable of doing. And the sort of old Steve Jobs philosophy was always, let's push the team as hard as we can 90 hours a week and loving it. That was always, uh, the Apple philosophy and produce some, some reason reasonable results, but at huge cost. And I would claim, uh, with a, a lot of risk associated that wasn't necessary. And, uh, what I much prefer to see is a team that has a reasonable balance and in particular, does not have every minute of their, uh, sprint say, allocated to, um, uh, particular tickets. And if somebody says, Hey, wait a minute.
I have an extra hour at the end of the day here. What should I move on to next? Uh, you know, what could I get done? How could I push further? How could I get more done? I prefer them to say, what could I learn in this hour? What could I try? How could I do something a little bit different from what I normally do so then I can pick up something new and fresh in the morning? So that's the philosophy of, uh, uh, keeping slack in your rope, uh, but also keeping slack in your roadmap, uh, in your sprint planning, in your, uh, engineering, um, uh, the strategy, however you might put it, uh, uh, what you don't want is to fill it all up, because if you fill it up, one of two bad things can happen. One thing is, if something unexpected comes, you've got no room, right?
So if I'm pulling the rope taut, uh, I don't have any room to kind of get a little more and, and go further, I'm like, I'm full. I can't do anything more there. There's no more capacity here. And that's quite dangerous. If you have a new bug, if you have a new customer demand, if something comes in, you have no flexibility. And that's quite dangerous. The other thing that happens is your, your team and your, your, your team's brains, uh, are not able to function at that level of intensity, uh, all the time. They, they need the ability to relax a little bit, to be creative, to come up with something different. And, um, knowledge work is particularly susceptible to this. So, uh, if you, if you, uh, don't take breaks physically, right? Your, your body gets tired and lactic acid builds up in your muscles and you can't function as well.
The same thing happens to your brain. Uh, when you're doing intense complex work with these very large numbers of states in your state machine. Um, and you never take a break. You never stop and play some chess. You never do something fun. You never try something a little more experimental. Um, your, your brain functions less well. And I can definitely see that in many teams that I work with who are running at that very edge of, uh, of their capacity. Okay? Uh, no more comments. So I'm gonna keep blasting along, but I appreciate, uh, all the discussion and so on. I, I hope, uh, uh, Google Calendar is feeling better for all of you, and you can make it to whatever your next meeting is after this. But ask me more questions, bring up more, um, issues and concerns and questions and disagreements, uh, 'cause those are always very enjoyable.
Uh, now, um, a a key idea that, um, really comes along with a team that is having fun, uh, is the ability to take risks. Now, uh, we had a question. It was a few weeks ago. It was a really good question, and I think I, I tried to answer it in the forum. I, I'm happy to address it again. And the question was about what do, what do you do when somebody insists on having, uh, no risk at all? And, uh, this is not uncommon in, um, very risk averse industries. So, um, I work, uh, a lot in biotech and, and medicine. People really care about not killing people. That seems like an important thing not to do. And, and so, um, uh, you can have people who go too far and they become a complete break on progress. They say, look, we can't take any risks.
Nothing can go wrong. We need to make sure that this system is always up, that this software is always giving the right answers. Um, and so, uh, if we needed to triple check and quadruple check and quintuple check, that's good. And if anybody makes a mistake, they're in trouble. Mistakes are bad. We never want to make them. We want to make sure there are no errors. Now, if you're building a nuclear power plant, you, there's a certain element of what you're doing that does have this characteristic. So anybody building nuclear power plants, please let me know. Um, I'll give you a special pass. You're, you're allowed not to do this. Rocket ships, uh, a few other very, very high safety conscious areas of software. Yeah, we may need to, to be even more cautious. But actually, if you go into those environments, if you work with those, um, uh, types of folks, and I've worked not with nuclear power, but just some of those that, that really matter, um, you'll find that they do take risks.
Their, their attitude to risk is very different from, say, a startup with two people. And it's building a cat picture startup. That's one type. And risk, uh, profile is very different. But even in those high profile, high, uh, complexity, high consequence, uh, pieces of software, they are willing to take a few risks. They're willing to mitigate and be cautious, and think about it that they want to try something, try a new library, try a new, uh, coding style, try a new, uh, customer result and, and see whether it works and, and test it out in the real world. Uh, the problem is that, uh, we just don't have enough understanding of these complex systems to be able to predict their behaviour. So when we try something, we're doing an experiment, we're finding out whether, um, the, the, um, uh, the new user interface or the new login or the new, uh, security model actually works.
And really, there isn't a way to find that out, uh, other than, than trying it. So the danger is that if you scare the engineers, if they're frantic and frazzled and feeling under pressure and feeling that they must meet a, a specific deadline that's arbitrary from the outside world, um, and, uh, there's no slack, there's nothing that allows them to be flexible or have fun, then, uh, what they're going to do is not experiment. And I saw a great example of this when I was looking at, um, uh, a report that another company had done on an organisation that I was investigating. So I was, uh, interested in, um, uh, reporting back to, to an investor on, uh, uh, how this tech team was doing. And, uh, I noticed that in the report, uh, the, uh, the people doing the assessment had taken no risks whatsoever.
They hadn't really talked to anybody about anything challenging. They had used very standard off the shelf tools to assess the team. Uh, they'd really kind of avoided conversations. They'd mostly used desk-based, um, uh, statistical analyses to understand what the team was doing. And as a result, this was the most boring report ever, <laugh>. It just said, you know, they're using this tool, uh, they're using it in this way. Uh, that's an effective thing to do. They're using, uh, uh, they're building the software this way. Here's the number of lines of code they wrote. Here's when they wrote them. Uh, here's the frequency with which, um, uh, the, that that code broke and the number of bugs per line of code. And here are all the statistics telling you about the team didn't tell you anything. And, uh, when I reflected on that, I thought, wow, what, what, how do I think about this?
Because when I write these kinds of reports, I'm, I'm very opinionated. Uh, those of you who have seen them or been part of it, many of you have, um, know that I pulled no punches. And, and that's 'cause I'm willing to take a risk. Uh, for example, um, in that call, uh, that I was having with, uh, the investor, um, I had a different view of what the software did than the software company itself. I had a different way of describing its market, and that was a risk to describe it that way, because they said, squirrel, you don't understand this company. This is what this company does. It's not that. Uh, but we had a really productive, robust discussion, which helped us to learn a lot. And had I been afraid, had I not had fun, had I not had a nap, um, I would not have had the, um, uh, useful experiment of saying, well, here's how I see how this company functions.
And we learned a lot and changed the report as a result and, and other things as a result of having this greater understanding. So the point is that you want your engineers taking risks that com com, uh, appropriate risks, right? That you want it to be something that is an appropriate level of risk. Um, the consequences are mitigated so that you're not gonna blow up the world, uh, you're not going to destroy the company. But gosh, you sure do want to have some experiments that have a negative result. And I call that a successful experiment. Um, a a dangerous thing is to call that sort of thing a failure. Hey, we tried a new, uh, way of, um, uh, of paying. We tried a new payment page or a new payment provider, and, uh, we lost some sales, some people didn't buy because they, their payment page was down.
We had an integration with Google Calendar. Google Calendar was down. Nobody could book meetings through our meeting app or whatever it is. Um, and, uh, the, the thing is that if that has a, a, a consequence, you can survive. If it doesn't kill you, it's gonna make you stronger. So having that, um, negative, uh, result from your experiment might tell you, Hey, hey, wait a minute. Google calendar's not as stable as it used to be. Maybe we should be using something else. That's a valuable piece of information. You're not going to get that from a team that is feeling frantic and scared and like they're going to get beaten up for every mistake. So a key thing to help your team have fun in an appropriate way, is to use language like that was a successful experiment with a negative result. I'm pleased that you experimented that you tried something.
What did you learn from it? And how are we going to prevent it? That kind of language, that kind of culture encourages a level of fun that is appropriate. Um, and, and you can measure for that very easily, and I literally do this with the people who work for me especially, is to repeatedly ask, are you having fun? And if they're not sure, or they don't know, or they're not, don't know what you mean. Give them examples. I've been giving you examples all the way through here of where there's appropriate fun. That means that the team is able to relax, that they're able to have a little bit of slack and unlock their creativity, but stay connected to the customer and do experiments that are meaningful for them.
DS So, uh, I see a couple questions here, so I want to deal with those before we finish. Uh, Jim says, a retrospective tool formulated by a friend of mine. He said, uh, they use joy, accomplishment and learning as the three axes to measure. Well, that sounds great. Um, uh, a really good book, by the way, is called Joy Inc. Uh, and it's all about a company that took joy as its metrics. So I talked about fun. Um, this company, um, also in software, um, took joy as their, uh, approach. And that's not something we talk about at work very much. Uh, so I like that a little harder to measure than fun. People are a little more uncomfortable with joy. I I don't think that's a bad thing. Uh, I think making them a little uncomfortable might be very healthy. So I like those three axes. That sounds like a great, uh, uh, tool. Uh, it sounds like you were using that in retrospectives with the team to discover how the team could function better.
That sounds really great. So thank you, Jim. Very helpful idea, and I will try to remember reminders would be welcome, um, to put on the forum, uh, a link to the, the, the book Joy Inc. Um, there's also another one, which I think is called Joy and Ease at work. So I'm gonna make a note to myself to put that up on the forum. So, uh, if you're interested in reading more about those sorts of things, um, I have some, some links, uh, in mind to, to share. Right? Dmitri has a question. Uh, let's see if I can stick that up here and let everybody read it. Also, uh, keep my, keep my throat in, uh, operation.
So, uh, anybody might be listening and not watching. Is it possible for organisations where the dominant culture is visible, hard work, long hours to be successful in tech, for example, finance or legal? Well, I know I'm going to sneeze here in a moment, so thank you, Dmitri, for an excellent question. Uh, let me just, uh, make sure I can breathe. I think I'm all right. Uh, a bit of pollen here, even late in the season, uh, in North Carolina. So apologies in advance if I sneeze in your ear, if you're on earphones. Um, but, uh, uh, if the dominant culture is visible, hard work, long hours, can you be successful? Well, certainly you can. Um, there are lots of game studios, for example, who have regular crunches and really kind of churn their people under the wheels of the, uh, of the operation. You know, you imagine this tank kind of rolling over bodies.
Uh, that's the experience of these 12 hour, seven day a week crunch periods that go on for months and months and months. And guess what? They produce really amazing games. So if your measure is just, uh, success, uh, can you have, um, uh, lots of money, can you have lots of market share? Uh, well, certainly you can, but what you're doing there is you're doing it in spite of your technology, not with your technology. So what you're going to produce is anod dying results. You're gonna produce, um, uh, things that look a lot like others. And guess what? The games that come out of those studios are not the super creative, really wild, really new, uh, ideas that really change people's thinking. Uh, they kind of look like every other game. Um, and the same is true of say, finance spent a lot of time in the trenches in the, the city of London dealing with, uh, the city boys and, and, uh, FinTech startups.
And, uh, that's, uh, certainly an environment in which, uh, the, the reward is for very long hours and very hard work. And, and there are very significant rewards for doing that. People can be very successful, but man, you gotta say, they're, they're not very, uh, creative. They're not very experimental. So, uh, you might get one or two people who come up with some new derivative or some new way of, uh, trading in the market, but the, the folks cranking out the work, they are not going to come up with some new idea. They aren't going to contribute a creative solution. So, uh, yeah, absolutely. Organisations who do that can be successful. And I'm not suggesting that fun is the only way to make profit from your tech team. It's definitely the most fun way, definitely the most enjoyable. Uh, so I'd much prefer to have a team that is appropriately relaxed, has enough slack to have clever ideas, is experimenting and trying out new things while delivering for customers, while staying in touch with what they need.
Um, and so that's what I'd advocate in that situation. Uh, I wanna open it up to more questions. Uh, so feel free to throw more in. Uh, we're coming toward the end of the, the time we had planned, but I'm, I'm ready for more questions if you have them. I will just remind you that, uh, the place you can go to, to do lots more of this, to have more of these events and activities and, uh, hang out more with me and the rest of the very clever folks who've been, uh, uh, updating us and, and adding new ideas and comments. Uh, that's at squirrel squadron.com. So, um, there you can find, uh, this recording, uh, which will be up, uh, very shortly. Uh, and also of course, on the link where you are, LinkedIn or, or, uh, uh, Facebook or, or YouTube, assuming all of them are up.
And the, the, the internet is functioning as it should. Then, uh, you'll be able to watch the recording there. But, um, squirrel Squadron is the place where you can find future events. So, uh, we have an event, uh, not next week 'cause I'm away, but the week after that on testing, and then after the week after that, on a different day, on a Wednesday. Um, I'm with Colleen Francis on, uh, and we're gonna talk about sales and ai. 'cause Colleen, who is a internationally famous sales, um, uh, expert, keeps talking about how you can use AI and she's doing it wrong. So we're gonna have a good debate about that. Uh, that'll be in a couple of weeks. You can sign up on squirrel squadron.com as well as make comments and ask questions in the forum and, uh, stay in touch with all our resources and, and ideas from the squadron.
DS 00:47:49 So, uh, I hope everybody had fun here. Um, that's a question you can always ask people. Uh, are you having fun? If you work with me at all, you will find that. I ask that quite frequently. It's a fantastic metric. Uh, it's a good indicator, good leading indicator of creativity and success in your technology team or any other knowledge work team. Uh, and I hope that you found today helpful. I certainly had fun and enjoyed chatting with all of you. So, uh, see you again in a couple weeks, uh, here, uh, on another event like this or, uh, even sooner on the forum. Have a wonderful day everyone.