Forsoft EN - 9min iniciais

BRIAN FITZPATRICK: My name is Brian Fitzpatrick. Most people know me as Fitz. BEN COLLINS-SUSSMAN: And my name is Ben Collins-Sussman. Most people call me Ben Collins-Sussman. BRIAN FITZPATRICK: And we're here to talk about working with human beings. A couple little notes, first of all. We're using the experimental service called SpeakerMeter so that you can talk all about this show on the SpeakerMeter site. BEN COLLINS-SUSSMAN: As we speak, you can rate us up and down, which could be very exciting. BRIAN FITZPATRICK: Exactly. So good or for bad, we would love to hear feedback. But thanks to everyone for coming to this live taping of the Ben and Fitz show. As all of you hopefully know, we talk a lot about things related to working with people in computer science, in software engineering. Human beings, otherwise known as a giant pile of intermittent bugs. BEN COLLINS-SUSSMAN: Right. Good way to put it. Really, probably one of the hardest things that we don't acknowledge about writing software is having to work with other people. Right? We study and study how to use our languages and our compilers, and then you get to sitting down to writing in the way as much as the programming language, or BRIAN FITZPATRICK: Right. It's more squishy, it's a lot less deterministic. I mean, your compiler is incredibly consistent. It's going to do the same thing, no matter what kind of garbage you throw at it. Go ahead. a successful engineer-- this is what we tell our friends, we tell our family. If you want to ship software and be really good at engineering, you need to also focus on the social, and not just the technical. BRIAN FITZPATRICK: But it's also key to being an efficient engineer, so you don't waste a lot of your energy bickering and arguing and yelling, et cetera, that sort of thing. So let's get started here. We're going to talk about-- there's four main areas that we're going to focus on in the show today. We're not actual doctors. We should put that out. chemists of any sort. These are just remarkably comfortable, and we think everyone's going to be wearing white in the future. So to start off, we have four different areas we're going to talk about. One is just general personal behaviors, right? You sort of have to get an idea of, how do you like to work? What are you good at working with other people, and where are you bad, and that sort of thing? social dynamics of being honest-- oops, did we lose a mic? Did you turn your mic off? BEN COLLINS-SUSSMAN: I turned my mic off. BRIAN FITZPATRICK: OK, talk's over. Thank you for coming. BEN COLLINS-SUSSMAN: You just talk while I-- You're back on. OK. All right. Well done. OK. Number two. BEN COLLINS-SUSSMAN: Number two, we're going to talk about the social dynamics of being on a team. This is, how do you interoperate with your team, BRIAN FITZPATRICK: And next, we're going to talk about how that work with you that are not in your core team. BEN COLLINS-SUSSMAN: But may work closely with you. BRIAN FITZPATRICK: Exactly. BEN COLLINS-SUSSMAN: And then finally, we're going to talk how you interact with other people who are not on your team at all, probably your users. Probably the most important group you need to work with at BRIAN FITZPATRICK: So we're glad to have all of you here today on this live, taped show. We're going to go to the phones now and take some calls. We're going to start with some questions, possibly work with you're sort of used to working, et cetera. BEN COLLINS-SUSSMAN: Yeah. So questions about personal behavior. BRIAN FITZPATRICK: We have a caller. Go ahead, Harlan. I have an open-source project on Google Code, and I want to hide it until it's totally ready to take over the world. Oh, I also need to wipe all the history before revealing it. Can you tell me how to do that? BEN COLLINS-SUSSMAN: So Harlan wants to hide his source code before it's ready. Until it's ready. BRIAN FITZPATRICK: Well, Harlan, why do you want to CALLER: Well, I don't know. I don't want people to see all the screw-ups I made when I was starting out. You don't want people to see a lot of the mistakes you make in that sort of thing. BEN COLLINS-SUSSMAN: And we all make mistakes as we work. The problem is, it's easy to take it too far. Right? So everyone's a little bit insecure to some degree. And part of it is the fact that we have this concept in our head of people doing miraculous things with software development. That someone like Linus Torvalds just woke up one day, and the Linux kernel sprung out of his head, fully formed, right? And I want to be just like that. And so maybe if I cover up my mistakes, everyone will realize what a genius I am. BRIAN FITZPATRICK: Right. And there's a lot of heroes that we have like that, right? And in reality, these guys, they may be really good, and they may have done something incredible, but they're mythologized to an extent. They don't necessarily deserve every last bit of the credit that they were given. BEN COLLINS-SUSSMAN: They do deserve a lot of credit. BRIAN FITZPATRICK: They do, absolutely. BEN COLLINS-SUSSMAN: So I would say, the thing that you should credit these folks for aren't just-- yeah, sure, they started a project. They may not have done the entire project by themselves, but they actually led a team. They created a team, they organized a team, and started something big, and coordinated something big. And so it had a huge impact. So I think the moral here is that you should be thinking about, how do you work with a team, not how do I present myself as a genius. BRIAN FITZPATRICK: Right. You don't have to hide all your mistakes. Mistakes are OK. Everybody makes mistakes. Let's move to our next caller. We have Dan from Albuquerque. CALLER: Hi. I've been working on this amazing piece of code for a month and a half, and my co-workers keep bugging me to show them what I've got done so far. I totally know they're just going to slow me down. How do I get them to leave me alone so I can code? BRIAN FITZPATRICK: OK. So he wants to live in a cave by himself and write code, and just show up with this sort of finished product. BEN COLLINS-SUSSMAN: Well, he sounds like he's worried about being slowed down by other people. BRIAN FITZPATRICK: Right. But you can be making really great progress super fast, but if you're doing the wrong thing, this isn't really worth it, right? So if you're working with other folks, you need to sort of have that interaction, that tight feedback loop. When you're writing code, you don't write 10,000 lines of code and then hit Compile. Does anybody here do that? Because I don't do that. I don't think you do that. BEN COLLINS-SUSSMAN: You have a tight feedback loop. You write some code and you compile it. Same way with your team. You write some code and you get some feedback on not just the style of what you wrote, but the design of your code, BEN COLLINS-SUSSMAN: That's all right. The question is, any project needs to be in a tight feedback loop of, are you working on the right thing? Did you make the right choice? If you go too far without getting any feedback, you may wake up and discover you've created something that's redundant, or you made a bad design decision that you can't undo. So there's a high risk to working alone for too long. BRIAN FITZPATRICK: There's also, it's a low bus factor, right? If this person in the cave gets hit by a bus, or giant rock falls and covers the entrance of the cave, nobody can pick up that bit of code, right? But more than anything, I think there's just a risk of wasting time. It's one thing to sit down and write a whole bunch of code. much you get written. Right? All right, let's take a new question. We have Bill from Peoria. CALLER: I was wondering how you guys feel about the social issues implied by the use of mitichlorians in Star Wars: The Phantom Menace. BRIAN FITZPATRICK: I think there's only three Star Wars movies. Sorry. Let's take some calls about working with your team. BEN COLLINS-SUSSMAN: Stay on topic? BRIAN FITZPATRICK: Yeah. Problems with working your teammates, concerns about, So we've got Sarah from Wilmington. CALLER: Hey there, I love you guys! We have got a new team leader. He wants us to write a freaking mission statement. What the hell's with that? Can you get me an interview at Google? BEN COLLINS-SUSSMAN: So it sounds like she doesn't like the idea of a mission statement. BRIAN FITZPATRICK: Well, when most people hear mission corporations saying stuff like, we're focused on focusing. BEN COLLINS-SUSSMAN: We empower people. BRIAN FITZPATRICK: We empower people to do the BEN COLLINS-SUSSMAN: Or Kumbaya. Hold hands, let's have a mission. BRIAN FITZPATRICK: A mission statement is actually, I think, really important for a team. Because it's a way of keeping you focused on what you're doing. It typically has got a direction and a limiter. So you know we're going to go this way, and we're going to do this, but we're not going to do all these other things. BEN COLLINS-SUSSMAN: The limiter is also important, like you say. It's not just about what you're doing. That's just as important. Because it's very easy to sort of have feature creep. And it's important-- well, actually, you have a cool story about this, I remember. BRIAN FITZPATRICK: We worked a lot of different projects at Google when we were open sourcing. And there was one product, about five years ago, that was going open source. And actually wanted to do their development in the open. And I talked to them about the importance of a mission statement. whole team together to do this. And a lot of people on the team weren't really interested in it. But one of the things that became really obvious quickly is that two of the tech leads on the team actually didn't agree on what the product was doing. BEN COLLINS-SUSSMAN: But nobody realized it, right? BRIAN FITZPATRICK: They had never actually codified what they were doing and what they weren't doing and working on. So you know, years later, I talked to this guy. I'm like, thanks so much for supporting me when some of your team members weren't excited about this. He's like, well, I thought it was a waste of time, but I figured, what's an hour, you know? We'll give it a try. But like he said, he discovered really quickly that team to be more efficient, to get everybody on the same page. BEN COLLINS-SUSSMAN: We should point out. You should do more than just get everybody to agree on what the mission is. You need to document it. If you simply all agree on what something is, and it's not written down anywhere, it's not on a web page, you will still find other people coming in and arguing with you about it, or trying to question what's going on. But if it's on a web page, it's official, right? People get amazed. Oh, it's there on a web page! BRIAN FITZPATRICK: So whether it's a new person, an open source project, or someone coming to join your team, You respond by email, say, well, this is why we do this. They will argue with you for a week. But if you say, it's right on this web page, which is maybe an easily editable wiki, for all we know. They're like, oh, it's on a web page. Somebody thought about this, you know? Maybe we should move on. It's a very serious business. BEN COLLINS-SUSSMAN: But you know, put it in the same place where you'd put your other documentations. Your design decisions, your goals, your failures. Right? You keep a trail of documentation so people know where you've been and where you're going. BRIAN FITZPATRICK: Right. So documentation, important element of communication. Mission statements, not all bad. BEN COLLINS-SUSSMAN: We have another caller. BRIAN FITZPATRICK: We've got Tom from Seattle. CALLER: Hi guys, this is Tom. I'm thinking about submitting a proposal for Google Summer of Code. I found two projects that look pretty interesting. One is super well-known, but I poked around on their mailing list, and they were basically all insulting each other and being jerks. The other project is more obscure, but their committers Which one do you think I should go for? BEN COLLINS-SUSSMAN: All right, so he's asking which Summer of Code open source project he should join. Everybody here knows Google Summer of Code? Who has never heard of Summer of Code? So Summer of Code is a way for students to flip bits and not burgers in the summer. They get paid to work on open source. That's a huge thing. Culture is really important, though, and you can't really expect it to change. BEN COLLINS-SUSSMAN: Yeah. So what you'll find is a lot-- and this is not just true in open source, pretty much any team in a corporation-- you'll find that certain teams are slightly dysfunctional in the way they interoperate with each other, and some are really smooth and everyone respects each other. And you don't see a single team flip-flopping back and They tend to perpetuate. And in fact, I guess you could think of it as a culture, just like a yeast culture. It perpetuates. So we're in San Francisco, home of fabulous sourdough bread. Go to any baker that makes sourdough bread, and talk to him. How do you make your sourdough bread? The first thing they're going to put in there is the starter. So the starter is yeast and bacteria that happen to get together and do some really awesome stuff for bread. So they take this, and then they put it into the new flour and whatnot, they make a loaf of bread out of it. That starter culture inoculates this loaf of bread, and you get more of what you want. As opposed to, you know, the bread just getting taken over by wild yeast and another junk that gives bad taste. enough to resist other cultures that may come floating by. BRIAN FITZPATRICK: Right, exactly. like bacteria, right? BEN COLLINS-SUSSMAN: No. Right? So if you start a project with a few people who are all very respectful, and they trust each other, and there's some humility, that tends to perpetuate. They tend to attract more people of the same behavior And if you start the project with people being angry and screaming and one-upping each other, that tends to perpetuate, as well. BRIAN FITZPATRICK: Right. Over the long term, you can see projects go from more quiet to more aggressive. But you really see a project go from aggressive to more peaceful and quiet. But so beyond that, obviously, I think interest is really important. But you've got to find a style that matches your-- BEN COLLINS-SUSSMAN: Oh, we're answering his question, that's right. Yes. Think about the culture that you want to be part of, not just what project. BRIAN FITZPATRICK: So if you're OK with the big rah-rah fight and aggressive culture, then go for that. Right? So OK. All right. We have another caller here. Reginald from Schenectady. CALLER: I just hired a bunch of really good software engineers for my project, but they're not following They don't really seem to care about the product. How can I get them to really kick ass? the vision of what you're trying to do in your product? BEN COLLINS-SUSSMAN: Are they excited? CALLER: Well, we've got a product plan from the sales guys, and I told everyone how important this is. It just seems like they're ignoring my orders, no matter How can I get them to listen to me? BEN COLLINS-SUSSMAN: Well, clearly you need to yell at more. No. BRIAN FITZPATRICK: Beatings will continue until morale improves, right? BEN COLLINS-SUSSMAN: So the problem is-- I mean, maybe this is self-evident to a lot of programmers, but maybe not to all managers, is that way to motivate people is not necessarily to yell at them and bark orders. That may be good for factory workers, may not be the Programmers want to have turns. They want to all feel like they get a turn to drive the bus and have a stake in the project, decide where it's going. and not just sit in the bus and do what you tell them to do, they're going to do a lot more. You're going to get a lot more out of them. didn't think of. BEN COLLINS-SUSSMAN: Right. In which case, your role becomes not barking orders, but instead, just removing roadblocks so they can drive the bus whatever way makes sense most to them. BRIAN FITZPATRICK: Right. leader isn't to bark orders and yell at people what to do, but to sort of clear the road. Clear the path for them. Help them out. Get them what they need to get their work done. So thanks. BEN COLLINS-SUSSMAN: There's a lot more to say about that. Well, let's keep going. BRIAN FITZPATRICK: So we have a call from Larry from Hartford. CALLER: That one guy who was working in a cave before But you told him it's important to work with the team. But surely, you can't do that from the start. If he did, he'd never get off the ground. guys dishing out here? BEN COLLINS-SUSSMAN: So he's saying, if you start collaborating from day one, you'll never get anywhere. Which is kind of true. BRIAN FITZPATRICK: If you start too early-- I mean, you can look at, what, Google Code, GitHub, SourceForge. And there is just tons of projects where someone comes And then nothing happens. BEN COLLINS-SUSSMAN: Here's my readme file describing how I'm going to take over the world, and nobody shows up. do a whole bunch of different things. And they all argue forever, and they never do anything. BRIAN FITZPATRICK: So that's what too early looks like. extreme, the other end of the spectrum, which is, if you do the wrong thing, but if you just sort of reveal to the world something that's mostly done, that's collaborating too late. because it's done. Or there's no chance to make a mark on it. BRIAN FITZPATRICK: Even if it's not done, it's so far past the mark, I guess, that people just aren't going to come and take your orders. There's not a lot of chance for them to have an effect on what they do. companies that take gigantic products, open source them, throw them over a wall. Nobody comes because it's finished and too hard to figure out. BRIAN FITZPATRICK: So I think the real answer for Larry is design, prototype, then collaborate. That's when you bring other people in. Because you've got something to sort of show and work with and chew on. BEN COLLINS-SUSSMAN: That's a sweet spot, we call it. So if there is a prototype, sort of a proof of concept, And it's still early enough that people can get involved and feel like they have a stake, but it's late enough BRIAN FITZPATRICK: And that doesn't mean you shouldn't talk to anyone about it. Talking to friends or something, or getting advice from people, hey, what do you think about this, and getting feedback is a good thing. But sort of opening the floodgates for help and collaboration is what we're talking about there. BEN COLLINS-SUSSMAN: All right. So our next caller is Chromos from Azjol-Nerub. CALLER: My girlfriend and I have been playing Warcraft for seven years, but the last couple raids, things have started to get rocky. I found out from her friend she's been talking about joining another guild, and I'm not sure my 25 men will be able to run anymore. What can I do to patch things up? BRIAN FITZPATRICK: Is that a Warcraft question? BEN COLLINS-SUSSMAN: I can tell you that the Red Dragon Dynasty doesn't do any recruiting at all, except in the realm forums, strictly. And if you see someone doing that, you should contact one of the officers. But not during raid times. BRIAN FITZPATRICK: OK, thanks. So let's try and focus a little more on topic here. Let's go back to the calls on our teams here, please. Now we've got Vern from Las Cruces. CALLER: Long time listener and first time caller. I have a friend who has a serious problem. BRIAN FITZPATRICK: What kind of a friend? Tell us more about your friend. CALLER: Yeah. Well, he seems to be writing less code lately, his-- teammates more and more. It's not like he's their manager, but people keep looking to him to fix arguments, and decide stuff, and give advice and things. Should I get him to see a doctor or something? BEN COLLINS-SUSSMAN: Well, we only look like doctors. BRIAN FITZPATRICK: Well, your friend sounds like they're suffering from what we call accidental manager, or BEN COLLINS-SUSSMAN: So you have this situation. And anytime you have a group of people working together, even if there's nobody assigned to be the manager or the leader, somebody will fall into that role, whether they like it or not. They'll start advising people, resolving-- BRIAN FITZPATRICK: Well, it might not be they'll go kicking and screaming. But they'll see a need, and determine that I'm the person who's going to step into this. BEN COLLINS-SUSSMAN: It's not necessarily a bad thing. I think it's just human nature. There's a power vacuum. Somebody falls into it. And it's scary. If you call that a manager, then programmers get very scared. Because the word manager is a dirty word. We hear the word manager, we think of pointy-haired Dilbert characters. Manager is a scary thing, which is why we like to talk about leaders instead of managers. People can be leaders without being managers. People can be leaders without having a title. BRIAN FITZPATRICK: Right. So the answer to Vern's question, it's OK. And it's not a bad thing, necessarily. All right. So that was good. Let's talk a little more about leadership. Is there anyone out there who's leading teams that has some questions? Scott from Bismarck. Go ahead, Scott. CALLER: We have a new manager starting next week. I haven't met the guy yet, but I want to get off on the right foot. Do you guys have any tips for me? BEN COLLINS-SUSSMAN: So the question is, how to get off on the right foot with a new manager. BRIAN FITZPATRICK: Don't wait around for orders. Basically, I'd say take responsibility. look at a particular treatise having an issue, don't just deal with that and come back. Go out in the forest and find other similar issues, and come back, and say, look. I found this, and this is what I'm going to do. I mean, I think the worst thing to do is come back and say, what do I do next? BRIAN FITZPATRICK: Oh, well, that's crazy. But if you come to your manager, or your leader, and you say, you know, this is what I think I'm doing next. What do you think about that? As opposed to, what do you want me to do. communication. Don't wait for orders. Proactively pursue some responsibility. Go out and figure out what you think you should be doing. Don't just be a yes man. Have some opinions. Express what you really think. Tell your manager about your roadblocks. Tell your manager about your successes. BRIAN FITZPATRICK: Communicate. Act like an adult, communicate, and get your work done, right? There's a guy who started to work with me few years ago, company, And the first day he comes to me, and it's quarter to five, and he's like, look. I've got to leave early. I had an appointment that I couldn't change. I'm really sorry. But I'll be here late tomorrow, it's no problem. As long as you put in your 85 hours a week, you're fine, right? And he's like, well, what am I going to do with all my spare time now? BEN COLLINS-SUSSMAN: Poor guy. BRIAN FITZPATRICK: But seriously, it's like it's, you don't need to stamp a time clock. You know what your responsibilities are. You know how much you need to do to get it done. BEN COLLINS-SUSSMAN: Act like a grown up. BRIAN FITZPATRICK: Exactly. OK. We have our next caller. Lance from Portland. CALLER: Hi, guys. I need people to work faster and longer. I've even threatened to fire folks if they can't get their performance up. Why aren't they scared? Why aren't they getting more done? BEN COLLINS-SUSSMAN: So he's threatening to fire people Stick. Shake a giant stick. That doesn't work so well. BRIAN FITZPATRICK: Especially not with engineering people. Engineering is a creative thing. I think that it's not just a matter of some rote activities. I think managers really came into prevalence during the industrial revolution. You have your assembly line. You have your workers who are stuffing cans with meat. And you know, you shake the stick at them, you give them the carrot, et cetera. You want to get things going more quickly. There's not a lot of independent thought there. BEN COLLINS-SUSSMAN: But if I shake a carrot or a stick at you, you're not going to be smarter, necessarily. BRIAN FITZPATRICK: Or think more creatively. BEN COLLINS-SUSSMAN: Think more creatively now or I'll fire you! You need to nurture people, right? I mean, really sort of help them to get their job done. CALLER: So what am I supposed to do? Coddle them? Offer them raises and bonuses to meet their deadline? Fluff their pillows? You guys are useless. [DIAL TONE] BRIAN FITZPATRICK: Thank you. Thank you for calling. I think you need to give people a reason to care. I mean, tell your-- Dan Pink who talks on the internet and other places. He talks about, all right, well, here's how to actually encourage people to be productive in the knowledge industry. You should give them autonomy, mastery, and purpose. I love these three things. Autonomy means, treat them like a grown up. Let them do their job the way they want to do it, what makes Give them some free rein in making decisions. And trust them. Mastery means give them a chance to improve themselves and learn new things so they stay engaged and they stay sharp. You don't want to take your sharpest knife and grind it in the sidewalk. You want to let the knife sharpen itself. actually feel like they have a stake in what they're doing. Give them a reason to care. So it's really important to them. BRIAN FITZPATRICK: To summarize, I think there's no they can motivate themselves. So give them the tools that they need to do that. BEN COLLINS-SUSSMAN: Intrinsic versus extrinsic motivation. BRIAN FITZPATRICK: Right, absolutely. That's an excellent question. OK. We have Todd from Lisle. Go ahead, Todd. CALLER: I've got to say, that last guy seemed like a total jerk! There's a guy on my team who acts like that, too, almost all the time! How do you guys usually deal with people like that? BEN COLLINS-SUSSMAN: That's a good question. BRIAN FITZPATRICK: Well, we see this with people not only in your team, but outside of your team, as well. section, right? Talking about working with people closely who aren't necessarily on your team. BRIAN FITZPATRICK: Right. Well I mean, you need to protect your culture, right? attention and focus. And what you're doing, you're here to write software. BEN COLLINS-SUSSMAN: Although it's hard. You'll want to have these emotional reactions. some way, you want to spend a lot of energy fighting back, or hurting them back, and it's easy to get carried away. And then you suddenly realize you've wasted your whole day, you're emotionally drained, you've not written any software at all. BRIAN FITZPATRICK: It's really hard when someone verbally or in an email or whatever attacks you, not to fight back. You want to give them that little zinger that puts them in their place and all, but typically, it's not going to affect them. So there's an old Usenet adage-- remember Usenet, around about 700 years ago? Don't feed the energy creature, right? And really, I think that's really important. BEN COLLINS-SUSSMAN: We were on an open source project for mailing list and said, oh, this product sucks. It's terrible. What's wrong with you people? He was basically there to give a bug report, but the email was full of just incredible bile and insults. It was ridiculous, right? And I was so proud, because we didn't actually respond. Somebody else in the open source project responded with the most simple, formal language, like, oh, looks like you found a bug. Thanks. We're going to look into it. And of course, he responds back with just more anger and bile, and [GROWL]. community just responds very calmly, as if there was nothing wrong-- BRIAN FITZPATRICK: We found the bug and we fixed it. BEN COLLINS-SUSSMAN: But it's funny, because the guy kept looking like more and more of an idiot the more he responded, and the less we responded to the bile. BRIAN FITZPATRICK: But if we'd just tried to argue, we could have easily gone off into a giant argument with the person, right? All right. That's excellent. We have Mark from Ann Arbor on the line. CALLER: Hi. I've heard you guys give this speech before. And as far as I can tell, it's just a recipe for elitism. you're just looking for a bunch of pushovers. All you guys want to do is screen out people who disagree with your team. BRIAN FITZPATRICK: He's saying we're being elitists. BEN COLLINS-SUSSMAN: Well. Maybe he should go away. BRIAN FITZPATRICK: Well, I think it's an important distinction to make here. We're not talking about throwing the people out, or getting rid of the people. We're talking about addressing the behavior. I mean, you can actually wind up alienating really good people if you sort of throw the baby out with the bathwater. amazing engineer. But he pissed everybody off. He just constantly said things that were insulting. He'd go along, work, work, work, boom, say something, and people would be like, what the heck? You pulled him aside on chat or something and said, you know, hey, do you realize that when you do this, you're having this effect on the rest of the team? BEN COLLINS-SUSSMAN: I did think he was surprised. But the point was, we didn't say, get out of We said, please behave in a civil manner. I don't think you realize that you're not being civil. BRIAN FITZPATRICK: Right. And I don't think he quite realized it, but he cut back on the behavior. And things did smooth out quite a bit. BEN COLLINS-SUSSMAN: Right And so that's what say for people who are moderating mailing lists, any kind of lists, right? It's not about who's in and who's out. It's about what kind of behavior is tolerated by anybody, whether they're on the list or not. BRIAN FITZPATRICK: But on that same note, you do also have to You get some people who just don't understand. We did have one guy who wasn't actually writing code, but he was really enthusiastic, and really friendly, and he would answer other people's questions all the time, incorrectly. He would also just sort of free associate on the mailing list. Hey, did you ever think about putting this in? BEN COLLINS-SUSSMAN: It was like his stream of consciousness kept emailing the list every hour. BRIAN FITZPATRICK: We should put a list of Star Trek reruns in the documentation. You're like, what? And we actually talked to him a couple of times about it, and he didn't quite get it. We finally sort of said, look, you need to stop doing all this stuff. And he really didn't understand. That was one of the harder things, right? BEN COLLINS-SUSSMAN: Well, I think what that proves is that there could be people who are disrupting your team's attention and focus who are not trolls, who are the nicest people in the world. One example is just people who are perfectionists don't realize they're being perfectionists. And they can actually drain all the attention and energy by never letting anybody start because the design doc is not perfect yet. So that's an example. BRIAN FITZPATRICK: But to turn all this around into a different way of looking at it, it's really healthy and important to have a good team ego, as opposed to individual egos. BEN COLLINS-SUSSMAN: I know that's the Apache Software BRIAN FITZPATRICK: Right. Apache is about building communities. code, you rarely find someone's name at the top of a file. This is a practice that is very contentious. It's almost as contentious as vi versus Emacs. How many people here use vi? How about Emacs? All right, fight! No, I'm kidding. There was this one guy came to our product who wrote a whole date parser module. It was a pile of code. It was actually great. It was pretty well written. We said look, you know, here's our style guide. You did great on this and this. But take your name out of the top of the file. We don't have anyone's names in the source code. BEN COLLINS-SUSSMAN: It's just project policy. BRIAN FITZPATRICK: We have other ways of acknowledging people helped out. putting my name on it. And we went back and forth him him, trying to explain, look, this isn't about trying to take away credit. I wrote three lines of code. You wrote ten lines of code, but I rewrote them. BEN COLLINS-SUSSMAN: Or what if I delete some code? Does that mean the name comes out? BRIAN FITZPATRICK: It's just a lot of wasted energy, right? You do want to recognize people. It's very important. motivation, I would argue. But we wound up not taking this guy's code, and he went away. BEN COLLINS-SUSSMAN: Which is sad. But it's also one of those cases where it was more important to preserve the culture than to accept this one particular contribution. BRIAN FITZPATRICK: Yeah, excellent. All right. We've got Norman from Winnetka. CALLER: I've been a long time listener, Click and Clack. You guys do just an absolutely amazing job. Anyway, I've got this [UNINTELLIGIBLE] cream. It's an '84. Yeah, so anyway, the transmission makes this da, da, da. I've tried to fill it with sawdust, but I just don't know what to do about it. BRIAN FITZPATRICK: Have you tried rebooting it? That fixes a lot of problems. BEN COLLINS-SUSSMAN: Think it's a wrong number. BRIAN FITZPATRICK: Yeah. All right. Let's move on to people who work with your product, right, as opposed to people on your team. Users. Yeah, take a couple of calls from-- we have Carl from Kansas City. CALLER: I've been listening forever. doing really well. And lately, a bunch of industry analysts have been asking us for whitepapers, and bugging us for interviews and things. Everything about our software is up on the website, clearly. These analysts and reporters, these guys just don't get it. How do we get them to stop bugging us and read the same docs as everybody else? BEN COLLINS-SUSSMAN: So the question is about how to deal with industry analysts. Do they wear white coats? BRIAN FITZPATRICK: They don't. So I was VP of public relations for Apache for a while. And we would get analysts who would show up and say hey, you know, we're doing this enterprise report on blah blah blah software, can you get this, this, this and this? Because they're used to going to big companies and saying, And people go, yeah, right away, here it is. Can I get you a cup of coffee with that? Because they want them to write good things. And then engineers, thinking very logically, think, well, this jackass should go read the documentation. BEN COLLINS-SUSSMAN: Like everyone else. mailing list somewhere. Go search for it. Right? That doesn't fly so well. anything to do with marketing, I think. In general, they distrust marketers. BRIAN FITZPATRICK: How many people here love marketing? Other than the marketers? No, I'm kidding. But the point is, is that I think perception is important. I could say perception is nine tenths of the law. You could have a great piece of software. If people don't know about it, if you don't shine it up a little bit, you're not going to do as well as you could have. BEN COLLINS-SUSSMAN: I think also a lot of folks don't realize that it's possible to do marketing without being slimy. BRIAN FITZPATRICK: No! BEN COLLINS-SUSSMAN: It's possible, I mean, you can underpromise and overdeliver. Make that your policy. BRIAN FITZPATRICK: So if you've got substance, it's OK to do some shine. I think where it comes into problems is that people expect BEN COLLINS-SUSSMAN: All shine, no promise. So what's the answer to the question? I think the answer is play the game a little. BRIAN FITZPATRICK: Play the game a little bit. I don't think you have to really, like, fall over to do everything for them. But you do need to, I think, play a little bit along there. BEN COLLINS-SUSSMAN: Don't discount it completely. BRIAN FITZPATRICK: Right, right. So our next caller is Connor from Galifrey. Go ahead, Connor. CALLER: My company has the email addresses of all our customers. We got those mainly so we could send out license keys. We promise not to spam our users, but now some of our marketing guys are begging to email the customers with-- I don't think it's worth pissing our users off for a quick bump in sales. What's your take on this? BEN COLLINS-SUSSMAN: So the question is, is it worth Sounds like spamming to me. BRIAN FITZPATRICK: No. Next question. No, it's about trust, really. And it's interesting, because we're in a different place Nowadays, in the software world, it's really easy to People can use your software easily. They can just as easily try someone else's. BEN COLLINS-SUSSMAN: So having a trust reputation, your company's reputation, how much people trust you, is really, really important. And it's dangerous, right? We always say trust is like a bank account. You can spend years building up trust with your users. But one night in Vegas, it's all gone. You blow it all, you blow all the trust at once. It's very scary. And doing things like sending spam, it's a slippery slope. It's a way to blow your trust right away. BRIAN FITZPATRICK: Well, I have an example. My grandfather managed a Firestone tire store for 35 years. How many people in this room own a car? Leave your hands up. How many people own a car and have a mechanic that you trust? Wow. That's got to be nine people with their hands up in the room. BEN COLLINS-SUSSMAN: Why is that? BRIAN FITZPATRICK: That's an example. I think mechanics are typically an industry where people take advantage of you. You go in with a flat tire, and they're, oh, you need to, your flux capacitor is a little bit too slow, and you're going to do a complete radiator flush, and fluids BEN COLLINS-SUSSMAN: They call it mailboxing, right? BRIAN FITZPATRICK: Exactly, yeah, sort of selling people other things. My grandfather, for 35 years, he took over this store. And when he took it over, it lost more money than any other store in Louisiana, and within three years, it was the number one grossing store in the state. And that wasn't just because they did great stuff. It was because he didn't try and rip people off. 95% of his business was return. It came back. It very quickly paid for itself. There's no real point to doing it. Short term benefits, but in the long term, it's going to kill you. BEN COLLINS-SUSSMAN: But getting back to the question, right? I mean, clearly, this guy's company, they want to connect to their users. There's other ways to do it besides sending product updates unsolicited. I know it's possible. You can have a relationship with the users that isn't just spam. For example, you can talk to them directly. BRIAN FITZPATRICK: No! BEN COLLINS-SUSSMAN: I know, it's crazy. You can listen to them. Give them an outlet to communicate. For example, put up a public bug tracker. We've got social media now, where you can communicate updates. You can read what they're saying back about you in social media. BRIAN FITZPATRICK: You see this with a lot of startups, actually. A lot of really successful startups that have user-facing products. They are in the trenches every day, helping their users, supporting them, answering their questions, listening to their feedback and implementing features based on that. BEN COLLINS-SUSSMAN: They love to be heard. I mean, I know that I like to be heard when I'm using a piece of software. To answer the question, is it OK to spam customers like that? I think you're going to get a bump from it in sales. It's going to be a short term thing, and I think it will hurt you in the long term. Let's get another call. We have Bill from Santa Monica. CALLER: My company does listen to users. They're always asking totally obvious questions in our forums. Half the time, they're unable to explain their problem, so it's almost impossible to help them. BEN COLLINS-SUSSMAN: So he's saying he's having trouble understanding users when they do talk to him. BEN COLLINS-SUSSMAN: For example, learning to talk to non-techies is a skill. I feel like probably everybody in this room talks to their parents at some point, or relative on the phone. BRIAN FITZPATRICK: Who does tech support for your parents on the phone? BEN COLLINS-SUSSMAN: Tech support for your family, right? And you're on the phone, and you're trying to understand what the heck they're talking about, because they're using language you don't understand, and vice versa. And so it becomes this skill you cultivate where you try to read what they mean, not what they say. BRIAN FITZPATRICK: You have to translate intentions. The most extreme example I have of this, my grandmother, OK? My grandmother, I love her to death. We're sitting down one day talking, and she asked about my grandfather, who died years ago, asked about his computer. Is that computer still worth anything? And it's like a Mac Classic, you know? She said, oh, OK. I only ever turn it on when I have to sharpen a pencil. I know I'm going to regret hunting this down, but I've So it turns out that the computer is plugged into a power strip, and there's also a pencil sharpener plugged into this power strip. So every Saturday, she goes in with her three pencils, turns the computer push on, the little Mac goes beep, and She sharpens the pencil, and then boom! Kills it. BEN COLLINS-SUSSMAN: For a Mac, never efficient. BRIAN FITZPATRICK: I assure you, I liberated the computer quickly. It's safe. BEN COLLINS-SUSSMAN: You put it out of its misery? BRIAN FITZPATRICK: I put it out of its misery. But I mean, talk about, like, holy cow. What are they thinking, right? And it's a learned skill. And the people who do it, I think, full time, should win some sort of award. BEN COLLINS-SUSSMAN: Developer relations people? BRIAN FITZPATRICK: Man, that's some of the hardest work. I think developers typically understand more. That is it. Thank you all for coming to this live taping of our show. We'll switch over to live Q&A in just a second, but that's all we have today. Thank you. We have microphones, if you have questions. If you do have a question, please step up to the microphone and ask it, so we can all hear you. Or maybe no questions at all. Anyone? We scared everyone away? Have we answered all your questions already? BEN COLLINS-SUSSMAN: Maybe they don't want to be on the air. BRIAN FITZPATRICK: No? This part isn't taped, I don't believe, anyway. So all right, first question. You can go right ahead. AUDIENCE: [UNINTELLIGIBLE] BRIAN FITZPATRICK: Whoa, no, wait. Speak a little bit more slowly. Sorry about that. Go ahead. It's not on? It should be on. Check? AUDIENCE: I don't think so There it is. So I'm starting a project right now, and my business and my IT are just talking. How do I drive that discussion so we can develop requirements and actually get this project off the ground? BRIAN FITZPATRICK: So business and IT aren't talking, you said? AUDIENCE: That's right. Business wants everything. IT needs to limit that. How do I get those two teams to talk so that I don't have BRIAN FITZPATRICK: That's a really hard problem. BEN COLLINS-SUSSMAN: I think we need to know what they're arguing over to be able to answer that better. BRIAN FITZPATRICK: Well, I mean, I've seen this, before where business, like, you know, we need everything and we need today. Right? And tech, you're like, well, we can only give you so much. So I think the hardest thing to do is getting someone who has actually the power in the company to drive that conversation. You can't drive the conversation if you're just sort of an observer, or not somebody who's actually running one team or the other. BEN COLLINS-SUSSMAN: Which is a case where you need a decision maker who can bridge the gap. discussion. would say that I don't see you going anywhere soon, except for the wrong way. Thanks. Next question? AUDIENCE: Yeah. A company I've been working for lately, they'll put out about a new final set of requirements every few days. And it's just super frustrating. So can you give any advice about how to kind BEN COLLINS-SUSSMAN: The question is about how to deal with constantly changing requirements. BRIAN FITZPATRICK: I like to deal with that by organizing, right? out for a year for your product, which I know, it's hard to really predict anything past three or four months. back the next day, and say, OK, we need you to do all this stuff. You could sit down and say, OK. Look, we can add this, this, and this, but all this other stuff is going to have to move back. Because we can't hold space and time. So that's a really good strategy, is to out-organize them. And then when they come back, you can just sort of very plainly point out, that's fine. I'm glad to do this. And then suddenly, they're the bad guys. They have to think of this. Oh, well, I don't want you to get rid of that! BEN COLLINS-SUSSMAN: Right. saying yes to everything, or no. You are making it extremely clear what the tradeoffs are every time with data. Nothing scares people like data. Fantastic. AUDIENCE: Thank you. BEN COLLINS-SUSSMAN: Should we take a question from over here? BRIAN FITZPATRICK: Over here, please. AUDIENCE: I wanted to know what your thoughts were on The idea when you check in some code, you're going to run some automated tests, with no human intervention, just put it live on your website. Who should use it and who shouldn't? BRIAN FITZPATRICK: Oh, that scares the crap out of me. BEN COLLINS-SUSSMAN: So the queston is about, when is continuous deployment a good thing? I think it's fantastic. We use it at Google. BEN COLLINS-SUSSMAN: Well, all right. So what are the downsides of using continuous deployment? BRIAN FITZPATRICK: You could blow yourself up. BEN COLLINS-SUSSMAN: Well, you could also spend a lot of time getting it to work. That's my personal experience, is that it's a big time the long term. So I would say it's an investment of short versus long term time. And are you willing to make that investment. I think it's appropriate for everyone, if they're willing to make that tradeoff. They have the luxury of making that initial investment. BRIAN FITZPATRICK: And another way of doing that is to have things go out into test servers and then move on. on one, et cetera. There's a lot of different ways of doing that. BEN COLLINS-SUSSMAN: Cool. AUDIENCE: We have a new developer on our team. We're part of an extremely large software project. And he kind of jumped in head first and has been making a lot of changes without, I think, really understanding. And it's kind of introduced a lot of bugs. And I tried to point this out to him. And the problem is, he's almost 25 years older than me. You know, I'm only 23. So he has kind of this attitude of this is how I've should or shouldn't do this? becoming a defensive-- because I have more experience in the project, in the code, while he may have more experience BRIAN FITZPATRICK: How many people on the team? Is it just you and him? AUDIENCE: I would say developers, five to ten. BEN COLLINS-SUSSMAN: This is a case of cultural invasion in some way, right? Does your team have a strong culture of code review, or this is how we do things? AUDIENCE: Not of code review, but. BEN COLLINS-SUSSMAN: But is it a culture of specific development practices that you all adhere to, all ten of you? AUDIENCE: We try to. BRIAN FITZPATRICK: Do you have any of them documented, by chance? AUDIENCE: Unfortunately, it's an extremely large software project that's grown over about ten years. So there are people, he understands this part really well, and I understand my part really well. that I spent a long time working on, and it introduces problems, and when I try to talk to him about it, he doesn't really-- you know, I guess I would say, doesn't give me the respect of being someone who's on the same level as him, even though I have a lot longer experience in the actual, what we're working on. BRIAN FITZPATRICK: I think anything more than anything, it sounds like a cultural invasion. BEN COLLINS-SUSSMAN: It's not about disrespecting you. It just sounds like he's not paying attention to the culture overall. And so I would argue this is a case where multiple people point this out to him, perhaps a manager or someone, to say look, it's not just this one young guy who's trying to get your way. You're actually disrupting the whole team. BRIAN FITZPATRICK: And it's not just the job of the manager of the team to do that. I would say it's the job of the whole team. and he hears it from everyone, it's one thing. your culture, I'm not saying the product, but your culture documented. Processes. We do this, we write a design doc, and then we get an That, I would argue, is pretty important. BEN COLLINS-SUSSMAN: But get more people involved so it's not just about you and him. It's about him and the whole team realizing that he's sort of going against the grain of everybody. Then it's not about personal conflicts. It's about everybody agreeing on what the process is. BRIAN FITZPATRICK: Next question, please. his app from the Android market because he kept noticing only the bad reviews people gave him. Even though supposedly the app was great, and it worked great on many phones. But still, really bad reviews kept creeping up to the top, and so he just couldn't take it. So he took the-- BRIAN FITZPATRICK: Was it a bad app? AUDIENCE: No, it was supposedly a really good app. BRIAN FITZPATRICK: Competitors trolling? AUDIENCE: So what are your thoughts on that? How can a team that is probably emotionally tied to a product they just made, and made available for free, and then, you know, you keep getting these bad reviews? I'm asking because it might happen to me if I put out a product for free and keep getting bad reviews. BRIAN FITZPATRICK: I think there's two BEN COLLINS-SUSSMAN: You are not your code? BRIAN FITZPATRICK: Well, yeah. You're not your code. I mean, you've got to be ready for-- Ben and I worked on Subversion years ago, right? Sorry about that. We've gotten past-- and people are like, you know-- we actually will joke because we use Mercure, and I'm like, oh, yeah, whatever with Subversion. Somebody's like, how can you talk bad about your product? And we're like, you've got to learn how So I would say, first of all, you're not your code. But second of all, if they're legitimate, you've really got to look to see-- are there legitimate complaints there? If it's just people trolling, or griefing, or just people complaining or whatever, it's just noise. I mean, if it really is a great product, I think you'll get more good reviews than you will bad reviews. But if there really are legitimate bad reviews there, Constructive criticism is, in my opinion, gold. And that's why, actually, we should move along to this. That's why I'm a huge fan of getting feedback. So back to the SpeakerMeter thing. Getting constructive criticism is a way for us to improve and get better. We gave us talk a couple of weeks ago, and we asked people, you know, what can we do better? And I think we learned some things, and I'm hoping that we'll get some more feedback today that we'll learn. So that's what I would-- BEN COLLINS-SUSSMAN: I was going to say, the other wisdom is, in terms of dealing with trolls, or people who are just criticizing for no reason-- what was that saying, the internet is full of crazy people? BRIAN FITZPATRICK: The world is full of crazy people, but the internet, it's like they all live right next door. to ignore the noise. BRIAN FITZPATRICK: The first thing I recommend people who are working in open source is, go buy a rhinoceros skin and Thicken your skin as much as you can. AUDIENCE: To go along the same vein as the previous question with the younger developer and the new older guy coming in-- I am the younger guy coming in. And so to me, a lot of management types are sort of gray beard tech guys. They grew up on Visual Basic-- BRIAN FITZPATRICK: Hey, hey, be careful there, buddy. AUDIENCE: And so to them, I'm a maverick. To me, they're dinosaurs. And so there's a little bit of head-butting with new tech. I want to do things, do it live, document it, send it out. They want to test it for two weeks, see what What do you guys recommend? BRIAN FITZPATRICK: Sounds like a culture conflict. BEN COLLINS-SUSSMAN: Again, get another culture conflict. Well, here is the biggest question. Is there respect going both ways? AUDIENCE: Absolutely, I'd say definitely. BEN COLLINS-SUSSMAN: Absolutely. Then I think this is a resolvable issue, right? If people have humility and respect, and there's some mutual trust, then it sounds like it's something you can work out. But again, it sounds like this is a case where people need to sit down and talk about, well, waht should our processes be? And if you want to change the culture, that's fine, but you should be able to have a discussion about that, and not have a series of conflicts over it. BRIAN FITZPATRICK: But it's hard sometimes. One of the interesting things about documenting why you do things, is if you can go in a little bit of detail, in some cases, you can show-- there's often a lot of reason and wisdom behind some choices and decisions that may seem not obvious or archaic. But if you can dig in and be like, oh, that's why we do that. Or maybe it's because something really bad happened carefully an trying to avoid risk. BEN COLLINS-SUSSMAN: So it sounds like you're recommending research of the existing culture before deciding to overturn it. BRIAN FITZPATRICK: Yes, exactly. I mean, that's one of the biggest things to do when you're having a disagreement with somebody. what their point of view is-- especially if you're married-- then it makes it a lot easier to carry that conversation. BEN COLLINS-SUSSMAN: The more you listen, the more you are listened to. BRIAN FITZPATRICK: Yeah, exactly. AUDIENCE: Just to follow up on that. Unfortunately, it was a small company, it's a startup. And so a lot of that apocryphal wisdom about why we don't reboot the server on Wednesday morning, for example, it's just not anywhere. So it comes to me, actually, to document that stuff. all committed to digital ink, so to speak. BRIAN FITZPATRICK: Well, it sounds like you got an opportunity to drive the bus a bit there, so that's good. AUDIENCE: Definitely, yes. BRIAN FITZPATRICK: Excellent, thank you. Next question. your culture, like documentation, the code itself. Are there any other tools that you use on a regular basis to kind of define your culture? BEN COLLINS-SUSSMAN: Wikis. BRIAN FITZPATRICK: Wearing lab coats. I mean, there's a lot of different stuff in culture. We focus a lot on the social aspects of it, of interacting. I know some teams, it's like, 4:30 on Friday, and everybody sits around and has a couple of beers. Right? BRIAN FITZPATRICK: Nerf guns, right? There's a team in Pittsburgh at Google. They used to be right next to a train. When the train would go buy, everybody would jump up and shoot each other Nerf guns, right? BRIAN FITZPATRICK: That was kind of cool. There's a lot of different things you could do. Like eating lunch together. I mean, Google's sort of known for having free food. There is an incredible benefit by getting your team to eat lunch together and not necessarily talk about work. with for programming issues is a human, right? He's married. He's got kids. Wow, you know? BEN COLLINS-SUSSMAN: It really helps. these hard discussions, and accept constructive criticism, that sort of thing. BRIAN FITZPATRICK: Thank you. Yes, please. AUDIENCE: Attention on details. I mean, how do you get people to really focus attention on details? It's not just you give them a visual spec, and they give you like very basic of what you have given them. BEN COLLINS-SUSSMAN: You're talking about attention to details in the software. How do we get developers to pay attention to details. developers just being sloppy, or--? AUDIENCE: Not being sloppy. It's just like being very basic. It's like, whatever you give them-- you give them a mock-up, and then the product comes back BEN COLLINS-SUSSMAN: Sounds like people are simply not meeting job expectations in that case, right? BRIAN FITZPATRICK: There's a lot of different things that It is tricky, but I think communicating more about expectations-- I mean, flat out. there's a lot of cases I know where people had someone that worked with them, or worked for them, who wasn't meeting expectations. And they don't say anything, because they don't want to rock the boat. And that's exactly when you should be rocking the boat. When you're most afraid to rock the boat. So it's like, boom. That's when you start communicating. If you just flat out say, look, this is what I expect of you, and this is what I'm not getting-- where I expected something-- BRIAN FITZPATRICK: Two exampels minimum. At least two. BEN COLLINS-SUSSMAN: Give them hard data. Say, I expected X, Y, and Z, and you gave me this other thing. And you did it two or three times. BRIAN FITZPATRICK: You can at least be sure, in that case, that they know it. Because quite frankly, they might not know it. We can take two more questions. A while ago, you talked about the ethical issues of, for instance, spamming people and whatnot. And what would be the right thing to do when the general culture of the place seems to be skewed towards that direction? And you did mention that that would cause financial damage I am just the engineer, and I doubt that would be persuasive from my part. BEN COLLINS-SUSSMAN: That sounds like a question of how That's a really hard problem. We get this question a lot, actually, and our answer is usually, find a new company. Wait, wait, wait. Our first answer is, is that you can make attempts at this, right? attempts to ask people about it. Have you thought about it this way? But yeah. If you try and are unsuccessful, you can just sit there and stew about it. You can learn to deal with it. Or you can get the heck out. BEN COLLINS-SUSSMAN: I find, also, reaching out to other people in the company who feel the same way, you can start to sort of build a movement within the company. I mean, it's politics, right? But you can actually form a movement within your company so that there's a single voice saying, we don't like this. And the louder you become, the more the dialogue is likely to happen. BRIAN FITZPATRICK: But do keep in mind that companies aren't democracies. BEN COLLINS-SUSSMAN: They're not democracies. movement within them. BRIAN FITZPATRICK: That's right. Go ahead. AUDIENCE: I work on a team where there's another guy who's a very capable developer, but he often holds his cards real close to his vest, doesn't share things with the rest of the team often. And furthermore, my boss looks upon him with great favor. Do you guys have any tips or strategies that you might suggest for dealing with both him and my boss? BEN COLLINS-SUSSMAN: Well, what's wrong with him holding AUDIENCE: Right. That often times, he won't engage other Or often times, he'll maybe get that super-special assignment or whatever before others are considered, that BEN COLLINS-SUSSMAN: Interesting. I mean, again, you can give him data. Like with your boss in particular, if we got more information, we could do more. But that tends to be one of the things that's really hard to change. BEN COLLINS-SUSSMAN: If you can quantify the impact of him make, saying, well, we should get him to open up. That gives us an argument to the manager, right, or other members of the team. BRIAN FITZPATRICK: But if the manager and the lead both think this is the way we're going to run things, you don't have much of a way to change that. It's really hard, because they're defining the culture top down, and you're just sort of following along. BEN COLLINS-SUSSMAN: Also, if I were on the team, I would also try to figure out the psychology of this person. Are they just insecure? Or are they egotistical? What's going on, right? How do you get them open up? get in there and get them to open up, figure out what's really going on. AUDIENCE: Sure. BRIAN FITZPATRICK: All right. Thank you all for coming. We appreciate it. We'll be around for a bit, talking a little more.