Pragmatic 18: Mediocrity, Consensus and Perfectionism

31 March, 2014

CURRENT

John and Ben tackle design consensus and dictatorship/auteur styles of design development. Is the dictatorship model better and if so what makes a good dictator?

Transcript available
Welcome to Pragmatic. Pragmatic is a weekly discussion show contemplating the practical application of technology. Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode is sponsored by Typeform. We'll talk more about them later on in the show. I'm Ben Alexander and my co-host is John Tridgey. How you doing, John? Hey, Ben. How's it going? Doing well. Awesome. Okay. Well, we're going to dive straight in today and today we're going to talk about a bunch of different things, but I'd like to cover a few things, I guess, but it's about mediocrity, consensus and perfectionism. Uh-oh. Yeah, I know. I have my reasons for wanting to talk about this one. I realise that it's a bit fluffy, but that's okay. We've had some pretty heavy technical episodes for the last few, and I think it's good to sort of mix it up a little bit. Yeah. Because when it comes to this sort of thing and you're doing this for a living, it's not just all technical. And it reminds me of something that one of my favorite managers of all time, a gentleman by the name of Robin McKenzie, he would say to me that 90% of problems that we face in business are not technical problems. They are people problems. And the longer I've been doing this, the more I agree with his words. So, anyway, let's start by talking about consensus. And the reason I want to talk about consensus is, consensus is, I think, very widely misunderstood. The technical definition of consensus, consensus is the community resolution when opposing parties set aside differences and agree on a statement that is agreeable to all, even if it is only barely. Now, that's sort of, I looked through a bunch of definitions, but that one fits my feeling the most for what actual consensus is. And the key elements of that is that there is still potential disagreement. However, there is a minimum level of agreement. Right. It's enough that no one's saying, "I'm out." Yeah, exactly. So, you reach a compromise to a point at which you can move forward. And the funny thing is, someone said to me years ago about compromise is that if two people compromise, no one's getting what they want. And it's a very black and white way of looking at the world, and that's just not how it works. Consensus means that each side gets something rather than both sides getting nothing. Why consensus matters? Okay, so when I'm talking about this, I'm talking about design. So I'm focusing on design here and honestly, it applies to a whole bunch of things, not just design, but let's just stick with design as the lens for looking at this stuff. So let's say you've got a design team. is not relevant but more than two. So we'll assume three or more in your design team. The larger the team the bigger the problem. So the problem is you have a design decision that you need to have resolved and let's just make it something simple. You're writing an app and you want to agree on the font. I say font because I find that funny and I find it funny because it's the sort of detail that 10 years ago I wouldn't have given a fig about. Yeah. Maybe it's something that's happening to me with age. I don't know what's going on. It happened to Marco Arment as well. So, you know, people get very particular about the font. So, anyway, all right. And this does actually come up and did come up in my career. So, everyone in the room has a different opinion about what the best font is and why. And in the end, reaching a consensus amongst everybody is considered to be the best way to go. But the problem is, what if that consensus changes the product to a point at which what you're delivering, well, frankly, to the majority of people outside the group, people that are maybe end users that are going to use this, what if they really think it detracts from it. It makes the overall product worse. And the problem is you don't really know that. And because it's a consensus, you have to try and give some degree of, well, concession to everyone to get a consensus. I guess that there's all sorts of other problems. It's because consensus is driven by a democratic process. And I'm not talking about democracy and dictatorship not in the context of a political system. I'm just talking about a microcosm of people in a room trying to figure out what they should try and do with their design. I'm not talking about democracy versus dictatorship versus any political system at all. This is not a political discussion. I'm just using them as a metaphor or using the model of that. Yeah, exactly. So, in an environment like that, it seems fairer though, doesn't it? It's like, you know, we're going to reach a consensus, so everyone sort of agrees, you know. It seems to be better and fairer because, yeah, everyone gets a say. But the problem with that is that, well, how do you vote if you've got a tie break? You know, how do you decide? There's another issue with groupthink. Is there actually independence amongst the group? So, Is it a safe place? So, let's say you got 10 people in the group. One of them happens to be very loud, very opinionated, very strong, stubborn personality. Worked with plenty of them. Been accused of being that and may or may not have been in some situations. Does that put you in a position where you are free to state your case? Yeah. Is it okay to say, "I think that we should go with Monaco because I like monospaced fonts or whatever the hell. You know what I mean? It's like, but if you've got people in the group that are just, "I'm sorry, but you know, we've all agreed previously that that is not acceptable." And then people sort of like lower their hand, right? And they sort of shrink down and, "This is not a safe place. I can't tell you what I think because you're just going to shoot me down." So, the problem, that's just one problem. Okay, then of course you've got the other problem is the single dissenter. The guy that says, or sorry, I should say, the person that says, no matter how many times you go over it and trying to build a consensus, they put their hand up and they say, "I'm sorry, but I just can't agree on this point." And it's usually a point that they've already debated and lost, but they keep harping on about it and on about it and on about it. They just will not let it go. It's like that person feels like they're the only person in the room that sees the real problem. Yeah. Everyone else doesn't get it. And all of this stuff also is driven heavily by bullying. So, yeah, like I said, the loud person in the room, they're bullying and they're undermining other people to get things to be done their way. You have any of these elements, is it really a consensus? because I argue it isn't. And I've been in so many reviews where people have said, "We're here to reach a consensus," and I'm like, "No, you're not. You're here to browbeat other people to seeing it your way and rubber stamp it." Is this something that you've ever came across? Yeah, absolutely. We did web development design and we'd also had a marketing communications wing, half of the company. So I kind of see it from both angles, you know, where we'd be brought in as we'd be consulting with someone, be, you know, working with a client, and, you know, the boardroom pitch, right? Where like, here's the idea, here's what we're doing. And there's five, six, seven people in there with various degrees of qualification to make the decision. And that game of politics, honestly, that you're playing, it's political. I mean, talking about dictatorship and democracy is the right call there. But that's kind of almost another issue, is like that gets really complicated and get tied up with that sort of business model there. But internally, like working with designers, working with a team, our biggest, we had nine people. And granted, I was like, you know, in my early 20s and not a good manager. And I probably leaned too much on that, thinking of it, thinking about it, I was being nice or being inclusive and I don't think that was a good thing. It's really easy to let things drift that way. Other thoughts about it too, that maybe at the same time it was a little bit of a show because ultimately I still made all the decisions. I could control the way things went. Yeah. So, yeah, it's complicated. Yeah, I know. Absolutely it's complicated. I wanted to talk about it is that this isn't straightforward. And, you know, what I get so frustrated with is the general belief is that a consensus-driven design is somehow a better design. And what I struggle with is that time and time again, I have seen that fail and I'm trying to understand why and what went wrong. So, I've listed a whole bunch of different things about how I think it can go wrong, some of which you've seen. And I want to talk about the flip side of that, which is that's a democracy angle. Let's talk about the dictatorship angle. All right. That's better. Oh, that's better, isn't it? Let's just all switch to being a dictatorship. It's funny because I hear different angles on this one. The first person that springs to mind, the classic example, is, of course, Steve Jobs. Now, do you think Steve Jobs believed all that strongly in consensus because I'm not convinced that he really did. Okay. He was more of a, "I think that these are the following things that matter, and we are going to do them this way, and you need to get on board with what I want to do." And he was sort of the guy that had this final say over, "Oh yeah, this is good. That's no good." And that's it. It did not appear based on everything that I've read, everything that I've heard. I didn't know the guy. I never sat in any meeting rooms with him. But for what it's worth, it sounds very much like it was run more like a dictatorship. It was run to his level of taste. Now, maybe I'm attributing too much and I'm reaching a little bit there. Irrespective of whether I am about Steve Jobs, I have met plenty of people that have run their design teams as dictatorships. So, the thing about the dictatorship point of view is that there's sort of degrees of strangulation, I guess, you could call it. There's the sort of a loose grip, which is everyone's fine to go and do and follow the path set out by the dictator, deviate now and then, and when there's a problem, the dictator will simply say, "You know what? You will not do it this way. You shall do it this way." Sometimes they'll explain, sometimes they won't. But in the end, they still have the final say. And then there's too far the other way. And too far the other way is, "I am going to dictate every single thing you do. I'm going to tell you how to write the code. I'm going to tell you exactly every little nuance of everything you need to do to do your job, like a control freak kind of dictatorship. And I honestly think that that can't actually work, but I've seen it. I've been on the receiving end of it, and it's not pleasant. It's terrible. The morale is destroyed, and you're told, "Oh, geez, you're an idiot," and "Why can't you even do something this simple right and I should get a graduate to do this and I expected more from you and oh, good God, I've heard it all, believe me. So, the thing is though, in a lot of those projects, they went on for less time and they delivered comparable results to the more consensus-driven democratic approach. And that's the thing that bugs me because if for all of the things that we say in society about how a democratic society is better than a dictatorship, we say, "Well, you know what? The consensus-driven model will give you a better result, a more considered reasonable result, than a dictatorship model." But the evidence that I see doesn't support that. That's what bugs me. I suppose the problem with the dictatorship idea is that individuals can take it too far. And I think that that's the problem is that dictatorship can work, but it's got to be the right person and they've got to be in the right space. And maybe it's one of those things that it can only work for that person for a while. And, you know, for example, you know how they limit in America the number of times that you can re-elect a president? Well, what I was gonna say is, you know, the word comes from the, it was a Roman office, it was an actual office during the Republic. And you would be made a dictator to deal with an emergency. And then when it was done, you were out of power, you were done, you had no more political career, or you'd be, you know, you'd be sent off to be governorship somewhere. I forget exactly. But it was exactly that, saying that, "Hey, sometimes we just really need to get this done because there's barbarians swarming through and you're the one to do it, but we're not going to let you become a king. Yeah, exactly. So, the point is that it's time limited. And the problem that I see is that the dictators that are the worst are the ones that have been dictators for too long, and they realize that they stop trying to build a pseudo-consensus. they stop trying to explain their rationale and they simply jump straight to the "Just because I'm in charge, that's it." And there's no other explored reason given or required. And that's the problem is that I think that there are some people that simply cannot be trusted with that kind of a role because that happens. Fortunately, not to me, but I've seen it happen to other departments in companies I've worked for, where someone's put in a position of authority in a design team and it's gone to their head in a matter of days. Yeah, power corrupts. I mean, it's... It does. It's true. Some people resist for longer. And I do remember one time I had an argument with someone who was running it as a bit of a dictatorship and I stated my case, I put all the facts out on the table and he said, "You know what, John? I can see what you're saying. You've asked for it now multiple times and I've said no and I'm the lead. So, end of discussion. You have to accept the judge's decision." Now, in that specific case, I mean, I won't lie, it worked out okay in the end doing it the other guy's way. I still believe my way was better, but irrespective, it still had a happy ending. So, from the dictator's point of view, they're vindicated. And that then builds in this overconfidence that they can simply do what they feel like just because, and that's the corrupting problem, the corrupting of their nature. But I still think that there's a window of time for certain people that resist that power going to their head where you can turn out a better design in less time to a higher level than you can with a consensus-driven model. I wish I had numbers to back this up. I don't, but just based on what I have seen. Because the other thing that the-- and we're just going to move away from the dictator word for a moment and going to swap it out for the the auteur. Well, and that's not a bad idea. The word is very loaded, right? It is. You could say prince. You could say... I mean, there's a lot of things you could say. But yeah, so the auteur. What's an auteur? I know the answer, but... Yeah, look, it's... I'm a John Gruber fan. I'll be honest. That is when I learned the word. So, John Gruber taught me something. How about that? There's an article. I read John Gruber's stuff on occasion. And sometimes articles that he's written stick in my mind. There are two that stick in my mind. One is the chair. The other one is the auteur theory of design. And the idea is that the person that has the final editorial cut sort of decision about how things should be pulled together in the end, they set a level, a standard of consistency. And the idea is that that one cohesive direction produces a better quality end result. At least that's my take on that theory. Because the problem is if you don't have someone in a position like that and everything is truly consensus driven, you end up with windows. You end up with five ways of doing the same thing. You end up with a configuration setting for everything you could think of and probably don't need to configure. you end up with the ribbon. You know what I mean? It's like the minimalistic approach, for example, that Apple takes is more of a "Trust us. We know what we're doing." Right. But I do honestly think that is less driven by consensus. That's right. I haven't worked inside Apple, but I know enough about the way that Steve Jobs operated to reach, I think a relatively informed conclusion that a balance seems to be the better approach. And that would be the way that I think that they would operate. Whereas Microsoft tends, seems at least from the outside to operate more like a lot of companies I've worked for, big companies where everyone is given a voice and there's a consensus driven to the design. And there's the guy in the corner that says, "I really think we need to have a switch to change the color from black to white and everyone in the room sort of looks at each other and they're like, "It's 4.59pm on Friday." And they're like, "Oh, give me stupid Switch. Fine. You can have it." And I think that goes all the way down, out the door to the customer. The way that Microsoft makes money and how they worked with business, they're very customer focused in terms of bringing their ideas in. So there's levels of it. There's stages where these kinds of consensus-building meetings could be happening. If you're going to sell some business 80,000 copies of Office, you can bet you're going to listen to what they have to say. Oh, sure. Absolutely. But the other thing is, and I know I've sort of dragged Apple and Microsoft into this discussion, I mean, just from my own experience directly, I've sat in meetings where we've had the one person in the room from the client and they specifically, I guess I'd call them the single dissenter in the consensus driven model, whereby we're talking about requirements definitions and he's saying, "Well, we need to have redundant power supplies to these switchboards." And we're sort of looking at each other and we're, "Okay, we started this meeting with budget is tight and we're looking at design options for this for their water treatment plant and it's like well okay you want redundant power feeds you do realize that this is an 800 meter run that that's going to be some very thick copper and blah blah blah. No rationalization was given, nothing to back up their request requirement, there was no risk analysis done, it was simply I want it because I want it and we're in consensus driven mode. So what did we do? We had to accept it and say, oh, fine, we'll give this guy's redundant power feed. Note to self, they never built the water treatment plant because it was too expensive. Anyway, I think the point of all of that discussion is, in my opinion, a purely consensus driven approach is not going to give you as high quality result or as cohesive a result. And I also think it's going to give you a result that takes longer because driving to get consensus takes more time. And it usually leads to feature creep, scope creep, and bloat in the product. Whereas if you have someone like an auteur looking at this at the end, and jeez, I'm probably mispronouncing that. I think as long as you can pronounce whatever you want, just kind of cool. Otter. Yeah, that's how you should do it. Yeah, the otter. It's an otter. It's the otter. It's an otter. Show title. I don't know. I'm aware of the fact that I have an accent and I've also been told when I went to North America that I don't actually have an accent, which was bizarre to me. Certain people said... I mean, you do, but it's not comfortable. No, I know I mean I could I slide I could slide back into a thicker or the accent say that's not a knife That's not a knife. I see it's not even close Okay, hang on that's not a knife No, I don't know too much time in Canada. Maybe is that you're blaming Canada now What we do look it's yeah, I know that's what you guys do. I don't really I don't know The thing is I see I can hop on a boat and be in Canada in like 20 minutes It's not I know we're digressing, but I'm just gonna get this up. I'm gonna get this off my chest. Okay? Oh, I know I see I see I know that Canada and America are two different countries right I get that I've crossed the border I see the the angry American Border guards, and I see the the pleasant Canadian border guards. That's not a generalization Every time okay So, you know, the point is that I know the two different countries, okay, I get that, but I love both of them. I think you like, I see North America, I say I lived in North America because it's like I lived in North America. Did I live in Canada? Most of the time I did. I spent some time in the States, but you know what? It's North America. You guys do sound terribly similar when you speak and you both love ice hockey and have similar foods and so on. It's like, anyway, so... We're going to get emails on that. Good. Go on. Two blanket statements that aren't true. Thank you. But yeah, I see the rivalry between the US and Canada is very similar to in Australia and New Zealand. So, New Zealanders speak just subtly differently and you can hear it when they count to 10, they say six funny, and they cut out certain sounds when they talk. But the thing is that, to be honest, we have similar political systems, similar currency. We talk very similarly. We are a three-hour plane ride away from each other, so we're geographically close. So, ANZ, right? The ANZ Bank, Australia and New Zealand. And the ANZACs, you know, Australia, New Zealand, Army Corps. So, I mean, we go to war together, we do everything together. And yet, because New Zealand is such a small population compared to Australia, like Australia is something like eight times the population of New Zealand, they sort of tend to cop flack. And such is the case between US and Canada, right? So, Canada gets flak because they're the smaller country compared to the US. So anyway, I see it as very, very similar. But anyway, we're going to get back on track now. We'll get on track because yeah, we could go the other way. Yeah, I know. Okay, all right. So, I think that's all I really wanted to say about the consensus and the consensus angle versus the, well, dictatorship or tear angle. But we're going to circle back to that later. So what I would like to do in the meantime perhaps is talk a little bit about typeform. Sure. Forms are a key component of asking questions online, but up until now they've meant a lot of work to design, configure and administer. And after all that, the results have usually been unflattering. There are form builders out there that take care of some of the problems and make it easier to get something basic up, but creating something great with them is still hard. We need a tool that's easy to use, feature rich, and something it looks and works great on any device. This is where Typeform comes in. Typeforms are beautifully designed and have cross-platform compatibility baked in. They're tailored to look and work differently on desktops, on smartphones, and on tablets. Design is about how it works, and Typeforms are built to really work, regardless of the device. The platform itself is a joy to use, both as a customer creating a Typeform and a user interacting with one. The UI is sexy, clean, and fast, and designing even complex series of questions is made simple through their dashboard. The experience is focused on asking and answering one question at a time so it doesn't feel overwhelming and nobody gets lost. It's like a real conversation. Typeform champions good user experience and design. This helps you create a space in which users will be more willing to answer and more likely to give honest answers. From customer feedback and surveys, contests and landing pages, event organization, in the classroom, Typeform lets your imagination fly. People are using Typeforms in a variety of ways. To make interactive stories, holiday cards, team presentations, avatar creation, the list goes on and on. Typeform is the only online form builder that lets you get unlimited responses for free. As many questions as you want, as many answers as you get, Typeform doesn't limit your interaction. It just lets you ask awesomely. For a limited time, Typeform is offering a three-month free trial of their new Typeform Pro service. Check out what you can build by visiting www.typeform.com/fiatlux. If you like what you see and sign up, be sure to use the coupon code FIATLUX to get your free three months. Thank you to Typeform for sponsoring the show and for making it easier for people to get to know each other better. It's awesome. - Thanks for that, Ben. Okay, so we've talked a lot about the problems in trying to build a consensus, the compromises and so on. And I guess one of the things that also bugs me about consensus is the tendency towards mediocrity. That's the second piece of this discussion. That's the battle between mediocrity and perfectionism. I struggle to flesh this part of the notes out because it's something I feel very strongly about, but it's hard to break it down into pieces. So, I've been accused of both. I've been accused in all my design and development programming activities that I've been accused of being a perfectionist and I've been accused of accepting mediocrity. I find that very amusing considering that those statements were not a great deal of time apart and they were on the same project. The two may actually be connected. Yeah, well maybe. I think it comes down to, well they are from different people that hadn't spoken to each other to compare notes. At least I assume they hadn't. Anyhow, maybe I'll just mess them with my head. I don't know. It's possible. Well, just the pursuit of perfection can lead you astray, right? And you might end up being stuck with mediocrity in the end. Oh, sure. You just don't. You have no other choice, right? What I find is that perfectionism is one of those things that's misunderstood. to want to make something better does not make you a perfectionist. I think the problem is it's the next stage that comes after that. So let's look at design cycle. So feature A is implemented and as it's implemented you go through a testing phase, you circle back and you re-evaluate. Okay, is it working for us? Is it not? The person that said design it in using the A method has a look at it and says, you know what, I think we could show it should do it by method B. All right, fine. So we're going to do method B now. So we're going to go and reiterate. We're going to do method B. Then we come to the end of the method B cycle. We come back to review and evaluate and it looks like, oh, you know, maybe we should go back to A, but we'll tweak it a little bit instead. So then the poor programmer goes back and we go back to rev A-1 I guess or method A-1 and it comes back and they say "oh you know maybe we should do it like method A-1-1" and it's like okay all right we are going to have to draw a line here at some point because we are going around in circles and we are iterating on detail that is so finely granular that it is offering diminishing returns in value. The pursuit of perfection for the sake of perfection is a pointless endeavor because the problem is that perfection doesn't exist. You can't ever achieve perfection. It's like infinity, right? It's a mathematical concept that is not actually quantifiable in the same way that perfectionism isn't quantifiable either. So, I've seen this where on a handful, and I say a handful because honestly, this doesn't happen often, in a handful of occasions where you've got a massive budget and a massive amount of time and you just– the design essentially– I like it to having too much time to think, you know, and the more time you got to think, the more you go over and you question what you thought about what you thought about what you thought about. And before you know it, you're trying to do something as perfectly as possible and you waste all this time going round and round in circles and iterating and iterating and iterating trying to make something better that is not possible to get any better realistically. And that's a big problem. Going around and what I find the issue is that people equate an iterative development cycle with the pursuit of affectionism. It's not the same thing. They're different things. So, if you're prepared to accept the fact that there is some degree of iteration in your design, you're going to have to go around at least once. I think you're mad if you don't go around at least once. And by go around, what I mean is develop a concept, develop a prototype based on that concept and then review, at which point then you can refine or you can throw it away and start over if you've completely screwed it up. There has to be a revisit. In designs where you don't revisit, you just say, "I'm going to do this. I've set my course. I don't care." Okay, well, you are the dictator and you've just lost the plot because no one gets it right. No one gets anything right 100% first time ever. No one. And the higher the complexity of the endeavor, the less and less likely you'll be anywhere near 100%. First attempt might only be 15% of where it needs to be. in order to actually get your product finished. I suppose the point is that you can iterate a couple of times, once, twice, but you know what? Beyond that, you should be asking questions, why am I iterating again? Unless the bottom has fallen out of this thing and it completely doesn't work and doesn't give you what you need and you've missed some fundamental things, some fundamental assumptions you made were wrong. And that is not a pursuit of perfectionism. That is simply development. That's just what happens. So when I was accused of being a perfectionist, that was like the first cycle. You know what I mean? It was not even the second. We developed something. I criticized a few elements of it and said we should go back and redo this, this and this. "Oh John, you know you're being a perfectionist." No, I'm not. Pretty sure I'm not. Okay, you're my boss. Maybe I am. Grumble, grumble. So what about mediocrity? And I guess mediocrity is you accept that substandard is acceptable. You know this thing's wrong with it, you accept that they're wrong with it, and you don't care. You have to get it out for quote-unquote "reasons", whatever the hell those reasons are. And the usual reasons are money, schedule, or boss screaming in your ear. And the funny thing is boss screaming in your ear doesn't always equal money or schedule as drivers. It could just be some bosses like to yell. It could be they have a bonus hinging on it but you don't. That's the one that irks me the most because you don't get to see that bonus. I guess the problem is which way do you want to see it? Which way should you see it? And obviously, mediocrity is the wrong end of the spectrum and trying to be a perfectionist and following a perfectionism approach is also too far down the other end of the spectrum. So, you've got to fall somewhere in the middle. And getting a consensus amongst people where they're all over the map is impossible because you'll have people that are down the mediocrity end and you'll have people down the perfectionist end. And the more people you add, the more variation there is, the harder it is to get a consensus. Yeah, this design thing is sounding really hard, Ben. It's kind of tricky. It's annoying, I'll tell you that. It's satisfying when you're done, but... It's... See, I kind of think this stuff is sort of fun in a weird way because, you know, what you're talking about. I mean, you're right. You're right on. There's this sort of very, very nice, polite fiction that we all like to tell ourselves that getting along and things like consensus are good because they're nice and no one's feelings get hurt. I think it's more just wishing that that's the way the world worked. It's the same way with perfectionism. Like perfectionism is not really about making something perfect. It's more about procrastination and not actually understanding what you're trying to build, what the job of the thing is you're trying to do. So if you recognize that, you can kind of slip through the whole thing. It's hard, and I think it takes a long time to recognize it because it requires real honesty about yourself, too. I think it has a lot to do with actually what makes a good dictator. I guess the next stop after here is the size of the team and the drivers behind corporations and when corporations do develop as opposed to smaller organizations like startups or that supposedly do... I hate using the word agile development because agile is actually a thing these days. It didn't used to be. It used to be a sort of an idea, "Oh, yeah, we're an agile company." Yeah, but now agile is associated with a kind of software development process, which yeah, is another story. So, I guess my point out of all of this so far is, actually, you said something interesting about perfectionism being about procrastination. There's definitely an element of that in there, and that's something that I didn't cover, but you're right. It definitely has an element of that whereby there's a fear of actually finishing, and it sounds so odd. Yeah. I mean, they're related. I guess maybe I worded it wrong, but you'll find the two together. Absolutely. It is interesting, but procrastination comes in many forms, and being a perfectionist is one of them. That's for sure. I mean, the thing is, though, Whenever I look at a design and people tell me, "We're behind schedule. John, we're not here to try and make it perfect." And I'm seeing something that is clearly confusing and wrong. The cost of fixing something that is a defect is amplified the further along the development cycle that you catch it. So, the trick is to have good screens early on. Every test, every review is a screen. How effective your screen is varies but each test is a screen and every review is a screen, an opportunity to screen out defects. If you want to think of it as defects, I find it easy to think of it that way but you know however you want to think about it, problems, issues, inconsistencies, whatever, they're all defects of different kinds. So by me raising it even when they're under schedule pressure. If it's just the first spin through the cycle or the halfway through the second spin, that's fine as far as I'm concerned because I'm trying to catch up the defect now before it gets out into the field and becomes very expensive and very difficult because once some of the software is out in the field it's got a rigorous change control process. You don't just "oh I'll just patch this line and upload it. You don't do that. No, you've got to do your patches, fill in 100 forms, get approval from all these people, may have to do a plant shutdown, may have to do it at 11 59 p.m on a Wednesday for some reason, you know, may have to travel to site which is 400 kilometers away or worse. Yeah, there's a whole bunch of stuff that goes along with this and I mean taking out out of engineering let's talk about I've got a bug in Microsoft Word and I work for Microsoft. I mean now I've got to fix this bug. How many people, how am I going to roll this out? Well it's going to have to get rolled up into the next service pack and then when's that due out? I'll start you out for months. What are we going to do in the meantime? Well it's a big problem. We have to do a separate patch. Okay well that's going to be a separate thing distributed through Windows Update let's say. So there's a whole bunch of other overhead that goes with that. Now if you had caught that bug before it went out into the wild, you wouldn't have any of these issues. Much lower cost, much simpler. Anyway, so to be told, "Don't try to make this perfect." It's like saying, "Well, you want me to intentionally, you want me to accept mediocrity just because you're using, you're saying that I'm a perfectionist because you're saying that as a weapon to stop me from dissenting in the consensus-driven design team. And that's the ultimate problem is that people will use it that way. And that's how this particular person was using it in the case I'm thinking of. So, what makes a good dictator? What makes a good auteur? Honestly, I think that you need to have a lot of experience doing what it is you're doing, not in a related area, but specific area. I don't think that you can judge what the best way is to do something without a reasonable amount of experience. And I don't think some people just have it naturally. I refuse to accept that. I believe that it's something that has developed over time and can only be that way. The other issue, the other issues are they cannot be in that position for a very long time because the longer they're in there, that power will corrupt them ultimately. They have to be able to listen. It sounds simple, doesn't it? Well, yeah. That's one of the things that actually is really simple. It is, but... When you get down to it, you just have to strip away all the noise and all the words that don't really mean anything. Yeah. I loved one design lead I worked for once. He said, "John, you have 30 seconds. Pitch it to me." And I'm like, "When do my 30 seconds start?" He said, "You've lost five seconds already by asking that question." Okay. I pitched him. He loved the idea. We went with it. Hooray for me. But you know what? He listened. He gave me his undivided attention for those 30 seconds. And yeah, okay, I wasted 10 seconds of it. I needed 20 seconds to convince him in the end. But hey, so the ability to listen is absolutely key. And it sounds so simple, but there's so many people that just don't. They say they are, they nod, and when they're done, they just ignore what you've said and said, "Look, I hear what you said, but we're going to do it this way anyway because I'm the lead. - Right, yeah, it's not just listening. It's, you have to be able to listen. You have to have a strong enough command of the language and of the domain that when you're listening you understand and then when you don't understand, you have to have the mental fortitude to try and learn, to try to get at least to the point where you have a successful interface, right? - Yeah. - And you also have to have empathy, right? You need to be able to pick up on the things that aren't being said, and then you have to be insanely, relentlessly self-critical, right? You've gotta be hardest on yourself. - Yes. - To catch those demons, right? To catch the things that make you a bad dictator. - Absolutely right. And there's one more I wanna throw in there as well. And it's a shameless Steve Jobs quote. "The best ideas have to win." - Right, yep. what I was going to say. I love it. I love that. One of the smartest things Steve Jobs ever said, at least that spoke to me. Right. And that's it. Yeah. It's that honesty, recognizing when, "Hey, is this ego or am I really right?" See, the thing that annoys me, well, a lot of things annoy me. No. The thing that annoys me about people that are in that position, that lose the plot is there's an underlying assumption that they know best. There's an underlying assumption that they know better, they know more, that their perspective is somehow of more value. The sad fact is, majority of people do not have good ideas all the time. In fact, I think it's fair to say that no one has good ideas all the time. We each have moments where where we have good ideas and they are spaced out randomly. So if you accept that that is true, and I think most people would accept that that is true, by getting a group of people together, you're not gonna get all of the best ideas sitting together for 30 minutes and talking about something. Some of it's gonna develop with time. Some of it is gonna, you're gonna catch in the second or third or fourth pass, if there is a fourth pass, I hope not, as the design develops, as the group becomes hopefully more cohesive. But the key point is that different people in the group at different times will contribute good ideas. The trick is not being the one that says, "I've always got the right idea," because that's wrong. You never will. The dictator, the auteur will never have all the best ideas. It's simply a function of the fact that they're human. They won't. The trick is identifying the good ideas and picking the good ideas and saying no to the ones that aren't the good ideas. And perhaps that trait more than anything else makes someone a good dictator, a good auteur, I think. Yeah. That the best ideas are allowed an opportunity to win. If I were to rephrase what Steve said. No, I agree. I think if you think about the characteristics of the author of the dictator, having someone that's maybe the word is like the editor, having someone who's or you could say like the hegemon, someone whose power comes from the threat of their power, it's not used. You're not going around exerting it all the time and saying, "This is how it has to be." you're going around doing, you're going around and saying, "I get to say no." I get to decide if it's not good enough. It's just subtle. It's a difference between saying, "I'm saying what it is," and "Hey, you show me what you've got and I'll let you know." I guess that's the other thing. You have to really think about how things work, right? How these kind of relationships and processes all connect and you've got to be really broad in your thinking. I think that's a big part of the Steve Jobs thing, right? That he had that. He didn't really put up these walls and say, "Hey, I know about this and that's what I'm focused on." Because like you said, right? You know, people have... Nobody has great ideas all the time, but everybody's got a good idea now and again that actually plays to the strength of the dictator. If he learns how to go through really quickly and get to the heart of the matter because you can go fast, you can start accelerating. I don't know. It's that's just an idea. It's it's interesting topic. It is kind of organizational psychology and the way way things work because it happens. It's not just like it's in business right. I mean this is No, that's right. It could be five of us hop in the car and we're deciding where to go to eat. That's it. It's always the loudest person. Well, not always, but usually. I've always had a hankering for, insert name of restaurant chain here. Well, right, and that's the other thing. Think about how frustrating it is when, let's go out to eat, where should we go? Oh, I don't know, you decide. Eh, I don't know. (laughing) how much nicer it is to have a good leader, right? To have someone that can manage to do that and you don't have to vote on everything. Because sometimes you just don't want to do it. That's true. It's a chore, right? Dictatorship is a chore. If you want to talk more about this, you can find John on Twitter @JohnChiggy. It's the same on App.net. You should check out John's site techdistortion.com. If you'd like to send an email, you can send it to [email protected]. I'm Ben Alexander, and you can reach me on Twitter @fiatluxfm. You can follow @PragmaticShow on Twitter or @Pragmatic on app.net to see show announcements and other related materials. Final thank you to our sponsor, Typeform, for sponsoring this show. Make sure you check them out, guys. Thanks for listening, everyone. Thanks, John. Thank you, Ben. Thanks, everyone. (upbeat music) [Music] (dramatic music) (music) [BLANK_AUDIO]
Duration 50 minutes and 11 seconds Direct Download
Episode Sponsor:
Typeform: Typeform makes it easy to build and share beautifully designed online forms, combining human creativity with the power of modern, cross-device web technology to create new ways of asking questions online. Visit typeform.com/fiatlux and use the Coupon Code fiatlux to upgrade to the PRO plan and get three months free.

Show Notes

Related Links:


Premium supporters have access to high-quality, early released episodes with a full back-catalogues of previous episodes
SUPPORT PRAGMATIC PATREON APPLE PODCASTS PAYPAL ME
STREAMING VALUE SUPPORT FOUNTAIN PODVERSE BREEZ PODFRIEND
CONTACT FEEDBACK REDDIT FEDIVERSE TWITTER FACEBOOK
LISTEN RSS PODFRIEND APPLE PODCASTS SPOTIFY GOOGLE PODCASTS INSTAGRAM STITCHER IHEART RADIO TUNEIN RADIO CASTBOX FM OVERCAST POCKETCASTS CASTRO GAANA JIOSAAVN AMAZON

People


Ben Alexander

Ben Alexander

Ben created and runs Constellation.fm and Fiat Lux

John Chidgey

John Chidgey

John is an Electrical, Instrumentation and Control Systems Engineer, software developer, podcaster, vocal actor and runs TechDistortion and the Engineered Network. John is a Chartered Professional Engineer in both Electrical Engineering and Information, Telecommunications and Electronics Engineering (ITEE) and a semi-regular conference speaker.

John has produced and appeared on many podcasts including Pragmatic and Causality and is available for hire for Vocal Acting or advertising. He has experience and interest in HMI Design, Alarm Management, Cyber-security and Root Cause Analysis.

You can find him on the Fediverse and on Twitter.