Continuing on Agile Beyond Operations
0:00Well, hello, everybody. It's the 5th of August, 2009, and this is the Agile Executive Podcast, episode number six, which is exciting. And this is a continuation of a conversation we were having between Andrew Schaefer, Israel Gatt, and myself about applying Agile notions to not only just the operations department, if you will, the people who are managing all the machines and servers and applications once they're developed, but as we'll probably get into the IT department itself, as a more Agile way of delivering, as we would say in the IT management world, business services and things along those lines. And to recap, last time we essentially talked about the sort of effect of being more Agile, and a lot of that had, some of the examples we talked about had to do with things like having more frequent but smaller delivery of software, and then, of course, with that comes the ability to be able to actually deploy that stuff into production and all of the IT management that comes along with it, which we spent a fair amount of time hashing over and discussing, because classically, in the IT management world, you're not really interested in deploying things extremely frequently. In fact, change is often the enemy, so this whole prospect of getting a whole bunch of software from the Agile world requires you to start thinking differently as far as the process
Delivering More Software, and Then What
1:18that you use, because you're being called upon to deliver things a lot more quickly and more frequently and so forth and so on. And last time we left off, basically wondering, you know, now that we have these, like, the excellent sort of business benefits of being able to deliver more software more quickly that people actually like or deliver software that has value in it to call back to another Agile executive podcast with Jim Highsmith, then the question becomes, well, so that's like a great, you know, goal in Candyland for us all to get to, but how do we actually get over the rainbow and get over there from the sort of traditional and sort of fundamentalist IT that we might be existing in currently. And, you know, I think that's, this is always the question that after you have a nice little hour-long presentation of fantastic Agilism, you sort of get to the process of the point of, how can we do this? And I think that's one of the things that we're going to sort of gloss over here in this podcast and in so much as we can get into it in a half hour or so recording. And so to that end, after that lengthy summarization, you know, what, to throw the question out there broadly, once you guys have sort of had this conversation to sort of have people let you in the door, so to speak,
First Steps to Make IT More Agile
2:33and sort of want to change their organization around a little bit. Like, what are the first steps that you see groups or organizations getting to when they want to make IT more of an agile environment? Well, this is Andrew. I think that in general, that's sort of a green field. And that's not something that's necessarily happened or happening. That's something that I think will happen in the next coming years. Right now, I think that people, that there's certainly a group of people that are working on agile system administration. But in general, the organizations themselves aren't making that decision so much as people that are actually developing their infrastructure, developing their operations are sort of doing at a grassroots level. And I think that this is, this sort of speaks to the difference between early adoption and crossing the chasm and that whole metaphor. So there's sort of a piecemeal approach where the pieces, of course, are people, and they're starting to do these practices on their own rather than starting from the top, if you will.
Sysadmins Adopting the Practices Already
3:50Well, you have, so the agile has been shown to have some success. It's also had some interesting implementations along the way. But there's, there's sys admins who've been exposed to these ideas, who are adopting agile practices in what they're, they're doing and they're exploring it. And then as we sort of alluded to, there's, there's also emergent best practices that are being driven by the sort of the scale and, and the SLAs that are involved building these large web applications. And, and that's sort of driving, I think the, the confluence of both of those things are, are sort of creating this emergent, um, what I'm calling agile infrastructure, agile operations, um, best practices. I would second Andrew with respect to actually an experience that I had a few years ago with agile development. It is not about IT management, but I think the lesson applies. Uh, I was starting an agile rollout and I was expecting that, uh, it will be 50-50. Namely, 50% would be bottom-up, 50% would be top-down.
Twenty Percent Top-Down, Eighty Percent Bottom-Up
5:05What I very quickly realized is that I only needed to do about 20% top-down and 80% came bottom-up. I asked one of the developer, development directors, well, why did you not, guys, why did you guys not do agile before? And I got the answer. Your predecessor would not allow us. So to me, the natural gravitation issues of people are solving the actual problems at hand. And people in the trenches, as they have, they first have knowledge and experience with the various problems, tend to figure out, uh, things that help solving, even if they don't have a full theory behind it or do not have the support from the executive level to make it happen. Yeah, that, that, that raises a, you know, an interesting question when it gets to, uh, to change management. And that's like looking at the, uh, looking at the operations people or the IT department as a whole, like what, when, when, when you're having these discussions, like what do you see as the, um, I don't know exactly what you'd call it, but what, what are the motivations people
What Actually Motivates People to Change
6:22have to change or not change? Like what's motivating them to like, look at the way they do things and do something differently? Like what's the frame and context for that? Well, I think that, that's, that speaks to the human condition. And I think you, you kind of have to look at the culture, uh, that's built and what people are trying to deliver. You know, if you have a, a culture that at the top doesn't value the work that's done at the bottom, then that it's in my experience leads to a group of people that are, you know, just punching the clock, trying to get whatever they can done. Um, you know, if they're, if they're on fire all day and they, they keep saying, help me, help me. And they don't get any support from the organization to put out fires and they become less and less, um, it's sort of a learned, a learned hopelessness, learned helplessness situation. So, so their, their goal is sort of just to pass the time and get paid for it. Sure. And, and I have, I feel when you, so this is if you start a new job, because I've never, I've never really been an executive, uh, in the capacity that Israel has. I've never managed thousands of people. Uh, you know, I've worked on, on small teams and startups and, and when you start a new, uh, position in my opinion, and I'm sort of, uh, I, I, I like things
The Window of Opportunity When You Arrive
7:39to, to be better, whatever that means. That's sort of a nebulous thing. But when you, when you first come to, uh, to an organization, you sort of have a window of opportunity to, to influence the way things that are, are being done. And you come in and you, you analyze what's happening and you analyze what needs to be done and, and you can make suggestions. And, and if you have successes, uh, at the team level, then, then that gives you some, some social capital to, to maybe do something again. And if you do that, I've, I've, I've in the, in the past, and we can talk about some of these in specific, um, had some success managing up and having, uh, you know, relationships with my managers and the executives and getting some, some buy-in for, for ideas about how I wanted to, to change things and how I want to do things. And as you get success with that, then, then that's what keeps going along. And in my experience, and, and I, I'd certainly love to hear Israel's perspective on this. You, you generally have success, uh, with agile, when there is a, a knowledgeable, um, and capable sort of agile champion who can, who can make it happen. Um, not by himself or herself,
Leading People to Water
8:54but by, uh, by, uh, by influencing and by, um, adding ideas to the discussion and by pointing people to resources and, and essentially leading people to water, if, if you will, except the metaphor. Right, right. How about yourself, Israel? Well, I think that there are two aspects to it. And Andrew, you clearly highlighted one aspect, which is the know-how and, uh, you know, years ago, we might not have had the know-how with respect to agile, but at this point in
Know-How Is No Longer the Missing Piece
9:29time, there is, uh, a body of knowledge which is available to anyone who really wants to get into it. And I'm very much hoping that we should start developing, uh, this kind of know-how with respect to agile in IT. For example, Andrew's first coming presentation in agile 2009 in a few weeks. Now, the other aspect of it, which I deem to be the executive responsibility is creating the conditions under which the natural desire of, of folks to do better can be implemented. And I would
Targets That Break the Laws of Physics
10:13say if the overall equation of what needs to happen is overly constrained, for example, it must be delivered in three months even if it's, it's against the rules of physics, then the executive cannot tap into the natural desire of folks to do better. If the executive is able to set up, uh, the overall operation in such a manner that they, uh, do, uh, that they do better desire, has an opportunity to spark, then it will. So I consider it to be a major responsibility to try to construct an environment within which the natural tendency of employees can add up and build on one another. And when this does not happen, I usually, uh, look into what I'm doing and trying to see where I am. But the desire to do better, I think is universal. And all you need to do is give the fertile ground in the place, uh, for which to really take off.
What Bottom-Up and Top-Down Have in Common
11:31Yeah, it's, it's interesting. I mean, there's one of the, the common threads from, from a small organization, like, uh, whether it's a startup or whatever, or you're, or if you're managing from the bottom, if you will, if you're taking a bottom-up approach like Andrew was talking about, and then the sort of, uh, larger organization and, and, and managing from the top or, uh, a top-down approach like Israel is talking about. One of the, the common thing there is to, I mean, and this is, this is true of change management of any type, but essentially to set yourself up for very small, successful wins in order to not only demonstrate that these things work, but more importantly, when it comes to changing the, the cultural and the people to sort of, I mean, to put it one way, just to sort of raise morale that things can actually get done and that this stuff is actually going to work and to make people happy with it. And it seems like in, in both capacities, there's, there's ways you can set up projects, if you will, such that you can initially have a lot of small successes that you can sort of bank up the credit for, if you will, to start getting bigger successes. But it seems like you have to build up to having larger successes either way. Well, I would say the art of agile, uh, in many ways is accumulating those, uh, small successes
Making the Iterations Add Up to Something
12:46to add up to a much larger success. So in a way, it's a little bit like trees and forests. You are definitely focused on succeeding with this iteration. And then next week or the week after, you are focused on the succeeding with the next iteration. At the same time, you need to see all of those and plan for all those successes to add up in a way, uh, where the whole is bigger than the sum of the parts. And I would say there is a fascinating analogy here between the technical side and the managerial side. I believe good agile programmers are able to, while focusing on their current task, at the same time, to be able to keep in their head the overall layout of the land of the release. In a similar manner, a good manager, while celebrating each and every accomplishment, has, at the same time, the bigger success of the whole organization in mind, and he or she builds to us by a sequence of small successes which build one on top of the other.
Lisa Crispin at the Salt Lake City Roundtable
14:08So this was a few, a few months ago, probably five, six months ago, uh, Lisa Crispin was at the, the Salt Lake City Agile roundtable. She was coming through town and, and she stopped in and she, she wrote a book about agile testing and, and she's, uh, got some ideas of her own. But, well, one of the things that she said during that roundtable that, that stuck with me, and it was something I, I knew, um, from personal experience, but she articulated it in a way that just really struck me, was that the, the business that she was in, that, that there was this transformation at some point, when, when the, the testers, um, the developers and everyone went from having their roles and, and their jobs to really understanding the business. And, and I think this, this sort of goes to the, and, and correct me if I'm wrong, but sort of the heart of what you're talking about, that if you understand this larger context and, and particularly if you have a culture where, where the testers can, can talk to the developers and, and, and make suggestions. And the testers, because they understand the business and because there, there's a culture of respect, they can talk to the, to the business people. They can talk to the, to the marketing people and the sales people.
Does This Feature Pass, or Do We Make Money
15:23And they're constantly, they're not just thinking about their responsibility, does this feature pass? But since they're thinking about, does this application fulfill the, the, the mandate of this company? Are, are we going to be able to, you know, for lack of a better metaphor, make some money? Um, and, and, and I think that once you get a culture that everyone understands, um, not just what they're doing, uh, for their, you know, particular task of the day, but what the business does, why the business exists and, and kind of internalizes that in a way that they're proud of. And then, then I think that's, that's one of the things that, that really unlocks the, the potential. And, you know, this is, this is sort of, you know, obviously a, a kind of purposely naive and, and somewhat rhetorical question. But anytime there's these kind of basic precepts that, that I come up against, I'm always curious in, in asking the question, like, why is that important? And, and I think this, this issue that, you know, you get to of having, uh, whatever you want to call them, individual contributors or, or sort of individual employees, kind of understanding the overall business context they operate in is, uh, you know, it, it seems like something that would be, uh, that would be valuable. And yet for as much as people talk about achieving that, obviously it's something that doesn't really happen very often.
What Individuals Get From Business Context
16:42It seems in, uh, in, especially in larger companies. And so, I mean, I'm curious, like from the both of you, like what, especially in the context of, of whether it's, you know, in the context of the IT department, whether you're developing software or helping deliver that software, like what value that the individuals get by sort of understanding the overall business context or the serve, the business stuff that they're delivering? Well, I think that it, it creates, if it's done properly, it creates a community of interest. And, and I think, and this is all just hand-waving and observation anecdotes, but if you have a culture that values that whole organism, that, that whole company, that whole, there's respect between every, every worldview, then, then you get a different kind of sense of pride. Uh, and, and, and you want to go, you want to go to work. And if you have a culture that, that hoards information and, and has, uh, sort of a habit of blaming, uh, the other side of the boat for, for the leak, then, then, then, then, then it's destructive.
The Fifth Dysfunction: Not Focusing on Results
17:59There's a, there's a book called the, the five dysfunctions of a team. And the, the last, the last dysfunction is, is not focusing on results. And, and what comes out in that is you have situations where the, the company's failing, but, but different organizations don't think it's their fault because they did X, we did, we did, we did great on X. Um, but it's those other guys over there in, in IT or those other guys over there in, in development or it's in software. It's always QA's fault, right? If anything's wrong, it's always QA's fault. I don't understand that mentality, but it seems to be pervasive. So it, it, it, it seems like, you know, what you're saying is, is, um, part of understanding the context is there, there, there's sort of another step in there and that's sort of, uh, wanting to care about being successful at the larger context or the larger business that, service that you're delivering. And so if you actually care about, if you up, if you up your caring beyond your individual role, so to speak, and you're more concerned as, that IT's doing their job to the overall company, you know, using IT to help support whatever business the company organization is doing, then even though something may not directly be your responsibility
Fewer Leaks, and Less Arguing About Whose Leak
19:14or it may be easy for you to sort of like slack off, essentially, you'll be more likely to make sure that IT is doing their job at, you know, at, at a, at a quality level, if you will. And then ideally what that means is that there's less leaks in the boat or when leaks occur, as they so often do, they get fixed a lot faster because you spend a lot less time worrying about whose job it is to fix the leak and you just go and fix it. Right. I think, uh, this is, this is borrowing from Alistair Coburn, um, but there, there is only us. If, if you can create a culture where everyone, everyone believes there's only us and it's not developers and IT and QA and, and sales and marketing or whatever, then you, you can do a lot of things that you can't think about if everyone's worried about covering their, their proverbial donkey all the time. That's right. Oh, let me ask you a question, uh, Andrea. Uh, like you, I am very, very fond of Alistair's, uh, quick, there is only us. I can, however, interpret it in two possible ways and maybe both, uh, uh, you know, both are appropriate and that's where I would like to have, uh, uh, your own good counsel.
There Is Only Us
20:30One thing is that in terms of the resources that are available to carry out a certain task, there are, there is only us. Another interpretation is that it's not a matter of I doing this task, you doing that task, what I'm doing another task, but that there is a business of us as a team doing things together. I would, I would say, and, and I don't want to put words in Alistair's mouth because, yeah, God help us. But I would say it's the latter, uh, that there, that the, the, the sense of unity more than the sense of the limits of our resources. Well, you know, this is fascinating as in my practice, usually I watch for one indicator, which tells me that the R&D director or vice president with which I, to whom I consult, reached a certain level of comfort with me.
"We Need More Appreciation of Each Other Here"
21:45And this is when he or she usually says, after we talked about in introductory meetings, after we talked about millions of things related to the do it this way and the do it that way, et cetera, when he or she says, we need to have more, uh, appreciation of each other here. And when I dig a little bit into, uh, this kind of thing, usually the true story about the dynamics between professional services and sales and customer support and engineering come, uh, come out loud and clear. And then it's relatively, once you get that, it's relatively easy to start working on the right model of governance for this kind of environment. But to me, what I have found, as long as we are talking about the technical aspects of agile in one fashion or another, the conversation is usually not deep enough. It's when the person on the client side says, well, and we need to be able to appreciate each other better here when we get into the root of the problem. Yeah, you know, I mean, this discussion makes me think of another sort of, uh, change conflict issue, if you will, in the sense that there's, uh, no, no, no matter what you're doing in, in IT, if you're developing software or delivering it or whatever, there's, there's certain roles that are defined by the technologies that you're using.
Skill Sets Against Organizational Structure
23:18You know, if, if you're in the process that you're using, like if you're, if you're doing, if you're a tester doing the QA stuff versus someone developing the software versus a system administrator or a DBA sort of taking care of the technology in a running state, there's definitely skill sets involved. And it seems like, well, it's more than it seems like the organizational structure that we have to take care of that is to assign people is to make someone's role into what their job is, which translates into what their identity is within a company. And then everything, of course, when it comes to, uh, compensation and all sorts of things gets tied to what your, uh, your job is, what your sort of identity is. And yet for, you know, you know, taking the, the sort of extreme version of the metaphor, there's no, you know, there's only us or whatever. You start to get this conflict where it seems like the, uh, the organization wants very much so there to be individuals instead of us's people who aren't interchangeable. You know, you don't, you don't want people to be interchangeable necessarily. They're very specific in what they do. They're a specific type of cause. And so I wonder when, uh, you know, when, when you guys are thinking about or when you've seen IT departments sort of trying to get into this more fluid us state, if you will, like how they can cope with the more static nature of jobs and roles that companies typically have.
The Monkey Wrench: Incompetence at Every Level
24:37Well, I, uh, I, uh, I don't necessarily want to throw too big of a monkey wrench in the middle of this, but I think one of the things that is, is often, uh, neglected in discussions about implementing agile or implementing technology in general is, and, and, and while you want to create a culture, uh, of us, there, there, there, there is, uh, a potential for, uh, what's, what's, what's the right word? Incompetence in, in every level of your organization. And if you don't create a culture that, well, on one, on one hand, you want to have a culture of tolerance and a culture of trust and a culture of respect at some level, you need a way to, uh, eliminate certain, certain people, uh, from that circle of us, um, circle of trust. And, and, and I'm not sure how, I, I've, I've, I've never seen people do that very well. It always seems to be, uh, clumsy and bloody and you end up carrying, uh, some people along too, too much. And, and that's, that's, that's a drain and it's bad for morale. And yeah, I don't know.
The Urge to Belong, and Carrying People Too Long
25:53I'd, I'd like to hear your thoughts on that type of topic, Israel. Well, I think in every one of us, there is a tremendous urge, desire to belong. And the phenomenon that he described, namely, who is us and who is not us, uh, and the reason that sometimes we carry people, uh, longer than, uh, perhaps we should have, I think it's because at a certain level, we all have this as a universal urge in us. We want to belong, we want to belong. I caught a talk a little bit, uh, earlier about the identity and I think particularly to people in our profession, namely software engineers, uh, a big part of our identity is really tied into what we do and the groups that, uh, you know, we belong to. So, for example, not all of my identity, but part of my identity at this point in time is agile and the fact that I am accepted by, uh, various people, uh, as, uh, you know, as an agileist means, uh, means a lot to me.
Why Drawing the Line Is Always Bloody
27:11So, uh, so, who, uh, belongs and who does not belong is something that, uh, you know, by the nature of the strong desire is always, as you called it, bloody. It's not, uh, you know, it's not something that is easy to define a line and to execute to it. Does it make sense to you? I think so. I'm going to, I'm going to further, uh, take us off course here. The, uh, have you guys seen some of the, there's an article, uh, that came out about how, uh, we as humans, we, we prefer essentially confidence, uh, to, to actual competence in, in many cases. Oh, yeah. That's it. It's like preferring sugar to whole wheat bread. Yeah. I don't know. It's been passed around on Twitter for a while, but this article came out that said that in, in general, we'll put our faith, in our trust in, in someone with a lot of competent or confidence. Um, and I think in, in some cases it's because we don't have a, a way to measure, uh, competence, but we can clearly, you know, on a psychological sort of intuitive level, we can, we can tap into confidence.
The Dunning-Kruger Effect
28:28Right. And you, and then you, you kind of cross the implications of that with, with something like the, the Dunning-Kruger effect. Are, are you familiar with the Dunning-Kruger effect? Not that I remember. What is it? So, so the Dunning-Kruger effect is a, it's a cognitive bias. And basically it says that, that people, uh, incompetent people will reach erroneous conclusions and make unfortunate choices. Uh, but their incompetence robs them of the, uh, metacognitive ability to realize it. Okay. Uh, incompetent individuals tend to overestimate their own level of skill. Uh, they tend to fail to recognize genuine skill in others. They, they fail to, yeah, it's, uh, you can, you're, you're basically not smart enough to realize you're not smart enough. Exactly. Which is, it's a, it's a, that's a, uh, that's a terribly recursive condition to be in. But, but I think you have, uh, a situation in, in IT, uh, and in, in software development and in agile where, where people have, have confidence. And, and they can certainly do some things, but they don't necessarily have a high level of competence.
A StarCraft Player With No Feedback
29:46And they don't, and they don't have, uh, proper feedback to, to recognize that. And this is a metaphor that you might not understand this metaphor, Israel, but hopefully someone, all two of you that are listening to this podcast are, are young enough. And, and maybe, uh, I don't know, geeky enough to, to understand this reference. But there's, uh, people play video games and, and you play a game like, this is a, maybe dating myself, but you play a game like StarCraft. And you, and you play this game and, and you think you're good. And then you, you know, you play with all your buddies and, and you're the best one. And then you go on online and you play on Battle.net and there's 14 year olds that play this game 24 hours a day and they'll destroy you. And, and I think in, in a lot of IT organizations, you have someone who's sort of the, the expert, the best one. They've been there forever and, and they're not necessarily pushed to learn. They, they're, they're the best one on, you know, in their neighborhood. They play in the, you know, the, the game at a certain level, but because they're not exposed to how that game could be played on a higher level, they never really get any better. Right. They don't have very effective benchmarking for rating their skills. Even if you have, even if you have something like, you know, in, in, uh, in a lot of agile sort of processes, if you will, and, and in other processes to be fair, but agile has a,
Faster Feedback Cycles as the Corrective
31:07has a particularly an emphasis on faster feedback cycles, meaning that hopefully you find out faster that you're doing well or you're doing poorly a lot faster than you would in a longer iteration. So in theory, you should have more data that sort of allows you to make a judgment about the, uh, uh, the success or failure of whatever you're doing. But now that's definitely, definitely. If you, but if you're staying in the basement with your guys, that's right. If you're in the confines of your own organization, you have nothing to compare it to except yourself. So all, you know, is basically percentages, you know, if you're doing better or worse, but you don't know, like if you're doing, you don't know how it, what, what your rating is versus everyone else in the world necessarily. I can't remember where I can't remember where I first heard this. And obviously it's more complicated situation than, than being able to actually implement this every time. But there's a saying that if you're the, if you're the smartest one in your, in your IT organization, it's time to look for a new job. You know, Michael Ma, who is an associate and a wonderful metaphor about measuring, uh, software performance metrics. He basically says, look, it's like riding in an elevator.
The Elevator You Are In, and the Other Elevators
32:22When you are in the elevator, you know, of course, uh, what the other folks are in the elevators, in the elevator are doing, and towards what floor you are heading. However, you have no idea whatsoever about who is in the other elevators in the building and what they are doing and where they are heading. It's only when you step out of your own elevator and look, look at the dashboard indicating where the various elevators are, that you start getting a sense of what you are doing versus what other folks are doing. And his, uh, metaphor is about software benchmarking, namely the fact that I or my team or we think that we are doing things greatly, uh, we are doing great things. Well, to itself, uh, maybe it's a confidence, but it's not really meaningful unless you compare it to other folks who are doing software in a similar field. And my own experience at BMC at the time when we did the study with Michael was that the data that he provided us against industry norms was of immense importance
Calibrating Against a Broader Context
33:42in terms of our understanding of what we do well, what we do not do so well, and what are some of the things that we can derive out of comparing to a much broader context than our own development show. Going back to Andrew's metaphor about the person who plays our video games very, very well, I think the metaphor holds up to a point, namely, we have data coming at us, not necessarily from within our own development team or our own IT team, but from things that happen in the world, it's a little bit more, I believe, like a chess player, I get additional data, and I analyze it by looking at the games of the greats, looking at new games that just have been published, looking at analysis, and in the technology area, this is basically the technology trends that get added, and had better be added, to what we are doing on an ongoing basis. I think, I agree with you to an extent, in the sense that you need data that's coming from outside, I think that there's other avenues where you can get information,
Blogs, Mailing Lists, IRC and Twitter in 2009
35:07and it's not necessarily pure numbers, it's not necessarily pure data, but for example, if you are a developer in 2009, there is a lot of information available on blogs, on mailing lists, on IRC channels, on Twitter, and getting involved in those discussions, if you're being honest with yourself, and you haven't got a case of Dunning-Kruger, then you can quickly assess where your deficiencies are relative to these discussions, and I think maybe, in a roundabout way, this is what I'm getting at, that at the heart of Agile, whether you're talking about IT, or development, or applying it to business process, or anything else, in my mind, the secret sauce is being able to reflect and adapt, and if you can't get to a level where you have some self-awareness of your deficiencies, and you're being honest, and you can get rid of whatever self-deceptions you might have, then it's very, very difficult for you to adapt in a meaningful way, or reflect for that matter. And I think this ties nicely into the business of the confidence versus competence that you mentioned a few minutes ago, Andrew.
Safety to Admit You Are Not Good at Something
36:27So, to me, the confidence or the environment within which a confidence can flourish and the people feel safe is a major executive responsibility. Namely, at the point in time in which I can get criticism, constructive criticism from my peers or from a blog, etc., and say, "Well, I'm actually not too good at doing X, Y, Z," then the impediments to progress, you know, are taking out of the way. It's when I am feeling insecure, and extremely worried that Andrew would outshine me, or Coté would do a better job than me, etc., and I refuse to admit it. This is when I stop developing as an individual, and the team does not move forward towards there is only us." So, I will agree. I think that's a great summary. Well, with that, we should wrap up this episode. I think we've actually hit upon some interesting things that sort of, like, dips beyond, as I always like to do,
Past the Motherhood and Apple Pie
37:42sort of dips beyond the motherhood and apple pie statements, like, "We've got to change," and "Change is good," and so forth and so on. There's some nice, meaty things to latch on here when you're sort of trying to tackle these problems. So maybe next time, we'll talk about things that are more technical. That's right. Well, you've always got to lay the foundation for technical things, right? But maybe that is, like, the open question is, like, what, you know, this being in the realm of technology, of course. Like, what are the technologies that, once you have the sort of, like, confidence and skills and you're thinking about us instead of me and everything, like, how is it that we can use technology to make that even better? Because otherwise, we might as well just be, you know, working with a bunch of rocks and sticks and everything. You can navel-gaze about anything, Coté. That's right. Usually people have a navel, so it's always handy. So on that note, unless you guys wanted to add anything else, I think we might as well wrap up. I'll just add one little note that I think that there's – people say that it's dangerous to go meta, and certainly that's not Alistair Coburn. But I think that meta is only good if you can bring something back, if you can bring something that changes your behavior.
Meta-Analysis Against Navel-Gazing
38:59So I think that on some level, what we just walked through was a lot of sort of meta-analysis. But if you can't bring that into the concrete practices and behavior, then it's just – that's where you get the pejorative navel-gazing. And let's do the meta, or bring the meta to the pragmatic, the topic of our next podcast. That sounds good to me. Well, with that, thanks, everyone, for listening, and we'll see you next time.
Machine transcription, lightly formatted. Chapter headings were written from the transcript; speakers are not identified, so nothing here is attributed.