Show Notes
From pair programming to NoEstimates, the industry brims with creative minds proposing new ideas and methodologies to tackle longstanding challenges. The issue, however, isn’t the scarcity of innovative concepts, but rather the failure to implement them, often dismissed with the notion “it won’t work” … or, in other words, “it’s impossible.”
In this episode, Andy and Mon-Chaio delve into the psychology behind the significant hesitation to consider provocative yet potentially beneficial new ideas. To illustrate this resistance in a practical context, they discuss two longstanding processes that, despite their potential, are seldom utilized. They dissect the mental barriers that lead us to deem things “impossible” and offer practical strategies to overcome these obstacles, in their ongoing quest to create more modern and impactful development organizations.
References
Transcript
Mon-Chaio: Here we are, once again, for another episode of The TTL Podcast. Andy and I were talking last week about what we might talk about on this episode. And while we were discussing that, we wondered, hey, these topics that we’re talking about, a lot of people don’t do them, right?
So, as an example, pair programming. A lot of people don’t do pair programming. I would say probably the majority of the software development world doesn’t do pair programming. Would you agree, Andy?
Andy: Yeah, yeah. It’s been pretty rare that I find any groups actually doing it.
Mon-Chaio: And it kind of got us thinking as to, well, why don’t people do it? And as we dove into that discussion, we felt like, hey, this could make a really good episode. So today’s episode is all about why people don’t do good things, why people think certain good things are impossible.
Andy: I’m gonna give it a positive spin, Mon-Chaio. I’m gonna call this episode, Doing What Is Impossible.
Mon-Chaio: Doing What is Impossible. Ah, I like that. Okay. So that is this episode. It’s doing what is impossible. We’ll talk about some things which we think we commonly see in the industry that people think are impossible. And then we’ll talk about why people might think they’re impossible. We’ll talk about some success stories perhaps that we’ve seen and hopefully get to the point where we are asking ourselves the question, why is it that we think possible things are impossible? And how do we go about doing the impossible so that we can do better?
And part of this is most of your competitors are likely not doing the impossible. And so if you can do the impossible, and if you can change your mindset to be able to do the impossible, would that give you a competitive advantage? I think maybe. So I think that’s what we’re going to try to talk about.
Andy: Yeah. And, even if you can’t fully do the impossible, you can learn a lot by trying.
Mon-Chaio: Mmm hmm.
Andy: And you can go far beyond what others are doing if you just try.
Mon-Chaio: Absolutely. Right, because the impossible doesn’t have to be an all or nothing. We talked about pair programming. Many people think that pair programming is impossible, but it doesn’t have to be all of it. It doesn’t have to be, well, in order to do pair programming, you have to sit next to somebody for eight hours a day, strictly one keyboard, one monitor.
Although we do believe in a lot of that stuff, but even if you take part of it, 20 percent of the positive value of that, 10 percent of the positive value of that, it is still positive value that you’re taking away that perhaps most people aren’t even attempting, aren’t even trying.
Andy: Absolutely. Yeah. So, all right, Mon-Chaio, let’s dive in. I think we decided let’s not talk about pair programming. That might be too impossible for people. So let’s pick something a little less impossible. Let’s start with the really impossible one that I keep hearing. It’s not as impossible as pair programming …
Mon-Chaio: Mm hmm.
Andy: … but it’s trunk-based development.
Mon-Chaio: Oh, well that is absolutely impossible. Can’t possibly do trunk-based development.
Andy: Yeah, I mean, the merge conflicts we would have.
Mon-Chaio: Mm hmm.
Andy: And we’d have no control over what anyone’s putting in.
Mon-Chaio: Right? Right. How do you even do code reviews in trunk-based development? It will have already hit trunk. And if we’re doing CI, then it would have already been built and maybe even released out into the wild. What the, how can you possibly do something like that?
So trunk-based development is something that we have, on this podcast, made snide remarks about many times. I guess we’ve made snide remarks about people not doing it, right? And I have generally found engineering leaders’ and engineering teams’ reaction to trunk-based development as this is impossible. As, it fits only into the realm of small teams. As, if you only have four or five engineers, maybe, but even then you couldn’t. As, if you have a distributed team, how could you possibly do trunk-based development?
So, I very rarely … and remember in my career, I’ve worked at startups, I’ve worked at large tech companies. I don’t think I’ve really seen any company, other than the one Andy and I worked at once, do trunk-based development. So I would say that that feels to me like something that people think is impossible.
Andy: And what’s interesting is throughout my career, when I’m at work, that’s just what we do, it was normal. When I would go to other places, I’d go to meetups or I’d be talking to people at conferences, that’s where trunk-based development was suddenly questioned as it’s impossible. That, it’s nonsensical. It’s cowboy coding. It’s uncontrolled. It’s unconstrained. You’ll have issues constantly if you do that. Which for me is just like this weird thing, considering that I would be programming that way every single day, committing to trunk, and having no problems.
Mon-Chaio: So maybe this is a great time to step back and say, well, what do we mean by trunk-based development? I think that there are at least a few meanings that I’ve heard before. Some of them I disagree with as trunk-based development. So maybe we can decide, what do we mean by trunk-based development?
Andy: So to me it is very simple. All of the commit activity for a repository happens on a single branch. We can get into the semantics of like, if you’ve cloned to get repo, you have a separate branch and all of that. But to me it’s conceptually you are all committing to the same branch, and you’re not dealing with merges and branching. Your main line of activity is simply on that one branch. So in a git workflow, from the command line, your workflow is ” git pull –rebase”, ” git add”, “git commit”, “git push”. That’s it. For every single commit, that is the only workflow you need to remember.
There’s no, oh, git branch this and put the ticket ID in the branch name. And then you commit onto that branch and then you do a pull request from that branch. And then you do a maybe a squash commit or some places do a fast forward merge or a rebase onto the most recent thing or that kind of stuff. None of that happens. None of the, oh, someone else’s pull request is also changing this file at the same time I’m changing it. I should cherry pick some of their changes onto my branch or merge their branch onto my branch, get their stuff over here so that I can deal with. None of that exists. It is purely git pull, add, commit, push.
Oh, and I should add on to that. The time difference between your “git commit” and your “git push” should be a matter of seconds.
Mon-Chaio: Yeah, when you said that, I took it as meaning that it was almost an atomic action between your commit and push. Because if it’s not, then you sit there and you could make a bunch of commits before your push and …
Andy: Yeah.
Mon-Chaio: … right. Okay.
Andy: And what I hear about this is, oh, you’re going to have conflicts all the time, right? I’m going to pull and I’m just going to have conflicts. I’m going to spend my entire day resolving conflicts as my team constantly pushes and I have to pull and get something new and deal with the conflict. And my experience has been that just doesn’t happen.
Mon-Chaio: Maybe we should set the problems of trunk-based development to the side for one second. The fact that we’re even talking about it, or that it even enters into the discussion, however quickly it’s dismissed, I think it’s because there is one big benefit of trunk-based development. And I think if we could get rid of all of the things that people think are problematic about it, I think most people would agree that the benefit of trunk-based development is well worth it. Wouldn’t you say?
Andy: So what is the benefit that you think is in it?
Mon-Chaio: So I think, to me, the benefit of trunk-based development is you’re all working on the same thing. You all have the same state. You’re all looking at the same context. And we’ll get into this when we talk about collective ownership as the other part that we want to talk about. But nobody is in a silo.
Andy: Absolutely! I agree with you a hundred percent.
Mon-Chaio: So, would you also agree that, for the most part, if you could magically wave your wand and say, look, I have this tooling that guarantees no merge conflicts because of our magical AI, who will just know how to cherry pick and how to merge and squash and do all of that stuff. I think people would mostly, in my opinion, be okay with trunk-based development because the benefits are so huge.
Andy: Would they? I think they probably could be. The thing that I often find is either cargo culting or just disbelief. The reason I say this is when I do health checks or due diligence on startups, even before they’ve got 10 developers, they’ve got like three, four developers, they are already doing a pull request system.
And so that’s what I see all the time. Now, in that world, if you have that worldview that you need to keep all these things separated, that branching is critical, yeah, what I hear is that a single branch is impossible. Now I’ve heard it’s impossible for the reasons we’ve said already about merge conflicts and code reviews and those kinds of things. I’ve also heard that it’s impossible for regulatory reasons.
Because if you allow trunk-based development, then it’s not auditable. It’s not traceable. You can’t say that you’re controlling things, which is not true. Like, you can still be compliant and do trunk-based development.
Mon-Chaio: Well, and Andy, you worked in a very heavily regulated industry doing trunk-based development, correct?
Andy: The industry was generally heavily regulated. I thankfully worked in an area that was not heavily regulated. But that said, we had customers that had lots of demands about our process. And trunk-based development never came up as a concern
Mon-Chaio: There you go, okay.
Andy: Because the question was, how do you do code reviews? Well, there’s many ways you can do code reviews. We did pair programming. So nearly 100 percent of changes were code reviewed by being written with two people. Other ways of doing it are just after the fact.
Mon-Chaio: Mmm hmm.
Andy: So you take meaningful changes and you do a code review session.
Mon-Chaio: Sure, either ad hoc, where you pull a couple developers, or just one over to your desk, and you say, hey, I have these changes. I’m about to do a git commit, git push. Come take a look at them. And they might ask a question: well, run this, and let me see how this behaves, or, uh, I don’t know, is this a race condition?
And you show them on your computer, could be it. Or I’ve also seen more massive type code reviews where you get into a room with maybe the team or something and you kind of review it there. I’ve seen both.
Andy: Yeah, and we’ve done that when we worked together. We did that every once in a while. We would say, all right, we’ve done a much bigger change here. Let’s do a review of it. We get the whole team in a room and we’d walk through the changes.
Mon-Chaio: Mm hmm.
Andy: And the interesting thing in that setup is it gave a much higher-bandwidth feedback and it gave much more learning opportunities, because you could kind of see the way that people were thinking through the code and kind of working out right there. Do we need to do this? Do we need to do that? Oh, I see. I understand why we’re doing this. Or you can kind of learn a bit about the domain. Whereas the text-written comments that I find in GitHub, very, very rarely do you actually get a back and forth, a real discussion.
Mon-Chaio: Mm hmm. I agree, and I would say that in my experience, that’s the case from small company to large. There are some larger Big Tech companies that would push back on this characterization. And they would say, look, this is really working for us, we get very meaningful comments and very meaningful discussion. But that has not been my experience compared to the type of discussion that you get with more of a trunk-based development team.
Now, of course you don’t need to be doing trunk based development to get great discussion, right? There’s nothing in Gitflow that prevents you from saying, I’ve submitted a pull request, now let’s come over to my computer to look at it before you check box it off. Or let’s get into a room to check box it off, right? And there’s also nothing in trunk-based development that necessarily forces that. You could certainly have a trunk-based development team who’s git committing, ready to git push, and he says, hey, I’m going to have a coffee, can you just come to my computer, look at this thing? And let me know if you have any problems, type in push if you’re agreed. You come back from coffee, somebody’s typed in push. You’re like, great, right?
So neither of them constrain the other, but certainly one method promotes, or is more likely to promote, one type of review over the other. And, look, I think that the concept of everyone having the same context, I think the concept of being able to do real CI and having tested artifacts versus just tested code, I think the concept of more rich and rigorous reviews, those are things that I don’t think many people are going to be against.
And yet, when you start to say, well, trunk-based development helps enable all of these things, It is still very much a, well, that’s impossible. So, do we want to kind of dive into the psychology there a bit, or kind of leave it hanging and then move on to another example, and try to combine the psychology of the two later?
Andy: Let’s go into the psychology just a little bit. This might give us a thing that we can grab onto when we get into the next one.
Mon-Chaio: Okay.
Andy: So the thing that I’ve seen in that is … because I was actually just having this discussion a few weeks ago with someone. And the argument came up of, oh, but the merge conflicts, or the changes that might conflict with what I’m doing. I think the psychology is, I want to put off pain.
Mon-Chaio: Hmm.
Andy: That was the thing that I heard, because when I pointed out, you’re just delaying the inevitable. They were like, what do you mean? I said, well, if you’re going to have that conflict, isn’t it better to learn about it sooner? And getting through that, getting through that understanding of resolving issues faster, faster feedback loops, then it seemed to make sense to them.
But when they were thinking about it from the standpoint of, I need to avoid pain, then it didn’t make any sense.
Mon-Chaio: Hmm. That’s interesting. I haven’t heard that as much. When I’ve had … And to be honest, it’s been a number of years since I’ve been interfacing directly with an engineer, talking about trunk-based development. Usually, I’m talking about these types of things with their leaders or their leaders’ leaders, that sort of a thing.
Andy: Yeah.
Mon-Chaio: I’ve often found that with engineers, umm, how do I put this? It’s really about their image of what an engineer is that prevents them from doing this thing. I don’t know if you’ve ever heard this exact pushback on trunk-based development, but I’ve heard it multiple times. And the first time I heard it, I scratched my head, and then the second time I heard it, I said, wait, there’s multiple people that think this? And here was the pushback: these engineers told me, well, my commits are really messy
Andy: Oh yes!
Mon-Chaio: I cannot show a clear step around how this thing was built and a clear thought process. So nobody even will really know why I built this in the way that I did. And so what I do is I have this branch where I experiment on things and some things might not be tested and I’ll put them in. And of course, most of the time it’s test after, these branching strategies. Again, doesn’t have to be, but most of the time it is. And then, you know, I go down one route, and it doesn’t work, and I delete a bunch of code, and then you go down another route, and finally it works, and then I write the tests afterwards, and then what do I do?
And then I structure my commits, right? Is it called a squash, I think? Or …
Andy: Yeah, you can either rewrite or you can squash, you can reorder, you can do all sorts of stuff.
Mon-Chaio: And now you have this very pretty looking commit history.
The first thing I did …
Andy: Looks like you were prescient !
Mon-Chaio: Oh my goodness, you were so precient, right? And the second thing I did was Y and the third thing I did was Z. Now, how many times have we ever had engineers actually read through the commit history and be like, “oh, that was how that person did it, interesting!” in any meaningful way as to extract value from it. But it builds upon itself, right? Especially when senior engineers do this. And then junior engineers look at them and say, wow, look, they were so prescient! That’s what senior engineers are, they’re prescient. Look at their commit history.
Andy: They just knew exactly what changes to make!
Mon-Chaio: Exactly! And so when they don’t, because, honestly, very, very few people do. I’m not going to say that there aren’t completely prescient engineers out there. I don’t think I’ve met one, but I’ve met some that were really, really good, certainly much better than me. But for the most part, most engineers struggle, right?
They go down rabbit holes, they hit dead ends. They have to delete vast swaths of code. But now you have this false utopian history that as a senior engineer, all you do is you do this prescient coding. And as a junior engineer, what you do is you modify the history of your commits and how you worked in order to make this prescient.
So that’s why I say it’s about the vision of how they see themselves or how they see engineers and successful engineering as a whole.
Andy: I can see that. I have also heard that I don’t want people to see all of these little commits that I’m making as I figure this out. I want to tell them a very clear story about what happened. And I get it. But I think it’s just I don’t value preserving my image that much? Because that’s what it is, it’s about preserving an image rather than getting the work done.
Mon-Chaio: I think there’s a secondary value that people espouse. I don’t know if they truly believe it or whether they’re trying to self justify. Because I do agree with the image thing, Andy. I think preserving that image, I think is a complete waste of time, honestly. Especially for the minutes, hours, seconds you put into it. Every second you put into that is basically a waste of time. The other argument I’ve heard is it makes for a clearer history so that when people read it, they will understand our design and thought process. Now. I have two pushbacks on this point.
One is that it’s a false history. And two is that I’ve very rarely seen value from that history. Maybe you’re different, Andy, but for me, I’ve very rarely seen people going and reading the commit history, unless it’s, here’s a bug, where was it caused? And so, that justification around, oh, we’re reading it to understand our thinking essentially, in my experience, never happens.
Andy: I’ve, I have done it, and I worked on a project where we had guidelines about what a commit message needed to look like. And it was actually very influential on me. I now write fairly descriptive commit messages because I have found you have now a record of various things you tried that didn’t work. And so now someone can actually go through that and say, oh geez, that was hard to figure out, wasn’t it?
Yeah, you tried that, you tried that, you tried that. I get this now. I understand why this code looks the way it does now. Whereas if someone had squashed that and removed all of that intermediate stuff, they probably wouldn’t think it would be valuable to explain those dead ends. And so now you’ve robbed me later of understanding the intricacies of getting OpenSSL to work with extensions on a certificate, as an example of one where I think they commit on that … there was a commit in the end, they finally got it to work after multiple attempts. And the final commit had like a three page explanation about what was going on here. But you could then see all of the different attempts that came before that.
Mon-Chaio: I agree. I think we’re on the same page here, and maybe our listeners disagree. If you do, we’d love to hear your opinions about this, but at least for Andy and I, this rewriting of history I think is problematic in our eyes.
Real quick before we touch on the second topic that we wanted to get to. I mentioned that when I talk to ICs about this, this is a weird thing that I get. When I talk to leaders about this, these are not the things that I hear from them.
When I to leaders about this, it is much stranger. I don’t even know if I know how to articulate this. But the best way I think I can represent this feeling is they are very uncomfortable changing systems. Especially very rooted foundational systems.
Andy: Which is unfortunate because the leader’s job is to be watching and prompting changes to those systems.
Mon-Chaio: Mmm hmm. Well, and we might get into this a little bit, but we’ve often said that, most of the modern leaders are very rarely in the system. They’re about the individuals, right? This local maxima, like if I maximize each local individual and then I give them agency, then magically the system will be optimized in order to produce great value.
And especially if you’ve hired a bunch of engineers in here that don’t believe in trunk-based development for one reason or the other, in order to get trunk-based development to happen, not only do you have to change the mechanics of the system to say, look, we’re getting rid of dev, test, stage branches. Now you might have questions around how do you do code review if you get rid of those branches and you get rid of push requests. Okay, now you have questions around, well, if my code reviews are more synchronous than asynchronous, what do I do about people in different time zones? What do I do about people working remotely? Then you start to have bigger and bigger and bigger questions about the culture and the system as a whole.
And I think most leaders are very, very uncomfortable diving into that topic even if they believe it’s right. And I think a lot of folks have just convinced themselves that, well, it’s wrong. Because, for example, asynchronous code reviews are an immovable piece of the modern workflow because we are a company that supports development across time zones, and we want to let people work how they want and where they are and all of that sort of stuff. And so since these are immovable, we cannot do the stuff that requires that they be moved.
Andy: Hmm. All right. Let’s move on to our next immovable. Let’s move, im move on to our next movable? … which is collective ownership. And the idea that the whole group can be the owner of something. In my mind, this is generally around code, but it can be all sorts of things. I think Mon-Chaio, when we first brought this up, did you have a particular thing that could be collectively owned in mind?
Mon-Chaio: I think it’s mostly around code, but you can even think about it as features or charters, generally speaking, it ends up becoming code at the end. It’s really funny, I think that’s where the conflict generally happens. I’ve found, especially in my time at Big Tech, people love collective ownership of charters, and they hate collective ownership of code.
With the charter thing, you end up saying, well, which team is working on it? Which team is supposed to serve this customer base? And the answer you get back is, we’ll just collaborate, right? We’ve talked about this on this podcast. Well, it doesn’t matter which team is on it. It’s just like, just collaborate and make sure you serve the customer.
And then when you get down to code, all of a sudden, it is, well, which engineer owns that? Who can I, who can call? Who’s responsible?
Andy: Yeah, and that is where I normally find that this is kind of deemed as impossible. Is when you get to that desire, I need a single named individual who is both responsible and accountable for this that I can go to.
Mon-Chaio: Mmm hmm.
Andy: And I think it generally comes down to at almost any level of granularity.
Mon-Chaio: Mm. Mm hmm. Mm hmm. I want to touch on that, but for me, I would love to be able to start again at there’s a clear benefit to collective ownership in my mind. And I think it is a benefit that most people would agree with. I would say a large majority. And that benefit is the fact that your bus numbers are low, that there are more heads thinking about something, that you’re not constrained on a single individual.
You’re not constrained on, oh, they’re leaving the company, or they happen to be on vacation, or in the middle of the night, they didn’t wake up when I called them, or whatever the case may be. And so, I think for most people, they would agree that if, again, you could magically wave the wand about solving all of the problems with collective code ownership in their mind, that the benefits are true and well worth it.
Andy: Yeah, there was a concept that I think is connected to this, that I almost brought up in our last episode, but I didn’t want to distract from Theory of Constraints too much. And the idea is, a guy named Chris Matts calls it “staff liquidity”. It’s this question of across everyone who can work on things in your system, of those things and of those people, what’s the matrix of your liquidity, of how many different things can be worked on by how many different people, to a reasonable level of competence.
This isn’t to say that everyone is a complete expert in every single aspect. That’s not what collective ownership means. Collective ownership means that everyone is competent and empowered to work on all of those things. And what it does, the idea behind staff liquidity, what it does is it gets rid of, going back to theory of constraints, gets rid of all of those constraints in your system. And this is talking about your development system of, oh, we can’t work on feature X right now, because Bob is on holiday for the next three weeks. And if he’s not around, no one else knows how to do this. That’s generally not a great situation to be in. But at the same time, people are like, but I need to know who’s responsible for any problems in this. And it can’t be the group in their mind. It has to be Bob.
Mon-Chaio: And why is that? Why do you think that is?
Andy: Ooh, that’s a good question. So, if I were to theorize a little bit about this, I think it once again comes down to … well, there’s a fear, again. There’s a fear of tragedy of the commons: that if everyone’s responsible for this, then no one will be responsible. And I think there is a desire for consistency. Like, there’s a feeling that if you give it to an individual, a single person will be consistent. They’ll be consistent in how they tell me about the issues in it. They’ll be consistent about how they fix things. I will be able to get a sense of how this is going to get done. Like, I know if I give this to Mon-Chaio, it will take him a week. If I give this to Andy, I have no idea. I haven’t worked with him as much on that, so I don’t know how long it’s going to take him. And so I think it’s that fear of the commons and desire for perceived consistency.
Mon-Chaio: Interesting.
Andy: What do you think?
Mon-Chaio: Yeah, I could certainly see that. I hadn’t thought about that consistency part, but that makes a lot of sense given a lot of our reading around social science and stuff. People like to build relationships and you feel more comfortable the longer you work with someone.
And so if you’ve worked with someone in the past and they’ve done a good job, you’ve built calculus-based trust with that person. It makes it a lot easier, and you’ve lubricated the relationship in that way, right? And so it’s easier to give them that in the future. So, I can certainly see that.
I think one thing we don’t talk about, specifically with this thing about really wanting to be able to ask an individual about it, is again that systems level thinking. It’s really easy to simply say, this individual is going to own it, and then abstract away all the problematic parts of that into aspects of personality of, of, what would you call it? Like missing personality traits when things go wrong. Right, so when that individual owns it, but they were on vacation, oh well, I mean, yeah, but they knew that we were releasing in June, so they should have planned their vacation later. Or if they had particularly tough night with a young child and they didn’t wake up for on call, well that’s their personality trait, they should have been more available. Or if they ended up doing a bad job with it and there was a lot of errors in the code, oh well, you know, they weren’t skilled enough. It’s easy to attribute that to individual personality traits. Whereas, in order for a group to do that, you have to have a strong system.
Okay, you’re right, there is a tragedy of the commons problem. You simply cannot say, well, nobody owns it, the group owns it, so just like email our list, we have no process and somebody sometime we’ll get back to you, maybe, right? And so now you have to have a process. You have to have a process around your SLAs around, do you have a regular, we used to call them firefighters, a regular on day-on-call person. If you do have an on day-on-call person, can they even be writing code that’s on the critical path because they have to be able to answer these questions. If they can’t, that means that we can do less, right, in terms of just sheer output. And so all of that gets raised, and none of it now can you blame on just terrible personality traits. And it’s much harder to reconcile that system.
And so I think for people, and leaders as a whole, it’s a lot easier to take their mental load off and just say, well, you own it, and I wash my hands of it, and now, you do whatever is necessary to get this done.
Andy: Now, the problem at the core of this … I think it’s interesting. So if we believe that people dislike this collective ownership because they feel that they get a consistency out of being able to go to that person and be able to understand that person, and they fear the collective ownership because it will just lead to no one doing anything, there’s a conflict.
Because in order to get collective ownership, you have to be more consistent than if you had individuals by having those processes to keep it working. Maybe conflict isn’t the right word here, but there’s this mismatch in that you believe you can’t do collective ownership because you need that consistency, but you’ll actually get better consistency if you do collective ownership.
Mon-Chaio: Mmm hmm. But it requires more work to get that consistency. Right? Your consistency ceiling is higher. But it requires work. And it requires work with people, which is difficult. And again, this is something that I’ve said over and over again on the podcast. It’s the dereliction of responsibility of leaders. It’s easier just to say I put it on you. I now have my duty which I should be doing which is running the process or running the system, but I’m not. And now it’s on you because the system is just on individual people. I think though, I do want to touch on another part of it, which maybe is bigger in larger companies or in Big Tech.
Another reason I often hear about collective ownership is how can I assign credit. And why do I have to assign credit? Well, I have to assign credit to figure out how much of the bonus to give and who to promote. And these days who to lay off, right? So I think that’s another part of this, uh, well, collective ownership makes it really difficult to assign credit.
Andy: So I would flip that around and say, hmm, that’s an interesting impossibility. And maybe here we can start getting into tactics of how do you deal with these impossible things. And I think the way that you deal with the impossible things is you look for the argument against them and you start working out what is the core of that argument? And then you just ask the question: “what if that wasn’t true? What would the world look like if that wasn’t true?”
So for instance on this one, I have to assign praise to someone. It has to go to an individual. I have to be able to say that this individual is contributing more than this individual. And that means that I need to be able to give each one of them individually their tasks so I can measure them on that output. And only if I have control over that can I provide this assessment. So the core thing here, the core assumption, is that I have to provide the assessment of contribution.
Mon-Chaio: Mm-Hmm.
Andy: Well, what if I didn’t have to provide the assessment of contribution? Or what if I didn’t have to provide an assessment of contribution? Like, you’ve got two sides to this assumption. There might even be more in there, but I’m just not seeing them at the moment. So you have different ways of tackling this, of like, how do you get past the impossible?
Okay, well, maybe I tackle the “I” part of that. Well, what happens if “I” don’t provide this assessment of contribution? What if I just took this to the extreme and I said, well, that’s collective ownership. They collectively own that assessment of contribution. I just say, you know what guys? You know what this is about. Work out how much each one of you contributed that you want to use for your pay reviews.
Mon-Chaio: Mm-Hmm.
Andy: Okay. Yeah, okay. That could be an option. Or maybe I’m like, I have a bit more control over these assessments. Well, what if I just said, I don’t want to do the assessment of contribution. I want to do something else. Okay, well, maybe I have that under my control, that’s in my locus of control, and I can come up with a different thing. But to me, that’s one of the tactics of how do you start dealing with this thing that I assume is impossible, is I have to work through what is the core of why I think it’s impossible? What’s the sticking point there?
Mon-Chaio: Mm-Hmm.
Andy: And then I just have to ask the question: what is a different world where that just doesn’t exist?
Mon-Chaio: I agree. I think often when you end up asking that question, people will come to this point around, well, I don’t have locus of control around that. So, as an example, in my time at Big Tech, we talked about collective ownership. And they said, well, look, the performance review process for this entire company relies on individual ownership. So we’re done, right?
But everybody has their own locus of control. And often when you start to dig into it, and you ask that why question, Andy, that you were mentioning, you will notice that you can get to some sort of solution. And often that solution requires you as the leader to do extra work.
Andy: Or to just do something different from your peers.
Mon-Chaio: Right, actually I’m glad you pointed that out because that itself is uncomfortable. But look, that’s a leader’s job, man, is to get the systems working. And that I think is way more valuable and should take up way more of your time than manager growth and planning their trajectory of how they’re going to get promoted and then figuring out which projects need to be sequenced where and who’s going to work on what like, I often … slight tangent, I think leaders spend a lot too much time working on that, and I think their leaders expect them to spend a lot of time working on that because there’s a mismatch on what leadership really is.
But that would be my thing is think about the system and think about that it might be more work for you and then put in that work.
Andy: Mmm hmm. Work on what the payoff is you think you’re going to get out of this. Work on what those obstacles are standing in your way. And then, yeah, put in the work to get that payoff.
Mon-Chaio: And then the other one that I will say is, if you are one of those senior key decision makers, you are responsible now for perhaps in partnership with HR for your review process, perhaps you are responsible for an entire engineering org, and you have the power to say, look, we are no longer using GitFlow.
I think as a leader, it is important for you to make yourself and your organization uncomfortable. I don’t think you grow without discomfort. So, if you are comfortable, and if you’re allowing your organization to be completely comfortable, you’re not going to change. And a lot of these things that people think are impossible, it’s not impossible, it’s simply super uncomfortable. And so, like, live with that discomfort.
And Andy mentioned this at the beginning, too. It’s not that you have to live with 100 percent of the discomfort. Right? You can say, look, I’m going to pick 20%. I’m going to introduce 20 percent of this discomfort, of this impossible thing. And we’re going to live with this for three months. And we’re going to see. And then we’re going to adjust.
Andy: Absolutely. And I think we’ve gone through it Mon-Chaio. I think we’ve now explained why nothing is impossible, and people can do anything that they want if they just put their minds to it. I think we’ve got a best selling self help novel here.
Mon-Chaio: You know what we forgot though is that open mindedness part about even being open to the fact that these things that are impossible are actually possible.
Andy: That is true, yes. That is the first thing. I was thinking of bringing that up, that one of the steps to doing the impossible is to convince yourself that it is possible. And in a lot of these things, it’s reading up on does someone else do this? And a way of doing that is to have a consistent study habit where you read up on how different places have just tackled problems. Not looking for confirmation of your own practices, but looking for ways that people do it completely different from what you’re used to.
Mon-Chaio: I like that a lot. A friend of the podcast, Squirrel, I think he calls them provocative ideas. it’s very important for us to, as leaders, to entertain with an open mindset these provocative ideas. And I think Andy has given you a great framework for how you can go about doing that. Often, it’s a lot easier with sort of some outside help, right, with a coach? Groups can tend to get insular, and then you can kind of feed into that behavior where you’re saying, oh, instead of helping each other become more open minded, you’re helping each other be more reinforcing of what you already believe. Not always, and I think there are ways around that, but often a coach can help.
And if that’s for you all, both Andy and I do that type of coaching, both for individuals, as well as teams. So we’d be happy to help you out. We’d also be happy for you to reach out to us for any other things that you might think, especially about what you think about the podcast. Comments: did you like this episode, did you not like an episode, or any possible topics that you would love us to cover in our upcoming episodes. The way you can reach us is hosts@thettlpodcast.com or anywhere where we have social.
So until next time, be kind and stay curious.
Leave a Reply