Why Software Development Sucks And 7 Mental Models To Help Fix It

Transcript

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I’m sitting down with Thanos Diacakis. Thanos, welcome. Thanks for taking the time to talk to us.

Thanos Diacakis: Thanks for having me on. It’s a pleasure to be here.

Shane Hastie: My normal starting point with these conversations is who’s Thanos?

Introductions [00:51]

Thanos Diacakis: Ah, Thanos. Thanos has the gauntlet and it’s been getting a lot of recognition since the Marvel movie came out if anyone knows about that. But it’s nice to go into Starbucks and go Thanos like the guy in the movie rather than Thomas. But more seriously, I’ve been a software engineer for my whole career. I’m nearing about 30 years right now. I have worked at companies big and small, some of my own startups, some bigger companies. I worked at Uber and Included Health, my two most recent bigger employers. And I love software in all forms. I have done anything from firmware all the way down to assembly code, to all the way to now, all these fun AI systems and more.

Shane Hastie: Cool. We got together because you’ve got some strong opinions. The focus of software development sucks. How do we make it better? And you’ve got some ideas about thinking differently. So, let’s tackle that first one. Is it a fair statement that the process of software development always sucks?

The Core Problem with Software Development [01:48]

Thanos Diacakis: Not always. But I’m going to take the opinion that it sucks a lot of the time. And to continue a bit of my background, I’ve been in the industry for about 30 years coming up to 30 years soon. And one of the things that I’ve noticed is no matter what team that I go into, the teams struggle with getting software out the door. They may be really good experts, smart people in their field, know their stuff really well, but getting software out the door is always a problem.

And one of the things that I observed is maybe there’s 30 or 50 things that one ought to be doing that help you with effective delivery. And again, it depends on what stage you’re in and all that stuff, but most of the teams that I work with do half of those things and it’s not always the same half. So, everyone does their own mix and match of what is good and some things that are completely broken.

And my hypothesis is this. People go to college and they learn about algorithms and how to build really complicated things and they get knowledge in certain areas, but no one is taught how to get software into production. They don’t learn about the engineering process and all these good things. They go to work their first job and maybe they do Agile with a capital A or Scrum or something like that, and they follow what they see as the process without really knowing why they’re doing this.

And they might move around a few jobs and maybe collect what they feel were the best practices from different places, but no one knows why they’re really doing these things. And that’s a problem. That’s why people stumble because they’re doing stuff without actually knowing. And it’s not because they’re stupid. I know that I used to think that, but I don’t anymore. I’ve figured out that people were just busy. People have jobs to do, they have things to deliver. And they don’t have time to step back and see, “Okay. Let’s think about the philosophy of software engineering and see how those things worked”.

And that’s why we end up in this mess and we end up with software companies that do things in a really broken way that ends up to people not feeling good about their jobs and getting burned out and not being happy about doing what should be a lot of fun, like creating stuff out of nothing. I think software is a lot of fun to make and we should go back and make it be that way.

Shane Hastie: So, you make the point. These are bright people. They pick up ideas as they go along and to quote Tom DeMarco, “Too busy to stop for gas”.

The drive for features, features, features [03:49]

Thanos Diacakis: That’s right. Yes. And it’s hard, because you get under pressure to build a certain kind of thing, and I’m going to call it u,sually it’s features. So, you have the business side of things. They want features, features, features. And all they can talk about is about features. So, people get conditioned to only think that the only good thing that I do here is features.

And we all know if we sit down and think about it for a minute that in any software team there’s more than features that you just do. I’m borrowing from the flow framework, that this says it’s four kinds of work, there’s features, there is bugs, there’s technical debt or investments that you’re going to make and there’s risk items.

So, if the only thing you ever talk to your team about is features, the other things fall on the wayside. And I’ve seen this happen before, engineers that should know better, “Hey, you should take back and sharpen your tools a little bit or fix this thing that is not going to work in the long run”. They just respond to the business and just get conditioned onto this until the architecture and the process and the culture collapses under its own weight because it’s not able to deliver any value before you go in and do some of the cleanup.

Shane Hastie: But haven’t we been working on this for a long time? I think of Team Topologies, I think of Agile methods, I think of DevOps, I think of name your brand.

Thanos Diacakis: There are many good tools out there. And I think, like I said, you go into companies and they’ve heard of the one but not necessarily the other. So, maybe they heard of DevOps and they set up an environment that looks a bit DevOps-y and works quite nicely, but they haven’t heard of Team Topology. So, now you have to straddle eight different teams to get one thing done.

You go to some places that are a bit, let’s say more enlightened and they’ve been in this and they’ve thought about this and you can see quite nice setups. But my broad observation is that if I go to most places and I say, “Have you heard about Team Topologies?” I’m going to get two out of 10 that have heard it and are actually implementing it.

And from there there’s a lot of nuance to it. It’s not like you’ve heard about Team Topologies, and ooh, let’s go and I can go make a stream aligned team. There’s a bit of understanding of, okay, what is locality? And how does that work? And why do I need to have everyone be in the same place to be able to make decisions quickly? And what is local efficiency versus global efficiency? Am I focusing on having a team just running in their little mouse wheel, or do I care about what I’m shipping out the other end of production?

So, your point is well taken. We do have the right tools and the right methodologies, they’re all out there. But the problem is does the team have the time to step back and see what fits in their current environment? What are the right problems that’re having? What are the right bottlenecks that they need to solve?

Focus on addressing the biggest bottleneck first, then iterate [06:16]

One of the things that I often find interesting is teams usually will have one bottleneck. If you think of the factory model and you have a series of machines that make a widget. If the one machine in the middle is the slow one, if you go and fix the one after it, well that’s not going to have any work. And if you fix the one before, then more work is going to pile in the bottleneck.

And once you think about this, it’s not really rocket science to realize and software teams work in the same way. You probably have exactly one bottleneck and that’s the one thing that you need to fix. And when you fix that, the bottleneck will shift somewhere else. And then you need to go find that, repeat it and go fix the next bottleneck.

But typically, what you see is teams figure out what to fix on a much more haphazard way. Like oh, that is hurting me right now. Let me go fix this. But then if you’re fixing the wrong bottleneck, that doesn’t really have an actual effect. So, when you ask for some time to go fix this thing, you fix it, but then there was no change in output. Next time you go ask, “Hey, can I have some time to fix this other thing?” You’re probably going to get a no.

So, I usually advocate trying to find a bit more of a methodical way to figure out what your bottlenecks are. So, then that little risk that you took in investing paid off, you can see the payoff and then you’re more likely to be able to argue to getting a bit more time to do this. And then maybe the idea of investments fits in your company vocabulary, and you can start getting some serious chunks of time where you can build these investments and improvement over improvement over improvement. You can get to really big improvements at the end of the line.

Shane Hastie: There’s, I want to say a leadership stance shift, a culture shift that is needed for that.

Leadership and Cultural Challenges [07:41]

Thanos Diacakis: Yes. Leaders typically go through this set or at least this is what I’ve seen. They ask for a feature and then they get it four weeks later and it wasn’t what they wanted to. So, I say, “No, no, no. This is not what I wanted”. So, they make this tweak, and then two weeks later they get something else, not quite what they want. Now it’s delayed, it’s a little bit buggy.

So, when this failure mode happens, the thing that they do next time is they reach for more planning and more predictability. So, they say, “Okay. This time I’m going to write you a really, really tight spec because I know exactly what you want”. Last mistake number one, you probably don’t know what you want. “And I’m going to give it to you in advance. So, now when you go build this, I’m going to get exactly what I want. And because you can break it down into really small pieces and figure out how long each of these pieces take, you can tell me exactly how long it’s going to take”.

And my argument is to your what does this leadership look like here is that’s not going to have good results. You can’t predict what you know in advance. As soon as contact with the enemy is made, the plan is going to change and it’s going to be out the window.

So, leadership is really afraid to take the jump and do something different. And they don’t know what that different thing is. So, we know what the different thing is. The different thing is we’re going to create a team that is a stream aligned team if we go all a Team Topologies. We’re going to give them all the tools that they need to get this feature done and get it done in a short period of time.

And in the beginning they’re going to fail, but as they get a little bit better and a little bit better every time, they’re going to be able to ship these features in a fairly short period of time. And when the product owners start seeing this, we can now deliver on the promises that we made in little small chunks and we can start building on that and build bigger and bigger and bigger over time. They’ll be less preoccupied with can I plan it in advance? Because they get the certainty like, “Hey, I had this feature idea and I saw it a few days later, not a few weeks later or a few months later”. And that trust develops.

And now we go away from, I have to make this tighter to how do we optimize for faster learnings? How do we optimize for that relationship where we can all collaborate and get things out the door rather than write a spec, throw it over the wall. Someone implements it, throw it over the wall. Someone tests it, throw it over the wall. And then when a mistake back comes back and that rework is a complete mess.

Shane Hastie: When we were chatting earlier, you made the point that this really is thinking differently and you mentioned seven mental models. Tell us your seven mental models.

Seven Mental Models for Software Development [09:49]

Thanos Diacakis: Yes. So, let’s do a quick one through each of them. So, the first one we already talked about is that there are four categories of work. So, engineering doesn’t build just features and we need to think about all these categories. And there’s maturity level concerns in here. If you’re a startup, you may be doing 80% feature work and doing 20% investments and you may not have many risks and not many bucks. But if you’re a mature company and you have a product out there, your ratios may look like 30, 30, 30. So, you may be doing 30% features, 30% fixing defects because now you have a lot of customers that are using it, they’re reporting things back, and then 30% investments.

And people freak out about this, but your 30% of features when you’re doing the other work, we’ll produce so much more than doing a hundred percent features and doing no investments anywhere else because you can be so slow in doing those features that it’s going to be really bad.

My second mental model is that of technical debt and investment. And the idea there is that we think of this as a little bank that we can borrow from the tech debt bank and then pay it back and borrow and pay it back. And my argument here is this is not what usually happens. What usually happens is sovereign debt. You borrow and you borrow, and you borrow and you borrow, and now you’re 180% of GDP and you call the IMF in and they bail you out and it’s a disaster. So, in the software equivalent, that’s the big rewrite.

So, don’t do that. Technical debt comes back to bite you really, really quickly. So, if you borrow it, you should be paying it back in the next sprint or the next period. Do not let it simmer for too long because that really slows you down.

The third mental model, we also touched upon this, is the one bottleneck. Don’t try and do a hundred things at once but think of where your bottleneck is. Fix that. Do some experiments to find out and fix your bottlenecks, but don’t try and fix 10 things at once. That’s not going to go well.

Mental model number four is global versus local efficiency. And I’ll explain this a little bit better because I touched upon it earlier. But the idea here is we don’t care if everyone is really busy. That doesn’t really get you results if you’re not shipping product out the door.

And the problem with what happens is I think I have this factory is like I have a machine, it shouldn’t be sitting around, it should be producing stuff, but then that stuff piles up and you have to store it somewhere and then you lose it or it gets stolen or it gets rusty. Software is the same way. If you go or write stuff that you don’t need, it’s not going to go to production. Then a PR becomes stale, you forget who wrote it, who wrote it might have left the company. It has bugs. You can’t merge it anymore.

So, what we want to do is focus on a few things and get these few things shipped before we start new things. And it doesn’t matter if some team member isn’t doing something at all times because maybe when a bug comes in they can go work on that. If they start a new project, now they may have questions and they might go distract someone that is working on something more important and that usually causes priority inversion.

So, focus on what it takes to get software out the door, work backwards from there on your bottlenecks and make sure you’re globally efficient, you’re getting value to your customer rather than like, “Hey, Bob was busy all eight hours of yesterday”. That doesn’t really do anything for you. Paying Bob the same amount, whether he’s bugging people that are actually shipping something a door or not. So, that was number four.

Number five is think of work in process as something that’s really, really evil. It’s like a hidden thing that you don’t really see, but it just sucks resources. It’s related to global versus local efficiency. It’s starting things that are not going to see the light of day. We see this, we plan a sprint and then you say, and let’s put some reach goals in here just in case we get to them.

And then someone is blocked on one of the important things. They go start a reach goal and the other thing becomes unblocked and the reach goal just falls out the next sprint because something important came through and that work is just thrown away work and maybe it’s just the PR is sitting and confusing people or maybe they emerge a little bit of it and then it broke things. So, my advice here is visualize working process, so you can see what you’re doing at all times and limit it. That will help you focusing on shipping things rather than starting things, which is not super helpful.

Mental model number six is planning the doing. And my argument here is get really good at doing before you start getting really good at planning. The joke that I make is someone wants to tell you how long it’s going to take to go from the east coast to the US to the west coast to the level of fidelity of minutes and they have a horse and buggy that breaks down halfway through town. It’s like you should maybe develop a car first, maybe get the horse and buggy to work, maybe then get to a car, get from city to city before you can plan how long it’s going to take to get across the country. And I won’t speak too much because we talked about this with a leadership issue there, but get really good at doing. You’re not going to get good at planning before you can get good at doing.

And the last one that I have here for you is quality versus speed. And this is a fun one because I think a lot of people associate if you go fast you can have poor quality. And that could certainly be the case if you’re in YOLO mode, which is like I’m just going to build stuff and just put it out the door. But think of quality as your ability to also fix your previous mistakes.

So, if you have a process that takes two weeks to develop something and then a week to QA it, that means a mistake will take at least a week, maybe more than that to make it into production. So, that is not quality in my mind because by the time you’ve shipped that bug fix, you’re going to have found three more and that release for going to make three more bug fixes and so on and so forth. So, speed and quality need to work together.

So, you need to put in the systems in place that enable you to have speed and quality at the same time. And one aspect of quality is also going to come from speed. So, don’t think of these as competing, but think of how you can make those to synergize together.

And those were my seven. They’re a little bit all over the software development process, but hopefully they give listeners some interesting ideas of how to think about their problems in ways they might have not gone through before.

Shane Hastie: So, how do we put this together into a, I want to improve my software development process? Maybe I’m a newly promoted team lead. I’m seeing some of the challenges as an individual contributor. I felt the challenges. Now I’ve got some authority. I’ve got into a position where I can start doing something. How do I synthesize this into a way of working?

Four-Step Implementation Framework [15:23]

Thanos Diacakis: Funny you should ask that because I think that’s what everyone asks me of how do I do this? And the problem that I see is people just get lost. Like, “Holy mackerel, you just gave me seven mental models. Okay, that’s great, but now what do I do? I go to work on Monday and how do I fix this?”

So, I’ve tried to synthesize this in a four-step way that walks you through it. And this is not the only way to do it, but it’s a way to get your head around it in a way that is relatively straightforward and you can walk through it linearly. It’s not always linear. When I walk through clients with this, sometimes you start with one, you go to two, you jump back to one, you go back to three. So, you have a little bit of room to maneuver here in the four steps that I’ll give you. But if you go in 4, 3, 2, 1 all the time, you’re probably doing something wrong.

So, my four steps are iterations, quality, complexity and planning. So, let me walk you through one at a time. So, my first step is iteration. And the goal here is you need to be able to get stuff to your production quickly, in days, ideally by the end of this process multiple times a day before you can do anything else. You’re not going to be able to work on anything much if it takes you days or weeks to get stuff into production.

So, this means that from linters to CI/CD pipelines, to ways to get consensus, to what goes out in production, to notifying your customers of what’s out there, all the stuff in that pipeline is a good phase of iteration. So, the first thing that we typically start from is how is our iteration? How does that work? What do we need to do to improve our ability to get code into production?

Now very close to that comes number two, which is quality. If you just shipped to production with no concern for quality, that’s YOLO mode, not good. So, we want to build the systems that go through that. What is our testing? Ideally automated testing that go in here. Are we monitoring production, observability? Do we know what is happening in production? Is what’s in production what we think is in production? A lot of people think they know how production works, but then they go look in the metrics and logs and things of that nature and go, “Oh, wait a second, how does that even work?”

And those go hand in hand. You might do a little iteration, a little quality and go back and forth until you are at an acceptable pace. But now you’re at a relatively good point where you can have an idea and take it to production with reasonable quality in some fairly short period of time. Again, days, not weeks or months.

And as you’re going through these, by the way, you’re thinking of culture, process and technology and what you can do to improve finding your bottlenecks for each one of these things and working on systems to improve.

Now the thing that usually happens with teams once they have iterations and quality down is that they start building up complexity. And complexity. Don’t think of this as only your architecture and what happens there, but this could be procedural complexity. This could be the cognitive load of understanding how the whole system works. This could be end user features and how those interact with each other and, “Hey, we just built this new ordering thing over here, but it’s affecting this other thing over there”. And every feature interacts with every other feature and it’s a little bit of a mess to figure out or maybe vendor complexity. It could be appealing to different customer bases.

So, there’s many axes upon which complexity scales. And together with broken process, that complexity is one of my most hated enemies in this thing because we think we’re so smart as humans, but we’re really small lizard brains in some ways and it’s really hard to get our heads around complexity.

So, I like to go in and start looking at the complexity in this third phase and saying, “Okay. What can we do to keep this down? How can we put good interfaces between things so things scale linearly, not exponentially? So, as I add features, can I build the architecture so I can test them separately? And I don’t have to test the combination of everything with everything else”. Because we eventually cannot do that.

Culture complexity is another fun one. As you scale up the teams and everyone’s doing things in different ways, a common thing that comes up is, do we want to have standardized across systems or languages or platforms or frameworks or whatnot? And these are oftentimes complex challenges. The benefits of standardization is that you may have one team that’s supporting it and you have built expertise in there, but then you stifle innovation because what if this is a really new cool tool that you can use to make your life a lot easier over here.

And these don’t always have easy answers, but there’s some methodology and tools that we have to go and play and answer those. But thinking thoughtfully through these will usually end up with good results rather than just winging it.

And now when you’ve got complexity tamed, again, none of these by the way is like I say, when you have complexity tamed, it’s never going to be done. But as you get to a point where that’s acceptable and you keep iterating on this loop, I think that’s where now we go to planning and predictability.

Once we have strung enough of these things together, we now have a team that is cohesive or multiple teams, it fits a larger organization. And there’s a rhythm to it now. We know how this works. We’re getting pretty good at it.

Now, I think we can get to the point where we can string this thing together and say, “Yes. We’re pretty good on planning a quarter out. Now we’re good at looking at what are the themes of the work that we’re doing. We have a pretty good idea of our systems. We know our ratios of how much feature work versus investments versus bugs we’re doing, and we can look at those and have some reasonable ideas for planning that are not just junk in, junk out”.

What really annoys me is you go to the quarterly or yearly planning meeting and you do two weeks worth of work and then it starts and two weeks into it, the whole thing is out the window because something else is different. And then you do again the same thing next year and it’s like, “What’s the point?”

So, I want my planning and predictability exercises to be something where we came close to the plan and then we can repeat it because there’s not much point in making plans if we can’t really get to follow at least some part of them. The adage of planning it’s worth its weight in gold. Plans are worthless. So, the exercise of thinking through things is really good, but be prepared. Plans change. It’s okay to move things around. But find that you’re getting some benefit for these activities rather than just doing them to feel better.

Shane Hastie: Four practical steps. How long does it take?

Timeline and Implementation Reality [20:40]

Thanos Diacakis: Oh, that hugely varies. If you’re a startup and you have three engineers and it’s a Greenfield project that you could have a lot of these things figured out in a quarter, but there’s a lot of ongoing processes that you have here that you’re going to carry for life. These are not things that are one and done.

If you have a more realistic example, I’ll give you an example. This one current client that I have. There’s like three or four engineers altogether in the team and we’ve been doing about 20% of effort in investments in these sort of things. And we started about a year and change ago and it was some existing code base. And what we did is investing 20% cycle after cycle. We were getting 1, 2, 3, 4% improvements week on week.

When you add these up after a year there now crushing it. They’re eating in the competition’s lunch. They have a lean mean engineering machine. They can build fairly complex features in no time. Architecture is under control, iterations, quality, speed, all these are going really great. But to do this, they didn’t really sacrifice any velocity as they were going through. So, for this year and a half or so that we were doing this, they were putting features out without really stopping and really chewing into the market.

So, you can parallelize these things. Again, it’s a delicate balance of how you do this. We could have maybe done this in six months if we just stopped everything and just did investments, but we didn’t want to do that because the market is not going to stop and wait for you.

So, you could have find the right way to do this and you can go from slow to fast. This is not an overnight thing. There is effort involved here. You are looking to spending at least 20 or 30% in looking to how you work in addition to actually doing the work that you do.

So, it’s not a trivial amount. But if you ask me, there is no other way. If you spend all your time and just build new shiny stuff and pay no attention to the machine that is actually doing this work, you collapse under your own weight sooner than you think. You can able to hide it for a while. And that’s where companies get the not fun part of working where things get ugly on the inside and take all the fun out of it, but it does come back and bite you pretty fast.

Shane Hastie: Culture, process, technology. The technology you mentioned, for instance, get your DevOps pipeline sorted and we know how to do that. The processes, I think you’ve given us a pretty sensible way of thinking about the software engineering process. How do we get culture, and I want to say right in inverted commas?

Culture, Process, and Technology Integration [22:58]

Thanos Diacakis: Thoughtfully, consistently. That’s a challenging problem, because the joke culture eats strategy for breakfast and eats everything else for breakfast as well. What is culture? Culture is how we do things in a given org and people learn culture not because they’re told what it is. They’re told process. They’re not told culture. They get culture by looking at what everyone else is doing.

So, process is an interesting lever you have. You can pull process in really fast, say, “Everyone should do this”. And you can reward on everyone doing this or not. And eventually if everyone does start doing this, that can become the culture.

I think the thing that I found is why I insist that my clients work on all three of these is that if you have the right culture and the right process, but your technology is way off, you’re still going to fail and you’re maybe blaming it on something else that was happening. You blame it on culture. So, for example, say you were doing manual testing, which we all know doesn’t really work that well and you probably should automate. And if you’re doing manual testing and that fails, we might blame it on culture and saying, “We weren’t testing hard enough, we weren’t so into it”.

So, culture gets the blame. Whereas that was a tech problem. That was not the right approach to things. So, I think you have to think about this holistically. And when it comes to culture, I prime it with process because the tool that you have, but then you also need to lead with communications and good examples.

So, communication as you keep repeating the same thing and what do you want it to be over and over again. And you have to show the values. You can’t just say it, but you have to do it. So, you cannot, for example, say that we have a culture where engineers can do the right thing for engineering, but then not give them any time to work on technical debt and investments because that’s not setting the right culture. You cannot say, “Hey, yes, that’s nice. I’ll give you a week for a fix-it sprint”. And that’s the only time that you get because that’s the saying one thing and then implementing a different thing.

The Software Industry’s Tolerance for Poor Practices [24:39]

So, I think as a leader you have to put your money where your mouth is and help the development team do the right sort of things. It’s actually a little bit mind blowing if you think about it. We do sometimes things in software that in any other industry would be the most insane thing ever. You wouldn’t have a surgeon say, “I’m in a hurry, so I’m going to skip washing my hands because I got to get the surgery done”. Or like, “Hey, we just finished this bridge, we’re going to do the load calculations at the end, because yes, that’s just paperwork. And we don’t need the barriers on the side. Let’s get a little bit of traffic on it to see how the bridge is working and we’ll put the barriers on the side afterwards”.

And you see where I’m going, right? We do this in software all the time and it’s not cool. There’s some things that are some good practices that are good that we should be doing good because there’s reasons for them and just skimping on those leads to bad things.

Now, on a positive note, we do have the right tools in place. This can be good, this can be fun. And it is just a matter of combining all the right bits and pieces in one place and staying agile with a small A and staying adaptive to things to get a team in a good location.

Shane Hastie: How quickly can we adapt and learn?

Adapting and Learning [25:38]

Thanos Diacakis: That varies. There’s a lot of pressures on teams. So, if you have a fairly small team that is just in the beginning of their journey, they are super eager to go and build product market fit and get things out the door because they’re not going to be around. And that is maybe the time that you’ll give them a bit more leeway and saying, “Okay. Maybe this is the time you can create a little bit more technical debt because you’re not going to be around to do that”.

At the same time, you have to stay adaptable and learn. You cannot pretend that these choices that you’re making don’t exist. You have to keep a very close eye on them and create these really fast learning cycles of what does the market need? How does this technology work? How does this product that I’m building for the first time work?

When you get to bigger companies and bigger teams, the existing processes have been, and maybe culture sometimes have been ossified in there, makes it a bit harder to adapt and learn. I don’t know if you heard that story with the gorillas in the cage, but it’s fascinating. I try to find that if this is actually true or not, but it’s still pretty instructive. But there’s eight gorillas in a cage. There’s a ladder with some bananas on the top. And one gorilla climbs to the top, try to get the bananas and they spray the whole cage of the gorillas with cold water. It’s a bit cruel of an experiment.

So, then another gorilla tries to do the same thing and they get sprayed with cold water. So, they basically stop. They don’t go up there. So, now they take a gorilla out of the cage. They send them upstate and they grab a new fresh gorilla that has never been in the cage. The new gorilla sees the bananas up the cage. The other gorillas will grab them and beat them so they don’t all get wet. And the story goes that they keep rotating all the gorillas until none of the gorillas have ever gotten wet. Yet, when a new gorilla goes in, all the gorillas beat them up without knowing why.

And that is conceivably how culture works. You keep doing the same thing and don’t know why you’re doing the same thing. And it takes a bit of effort to figure out, “Okay. What’s happening here? Why are we doing this? Does this still make sense? Is this protecting something?”

Oftentimes you’ll put a constraint around a bottleneck. So, we had this bottleneck. Maybe Bob is the only guy that knows something about our system, and so we protect Bob’s time. And then when we solve this bottleneck, now we need to go remove this protection because we don’t need it anymore because the bottleneck has shifted somewhere else and this bottleneck is not doing something. So, there’s a lot of these artifacts that were there to protect something in culture, process or technology that eventually need to go away to keep forward motion going there.

Shane Hastie: Thanos a lot of ideas in there. I find myself in vehement agreement. If people want to continue the conversation, where can they find you?

Thanos Diacakis: They can find me on LinkedIn. I post there daily with topics around these issues.

Shane Hastie: Well, thank you so much for taking the time to talk to us today.

Thanos Diacakis: This was a fun conversation. I’m glad you had me on, Shane.

Mentioned: