ASTRID: Hello, everybody. I’m Astrid Countee and welcome to… What are we talking about today? What is this today? Well, here today is one of our patrons, Darin. Say hello, Darin. DARIN: Hello. I’m very happy to be here with Sam Livingston-Gray. SAM: Hello. Welcome Darin and I would also like to welcome another surprise special guest, Cheryl Schaefer. CHERYL: Thanks, Sam. I’m happy to be here and introduce our friend here, Jessica Kerr. JESSICA: Thanks, Cheryl and this is a really fascinating episode today. Let me tell you the story of how this episode happened. See, Coraline was in Africa and she was coming back from Africa. Then people wanted a show with some origin story so we thought we’d have a show with just us but we moved it because Coraline was coming back from Africa but apparently Coraline is still in Africa time zone because she’s not here so we popped up in the Slack and ask for some company and Cheryl joined us and Darin joined us and Darin has a question and we don’t know what it is. Darin, what is the topic of today’s show? DARIN: I’ve been thinking a lot about what it means to be a senior engineer when you don’t want to go into management so I wondered what all of that meant to you. What is your career path look like now that you’ve sort of crossed over to senior developer when it’s not as clear what the next steps are? JESSICA: Excellent question. SAM: That’s a really interesting question. It’s one that I’ve been pondering for like five or six years. I don’t really have a good answer but I really love programming. I really love figuring out how to get better and better at expressing solutions and even just expressing problems and I love being able to teach people. But I have zero interest in going into management because I know that if my job involves going to meetings and remembering stuff, I would be absolutely horrible at it. I’ve been a senior developer, in title, for six years and I don’t know where to go from there and that’s probably going to be an issue at some point. But it’s okay for now. ASTRID: Can I ask a question related to this because I don’t have an answer, obviously but I do have a question, which is when I was working at HP and I’m wondering if this is just because they do a lot of hardware, they seem to have a path for this and it was different. It was like you became almost a senior fellow kind of thing where you were a person who within the company, you were considered to be an expert. Whenever different groups were working on certain types of solutions that maybe using your wheel house, they could consult with you. It was like you were an in-house advisor and you were also the first point of contact for whenever they were going to make new products or something like that. Does that not exist for software? JESSICA: It does in a few places. In Monsanto, they called it a Technical Fellow. That would be like the extreme senior level, like Kent Beck at Facebook of someone that anyone can consult when they need with some mysterious wisdom or serious perspective on what the company is doing. Sometimes, it’s just a matter of knowing so many different groups in the company that you can give a much broader perspective and connect people. SAM: I’ve seen places that after senior engineer, they might have tech lead and they might have principal engineer but those have definitely been much less common as I’ve just been wandering around looking at random job postings. ASTRID: Like the principal engineers and the tech leads, what are they doing? SAM: Well, tech lead is fairly descriptive like you’re a senior engineer who is also like the nominal head of a team — JESSICA: As far as technical decision — SAM: Right, yeah. When I was in LivingSocial, they had at least the idea of this, where they would have somebody who was taking care of the management side. This, I think was more at the director level but they had somebody who was taking care of the management side of things so that they could have tech leads focus on tech leading. But one or two of the places where I’ve seen principal engineer, at least one of them, it was basically an excuse to give you a higher salary than they could if you were a senior engineer. In other places it may vary. JESSICA: Sure. At Stripe, they had a very well-defined technical track that went as far up as the managerial track because they really do want people to remain technical and also they defined it pretty well. Basically, as you move up in the technical track, you’re expected to have more impact and influence at the company, like these technical fellows do at the top level. But you can think of it as if you want to be more value to the company, then there’s only so much productivity you can have. There’s only so much code you can write, really. As you get senior and more impactful, you start having more influence on what other people are doing, you start making the people around you more productive. As a tech lead, hopefully what you’re doing is making the people on your team as productive as they can be, even if the sacrifice is for you. I have a name for it. It’s generativity. I got this word by reading the Journal of Organizational Psychology, kind of randomly. This would came up in three articles in just one volume and every time, it had a different definition. But the definition that I liked and therefore the only one I care about is generativity is the difference between your team’s output with you on it and your team’s output without you. As opposed to your personal output, you can have a ton of productivity. You can be primed in the Phoenix Project and you could have a negative generativity because if you are dragging your team members down, if you’re not helping them, if you’re making them feel stupid, you’re actually going to be destructive even while you look way better than they are. This is one way to be a 10X developers, to hold the other team members down. In my opinion, this is not a senior developer. A senior developer is about generativity. It’s about, is two developers more productive because I’m on it? Two junior developers are more productive and you’re not doing the work of two junior developers. You’re bringing up the junior developers on your team, to you and then at a higher level, you can even do that for the whole company. I see several ways that you could go about increasing the productivity of your team and your company as you move upward in the senior developer track. There’s the usual ways of pairing and teaching, mentorship of helping other people understand what’s important, also sponsorship in making the managers aware of who should be promoted from junior to mid-level or whatever and who’s not happy on the team and who would be a really good fit over there. Networking is another one. One thing that most developers, when we start out don’t do a lot of is finding out what’s going on in other teams. That’s a huge generativity boost, both for your team and for the other teams, when you can find those synergies and more often, find those pitfalls of what you’re about to break for somebody else. Or what they’re about to break for you but we can express it in the positive sense of finding things that you’re both doing and could work together on. Management is another way that you can increase your influence, your leverage, your impact but if we talk about, that’ll be another segment. I’ve got a brand new one. This is totally new. You know the architect career track, which is stereotypically, I’m just going to tell you all what to do and let you deal with the fallout and making it actually work. SAM: I’m going to make beautifully UML diagrams over here. [Laughter] JESSICA: Right, which the business loves because one of the jobs of an architect is to make the technical reality legible to the business people and those diagrams add legibility. They make it so that people can understand or have the feeling of understanding without knowing the whole thing because nobody can know the whole thing anymore. That’s one job of an architect. Actually, Gregor Hohpe has a good book about this which I will link in the show notes. He’s fun to read and really fun to listen to but I don’t think he usually [inaudible] talks be videotaped which is that [inaudible] he didn’t, the last time I was there. I have a theory that the real architects, the real ones who are influencing how the software is actually written and increasing the productivity of the developers, have the title infrastructure engineer because an infrastructure engineer is building the platforms that developers are using and as we accept the face of reality of devops is a necessity of we have to operate the software that we write, we don’t just each team picks its own way to operate it. But that would be a mess because it’s a lot of work to pick a way to operate it. A lot of work to automate that operation. SAM: And it’s bad for the business to have portability problems like if I change from one team to another and I have to spend two weeks learning how to ops on that team, then I’ve just wasted two weeks of money. JESSICA: Yeah, that’s a dangerous consideration to focus on because then you start viewing people’s resources. It’s also a thing. That and it’s just a decision fatigue and the work of getting everything right. Well, before you get to the size of Stripe, most companies when you get three or four teams, somebody is doing the operations stuff and handing other people their scripts. Somebody did it to begin with and other teams just copy it. Then as you get bigger, you’ve got a team whose responsibility is to maintain that infrastructure and to keep the other developers productive so that everybody doesn’t have to know everything about everything because since your system gets big enough, that impossible and that happens really early. Way earlier than you think it will. But those people have huge generativity. They are leverage. This is the team that making your other teams able to focus on the business logic. That’s the goal and we haven’t achieve it yet but we made progress in that direction. We talk about how software is for and by people. This is very important. There’s also the part that people are influenced by software. The software we have available changes how we work. See, operational software that you have changes how you deploy your code. If you make something easy, they will do it. CHERYL: You talked about how this works at bigger companies where each team is responsible for each part. How would you say that plays out in smaller teams where maybe that kind of infrastructure work becomes a story that you take turns doing? JESSICA: That’s great because it spreads the knowledge. Usually, there’s somebody on each team who’s good at Bash and rectify the scripts then everybody else uses them. CHERYL: Maybe my small team doesn’t necessarily have one of those people yet. SAM: Mine doesn’t. CHERYL: But we all taking turns like, “Oh, we have to do that now.” [Laughter] JESSICA: You might look at that at your next hire, seriously. At Monsanto, it’s David Dooling and I have recruited him to Atomist with me. It’s one of those things where automating your work feels unproductive because it’s not your work and also because it’s more fun than your work. [Laughter] JESSICA: But it’s incredibly productive once you get like a decent idea of, “This is taking too long. I should stop now. No, this is going to be worth it,” or even not. If you just have like that kind of hack day where you can experiment and find that magical golden yak that once you shave it, there is wisdom under it skin. ASTRID: That’s the thing. JESSICA: Yeah, totally. SAM: There’s a pretty cold calculation that you can do for automation which is how much time am I spending on it now? How much time am I saving by automating it? And how many times does that run? You multiply time I save by times it’s run and that’s how much time you should spend on automating. It’s pretty straightforward. JESSICA: That’s a starting point. That’s a minimum of the time you’re going to save. Look at Git, how much time did I spend waiting for svn log? None, because I never used it. [Laughter] JESSICA: But now I use git log all the time because it’s at my fingertips. It’s right there. It was unusable before and now it’s usable. Now, I have a tool that I didn’t even know that I needed. Somebody quoted a [inaudible] article on Twitter the other day and I think it was at Google. Someone optimized the page load time to make pages look faster and they discovered that the average page load time actually went up. When they dug into that, they found out that it was because they were now getting a lot of requests from Africa, where before, it wasn’t usable from Africa so they just didn’t get requests. Now, it is usable so they get requests that are much more challenging so their average page load time went up. But that’s a win, right? CHERYL: Right. Making it so accessible to many people that’s a total win. JESSICA: Yeah, like git log is accessible to me and [inaudible] was not. The time that you saved is only the stuff that you know you will benefit from this. But the real benefit is the stuff that you do that you never did before because it wasn’t right at your fingertips. Or maybe because you have the time to do it now. I haven’t even started on my actual opinion of what — [Laughter] JESSICA: I’ll be talking about this in April. I’ve got a 15-minute keynote at O’Reilly Software Architecture. But you’ll get some of the advance thoughts. People are influenced by software and what you make easy for them is what they’re going to do so if we take the job of an architect, rather than to decree, you must use event sourcing or your service must be tolerant of downtime. Make that thing easy. Make it painful if they don’t. Maybe write automated tests that run on various services and make things turn red so measure it and make it easy for them to do. If you want a specific coding style, don’t just put a freakin’ RuboCop up there to yell at you on your pull request. I’m not going back to add freakin’ spaces in the place that you want spaces all over my code. I have better things to do than that. But when you’ve got RuboCop autocorrect, fine. You want a space there? Put a freakin space there. I don’t care. That’s like basic linting. There’s also like refactoring. Take what you want to do and make it easy. This is what we’re building at Atomist, among other things. We’re building kind of a framework so that people don’t have to have a whole team to build SlackBots to coordinate GitHub, with Travis, with RuboCop — I wouldn’t write them in RuboCop — also there’s automated code changes. If you want my code different, write a program that alters my code and if you want me to continue to follow that standard, automate a little reviewer that checks that and makes the commit. If you want me to close my issue after I merge the pull request, close the issue in JIRA after I merged a pull request in GitHub or something like that, make that notification that says, “You close this pull request.” Isn’t that great? Have a button on it that says, “Closed your issue.” Or, “Relate to JIRA issue.” Actionable notifications and automation of code changing and reviewing, I think this is what architecture should be doing. Not decreeing how things should be but automating to make that the easiest way for developers to work. That’s generativity. ASTRID: It sounds like what you’re saying is the architect should be basically like user experience researchers with software engineers and say, what are you guys doing? How are you actually working? And then build something that enhances that process. JESSICA: Yes. SAM: Or build something that nudges them more in the direction you would like them to go, if it is demonstrably better. JESSICA: Yes. ASTRID: Well, that if it’s demonstrably better as where I’ve watched the screaming magic happens. [Laughter] SAM: That’s why you bring data to that fight. JESSICA: Yeah, and if you don’t have data, rock-paper-scissors or whatever. Make a decision. Then you can get consistency between teams. SAM: Right, just as an example of that, a team that I was on a couple of years ago, we had a variety of process tweaks over the years but one thing that remained fairly constant for quite a while was that at the beginning of the Sprint, we would do planning poker, which is where we describe a story and everybody has these cards and we all hold up the cards which are labeled with points: 1, 2, 3, 5, 8, 13 and so on. If there is wild divergence, we talk about it and then everybody holds up their cards again until we come to some sort of consensus on how many points the thing is. We would argue about how many points a thing was. Was it five? Was it eight? Until eventually, we also had to track our time on this project. Eventually, somebody on the team who had a background in statistics took all of the data on how many points we assigned to stories and tried to correlate them to the amount of hours that we spent working on them and it turned out that we were pretty accurate for 1, 2 and 3 points and anything above three was just too complicated and there was no correlation or whatsoever between points in time. What we learned from that was if it’s too big, break it down. That’s one of the best examples I’ve personally of bringing data to the screaming match and it worked out really, really well. JESSICA: Yeah, that unexpected skill of statistics that you probably didn’t hire for but you got lucky brought a huge amount of value to the team because it save you a lot of arguments. SAM: Oh, yeah, that actually leads to another. Remember the bug’s story about I can save that for later. JESSICA: Yeah, of ways to advance as a senior dev, I think at anyway that you can bring up the productivity of the people around you, whether that’s networking, automating, encouraging. SAM: Or like you said, mentoring and pairing. That goes back to something that I saw on Twitter a while ago. It was the best way to be a 10X engineer is to find five other people and make them 2X engineers. ASTRID: Yeah, exactly. JESSICA: But also that statistics example brings up sometimes your most valuable developers are the ones that have skills unrelated to devops. You would think they would be unrelated to development but software is developed by people so there’s not much that’s not related. Any of those skills that are rare on your team is particularly valuable. Oh, and one more. Understanding the company, the business that you’re in, on one side networking. But on another side, really understanding the business that you’re working in, whether it’s like finance or insurance or retail or health care, that is a huge, huge benefit because it can save a lot of really wrong implementations. Personally, I think that if I were hiring software developers as a company, I would look for developers with experience in my industry and not care what language they knew. ASTRID: That’s interesting. SAM: That’s sort of leads into this idea that has been for me in my head is that you talked a little bit about how good principal or — what did you call it — a technical fellow, knows a lot of different teams in the company and has some idea of where one team might benefit from something that another team is doing. Then that sort of lead into networking a little bit. It seems to me that there’s a fuzzy line here. Darin, you started out asking about how do you advance as a senior developer without going into management. You know, there’s a lot of these things that boiled down to people skills and bringing value by connecting different people together who might not necessarily have the same jargon or even the same job titles or background. But there’s a really sort of an almost a dangerous slippery slope there of like if I get too good at that, maybe they’re going to try and push me over into management, right? How do we avoid that, if we want to? DARIN: Well, I really like Jessica’s focus because I’ve been thinking about what was being a senior developer mean for me. What should I be doing? You just help me shift the focus out toward the people around me and not so much about what I’m doing, which is really useful. Because the truth is I don’t feel that much different than I did when I was a junior developer. Still think I don’t know anything. I mean, I know I know stuff but I don’t know what I know and I don’t know how I know it. [Laughter] DARIN: I’m working with junior developers now and sometimes they come to me with questions and I’m like, “Well, you do this,” and they’re like,” How did you know that?” I was like, “I don’t know. You know, it’s just something that came to me at some point in my career.” If I think about it, there was probably some horror story back that, “Oh, yeah. That was the time I screwed up that option.” This is how I do that before but it’s years of acquired stuff that you don’t think about too much. But just changing the focus to — JESSICA: That’s pretty much the — DARIN: I guess so. But sometimes, there are other times in other areas where I’ve had to really work hard to learn something and I can articulate that process to somebody else. But coding has always come pretty intuitive to me. You know, I study and I learn but I just kind of absorb. Whereas other things I’ve learned other types of skills, I had to follow a series of steps that I can articulate those steps to somebody else but coding is different. But just shifting the focus to how can I bring the team up, that’s a great way to think about it, I think. ASTRID: I have a question tangential to that. Jessica, from what you explain about architects and then even some of the questions you just asked Sam, what are the managers supposed to be doing because it sounds like you could run this whole system without managers. What are they doing? JESSICA: That’s a really good question and it plays into a question on our Slack, from [inaudible] he asked about, “Is it too much to ask for your manager to be your career mentor?” Everything we’ve talked about the architect, this is pretty technical direction. This is like shepherding the software but that only has some impact on keeping the people happy. You can’t get anything done if your people leave or if they’re despondent or they don’t feel like they’re growing — SAM: Or if you’ve got 50 people packed into a room and that’s like right next to a construction area. JESSICA: And we haven’t gotten into how do you decide what to work on because you can build software and write all day and get nothing for it if you’re not building the right software. ASTRID: So your managers should be dictating the right direction to go in? JESSICA: Is that a manager or is that a product owner? ASTRID: See, that’s my question because I was thinking as you guys were talking, why should you be 10X engineer. This doesn’t seem to exist in other technical areas. There’s nothing like a 10X researcher or like a 10X doctor. Why should you be a 10X engineer? Is that something that we’re just making up because we can do that? Or is that a failure of something else in the system because our systems are changing so quickly? SAM: You actually kind of hinted at my answer right there, which is that there is no such thing as a 10X engineer. Some of us just like to think that we’re better than others. CHERYL: That 10X thing among musicians is actually a thing — a construct that maybe some people think is real but maybe it really isn’t a thing that if I’m just starting out and I can get into the studio of the best teacher, the strongest rock star unicorn, then somehow I will succeed because of their guidance. I think, there’s got to be some tempering of that. So many people who are been in the field like less than two or three years are hungering for that direction than help. But the other person is still just one person. Especially, if you’re stretched amongst 20 or 30 other people, how much effect can that really have? If you’re stretched among five, then they can do a lot to help. DARIN: There’s a distinction between people who are really, really good at what they do and people who can teach what they do and they’re not always the same. This especially true for musicians because the work is so abstract. You can meet fantastic musicians who cannot explain what they do at all and there are some people who are fantastic teachers that are never famous as musicians but they really know how to get people from a starting point to an advance point. CHERYL: Or if they know how to get them from somewhat advanced point to a more advanced point. In my personal experience was is that very few teachers were good at the beginning point that were also good at a college or high school level. It could be beginner teachers who were good at teaching beginners and there’s not a lot of exposure to that. But if you could teach someone who was a masters lever or higher, then of course, there’s a lot of exposure. There’s this assumption that since you can play this, you should be able to teach someone else. Then when they’re not with you, they will be able to learn as well and that’s a totally different thing than teaching them to play the song or teaching them to write this specific code to do this thing. It’s like helping them come to that mindset where they can figure out what to play or what to write and then come up with the plan that’s going to work in this case that maybe different from that case. SAM: Yeah, that was my first impression after hearing your question. I was like, “What if you find that magical musical guru and you study with them for two or three years and it turns out that what they’re good at is teaching you how to play like them. Have you really gained anything or do you still have to go through a couple years of mastering your craft until to the point where you develop your own voice? Does that make sense at all? CHERYL: Yeah, absolutely. I found, as a musician that I learned from people with very different voices and that help me learn faster like Jump Studios. Like my teachers came from different universities that almost like your parents: go live with a foster parent for to learn something different, hangout with the babysitter, get in trouble for your parents later. I haven’t been coding long enough to do that yet, really but it’s easier, I think to see other people’s voices and know what’s different about them because I can’t just hop on different kinds of tutorial that come from different perspectives. ASTRID: Does it work, though, in your opinion, Cheryl? Like there’s other really 10X people? CHERYL: No. [Laughter] CHERYL: I would say, they’re 10X teams and that’s the same with music like that rock star has, someone else is paying the bills at home and someone else running the music group and someone else handling the sound for them, like our fantastic MIDI. There’s somebody else is handling the sound, which makes them sound better and then somebody else is handling each part and as an aggregate, then they’re fantastic. ASTRID: I see, so then why do we do this to ourselves? Why do we even have this as a concept? It seems like it’s just self-defeating. JESSICA: The 10X thing? ASTRID: Yeah, the 10X thing. JESSICA: Historical reasons. I think in development, there’s been a trope for a long time. There was some research — or I meant there’s was an article — that was published in one place and said that certain developers are 10 times more productive than other developers and that you should just hire these 10X developers. There’s a book out about fallacies that we believe in software development and it debunks this 10X myth, specifically it was published at one place and then cited in a thousand and then all those citations start citing each other so that it looks like there’s a lot of sources but he traced it to its roots and that was like this one study and that study was like not applicable or that good. The 10X developer is a myth that has permeated our industry. Frankly, I observed when I was a young developer that I was 10 times more productive than some other people who were new developers. But as we advance and passed entry level, that is not the case anymore. I think we level up a lot. But maybe that’s one thing that makes it stick that you can look around and find a developer that is less than 10 times as productive as you at a lot of large organizations. CHERYL: I think it’s a useful abstraction too. If I’m considering a sports team, I’m going to think of the quarterback. I’m not going to think of the whole team. I’m not going to think of all the coaches and that’s okay, as long as we don’t try and make ourselves be all 60 people. If you think of that team as that person is the symbol of the team, I think that kind of brings this up too. JESSICA: It’s a fallacy that results from looking at productivity, instead of generativity because sometimes that person who is not nearly as productive as I am. It could be if they knew what I knew, if they had my context, if they knew the people that I knew, if they had the background in the code or if they happen to have lucked out and their three computer science classes at college taught them C in Unix and that’s exactly what they wound up doing as a job. CHERYL: How do we show that it’s if we’re working with non-technical managers? How do you show that your productivity in a generative way instead of saying, “I worked on these stories. I worked on this.” I mean, I’m going to be here the whole time. I’m not going to take a month off so that they can see what I would be like without me. JESSICA: What if this is the job of a manager? We’re talking about what are they even good for? What if part of their job is to recognize who is contributing in ways that are harder to see and giving them credit for that? ASTRID: I think that is a job of a good manager. When I’ve been a manager in other context, I really tried to spend my time helping to put the right people in the right places. We were doing a technical product but it wasn’t software but we had some people who were able to figure out the really tough stuff and they could only produce maybe two or three things each day, whereas versus another person who could go really fast at really easy stuff and produce 25. But the return on having those really hard products created was high so it was worth taking the right person, who’s this was something they were good at and letting them move technically at a slower productivity. But to produce something that was high quality that we were going to really use and then have other people who were probably never going to be able do that job and let them just escape on the easy stuff and just trying things out because at the end of the of the month, they would balance out. It was better to have those people in the right position that they were all happy and then not have them feel like they all had to do the same thing because I think that’s where people start to feel really upset and they feel disillusioned because everybody is not the same. Their strengths are different and if you give them the same goal and then they’re going to measure themselves against other people, then they start to feel like, “Maybe I’m not as good. Maybe I can’t do this.” It just didn’t help. We had a morale issue when I started and by putting people in the right positions and then leaving them alone and then not let other people tell them like, “I’m better than you,” it actually helped a lot. JESSICA: Nice. ASTRID: I think really, a good manager should be helping people be better at what they do. JESSICA: That kind of coordination and behind the scenes, sort of noticing who people are and what they can do and where the need is, that is hard and it’s time consuming. ASTRID: Yeah, which is why I don’t understand. That’s why I asked my original question because it doesn’t seem like managers are doing that a lot in software teams. I’m not trying to hate on all the managers because I think they’re also getting tasked with the wrong things too. But I think that it would need to have, it’d be someone’s job so that actually help other people deal with their jobs that are better and not give them a whole bunch of business task and metrics crap because that doesn’t really help anything in the end. You’ll meet your goals if you’re actually taking care of your people. I think instead, they have more focus on these business goals, which doesn’t really include the people so there’s always a disconnect. DARIN: Well, that actually ties into my original question, which is that a lot of people who have the title of software manager are senior developers who didn’t want to be developers anymore and weren’t necessarily trained to be managers, which is a totally different skill set. SAM: Yeah, or maybe they did want to be developers but the track ended at some point and the only way to make more money and to keep progressing, especially in an upper organization is to hop onto a different track. One of the reasons that I am absolutely horrified at the idea of ever personally becoming a manager is that I recognize that there is a completely different skill set. It’s one that I’m going to have to go back to being a newbie. I know that my brain is probably not predisposed to work well in those ways and the idea of being a newbie at something that I might not be inherently good at and having that responsibility for the welfare of other people, it’s just a horrifying concept to contemplate. ASTRID: I think because you actually know that about yourself, Sam. You’d probably eventually make a good manager. I think — SAM: Maybe in five or ten years but — ASTRID: A lot of the bad managers are the people who don’t even think like that. They’re just like, “I have a title. I get to run the world,” and they’re just so drunk with power and they’re railroading over people and they don’t even see it. CHERYL: Is it different minds that, whether you got empathy or is it just opportunity? ASTRID: Yeah, because you can learn a lot if you care about people. I think being a good manager is not something you can actually get trained to do. You can get trained on tools but it’s you either care about your staff as people or you don’t. If you care about them as people, then you’re going to take the time to notice like, “Look, this person’s been coming in. I noticed every day when we do our stand ups.” They’re not really giving much detail. They don’t seem to talk that much to their teammates because this is like their personality or is there something going on and they don’t feel comfortable saying in private group. A good manager would try to like, “Let’s talk,” and not make it this your-job-is-on-the-line conversation but for somebody who doesn’t care, they’ll just… you know, whatever. That one little thing that could just be alleviated with a good discussion could grow into a huge team disruption. Then the manager will just [inaudible] the team. SAM: I want to bring this back around to [inaudible] question, which is that he heard that it’s too much to ask for your manager to be your career mentor. We can get into what it means to be a career mentor versus a manager and whether this might or might not be compatible. What do you think? ASTRID: I think they should be your career mentors. My best managers were career mentors. CHERYL: Where I am now is completely built on the idea that they are and that they can be. But I think you have to select for that when you’re looking for a job. I see myself continuing the next good things that I’ll be looking at doing that, that being an important thing like do I get to work at something fun? Does this have a future? Is there someone here who can mentor me in the tech and the things around the tech while I’m there? I think a lot of people crave that. I think the people who continually self-improve want that. I think it’s valuable to have career mentors that are outside your job too, though because you’re their managers, if you’re ever going to- it’s time to go. JESSICA: Also, like you said about having multiple teachers that you find your voice when you have multiple sources of learning. ASTRID: But I think there’s a difference between your personal growth as a software engineer and understanding the opportunities inside of the company that you would thrive in. I think that is something that your manager should be helping you do. JESSICA: Yeah, I would say your manager only needs to be a mentor and even more than a mentor — a sponsor for you, if they want you to advance within the company. If they just assume you’ll leave, then no. The manager doesn’t need to be a career mentor. [Laughter] ASTRID: Very good points. SAM: Did Caroline just stepped in? Oh, hi! CORALINE: Hey, there. Remember me? SAM: Who are you? JESSICA: Yay! Coraline. It’s been so long. CORALINE: Hi! [Laughter] CORALINE: I have missed the show so much. I’ve been travelling so much for the last few weeks and I just got back from South Africa where I can [inaudible] and it was amazing. Jet lag just caught up with me so I just slept for about 14 hours just now. JESSICA: Right and let’s see if Coraline has any comment. The topic was should your manager be your career mentor. CORALINE: Oh, my God. My first impression of that is like what a terrible idea. [Laughter] SAM: Well, we’ve now got representatives from all the parts of that spectrum. CORALINE: I guess I have to express why I think that’s a terrible idea. JESSICA: Yeah and maybe define what is a manager to you? What is a career mentor to you? What are those roles? CORALINE: Sure. A manager is tied to a job and a manager’s job itself is she has to represent the best interests of the company and your best interests and not to cause a conflict of interest. I think having someone that’s a career mentor who works for your company, they’re going to focus on things like retention when it may be best for your career to move on. There are so many possibilities for conflicts to arise that just strikes me so it’s a really bad idea. Given how mobile a lot of us in tech are and the fact that we take advantage of that mobility to get the salary bumps that companies don’t normally give us because no one likes to give raises anymore, it seems like you would be going through a new mentor every year and a half or two years. I see a mentoring relationship as a long term relationship. It has to outlast the job you’re at. I don’t really see a role for a manager in that process. JESSICA: I want to distinguish components of mentoring because there’s mentoring like giving an advice and then there’s mentoring as sponsorship. As far as sponsoring you and your career advancement within the company, I think a manager absolutely has to do that or they’re failing. But you can also sponsor someone outside of the company as a mentor and like, “Have you seen this opportunity over here?” And, “I know this awesome developer. You should really interview her.” CORALINE: I guess for me, mentoring goes beyond like someone who’s giving you advice and it’s someone that you build a long term personal relationship with someone you have to trust deeply and mentoring is a two-way street. Both the mentor and the mentee have to get something out of it. That just seems to me to be in conflict with the responsibilities of a manager. JESSICA: Yeah, that is very different. CHERYL: What would you suggest for those people who have made their first foray in tech that are turning their manager into their career mentor? Where should they go to find someone else to do that? Can they take some components from their manager and go find someone else to fulfill the other parts? CORALINE: Probably so but I really think that, especially if you’re new in tech, you have to find two things. I think it is important to find a mentor to make sure that you’re on a path of learning and growth and that someone’s looking out for your future and sort of advising you on where to go from here. We have lots of great resources for getting people in the tech but not for keeping them there so finding someone like that, I think is really critical. Another thing is finding a community of peers because someone who is further along in their field than you are, while they may have empathy for where you are, they may not have the memory of what it was like to be where you are so having that peer network to fall back on to say, “This is really hard, isn’t it?” then you hear people say, “Yes, it is and we can do this stuff.” I think it’s really important. Finding a mentor is difficult but if you’re new in tech, you should be networking and networking and networking. There are lots of people who are available and are willing to be mentors if you can find them. I think there’s been some websites and so on that have tried to create mentor-mentee networks that I don’t think any of them really gain traction. I really think it requires sort of in-person networking to find that right person and find that right match. ASTRID: Coraline, I understand what you’re saying about the manager having the conflict of interest that you may have the retention. But one thing that I was thinking about as you were talking is that I have actually had managers who, I think encouraged me to leave the company, which was interesting. But I think maybe one of the difference is that, we were all in the same industry so they were kind of mentoring me from a position of I know what this industry is and I can see what you could be doing and you are have that opportunity here. That might be different in tech because I don’t know how many people are thinking about their tech career in terms of industry versus like acquisition of skills. Maybe, this is a unique issue in technology because I didn’t have the same kind of concern before. CORALINE: I think it makes a lot of sense and I don’t want to say that a manager can’t be a mentor. I just don’t think they should be your first choice but obviously, my experience is skewed definitely toward tech. SAM: Yeah, I’ve personally had managers who were from various points along that spectrum as well. I have had managers like they had a very paternalistic style and just rubbed me the wrong way at every possible minute. I’ve had managers who are totally hands off. While that can be freeing, it’s also like, “Uhhh… Where do I go from here?” I had one manager who not only advised me to leave the company but left with me to go to the next job. [Laughter] SAM: In my experience — JESSICA: What? What? You mean, managers are people too? SAM: I know, right? That last one and I are still friends and we keep looking for other excuses to work together again. But in my experience, that is definitely in the minority. Most managers that I have worked for or near, they get distracted by the minutiae of the administration of the job. Or they don’t have a technical background and they don’t really understand what our particular needs are so they can’t really be effective mentors. CHERYL: I’m coming from the mentor perspective. If there’s a tendency, I think and I’ve seen this in other places I work as well. Once other coworkers find out that this one person is good at mentoring and is willing to help, you get pigeonholed and a whole bunch of evil all come to you. There’s other people here as well who could do that would be willing to help but it’s like not knowing if they can do it. Maybe they feel that impostor syndrome, maybe I’m not ready for this and they don’t know how to make that jump. JESSICA: And then you’ve got the problem that you referred to earlier of having 30 to 50 students. CHERYL: Yeah. CORALINE: I don’t want to make it sound like I don’t like managers. I’ve had some really good managers. I don’t want to dismiss the role of the manager outright. I’ve a manager now which was really challenging me. Not technically because I’ve reached a certain point and I consider myself responsible for my own tactical learning at this point. She is challenging me to be diplomatic which is something that does not come easily be me, especially when I’m right. [Laughter] SAM: Which is always. CHERYL: And being a sore winner is always so much worse than being a sore loser. CORALINE: Yeah, and she sort of pointed out to me that if I feel very strongly about something, all of my diplomacy just flies out the window and I’m very declarative and I’m like, “No, this is what we have to do because it’s the right thing to do,” and I shut down conversation and I alienate people. I keep doing this because I keep feeling really strongly about things and I’m like, “No, there’s no compromise. There’s only one way to move forward with this. I’m sorry. I don’t even say I’m sorry but — [Laughter] CORALINE: I’m being challenged to work on that and that to me, makes her a great manager to me because she’s challenging me and I’m having to change in response to that. It’s really interesting and hard. JESSICA: Yeah, but if you want, not only to be right but to spread that rightness. Diplomacy is important. CORALINE: Yeah, I can’t be effective if I’m just right. SAM: Can I make a book recommendation along those lines? CORALINE: Can I say no? SAM: Yeah, of course. CORALINE: No, no. Please do. SAM: All right. Well, fine. I’ll just keep it to myself. CORALINE: No, please do. JESSICA: It’s a mystery. SAM: One of the things that I absolutely did not expect when I went back to college was to find a profound life altering text in 100-level writing class. But my textbook for one of those classes was called Everything’s an Argument. It’s by Andrea Lunsford, et al, I think. But this is basically a book on rhetoric but they don’t really talk about it in classical terms. It’s very modern, up to date. The cover of the edition that I had at the time was a Dilbert cartoon. It basically talks about how all speech is persuasive speech and it talks about the thing that made me think of it, particularly for you Coraline is that it encourages you to go beyond the statements that people are making and try to figure out what the values are or what the goal that they’re trying to meet is that would make them make that statement. It can be a profound tool, essentially for starting your empathy. Also, if you can understand where somebody is coming from and what they value and what they want to get to, maybe you can figure out how to either change your message or possibly even change your mind because you realized that they value this other thing you hadn’t thought of. JESSICA: It’s like requirements gathering? SAM: I suppose. JESSICA: You want me to do what? No, no, why. What problem are you trying to solve? CHERYL: I think that is so helpful but maybe you are right but you’re right on the wrong context and somebody has seen from the world, from a different angle and there are going to be people who when confronted with that forceful statement just that and you lose their voices. Then there’s a whole level of involvement that we would lose. CORALINE: It’s like being a rock in a stream — the water is just going to go around you. JESSICA: Yes and then you can be productive in your way but you’re not being generative. CORALINE: Yeah. JESSICA: Okay. This is the time in the show where we each decide something that we will take away or a call-to-action or something else that we say. Who want to go first? ASTRID: I learned from Jessica’s perspective what’s the stuff for architect actually is supposed to be doing because I’ve asked this question several times and most of the times, the responses I get are they’re just software engineers who get paid more because they think they’re smarter than everybody else. [Laughter] SAM: That is not always wrong. There were so much interesting stuff in this call that I’m having trouble thinking of a specific thing so I’m going to cheat and say that my book recommendation to Coraline is a call-to-action to any listener with time on their hands who wants to get better at arguing and not in the shouting back and forth sense but in actually persuading people. CORALINE: I’m going to pledge to read that book. JESSICA: I really enjoyed this episode and my call-to-action is to propose that we do more surprise episodes like this. CORALINE: Hopefully our listeners enjoy it — the free form conversation. JESSICA: Yeah, let us know on Twitter or you can email Panel@GreaterThanCode.com or even better, join our Community Slack. In fact, while we’re on the topic, if you become a patron of Greater Than Code at any amount, you get an invitation to our Greater Than Code Community Slack. Also, you get special patron-only content such as what we really talked about when Coraline popped in today. SAM: And you might even get invited to be on the show at random. [Laughter] JESSICA: Darin, Cheryl, you have any takeaways? DARIN: I have a couple, actually. The conversation around what it means to be senior and where to go next was really useful. I’m going to think less about me and more about the team around me. That’s going to be very useful. The other thing is that the mentorship conversation was very useful because I’ve never had a mentor. I think right now, I could really use one so I’m going to go and look in. JESSICA: At least we have the whole internet to look in now, not just the local community. CHERYL: Thanks for bringing me on. I did miss Mission Taco for this but it was worth it. [Laughter] JESSICA: Oh, man. That sounds good. We should go to lunch next week. CHERYL: My commitments are isn’t my work, except she’s on leave for medical reasons. I too, will be mentor hunting. Maybe I should watch out for that conflict of interest. CORALINE: It’s good to be back. I really miss you all and I’m looking forward to coming back to our regular schedule next episode. JESSICA: Awesome. Thank you for joining this episode of the Stone Cold Podcast. No, wait… [Laughter] CORALINE: Did we change it again when I was gone? I like Greater Than Code. It’s so fitting. ASTRID: It comes back every time, Coraline. Don’t worry. It will be back next week. CORALINE: What if it doesn’t? ASTRID: Then you’ll just tell everybody that you’re right and then — [Laughter] CORALINE: No, I’m right. The podcast is called Greater Than Code. Stop it. JESSICA: Thank you for listening to Greater Than Code. SAM: And that’s the way it is. CORALINE: Bye, everybody.