02:05 - Marcus Blankenship Introduction

02:52 - Pain and Difficulties of Moving From Programming to Management

10:50 - Image and Identity (Cont’d)

19:16 - Management; Making the Move to Management

23:37 - How do you know if you have a bad manager?

27:13 - Feedback; Tone of Communication

33:54 - What should you do when you get promoted to a management position?

48:25 - How do you know you are doing a good job?

51:06 - What if you don’t want to move into a management role?

Picks

The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz (Jessica)
The Narrow Road to the Deep North by Richard Flanagan (Jessica)
Star Wars: The Force Awakens (Chuck)
JS Remote Conf (Chuck)
Ruby Remote Conf (Chuck)
Freelance Remote Conf (Chuck)
The War of Art: Break Through the Blocks and Win Your Inner Creative Battles by Steven Pressfield (Marcus)
Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost by Johanna Rothman (Marcus)

Special Guest: Marcus Blankenship.

 

Get all messy and personal and crap.

Yeah.

Yeah.

It's Christmas.

Let's make Marcus cry.

Hey everybody, and welcome to episode 240 of the Ruby Rogues Podcast. This week on our panel, we have Jessica Kerr.

Good morning.

I'm Charles Max Wood from DevChat.TV. And this week, we have a special guest and that's Marcus Blankenship.

Hello.

Do you want to introduce yourself, Marcus?

Sure. I'm Marcus and I help coders like you who have to make the difficult transition to become managers or leads, do it a little bit less painfully.

I just want to point out that the team lead in Star Wars was the Emperor, not Darth Vader.

I'm going to see Episode 7 tonight, so I'm kind of excited.

Darth Vader was clearly the technical architect.

That's right.

I won't spoil. We shouldn't talk about this. I have very strong view on what I just viewed a couple of nights ago.

And I'm afraid I'll spoil it for you.

Yeah, you can't talk about it until tomorrow.

Yeah, I haven't seen it yet, so I'm safe.

Alright, well I'll be quiet. We won't discuss it, then.

Okay, so back to pain.

[Laughs] I know, right?

Yeah, Marcus, in your introduction you immediately started with pain and the difficulties of moving from programming to management. What makes that so hard?

Well, it was hard for me. And honestly, everybody I've asked about it so far, and probably you two will be the exception because we're doing a show, has said it was hard for them, too. And I'm still trying to figure out exactly why it's so difficult. But it was. So now, this is my turn to ask you, Chuck. Did you find it difficult to move from being a coder to being somebody who was in charge of other developers?

So, I kind of have, I have to give a little bit of background on this. First of all, I had previous management experience before I became a full-time coder. I actually ran a technical customer support team for a company called Mosey out here in Utah. Then I moved to QA and then I moved into development. And then eventually it came back around to where it was like, “We want you to be the team lead.” But the team lead wasn't manager/non-coder. It was coder that kind of pushed things along when they needed nudging.

That makes sense.

So, it wasn't as much of a painful thing, because I didn't have to really give up any identity. I just took on a little bit more responsibility and occasionally pretended to listen during meetings.

It is important to pretend. That might be the one under-appreciated skill, is the act of pretending to know how to make others appear… others need to think you're listening, right?

Yeah. [Laughs]

Oh, sometimes do people manage to listen without looking like they're listening? Is that a problem?

So, the thing is, is I was always pulled into the meetings where I needed to be there for 10 minutes of it. And I wound up sitting there for all two hours of it.

Right. So…

Oh, that's when remote meetings are beautiful.

Yes. And…

Well, that's…

Yeah.

That's another show, right?

Yeah.

But you try and tell your boss, can you just call me in here when you're going to talk about this stuff that I need to know about and stuff you need to know about from me? And I would get dirty looks.

So, Chuck I think that… so, from my very limited research of talking to people, your experience as a manager in any capacity sets you on the right foot to realize that there's a different mindset for it.

Yeah.

And that you can do it. And it is separate from doing the work that your team performs, although it is very important to understand that work. But it sounds to me like you had this great opportunity to do it in a way where it wasn't really a crisis of identity for you.

It was once I went freelance. So, when I went freelance it got to the point where at this point, I've hired people to help me with the coding and I still jump in and do it when I feel like I need to or feel like there's something I really want to do. But most of the coding I do anymore is either personal edification, so it's some project I'm interested in, or it's a demo project for somebody else. But that really hit my identity as a freelancer and as a programmer when I was effectively paying somebody else to do work that I could do.

I wonder. Why that was so hard?

Well, part of it was just that especially with these shows, I've gotten a lot of identity tied up in it, since I was in sort of a team lead position. And so, it's like, “Look, I have to be a coder and I have to have tech chops because I have to put that image forward on the shows.” And I felt like I was almost letting people down by not doing all of the coding on all of the things all by myself. And I had to get around that and recognize that a lot of the value I bring is adding infrastructure and help do the podcasts. And I can still contribute to the direction of the shows and I can still contribute with technical knowledge to the shows. I don't have to be an expert in everything. And that was kind of what I had to come around to.

Interesting. Now Jessica, you've been a long-time panelist on Ruby Rogues, right?

A year now.

A year now. Do you care how much Chuck code on the site and things like that? Is that the value he brings to your world?

Did you know that Dave Thomas creates the site and the billing system and everything for Pragmatic Programmer?

I did not.

That is such cred.

As in, create, read, update, delete?

No, [inaudible].

No, not CRUD. [Inaudible]

Like street cred.

Ah. Credit. Credibility. So, that's huge for you.

It's not. You know, I don't feel like it should be. But yeah, it is. I mean, when I was at a conference with Dave and he was like, “Oh, I have to get back to my room because the billing system crashed and I've got to check the code and debug it,” and I was like, “Wow, he still has the perspective of coder, of a programmer.”

Yeah.

And I always feel like, I'm like embodying the stereotype that hurts out industry, that you have to code to be able to talk to coders. But I guess I'm just illustrating the power of it, that I really was impacted by that.

Yeah, I think what I was driving at really was just that I have to work hard to go and get it, because I spend a lot of my time in the business of running the podcasts and things doing other stuff.

Yeah, for sure. And for me to hear that Dave Thomas was leaving a conference to work on the billing system because it wasn't working right, it seems odd. It seems like the kind of thing that you would want somebody who is minding the store to be on top of while you were out at the conference. Because your whole thing is to sell books, right?

You know, with Dave I don't think his whole thing was to sell books. I think a lot of it is to keep learning. And that's probably what he gets out of keeping his hands in the coding systems that his business works on.

I think that's really the key though, right? Is that Dave Thomas isn't just doing it to sell books. He's not just doing it to reach programmers. He's also doing it because he's interested in the problems that the business has and how to solve them.

Mmhmm.

And I think in some cases, some people have a really hard time moving up into management because they don't want to solve all of those problems. They're really only interested and inclined toward the technical ones. And other people don't have a problem with it because they see those other problems and they're just as interesting to solve as the coding ones.

I would also point out that the last job, full-time job, J-O-B, that I had, we had a manager of our team. And I think he had been a coder in the past and he had some side projects. But he didn't contribute any code whatsoever to our project. All he did was manage. That was his job. And I will tell you that he was probably one of the best bosses I ever had. And it was just because he was so focused on that that he didn't have to prove that he had any chops. He just had to go in there and basically clear things out of our way and make sure that the expectations for us were clearly stated. And he did that really, really well and represented things going both ways in a way that made the communication much easier and our jobs much easier when we actually had to do something. And he would allow us to make the decisions we had to make and led us to make the decisions with as much information and handling all of the concerns that we need to as possible.

Yeah, I think that you hit on one of the things I was going to bring up of what makes a good development manager. And one of them is I think you shouldn't feel like you have to prove continually how good a coder you are or were. And it really, as you sort of pointed out, it gets in the way of the real work that you need to be doing. If you're… but I think this is true of a lot of kinds of things. If you're constantly feeling insecure about things, about how's your team going to look at you if you're not coding? How is your team… it's not about you wanting to contribute. It's about you wanting to have a certain image in their eyes. So, if you can free yourself from that, I think that's a really important hurdle to leap over in order to be a good manager.

So, we're back to image and also identity. I wanted to ask you earlier. Could you define, what is the identity crisis that people experience sometimes when they switch roles?

Well, I can tell you what I did. And I did it all wrong as I'm sure. But you know, here's my nutshell story. I got into computers in the early 80s. I was really young. They were the first thing I think I was really good at and they were kind of the first thing that I was good at that other people around me stopped being good at. My family looked at the box hooked up to the television set. This Vic-20 thing is like, “I have no idea what that is and I don't know what you're doing on it,” and it seemed like a huge waste of time. But for me, it was like somehow my whole world changed when I started coding and I got into computers.

And all through high school, I spent a tremendous amount of time “online” which back then meant you were on a BBS and a telephone line and message boards and things like that. And I sort of self-identified with this idea of a hacker and what that meant. And I really romanticized it. I read a lot of old computer books. I was big into the jargon dictionary. I thought that computer history was really fascinating. And so, I saw myself as a programmer kind of at the core. And I used to say different things. Now as I look back, I would kind of reflect back they weren't true. Like, I used to tell people, “If you can do anything else in life other than be a programmer, you should. But if you can't, then that's exactly what you should do.” One of those stupid things we say in our teens and 20s, which it sounds really lame now.

Anyway, my point was I had this huge amount of self-identity tied up with it. It was, I could be bad at a lot of other things in my life and I was. I wasn't great with relationships with the opposite sex. I wasn't great with making a lot of money. I wasn't great with school. My grades were never stellar. So, all the other markers in my life were kind of, I was like a C average person. But when it came to the computer, when it came to interacting with other people around the computer, that's where I felt like I shined. I was really like, “Okay, this is what I'm good at.” So, that became my identity.

So then, when I made the move to become a manger, a team lead of four or five people, I thought what it was, was like added responsibility. Like, “Oh, I get to do everything I'm doing now except I have to keep an eye on a couple of people, too. Well, that doesn't seem too hard.” That was kind of my wrong impression of the job.

Yeah. One other thing that I ran across was just that I was very used to being measured by what I

contributed to the team as far as the number of stories I was finishing, as far as the amount of work I could get done, the number of hours I put in. So, there are all these different measurements of either how committed or how skilled you are. So, you could essentially say, “I add value by adding code to the codebase or by refactoring the code in the codebase.” So, you have these different technical skills. And if you're good at them or at least relatively good at them with relation to your team, then you feel that affirmation, that you are doing the right things and you're making those contributions.

And then somebody comes along and says, “Hey, we want you to do management.” And be that, that you're a team lead which means, in my opinion team lead usually means part-time manager. Or whether they come in and they say, “Look, we want you to run the development or manage this process or set of processes that help us make what we make,” then you're asked to basically contribute on a completely different set of skills and be measured on a completely different set of measurements.

And so, I see the identity crisis not just in the, “I'm not a computer person anymore. I'm a management person,” but I also see the crisis in, “I have no idea how to get the level of affirmation or to say that I was successful, I don't see a way that I can say I contributed so many lines of code, or I finished some stories or squashed so many bugs, or made the process so much easier or save the company so much money.” Those measurements are different. And so, you're playing by different rules and it's hard to say, “I'm really good at the management game,” after you've been really, really good at the development game.

I completely agree. And I think the first place where that showed up for me and typically for the folks I've worked with isn't in the external affirmation. It's the internal affirmation. It's, “Man, I feel like I didn't get anything done.”

Mmhmm.

Oh, yeah.

And when you check in code, when you… every time I push code today, every time I do anything where I'm accomplishing even the tiniest little problem being solved in code, I get a little bit of brain candy. My brain's like, “Yay! You did it!” I don't know if that makes sense. Maybe that's just my brain.

“The test is [working]!”

Mmhmm.

Yeah, it feels good, right? And when you go… I remember after, like a couple of weeks as being a manager I was like, “Man,” and this is what I thought like, “I'm going to have to start coming in Saturdays to get my coding done.” So I did. My boss never asked me like, “Why aren't you coding more? What features have you contributed?” My team never looked at me, this was one of my fears, was my team will say, “Well, what value are you? What use are you? You're not even coding.” That was of course a completely unfounded fear. But I didn't feel like I was really adding anything to the organization at first.

Yeah. Well, the other thing is I found that the targets for developers in a lot of cases are, you finish the story, or we as a team hit whatever benchmark we set for the current sprint. And so, you know within a week or sometimes two weeks whether or not your performance was up to snuff. And as a manager, a lot of times it's, did we reach enough of these targets on the development team to actually impact the bottom line? And so, in some cases, yeah it's like, “Yeah, we had a really productive sprint,” but you go tell your boss and they're like, “Good, good, good. Keep doing it.” And then when you get a new feature out that allows you to sell more product or make the customers more happy or some other metric that they're really looking at which can be three months down the line, then they're like, “Yeah, you did a great job.” And there's no other clear way for you to measure how things are going.

At least not in the positive. Sometimes in the negative when people quit. That's a big…

Mm.

Jessica?

Yeah, I was going to say it's all about those expectations, especially the self-expectations. You feel like, “Oh, I'm not going to live up to the expectations of your team,” but your team actually isn't watching you like that. It's really our own expectations that hold us back, I think. And as coders we know what we expect of ourselves. And then when we move to management not having done that before, we don't even know what to expect.

We don't. And a lot of us don't have good role models for managers. As somebody who always liked computers, I had role models of teachers, of college teachers. I would read books on… Steven Levy's 'Hackers' was a great book. I remember reading that and like I had all these really positive role models around coding and computers and computer science. And I had no role models for being a manager, really, until I started working in an organization that had good management. Before that though, I just thought management was one of those things completely to be avoided, like marketing or something.

So, you sought out role models with coding. You read books about people. You looked for that.

I didn't do it intentionally as in like, “What I want is a good role model.”

I just found myself fascinated with how other programmers worked. And so, I read books about it. And I read magazine articles. And yeah, I thought it was very interesting. But again, I think that that just continued to tie my self-identity into this thing called coding, which to me still is the most magical kind of work that I've ever done. I know that SICP and other books have wizards on the cover. To me, coding is like being a wizard. You speak a spell. It's almost like you know the spell, you can make something happen. And that just hits me at like a junior high Dungeons & Dragons kind of level.

Totally. So, since then have you become fascinated by how good managers work?

I have. And part of that is I've gotten a chance to work around really good managers. And I've made a mountain of management mistakes. And I've realized I think that I have this idea now that managers… I used to think that management was not the act of creation. Like if you were coding, that was a really creative endeavor. You were creating something. But management wasn't. And now I have this idea that management is actually the act of creating teams of people that work together, and that that is… that there's a lot of intentional work that has to be done there.

And great managers I think just kind of fade into the background. And that's good. You almost don't know if you have a really good manager until maybe you work for a really bad manager because he's just like, almost transparent, or she is transparent to the process. And you just find you're working in a group that's healthy. You're working amongst people where there's a really good culture, where there's good process, and your manager is oftentimes able to do it in a very nuanced way that almost feels effortless. New managers oftentimes wield the sword of authority as though it's a bit too heavy. And so, they tend to be heavy-handed about things. Experienced good managers are able to be nuanced and understand when to apply what techniques to get the results they want. And most of the time people don't even really realize when they're working.

So, good management is like aikido?

Ooh, I like that.

Management's… dev lead, management aikido.

Yeah. I mean, sometimes you have to… I don't know anything about aikido. My guess it there's… I think I've watched a movie and it was in it or something. But there are probably a lot of soft, flowing moves that's redirecting that force that's coming at you. There's probably time for some direct force but it's probably much more rare than other martial arts. I'm guessing, here.

Yes, yes. In aikido, my daughter takes this and I watch the lessons sometimes, it isn't you causing your attacker pain. You put them in such a position that they cause their own pain.

Now, whether they realize that or not is left… they probably don't and it doesn't matter. But I think that that's a great way of describing what a good manager does, because there are things that people do that cause pain in the organization. And how many times have you found that the people who cause the pain aren't the people who feel the pain?

Oh, yeah.

Mmhmm.

Yeah, that's the feedback loop that we keep trying to close with dev ops, with all of the end-to-end from server to interacting with the users that we're trying to get one developer in that loop so that we can communicate that pain, right?

Yeah, exactly. So, I guess I think that for me again going back to your question, making the move to management was really hard. And once I got it, I think it sort of clicked. There was a new set of skills here and I needed to start pursuing it a little bit differently. And I needed to become a little bit obsessed with it, kind of like I had been with coding. And originally I remember when I became a developer, I'm sorry, when I became a manager, my dad who'd been a long-time manager at a retail store had told me this. He basically had pulled me aside and he just said, “Now remember son, everybody deserves a good manager.” And I don't know why, but that really resonated with me. And it kind of scared me because like, “Oh man, what if I'm not a good manager?” Like, what does it mean to deserve a good manager? Is it like, I deserve the right to be able… like free speech kind of deserve?

It wasn't in my opinion exactly the same thing, but it was this idea of like, we all have to go to work and there's a mountain of terrible managers out there. And people really, they really deserve something better than they're used to.

That's really interesting.

That brings me to a question. How do you know if you have a bad manager? How do you know it's not you that is the one who could be preventing all of this struggle and difficulty you're having, but that really you're not getting what you need?

In my experience with one exception, you have a manager. That's how you know you have a bad manager.

Gosh. [Laughs] I'm so sorry.

A mountain of bad managers.

Jessica, do you have a good manager?

Yes, yes. I have been very lucky in my career. I have had many great managers.

Have you ever had a bad manager?

Yes.

How did you know? How did you know it wasn't you?

I'll tell you how I knew this was a bad manager.

He couldn't [see] how we've got our team… our team is working pretty well together. We've got our team where [inaudible] we've got our little stand-ups and our little scrum-ish thing going. And in the stand-up, he asks people to name their blockers and he writes down on the paper, the giant post-it board, one of the blockers which was so-and-so doesn't have access to this thing that he needs access to. And of course, we've already submitted the request for that long ago. The next day in the stand-up he says, “Alright. And now we're going to cross off the things that are no longer blockages,” and he crosses this off, and we're all like, “That's still a problem.” And he's like, “No, we must cross it off.” I just… reality, okay?

So, good managers…

[Inaudible] It's obvious.

Recognize and face reality?

[Laughs] That is a great step one.

Oh, man.

I have a very similar story, except it was, so we had this scrum master and he was supposed to be part of the management team. And he was supposed to help us manage our process. And he calls it infra-retrospectives. And we'd sit down and he had this thing. It was the good, the bad, and the ugly. And he would ask us. And he would just put somebody on the spot. “David,” David Brady was on this team too, “David, tell me what's an ugly on this team.” And we're all staring at him like, “You are.”

But I mean, he would. And he wouldn't let up unless David named something. And then it will, “Well, what's a good on this team?” But instead of fostering a discussion where we could actually talk about some of the problems that we were having, which we inevitably did anyway usually when he left…

You'd think these are jokes, that people go through this. It's real. But our planning meetings, we would actually get together before the planning meeting to have the planning meeting so that we could cut short the planning meeting. Because his planning meetings would go two days and our planning meetings would go two hours. So, in my opinion, you know you have a bad manager when people are trying to work around them. And you also know you have a bad manager when you had a process that worked before and they have come in and made it worse without any measurable benefits. Now, I want to give a little bit of a caveat there. Sometimes you have to try things that are going to make things worse in the short-term but pay off in the long-term. But they should be able to explain to you what metrics you're looking at in order to determine whether or not it's working. And they should be able to give you an idea of what you're really working toward. But yeah, if you're working around your manager, it's a problem.

The other thing is if you're constantly having communication issues, and this is another thing that came up, this was my second development job. The boss would come tell us what he wanted. We'd go build it. We'd bring it back and then he'd tell us that wasn't what he wanted. And he wouldn't work with us on communicating. He just expected us to get better at figuring out what he wanted.

Yeah, feedback, yeah. Going back to that feedback loop, right? You know, there's this concept and I'm sure you guys are familiar with it, that concept of the code smell, right?

Mmhmm.

And like I hear people talk about it and they're like, “Oh, this code smells,” and, “Oh, why?” and they will point to five or six symptoms. But oftentimes they're not the hard and fast rules. They're just like, “This is like a smell of something bad.” I think you kind of know when you have a bad manager.

Yes.

I think there's like a bad manager smell.

I think that takes experience, really.

It did when you started looking at code too, right?

Yes. Yeah, that's true.

Yeah.

I think that's a fair point, Jessica. Because I know people, they go get their first dev job, and they have no idea that they're working for somebody that either… best case is clueless, worst case is sadistic.

Yeah.

And they just, they don't know because they don't have anything to compare it to.

Right.

And they just assume that that's the way a development job works.

You have to have good managers before you can recognize a bad one.

But I do also want to push this a little bit, and that is that if you're new and you have this gut feeling that something isn't right, something probably isn't right.

Yeah.

And it's probably not you.

Probably not. I think one metric that I will use if I were new and doing it again, actually this is true of any time I interact with a new boss which hasn't happened in a long time, I think the amount of feedback you get. I think good managers give feedback. They give feedback. They give feedback. They communicate. So, if you're finding that you're working at a job where you're communicating with your manager once or twice a week, I think pretty quickly that's going to be a struggle to really stay connected with what your manager wants. And if you're working on a team of people and you have, and you're plugged into a process, maybe it's a little bit different because you've got mentors, peers, informal leads, trainers, other people you're interacting with. But if you got hired as an IT person at a manufacturing company and the IT manager only pokes his head in twice a week to check in on the project status and other than that you're left alone basically, I think that's a really big bad manager smell.

Yeah. The other one that I would put out there at least for programming jobs is the tone of that communication. So, in a lot of cases when I was in high school and college for a little while, I worked on janitorial staffs. I worked at Kmart. I worked at a McDonald's for a little while. And in some of those cases, the only way that they can get things done is to yell and scream, because let's be honest. They weren't paying people very much and in a lot of cases, people needed that kind of motivation. But as a programmer, you're a skilled worker in a skilled job. And if it's constantly adversarial, then to me that's a code smell as well, or a management smell.

Mmhmm.

Because they are not recognizing that you have some expertise and something to contribute and they've hired you as a professional.

I completely agree. I think it's really important that people who manage developers have significant years of experience as a developer. Do you guys agree or do you think it's not necessary?

I hate to say always, but the other thing is…

Mostly.

I would say that it is definitely a leg up. I'm really hesitating to say yes, and the reason is that a lot of the issues you're going to have on development teams are the same you're going to have with any other team with people. And so, if you understand how to help people get the right thing done, even if you don't understand the process, you can probably be effective at it. But you've got to be really, really good. Otherwise, you can short-circuit some of that just from the fact that you understand how they work and what they're doing. I think somebody who hasn't been a developer for a long time that's put into that world will probably wind up just as part of being a good manager, figuring out how they work and how they do what they do anyway.

Right. I would take a good manager who knows that they don't know what developers do and listens over a developer with no management experience as my manager.

I would agree with that. I think… and I definitely didn't want to say that in order to manage developers you have to understand what they do intimately. I think the more you do understand what the people that work for you do, the better chance there is you can empathize with them.

Mmhmm.

You can help and guide and direct them. You can help them troubleshoot their problems. My first as a manager, I led an ERP development team in a language and platform I'd worked on for four years. So, it seemed really natural. But the next time that I got promoted, it was a sideways promotion. And I was asked to go hire and built a team in a technology I knew nothing about. And once I did that, it actually happened three more times at that same company.

So, I actually got pretty used to… at first I felt it was really important that I be one of the better developers on the team. Like, that was coming back to that self-identity or the, “Oh, I'm the manager. That means I better be pretty darn good at this. I better really understand the system.” And it was a little bit more of my growth to then move to a team where I didn't know anything. I didn't know. They were working in Java, J2EE and on the web. And I didn't know any of those things. And here I was managing them. And I did it successfully for three years. But it was a really a growth opportunity for me.

Well, and I want to make sure that people understand too, that we're not saying that it doesn't help to have the experience working in a technology your team's working in or doing the same kinds of things that your team was doing. It definitely makes a big difference and it helps your communication which is really important to managers. But at the same time, what we are saying is that it's not essential. You can learn it on the job.

And there's an uncanny value of evil here. The worst is when the manager thinks they know more.

They know everything that's going on but they actually don't.

Well, I've never been accused of that or guilty of it either.

But I guess the nice thing is, you sort of mentioned it Jessica, is when I moved over to manage a Java team and I didn't know Java or web or any of these other things, I was not at all really concerned… I didn't think I knew it all. And in fact, I wasn't that tempted to dive into the code. I remember spending a lot of time reading Java books because at first I thought, “Well, the first thing I've got to do is come up to speed on these tools and technologies so that I can prove,” to myself primarily, “that I'm worthy to be the manager.” And of course after six months I realized I'm never going to be anywhere near as good as these guys who had been coding in Java for 10 years. So, I abandoned that effort in terms of trying to do it to make myself feel better.

So, I have to ask this. Let's say that we've got Joe developer and he gets promoted and now he's Joe manager. What should he do? We've talked our way around and kind of nibbled around the edges of what a good manager is. But brand new manager coming out of a dev team, now he's managing the dev team. He probably isn't going to have a whole lot of time to code. I think I've gotten from you that he probably shouldn't necessarily be coding. But what should he be doing? What kinds of skills should he be developing? What should he be learning about his team that he didn't know as a developer?

I'll give you my opinion then we can round-robin this. The first is, you sort of hit on it. I think he should stop taking production coding tasks. I'm not going to go as far as to say he shouldn't touch his compiler or the code anymore. But when he puts himself in the production cycle, or she, they put themselves in a production cycle, they're subject to a whole lot of other deadlines and measurements that their team is in the midst of, and they were used to being in the midst of. But that doesn't really reflect their new role. So, I guess getting out of that production cycle of coding I think is important, at least at first.

And then the second thing is I think you've got to establish something like, I just start with a really basic do weekly one-on-one meetings with each person on the team.

Oh, wow.

Get to know them. I know, isn't that terrible? Like how [inaudible] is that?

No, I've never had a manager do it.

Really?

Really?

Oh, I wouldn't work for someone who didn't.

Not one-on-one. He… so, the best boss I ever had, and I told you about him, he was the last boss I ever had. He would pull us aside at least every quarter, probably once every month at least. I can think of occasions where, but at least not deliberately that I noticed, he talked to us on a weekly basis. But not one-on-one.

Jessica, you made a really strong statement. You said, what did you say?

I said I wouldn't work for someone who didn't do weekly one-on-ones with everyone. Or at least every other week. Every other week is okay.

Why?

Well, it's that feedback loop again. We talked about how as developers we need feedback loops so we know how to write the right code. A manager needs a feedback loop to help their people to find out how they're doing for the team.

So, is the feedback loop for the manager, not necessarily for the employee?

The manager's job at that point is to listen, yes. To find out how the employee's doing, what's… you hear about the status on various things but it's also, how are you feeling? How is this working for you? Do you feel productive? Are your energies directed in a way that you find fulfilling? Because if those incentives are aligned and they are in a good organization, the developer feeling fulfilled is also often means that they're helping the user and solving problems. Yeah, it's that feedback loop. And for the manager, it's about listening.

I was going to ask you Marcus how as a manager you get team members to give you that feedback.

I think, and I'm going to interject here, I think it's about listening. But I also think it's about giving feedback. Because I have a policy in my life. It's sort of this… have you ever had an annual evaluation, either of you guys, at your job?

Ugh.

Okay. That says…

That's all we needed to hear. Have you ever been surprised by something that you heard at your annual evaluation?

Yeah. That is one of those major flags that are beyond a smell. That's like finding a turd.

That's exactly right. That's the giant management turd.

Yeah.

So, I have and have for years had a zero surprises evaluation policy. And the weekly meeting is not only a time to get feedback from your employee, because after all people are not loyal to code and they're not loyal to companies. They're loyal to other people. And if you're not sitting across from one of your employees, and this is my opinion of course, and you're not interacting with them as people hearing what they like and don't like, hearing their struggles, hearing their aspirations and their dreams, and them helping them with those things, that's where I think real leadership and loyalty is built. People want to work for somebody that they believe in and that they want to… hope to follow.

Really, if you're a new manager you got to know your people, hope that you're the kind of manager that they would want to go down with the ship with. That's what kind of manager I think all employees want. But unfortunately it's the kind very few get. And I think the weekly one-on-one is a great place to start establishing those communication patterns where you bring up little things in private, gentle small corrections. You don't save them all up for the end of the year. You don't even save them up for the end of the month.

No. You give them [Inaudible]

And I [inaudible]… If I hadn't talked to you about something and your annual evaluation came along, I would now allow myself to put it on your evaluation unless we had discussed it multiple times before.

Yeah, yeah. And those weekly or every other week, that's a time when you can receive actionable feedback. When as a manager you can say, “This particular incident,” maybe, “How else could we have handled that to produce better results?”

I think you're right. And it's very important to be specific, right? If you sit at the end of the year and you tell your employees, “You're not very good in front of a customer,” that is a hurtful and worthless thing to say.

Ugh.

But if three days after a customer meeting you say, “I think you should have listened more and been more diplomatic,” or, “I think you shouldn't have just said yes to everything they wanted and instead balanced the whole company's needs,” you could give really specific feedback where people can grow. And so, I think it is really important to be specific and concrete and give little pieces of feedback. And unfortunately, because so many of us are conflict-avoidant, we like to imagine that we don't need to or that we're just going to save that up for a special miserable time of the year known as our annual evaluation.

Well, my annual evaluations at the companies that I worked at that did them usually went something like this: Alright, we've got all these lines.

You know, they didn't want to talk to me and I didn't really want to talk to them. It was just, “Alright here we go. Oh, we've got the blank for what you do well. Now, let's see. Let's make something up here. Oh, and what you need to work on. Let's make something up there.” And it never occurs to them that the person [inaudible] actually reads these things. And so, I run into my boss's boss or my boss's boss's boss and it's like, “Oh, I saw that evaluation,” pat on the back. “You're doing really well with X, Y, and Z. How is it coming with your,” whatever problem.

You know, and I'm just like, you know, I'm looking at him like, “What problem?” “Well, your evaluation said” and I'm like, “Oh.” Because I can't tell my boss, the boss's boss, that my boss lied on my evaluation because that causes problems.

It does, because he had to fill in every box, right?

Yeah.

Right. Now, I'm going to just say here Chuck, I have sat in… the organization I worked at for 14 years and I really grew up as a programmer and a manager in, we had one of those forms. And people complained about it. But I will have to tell you, I think it's not the form's fault. It's the manager's fault.

Well, it's the expectation that's set around it. That's the problem.

And that comes back to expectations. My experience with that form was that I actually would take this one-page form and I was encouraged to use it as like a personal end-of-year retrospective. And I remember literally about five years in, I walked into my manager's office and I had written 32 pages. And I plunked down his copy and my copy. He was thrilled. We sat there for three hours and went through everything in that. And I got great feedback. But that's because I was really excited to think deeply about these different things. I wasn't just filling in boxes. And I had been taught you're not just filling in the boxes. You're dreaming a little bit. You're bragging a little bit, in a good way. You're thinking about what you did well, what you'd like to do better. Because if you can disconnect it from a lot of other organizational things, then I think those kinds of [inaudible], actually are really helpful for self-work.

Yeah. That boss I keep talking about who was so awesome, we did quarterly reviews. And our bonuses were actually based on the quarterly reviews. However, the quarterly reviews were, we set some goals three months ago. These are things that you said you wanted to do. And so, we're going to evaluate how well you did on those and then we're going to determine how much of your bonus you get. And the thing that was really interesting about it was that at the beginning of the quarter when we set those goals, it wasn't “You're going to get so many lines of code written,” or so many stories or this or that or the other. We were a Ruby and Flex shop and if I had told my boss I wanted to learn Go and have written some side project in Go, that would have been what my quarterly bonus was based on. So, it was entirely based on the ways that I wanted to grow in the business. And it allowed him to coach us and attach a reward to it.

I think that's great.

I suppose yeah, a good boss can use it that way and can direct it that way. Marcus, I'm curious. You mentioned that you used the annual review as an opportunity for self-work and self-reflection and that that worked really well between you and your manager. But to me, that doesn't fit with what Chuck said about the boss's boss's boss reading those.

So, first of all I did that when I was an employee. And it was, as I've looked back on it there were lots people who all they did was complain about the process so they got nothing out of it. I chose to take a different approach and to realize that this was a tool I could use to dream a little, to look into myself, to imagine the possibilities. And sometimes I did have stuff on there that was kind of personal, like I'd like to lose 20 pounds. I'd like to run a five-K race. I'd like to do things, like I'd like to learn something completely outside of what my work says I should do. And again, this was a manager I worked with weekly. And so, it's by no means a substitute for a relationship. But yes, this document then goes up all the way to the Vice President who flips through them and reads them. I haven't had a Vice President who never asked me how my diet was coming.

Who never asked me if I was going to the gym.

I think that having those kinds of things on there, like I imagine when I've been in the upper parts of management, you sort of… the higher you go, the more you realize that all of us are flawed and all of us have things we need to improve. And most of all, you. That's at least what I found. The higher up I went, the more the curtain was pulled back, and the more mistakes I realized that I would make. And unfortunately, most companies are really, most managers are completely terrified of showing their team that they've made mistakes. In a little bit the same way as a lot of parents are really terrified of showing their children that they've made mistakes. Because it's about that expectation and that idea of, “Who am I to you? I'm somebody who needs to not make mistakes.

Otherwise why would I be the manager?” But of course, that's not at all true.

You don't get to be a manager because you don't make mistakes. Quite the [opposite].

Well, I do.

You get to be the manager because you hire the people, Chuck.

That's right. [Chuckles]

Or maybe it's because you've made so many mistakes that you've learned from them.

I like to think…

I make so many mistakes that I make mistakes making mistakes.

I still make mistakes. I still make terrible mistakes. Anyway, we won't go into all those mistakes. That's for another episode. But you had asked me, you'd asked me Chuck. You said, what should we managers do? I think having a regular, I would say every two weeks is fine, every week is a little bit better, especially if you're just learning the skill, learn to meet with your people.

And pick a format for doing it. If all you do is get together in your one-on-one and you imagine that there's going to be these amazing conversations, that's not necessarily going to be true. So, have a format. I like a format that starts with a little bit of accountability. “Hey, what are you working on and how's it going?” “Oh, what are you struggling with?” “Oh, you're still working on this. Are you stuck?” And as the manager, you're gauging skill. You're determining, is the person distracted? You're sort of having a little bit of accountability.

Because let's be honest. As much as we all love the idea of communism in some ways, that we're all just singing Kumbaya, managers do need to be able to hold their people accountable for things. And the more you can do that gently and the more often with little nudges, the better it is, in my experience. So, I like to start with a little bit of like, “Let's just talk about the project,” and then move into oftentimes if we've established quarterly or annual goals, I think it's a great time in the one-onone to just say, “Which goals are you working on? And how are they coming?” Of course, it's always in the context of, “How can I support you?” no matter what the goal is, personal or professional.

I also find, I can't tell you the number of times I would just ask people, “Do you have any vacation coming up?” “Oh yeah, I'm out four days next week.” “Oh, okay. I wish I would have known that two weeks ago and maybe next time you could tell me a little more in advance. But okay, we'll make that work.”

Dang it, I do that all the time.

Oh no.

Yeah, but you work remotely. The situation is a little bit different. It sucks if they're planning on you getting some work done. But…

Right. And then I guess the last thing is just, as you guys mentioned, Jessica, as a manager you really need to hear how you’re doing. And you need to give people a safe place to say, “I think you're missing on the important stuff. I don't think you're doing a good job.” So, sometimes that means you've got to ask a couple of different ways. It's not just enough maybe to say, “How am I doing in this role?” because I bet everybody's going to say, “You're doing fine.” So, asking questions like, “What did the last guy do that you really appreciated that maybe I should consider?” or “Tell me something about what you would do if you were in this seat,” other ways to have conversations where you can get some feedback on what you're doing. Because generally people are going to be pretty worried that if they don't tell you everything's great, of course you're going to get mad or punish them or something like that.

Yeah, that's really clever.

Alright. So, I need to start winding down here in a minute. But I did also want to ask. For people who have been in management for a while, how do they evaluate themselves to know that they're doing a good job?

I think getting feedback from the team is the primary way. I think the 360-degree review on a quarterly basis or a regular basis where people can give you feedback. I think skip level reviews if you're familiar with those, where you ask your manager to interview your team about what you can be doing better so that they feel empowered to be honest and they're not having to say criticisms to your face. But those are just a couple ideas. I think it's really easy to imagine just because your team is working really well, that you don't have any place to improve as a manager. I don't know.

Jessica, what do you think?

We talked about how as a coder you have an expectation of yourself that you would produce such code and make such users happy. I think as a manager, what matters is whether your team is happy, whether your team is growing, and then whether the users are happy, whether the people that your team is producing software for, is that getting done successfully? And if those two things are happening, then awesome. Also, it's a good sign if the people on your team are growing and moving out to start their own teams. Someone told…

Mmhmm, if they're getting promoted.

Right. And if they get promoted past you, even better.

Mmhmm. That's a scary thought.

That that reflects really well.

That's a scary thought.

Related to that though, are they bringing people into your team? Are the people working for you actively telling their friends, “Come work for this guy. He's awesome,” or, “This girl, she's awesome”?

Right. Do they exhibit signs of loyalty? For example, when you need a little bit more effort. When there's a deadline, do they sign up for it? Are they all in because you're all in? And again that idea of, you're the kind of captain they would go down with the ship with, right? Or, do you find that when things are going bad, you're all alone in the office firefighting and you're sort of leaving yourself to do that activity when really the whole team should be there? I think that you hit on a lot of great points, both you guys. And you got to be delivering organizational value. You have to make sure your customers are happy. You have to makes sure your team is happy, your boss is happy. And in the end, I think you do have to like the work. You have to have transitioned your mindset from you add value not just from writing code but from building a great team that great coders can work on. And that you can take coders that are less experienced and move them up the skill chain to be really good at their jobs.

Alright, I have one more question and then we'll head into picks. And this is aimed at both of you. If somebody comes to you and asks you to move into a management role, what kind of obligation do you have to say yes?

None.

Yeah, I agree.

But sometimes I know that people feel some pressure. The people above won't be happy if they tell them no, or they feel some obligation to their team to step up because the odds of them hiring somebody who isn't good comes into play, or things like that.

I was talking to someone the other day, an engineering manager. And someone asked him, what would be a piece of advice you would give to a developer who's thinking about moving into management? And his first reaction, I don't know how much he was joking, but I think it's a good reaction was, “Don't do it.” As in, don't take this lightly.

Mmhmm.

You really need to want to. And if your heart isn't in it, you're going to be part of the mountain of bad managers.

I like that. I certainly won't agree, don't take it lightly. One of the folks I mentor described it this way. He said, “I took the hit and became the manager for my team when the bad manager left.” And that phrase 'took the hit', he viewed it as like 'I sacrificed myself'.

And stepped into a place no one wanted to go to be the thing no one wanted to be out of love for my teammates. And since then, he's doing a great job because he really practices servant leadership which I think is really important. But definitely don't take it lightly. I know that I felt a lot of, when they asked me to become a manager, I think it was my pocketbook, my wife, and the impression that this is what you do at a corporation, you move up the ladder, that were all… and my wife was very good-natured about it but she was like, “Well, this is a great opportunity.” And I did feel a little bit of obligation about like, “I can't turn this down,” and, “If I turn it down now, does that mean I'm turning it down forever?” And it might at some companies. I know that some people are looked at as just, “Oh, he has no interest in management.” So, don't take it lightly either way. And if you have any interest, talk to your boss about how you can investigate what it really means to be a manager at the company you work for. I think that every company is… what it means to be a manager feels really differently, feels really different. So, just be careful and see if you can peek behind the curtain to find out exactly what activities and duties you'll be responsible for rather than just imagining what it's going to be like.

Boy, you guys nailed it.

I have one more, Chuck. If your manager approaches you and says, “We think that maybe you would make a good manager for this team,” take a minute to think about everyone else on that team and maybe whether they've possibly overlooked someone, especially maybe a minority, who doesn't come to mind as the picture of management but who would actually make a very good servant leader. And ask whether they've considered that person, because…

I like that.

Mmhmm.

When you said Chuck, you talked about, “Oh, and then when they come to you and they say we want you to blah, blah, blah,” not everybody gets that.

Yeah.

And not everybody who would be great at it gets asked that question.

That's really true.

I think asking the question in terms of, “Why do you think I would be good at this and who else have you considered for the role? And if I decline what will you do?” questions like that that are kind of not just… I know the feeling of flattery can be very intense, right? “Oh, you want me to do it? Oh, that's wonderful.” It's almost like being asked to join a club.

[Chuckles] Yup. Yeah, the one other thing that I would point out at least in the current market with the current state of things is that they're putting real pressure on your to take a position that you don't feel like you would do well at or be happy in, there are a lot of other jobs out there. And I hate to tell people to quit their jobs, but if it impacts the quality of your life and the quality of your work and your ability to do your job by turning down a position like this, do it. It's not your problem. It's not your fault. It's just the way it is. And it's unfortunate.

Yeah. And more and more companies are creating real individual contributor tracks so that you can grow and influence without being a manager.

Mmhmm, yup.

Yup. And if your company doesn't, you should start advocating for one.

Yup. That's another thing that we don't have time to go into. But I think people don't really understand the power that they have to advocate for things that will make a difference in the company, even at the lower levels. So, definitely think about that. Maybe we'll talk about it on a future show.

But now we got to get to the picks. Jessica, do you have some picks for us?

I do, I do. I have picks today. In the spirit of getting interested in how management works, I recently finished Ben Horowitz's 'The Hard Thing about Hard Things' on Audible. And that was pretty fascinating, just how startups work, how CEOs of startups work. And it was a really interesting behind-the-scenes of what it's like at high management levels. So, if you're interested in that, I do recommend the book. Very interesting. Also has some great things to say about one-on-ones and hiring for strengths, not weaknesses, that kind of thing. Or not lack of weaknesses.

My second pick is not technical but it is also a book. I read 'The Narrow Road to the Deep North'

by Richard Flanagan. He's an Australian. And the book is about, it's fiction but it's very historically realistic fiction about Australian prisoners of war in Japanese labor camps in World War II. And it's a great book and it is about the horrors of that particular prisoner of war life. And also, the horror that is ordinary, everyday life. Even when you have it good, life is never easy. 'The Narrow Road to the Deep North', that's my other pick.

That's interesting. Have you seen the movie 'Unbroken'?

No.

It's about Japanese labor camp. Anyway, it's an American soldier that winds up in there. But really interesting. I've also read a couple of books about the European concentration camps and some of the things that they go through and how people make it through. And besides understanding some of the terrible things that happened, just understanding how these people had to change their mindset and approach their lives in a way that allowed them to make it through it all.

The interesting part about this one is that while the POW camp is central to the story, it is by no means the whole story. Most of the book takes place before and after. And it's really about people and how they cope with life, including in affluent situations, in poverty, and in the extreme, the POW camp.

Oh, interesting. Alright, well I've got a couple of picks.

The first one I'm going to pick even though I haven't seen it yet is Star Wars. We nixed the spoilers before the show. But yeah, I'm super excited to see it. It looks to be just awesome and excellent. J.J. Abrams. And I'm dearly hoping that we get to see Jar Jar Binks dead in a ditch somewhere. But besides that, yeah I'm super excited about it.

I'm also going to do a quick call-out about JS Remote Conf that's coming up here in a few weeks. Also, at this point you can buy tickets, group tickets and individual tickets. We're doing Freelance Remote Conf in February, at the end of February and Ruby Remote Conf at the end of March. So, if you want to speak at any of those or get early bird tickets, now is the time. I'm probably going to move the CFP deadline up because people keep wanting to see the talks before they buy the early bird tickets. And so, I'm going to see if I can accommodate that. I can't do that for Freelance, but I can do it for Ruby. So, if you want to go to that conference then go check it out. It's all online. So, you don't have to go anywhere. But yeah, that's what I've been working on lately and I'm super excited about it.

Marcus, what are your picks?

I have two picks. Neither of them is as profound as you guys chose. If I was going to pick something on the topic you were talking about, it would be Viktor Frankl's 'Man's Search for Meaning'. But that's not…

Yeah, I just read that one.

Such an amazing book.

It's really good.

So, my first pick is Steven Pressfield's 'The War of Art' which I've really found useful as I've been trying to do things that I'm not naturally inclined to do. Maybe management is one of those things for you. Writing and speaking is one of those things for me. And it really helps to personify the resistance that I feel when I sit down to do those things, as a more active force that I'm trying to avoid. And I like the way he lays that out in 'The War of Art'.

And the other one is Johanna Rothman's 'Predicting the Unpredictable' which is a technical book on agile estimation. And I just found a lot of the stuff that she says in there so common sense. 'Sensical' I guess is the right work, but just, it really resonated with me like, “Oh, duh. Of course I should have been doing these things.” Of course, every time I give an estimate in terms of a single number, I'm showing a high level of confidence which I don't deserve, which I don't really have. All these kinds of things in there. So, really I think both of those are very impactful to me.

Alright. And I know that you also do some consulting and coaching with regards to management. If people want to know more about that or anything else you got going on, what do they do?

They can go to MarcusBlankenship.com. And you can read my articles or sign up for the list to get the articles in your inbox. And there's a page on there that talks about a coaching program I have where I help CTOs and IT managers and even new dev leads get better at their job. It almost doesn't really matter what level you are in the organization. Having a coach, which is how I frame it, somebody who can look from the outside in to watch you work, appears to be a key to getting better at things. And I think this is why great sports athletes, great tennis players, great swimmers, they have coaches. Because you just can't see yourself properly from the inside. So, having a trusted adviser, it helps you from the outside viewpoint, that really appears to be important to some folks to get better at things.

Alright. Well, thanks for coming, Marcus. It was fun to talk about this.

Yeah.

Thanks for having me on.

Alright. We'll go ahead and wrap this up and we'll catch everyone next week.