CORALINE:  Hello and welcome to Episode 97 of Greater Than Code. My name is Coraline Ada Ehmke. I'm here with Astrid Countee.

ASTRID:  Thank you, Coraline and I'm also here with friend, John Sawers.

JOHN:  Thank you, Astrid and I'm here to introduce our guest, Brandon Hays. Brandon left the world of marketing to find that creating software made him happy. Brandon lives in Austin, Texas where he leads teams and tries to help make the world of technology a more humane place. Welcome to show, Brandon.

BRANDON:  Hi. Thank you so much.

CORALINE:  Brandon?

BRANDON:  Yes.

CORALINE:  What is your superpower and how did you develop it?

BRANDON:  This is going to sound a little too on the nose but I really do think that my superpower is helping other people discover their superpower. It is pretty much my favorite activity: sitting down with somebody and understanding what motivates them and what impact that they hope to have and what they care about and helping them combine that with attributes about themselves that are special. We don't always feel special but I think everybody knows there's something about them that special in that confluence of something about them that is either weaknesses that they've worked on so much that they become strengths or natural strengths that they've worked on that confluence of that. Their interests and their desired impact on the world and something that the world really needs is really fun to help people uncover.

CORALINE:  You're like the Professor Xavier of the software development world.

BRANDON:  That would be my dream, yes. That would be my dream. That's definitely the skill track that I'm trying to level up at. I find more satisfaction and as a career advances over the period of years, you discover impact that takes years to have and helping people make those discoveries five or 10 years ago is starting to bear fruit now in their lives and that's a really satisfying place to be but you have to be playing a real long game.

CORALINE:  Yeah, I think that's something that's often lacking. We certainly see business models that are focused on quarterly results. I think that a lot of people in management focuses on quarterly results or maybe an annual review but people stayed jobs for so short time these days. How do you maintain that influence?

I can see that influence being really great when someone's working for you but I had a manager once that's said, that his goal would be that if I moved on to another role, that he would still be around to help me and he would want to help me find that better fit. How do you maintain that kind of relationship when people change shops so frequently?

BRANDON:  That's a really extraordinary point. Some of the toxicity of our industry is that people perceive these relationships to be short term and largely transactional or they are compressed to fit inside of what people perceive to be a 10 or 15-year career, instead of a 30 to 45-year career.

Now, that we've tried to compress that and you see these 18 months stints that people stitching your career out of, it's very difficult to feel a sense of permanence and it's really easy to feel a sense of burnout that you haven't achieved everything you're supposed to by 35 or 40. Instead of realizing, "Wow, I'm only half way through my career. All of my impact is ahead of me."

Your manager was a great example of that of saying, "This relationship isn't around this job here. It requires taking that longer view and looking at somebody's career track and helping them design a career track that exceeds the bounds of the work context that you share in that moment and that's a really cool perspective and I think it's kind of rare actually, for people.

You talked about being sort of quarter-to-quarter results. You can't always live in this 45-year span but being able to take that 30 to 45-year career span and fit these little slivers of, "What are we going to accomplish this quarter or this year?" and understand that this is a tiny sliver of somebodies overall career, periodically checking in on that, every a few months or at least twice a year and having that conversation in that broader context really reshapes what those relationships are about. It's the gift of getting older. As I've gotten, older one of the gifts that's given me as that perspective is a lot easier to access.

ASTRID:  I definitely feel like the older part is something that is kind of downplayed. This is something that I talk about with some of my friends now. We try to imagine where we're supposed to be when we're 50, 60 is challenging when you don't have a lot of role models that you can see who are thriving in their careers. It makes it really hard to start to set those next level goals because once you've done some of the foundational 'I've laid this bricks and I can do this thing,' then it becomes a harder, more of a nuanced problem to try to figure out what you're supposed to grow into, which is something that I struggle with a lot.

CORALINE:  I think part of that too is how quickly people are expecting to advance in their careers right now. After three or four years being given the senior title, there's not a whole lot of room for growth there.

JOHN:  Yeah and a lot of companies don't really have a really good non-managerial tech ladder, so you get to senior and then there may not even be somewhere to go after, like another title after that. Beyond is VP and CTO and there could be a pretty huge gap there when you're ready for that.

BRANDON:  Yeah and in that vein, it's almost a revolutionary act to show up to your job and if you come in as a manager, you have some position of a sense of responsibility and ownership for making decisions like that and choosing to make the decision that we're going to implement a tech ladder. Even if we don't have any people currently to qualify for it, we're going to set up a basic tech ladder that takes people all the way up through a 30, 35-year or longer career and allows them to continue to progress in impact and income and access the multiple factors there within the context of your company, even if you're not at a place where that makes a ton of sense yet. I've found that to be like help set the stage for helping people understand that you can have conversations in that vein.

Then the cool thing that happens is when people, at that experience level, do come and talk to you, they understand that they have a place with you. It has been a really phenomenal recruiting tactic. I can say, I work with multiple people that have been doing this 30+ years now and having access to people that have been doing this for longer than 30 years and have stayed technical because they wanted to and have a path to continue progressing along that track in their own way.

That’s such a hugely overlooked segment of our engineering population because it doesn't feel that useful if you're lighting the match on an 18-month startup and you either raise funding or shut down. A lot of people with 30 years of experience don't want to experience that 18-month cycle over and over again. But if you're at a company that has a longer legs underneath it, at that point it might make sense to start building up that engineering track and attract some of those kind of people and then give access to mentors like that to people that have less experience.

CORALINE:  I got a new boss about six months ago, eight months ago. I work at Stitch Fix and I'm a principal engineer. At that time, principal engineer was the highest individual contributor level there was. I got to the new director and I had a one-on-one with her and she asked me, "How do you feel your manager is doing in guiding your career progression?" and I said, "What career progression? There’s nowhere for me to go."

There were a few other people in a similar position so the company did the right thing and they designed new levels above principal. With a level matrix that actually explicitly said, "Here are the expectations and responsibilities on each of those levels," so advancement from principal to architect requires working on a project that spans all of engineering. Then to get fit architect level two, you have to be someone who is identified as something of an industry expert on some topic that's relevant to the company and that makes so much sense in that progression.

I feel like we do such a disservice, Brandon to the people you're talking about, who are 25 or 30 years into their career who are basically nowhere to go and I'm so thankful working with a company where they have actually thought about that and they have actually planned for that long term career for us.

BRANDON:  I love that. I love that idea. I love what Stitch Fix is doing. I followed them. I followed Lara Hogan. I've seen really interesting stuff at Etsy and Meetup and other companies that are doing this in public. I did see Stitch Fix. I think they've published some materials around some of the stuff that they're doing. I'd love to see more of an open source strategy to this because the impact that we can have as an industry is really large. 

Everybody benefits from sharing more information. Because I think as an industry we're like a little baby at the stuff. I feel embarrassed sometimes at how elementary my take-ons on this stuff is, where I'll sit down with somebody and I'll be like, "Here's a spreadsheet of the list of things that your job entails now and the list of things at the next level and we're going to go through and decide where you are in any of those things and use that to come up with a plan."

But even that, this little baby strategy that we have of stuff that somebody made up here and we're iterating on internally and trying to take in some outside influence into, all of that stuff, it feels like we're just doing little baby versions of something that could be really powerful and if more people in the industry were to participate in this, there could be a more generally accepted understanding of what these levels are and could be. I would love to have that be something we talk about publicly.

CORALINE:  I just made a note, Brandon to bring up with my managers if we can open source that and maybe do that in a form of a blog post on Multithreaded.

BRANDON:  I love that. I kind of want to come back to something that Astrid talked about, about being earlier in your career and not having access to people that are more senior. This really bums me out because if you think about the reasons for that, some of us have been in the industry a little longer and I know people and Coraline, you can correct me but my sense is sometimes, you may fall into this category because I feel like even I do sometimes. You feel like you're holding onto this industry by just your fingernails, just dug in and I know too many people that have burned out and just kind of let go and it's almost as easy as falling asleep to walk away from the culture and toxicity of the industry.

I think we're doing a real disservice to people to burn our people out at 35 and shorten the expected lifespan of what an average engineer can productively do. Once you're 35, you've outlive your usefulness to the VC-run startup ecosystem. I don't know what all of those factors are. I don't even know if I'm on the right track but the sense that I have is that we're bringing people out before that point.

CORALINE:  Yeah, I think there's a big gap between the 25-year olds entering our industry and rising rapidly, not finding a path forward and either dropping out or going into management because there's no other path forward. I actually did that my first time around in my career. I went the management track and I got so unhappy. The things about management were the people development skills and responsibilities that I had and I didn't think there's a way to do that as an individual contributor but I knew that personally, I was happiest when I was writing code and helping people.

I found that as a very senior person in my profession, that is a possibility and I can do those two things together. I'm much happier as I see but I think I'm very lucky to have gotten to the point where those are my responsibilities and I'm not sure that people are aware that that is the path, that there is an alternative to management. I think in a lot of companies, there is no alternative to management.

ASTRID:  I think that's so true. For me, it's a little bit different because since I changed into this career from another one, one of the things that I've noticed is that it feels so much more narrow, the things that you're able to accomplish and it doesn't feel as easy to take whatever experiences that you do have and share them at different levels on the company. I think that that's maybe a function of the fact that what you're doing is so technical, so you're kind of siloed into a particular group.

It doesn't allow for that mentorship and fostering of other younger minds and maybe, even other minds that have been focused in other areas, to have that cross collaboration so easily, which is something that I struggle with because I really benefited in the beginning of my career. Because I was working in the energy sector, so I was doing a technical sort of job but my job wasn't really tailored to only one part of the company.

I benefitted a lot from learning from different types of managers and different types of individual contributors just because I was able to be in the room with them. That seems so much harder to do in technology because you're just put into your position, you have to do this particular thing and you don't really get to hear so much what's going on the other parts of the company or even get to contribute, which is something that I got to do, that really helped me figure out that I like technology. It's kind of hard inside of technology to figure out what else I like because if I'm not just coding under somebody, then it's like you're not growing.

JOHN:  I've actually been kicking around the idea. I won't implement anything like this yet but trying to think of a way to implement the idea of actually mentoring people outside of the technology side of our organization, just as I'm becoming more of a manager type person, just having other people in other departments who may need some sort of mentorship, whether they're an outside of technology. I'm doing that inside of technology but sort of broadening it out and also, just bringing those extra parts of the company but more into my awareness and also, exposing them to a bit more of the technology and then, also just helping them to be better at what they're doing.

BRANDON:  I love that and it sends me like a little bit of a thrill of hope that that's the direction things can head and a fit of rage that it requires somebody that is just moving into a manager track from a technical track, to even conceive of an idea of how would we start building connective tissue to help engineering teams be more connected to other parts of the business.

This is actually a big part of management that's really lacking and I find very frustrating that there is this sense of we're supposed to reinforce the silo and protect the engineers from mean, old business. This is a value center for this business and usually, a value center is 100 to one ratio in a lot of work places, where it's 10 to one or 100 to one ratio of the investment you make and your technology and the people that build your technology and the value the business draws from it. You’re kind of protecting engineers if your job is to protect them from all the mean, old business. You're actually protecting engineers from the impact they're really having on the business, protecting them from understanding the value that they're actually creating.

It creates this weird power disparity from the people that have the ideas and the people that execute it and you're just the executer. It's hard to complain too much because it's a reasonably well paid profession and people are generally well-taken care of because it's hard to find qualified people to fill roles in this industry and so, you have massages called in at some workplaces, lunch catered, all those things and so, it feels bad to complain about the power disparity but it's still there and it feels wrong and it keeps engineers from achieving more of their potential by contributing actual business value.

If you knew more of the 'why' of what we're trying to accomplish stuff, if you give that to engineers, you can actually generally trust them to do something really cool with it. Basically, so much of what I see in bad management, which comprises most of management in engineering is basically, most of well-being in management in engineering is patching overload trust relationships like crummy management.

This has been a very expensive lesson for me as a manager because I fall into this trap all the time, on an individual level and an organizational level. The biggest temptation to fall into in engineering management is let's say two people have a conflict with each other. One person escalates to you, you go to their manager and what you've done is you've created a route around a low-trust relationship, instead of debugging. Why is this a low-trust relationship? How do we build trust?

So much of what we do organizationally is patch around the fact that business doesn't feel like they understand what engineering does and they don't really trust them to do their thing. We need a real time box on what they do. We really need to keep a lid on. When they say technical debt, I know what they're going to do as a six-month 'refactoring,' where they rewrite our entire system and produce no business value. Then on the engineering side, we feel like we're being crushed under this oncoming steamroller of release dates and targets and all that stuff.

Most management jobs are kind of crappy because it feels like your job is to keep routing around these low-trust relationships. Fixing that at the root kind of requires a different outlook and hopefully, an organization that will actually support that. I worked in both. I worked in organizations that will support that. It sounds like Stitch Fix is one of them and I've worked in organizations that would not support that and spent a long time trying to figure out why I was miserable and I was trying to run counter to the values of an organization.

Creating an understanding of the definition of management as facilitating the communication and facilitating trust relationships and helping people gather their own contacts and empowering engineers to make business decisions, that to me is what I think 10 years from now, I'd like to see more of the job of managers to be. It's a pretty bold ambition but I'm seeing more of it, so I'm reasonably hopeful.

John, you talked about the stuff that you're working on. That sounds like it's headed in that direction. I'm curious to know, John what are the stuff you're learning as you kind of transition more into manager roles? I don't know if you've done management the past or you're relatively new to it, what drew you to it?

JOHN:  Completely new to it and just sort of in the process of transitioning. I think part of what actually made it feel like it was a place that I wanted to go was the fact that there are better resources out there now than there were even a couple years ago. There's The Manager's Path by Camille Fournier and the Mike Locke book and the stuff they're doing at Watercooler.

There are a lot of great new resources that talk about managing from this humanistic perspective, rather than from the business-y-business-y perspective, which was always a huge turnoff to me. Seeing that it's a thing that you can do where it's about cultivating people and relationships, suddenly I was like, "Oh, that is a thing I might actually enjoy doing."

BRANDON:  Yeah, I've met managers where literally, as I start talking to them about their job and what their goals are and what they understand it to be, you can kind of tell when these managers felt like they were pushed into that path. It wasn't what they wanted to do, they were pushed into that path because they felt like it was their only maneuver into any kind of career progression.

I asked somebody that really concerned me at once, like why are you doing this? Every time we talk, you dig right back into the technical details of stuff. Why do you want to be a manager? And they said, "Oh, I want control." I was like, "Oh, my God. That's like saying, I want to become a parent so I can control the life of a child." That's both not a good motivation and a deep misunderstanding of what the job entails, like prepare for your level of control and influence to go down actually.

ASTRID:  It sounds like it's related to the way you were talking about, Brandon with the routing around, the mistrustful relationship that it's like, "I don't want to have to do that, be in that situation where I can't do anything about it so I'd rather just be a manager, so I could have some say over how this happens."

BRANDON:  Yeah, that's actually a good point. I hadn't thought about that. It's like, I don't trust the current management structure and when I talk to people that are like close to burnout in the industry. I have a friend, I'll go and name him. He's a really great guy named Elrick Ryan and he's talking to potential employers and he's like, "Oh, yeah. I've learned to build my own path. I've learned to fight for myself. I've learned to do this for myself," and I'm like, "Man, it really sounds like you haven't had a good manager." He's like, "Oh, gosh no. Who has a good manager?"

That kind of stuff, my friend, Nick tells me that he likes it when I get indignant because I don't get indignant not much. I usually see most sides to something but I'm very frustrated with the state of understanding of the role of managers in our industry, that their role is to kind of corral and directs. As you're seeing more resources come out, I think Google came out with a resource. I forget what they called it -- "Project 'something,'" and they came up with 10 behaviors of great managers. I forget the name of their project but they basically came out with 10 attributes and chief among them is a great coach. He's a great listener. 

All of these things that people does not micro-managed, delegates and empowers people, makes the team inclusive and safe. All these things that historically, we haven't really thought about as management skills or leadership skills are starting to emerge. As we study successful teams, it turns out the stuff that you would want to have for somebody to fight for when you are an individual contributor, actually are the things that make managers great.

This sort of old school... I don't know if you all have heard of Taylorism. Taylor was a manager from the turn of the century in the early 1900s that said, "My job is to make the autonomatons in the factory produce more. How do I increase output of people that you don't trust to even come to work, much less produce while they're here."

There's an entire century of built up expectations around what people, management fear even is, that we're just starting to dig out from underneath. I'm not a very patient person, so I get pretty frustrated with the state of things as we move away toward a more humanistic approach, as you said John, away from a lot of this sort of Taylor-esque, low-trust, asses in seats type management.

I'm curious to know, Astrid you were talking earlier about having great connections with managements in other career tracks. I'd love to learn more about that. What was working for you that you'd like to see more of?

JOHN:  Before you answer, sorry, I just want to go... The Google's project was Project Oxygen, just before we get to far from --

BRANDON:  Yeah, thank you.

ASTRID:  Thanks, John. The company at that time was not very corporate when I started and that was great because we didn't have all the structures. They were just interested in hiring people who are smart and who were willing to learn and they did not really care about like do you have this particular degree? They were much more interested in what do you want to learn. If you want to learn this, we will find people who will help you and train you and you can learn how to do it because we had so much work that we didn't really have time to make all those different hierarchies.

As a function of that, it meant that whenever you had questions, you were empowered to go find the person who could answer your question, as opposed to go up the chain and have somebody else, direct you to another person to eventual training, which would happen three months later. Because of that environment and me coming into it right after I finish college, I didn't have this distinction between business and engineering. That's something I kind of learned later as I moved into bigger companies and I would have a problem and I would be trying to solve my problem and they would tell me I'm not allowed because I'm not in the engineering department and I was really pissed off about that.

Because I was much more trained that if there is a problem, you find all the ways to solve it. Either you solve it or you find other people who can help you solve it but if you encounter the problem, you're now part of the team of trying to make sure it gets fixed and then, that slowly changed when that company became more corporate. When I moved into other bigger companies, you pass this problem on to this group of experts and you let them do their job, which meant that you lost a lot of the meaning and then as for me, as an employee who was trying to learn, it made it really hard to understand like what happened when I threw it over the fence. Why is it no longer a problem? Because you just don't have those open lines of communication.

I think it was really nice to just, kind of like what you were talking about, Brandon, just empowering people to go find the solution because I didn't even really understand that a lot of what I was doing was a technical job until much later because that wasn't how I was taught to think of my work, whether it's technical or non-technical. I was taught to solve problems whatever that meant and as long as I was working and getting the problem solved, I was doing my job.

BRANDON:  I think that's a really cool outlook and I think what it actually taught you was you were learning devops philosophy but you were in a role that hadn't any language for that --

ASTRID:  Yeah, that's very true.

BRANDON:  The devops philosophy of understanding the value chain, what's the chain that causes value to be delivered and how do we remove friction in that chain, who needs to get empowered, what approval stages this stuff get stalled in, what walls just stuck and throw over where context is lost, identifying the delivery of value from end to end and streamlining that.

Protecting people's ability to have that kind of autonomy as a company scales is actually a very tricky job in management. I'm finding it personally very difficult in my current position, even. As a company gets bigger and you have more people down, there are more cooks in the kitchen and if you don't scale that carefully, I don't think it's controversial to say like, I have friends at work at GitHub saying nothing about the current state of GitHub or whatever but there is no secret that GitHub became a shit show as they tried to scale their culture of total perceived autonomy, total flat hierarchy organization, you know, #managerless or whatever.

It turns out that scaling that isn't just letting people do whatever they want all the time. Silos and cliques formed and then power structures become implicit. My friend, Nick Means talks about this and says, "My job is to remove processes as much as possible and then only put process back in when you start experiencing pain."

CORALINE:  I often said that processes are a scar of our communication [inaudible].

BRANDON:  I like that metaphor.

ASTRID:  I do too.

CORALINE:  Brandon, you said something in passing that I'd like to drill onto a little bit and that you talked about context and contexts being lost or preservation of context. I've had a lot of managers who have said, "My job is to be an umbrella and to keep the shit from raining down on you," and I wonder if that is actually a healthy approach. Shouldn't I, as an engineer, know all of the implications of the work that I'm doing and all of the motivations that the business level for the work that I'm being asked to do?

BRANDON:  I'm out of my depth at that point because I think there is maybe a size of organization that requires the shit umbrella approach. I had a really great manager at AT&T that viewed himself that way but also that team accomplished nothing. We were shielded from interference, so that we could work successfully to deliver a product that ended up being destroyed. I do view that as context removal and I do view that as not the healthiest approach. The shit umbrella approach is a trust routing issue, where you can't trust the organization. 

I don't know if there is a company size where that becomes absolutely required for people getting their work done. Certainly, at AT&T, where the company is too big to impact personally at any size, maybe I'm mentioning company names and [inaudible] too much here but it's also too big where they couldn't possibly care about what I have to say about them. It was a great place to work in a lot of ways but it was just too big to personally care about and so, at a certain company size, I really don't know if that becomes necessary but I would say it's a lot later than people think.

People that carry around the notion that that's part of what the manager’s job is, I would say, it's probably time to dispose of that pretty much industry-wide. I would say nine out of 10 manager jobs should not have that in the job description or in the attitude of the job. That's my hot take.

ASTRID:  I did have an experience where our manager kind of shielded us from certain things that was useful. I think it just depends on what the actual shit is. In this case, it was not real work stuff. It was that interoffice kind of fighting for power type of stuff that had nothing to do with what we were doing, which was actually helpful because then we weren't worried that we were causing a problem that wasn't a real problem or that we were doing something wrong because somebody just doesn't like it because they didn't come up with that idea themselves. That type of shit, I think you should protect but the effect of your work and how it's being used in the business, I think is really important that you have access to that.

BRANDON:  Yeah and sifting between what is trivial like that and not impactful to your job. I may not be able to lobby successfully for the removal of deeply formal expense reporting but I can do the expense reports or pull that off of somebody's desk so they're able to focus on their job. There's a little bit of small levels of politics like that or like you'd said, interoffice things that don't have any bearing on the day-to-day job, that don't actually have any direct business impact, that are noise and being able to tell signal from noise and help increase the signal that gets to the team in the context that's relevant to them, I would say that's a definitely not 101 stuff. That's part of the art of the job that I'm very much still learning.

CORALINE:  Brandon, what was your biggest surprise when you became a manager?

BRANDON:  My biggest surprise when I became a manager was that I wasn't good at it. I thought I was going to be a natural. I'm like, I like people, I get along well with engineers when we pair program, I can get along with cranky engineers that generally people look at as the grumpy one that doesn't want to talk to anybody but I like them just fine and when we talked about code and stuff like that, I found that to be generous in spirit and kind and empathetic and just kind of a little burned on organizational BS.

I thought surely, when I go in to manage teams that all of those skills and experiences and natural tendencies are going to translate and I actually kind of sucked at it. I feel like I'm a recovering shitty manager and that was a very humbling experience. I would say the biggest surprise was the skills required to do the job weren't things that came as naturally to me as I thought they would. Just by liking people. |That's a good start.

The requirement of practicing active listening, probably is and I would say the two things that I had to learn as a manager that are basically the two key things you need a manager to do, which is to listen without reacting, listen, process, store information, gather context without reacting in an any meaningful way until you have enough information to do something to help or allow the person to help do something on their own.

Listening and actively letting go was not a natural skill and I had a lot of criticism about my abilities in that area from people that were truth tellers that I managed, fortunately. I would say that's probably the biggest one and then, enabling people to solve their own problems is a really big one, instead of trying to solve things for them or make decisions for them. I thought my abilities as a decision maker were going to make me a good manager and that wasn't the case at all. There's very little of that. I make a very few decisions. I would say those are probably the two biggest ones that surprise me as how few decisions you actually make and how much of your time should be spent just listening to people.

JOHN:  You said at the top of the show that you are sort of working on a talk that's coming up and some sort of new ideas that you're turning over in your head. Do you want to talk about those a little bit more?

BRANDON:  It's definitely early stages but I've had multiple years of notes about what I've learned in management and it's scattered all around. I name the talk 'Something I Felt Safe About.' It doesn't sound very exciting and it's a little bit safe. It's called the new managers toolkit but really, it's a treatise on the moral imperative of management that bad managers are causing people to burn out and leave the industry. With a few techniques and applying some small levers, you can actually change the expectation of what managers are for within your organization because it turns out, nobody really knows.

In an area where nobody really knows what they're doing, it sort of like the web in 1990, 2000 and then web applications in 2004, 2005. This is really early days for management, so a few people with really good intentions and are willing to sort of study and listen have the ability right now to make a significant impact in whatever company you walk into and shake their understanding of what managers are there for. If I could evangelize one thing, it would be this idea that educating yourself on what managers could be using. Like you've said, there's new materials out there like the manager's path.

I would say the other really big thing for me lately is this idea of Radical Candor of caring a lot about somebody personally and being direct with them is another thing that I had to really grow in skill at. If people are willing to sort of self-educate on this stuff and start building the first tier of a support ecosystem for management and engineering, this is such a nascent area that you could have a pretty tremendous impact on the lives of a number of people by deciding to jump in and participate right now.

Management doesn't have to be for everybody. Not everybody wants to do it but if you see that opportunity and it comes up, you can have a major impact by just being part of this new wave of engineering leadership and I want to see better trained, more people-oriented and more diverse group of people doing that.

CORALINE:  Brandon, everything you've talked about so far presupposes a manager who has a high degree of self-awareness and a desire to improve. What do you do, as an IC, when your manager doesn't have those things? Are there techniques for managing from below that you can kind of influence your manager to become better at the kinds of skills that you were talking about?

BRANDON:  First I will say, the most important thing is the culture of the company in which you work because that's the direction the wind is blowing. If you have a culture of tolerating crappy behavior and if it reinforces the stuff that you don't like in your manager, I almost would say, you're not going to get have a lot of success -- tacking your sail against the wind. But if you look at your overall organization and say, "No, the organization and I are mostly in line, but my manager is out of line with what I need and the organization would back me up at this if I look a little higher in the org chart than where we are," I feel a lot more secure in advising somebody to have a direct conversation because I think it's almost always safe to say, "I'm not getting what I need from you."

A tactic that people took with me is, "Hey, Brandon, we're in these one-on-ones and I feel like you're dominating them. I feel like you're giving me context about my work and trying to inspire me or whatever and that's great. Thanks," but I don't feel listened to and I need that. Or when you do listen to me, you're not really listening all the way because as soon as I mention something that I need, you're reacting and doing something with it before giving it time to settle or giving me the opportunity to solve my own problems.

The best changing moments I've had as a manager and I don't want to assume that everybody is going to react this way but I do think that being able to communicate directly with a person is in terms of my needs. Like I need something from you and I'm not getting it currently. I need you to be able to handle this for me and at least, you can sort of negotiate about what your manager can and can't provide for you.

I've seen some good resources from Julia Evans lately. I don't know if you've seen her comics about this, about sometimes you have to sort of build your own... Who was I've been talking about? I think Lara Hogan maybe as well talking about building your own Manager Voltron, about how to stitch a decent manager out of a group of people in your constellation of coworkers, maybe inside and outside of your company.

There are a couple of tactics that you can take. One of them I would suggest strongly is if you're willing to take the time to read the book, Radical Candor, it's a great guide to having these types of conversations successfully and it's great to have a conversation framed in terms of what you need. Otherwise, you may have to sort of understand the limitations of what you're working with and understand that those needs are going to change. You're just going to have to get them met in different ways and then, I love telling people to quit their jobs.

If you're in a position of that level of privilege where you have the ability, don't be shy about that one, especially if it's out of a sense of loyalty. If you don't have that position of privilege, everything from that point is coping strategies and trying to make something good out of it and recognizing that a lot of good lessons are going to come from that. But if you have that ability, there are, hopefully, opportunities out there.

I love putting a nice bow on things, if it's at all possible. I think we've covered a little bit already but the thing that I find most exciting in our entire industry right now and fascinating is this idea that engineers are starting to wake up to the fact that they should have business level input. They're starting to recognize the value that they provide and are starting to recognize that they would provide more if they had more information and more contexts.

My goal is to create, at least for the people that I work directly with, I want to see a next generation of development and engineering managers that are there to facilitate that. My hope is that more people wake up and realize this is something that you can do because I was certainly not equipped to do this, even though I was deluded enough to think that I was. My hope is that people that don't have that same Dunning–Kruger effect bullshit of thinking they can do this just because they think they can, that people that may currently think they aren't qualified for this or this is something that somebody else would do, recognize some of these topics as things they care about and that's the only qualifier.

Coraline, you'd said earlier, what do you do when we're in a position where we have people that don't have that level of self-awareness or maybe, even don't care. My goal is push those people out of the industry with a bunch of people that do care over the next 15 to 20 years. I would really love to see more of those types of people and that's why I talk about it and almost like a revolutionary act because it is just quietly replacing people that don't understand what this job entails or the value that could be provided, putting people in there that do this a little better because they are more self-aware. They're willing to self-study and watching them have more success in building successful teams that get software out the door and are happy and hopefully, don't leave their jobs as frequently and start having teams where you have 30 to 35-year veterans.

I have people on my team currently, where this is their last job and I think that's super cool, where they know that, "This is the job I want to retire from." Okay, great. What do you want to leave this industry with? What gifts do you want to have left this industry when you're wrapping it up? That’s such a fun conversation to have in a room full of people that includes 20 to 25-year old engineers. I want to see more of that.

CORALINE:  Brandon, at the end of every show, as you know, as a long term listener, we like to take a moment to reflect on the conversation we've just had and talk about the things that really resonated with us individually and maybe, calls to action that we heard that we want to follow up on. John, would you like to reflect first?

JOHN:  Sure. One thing that strikes me is and this is something I've been mulling over the last couple of years myself is that there's a deeply ingrained thread in geek culture and nerd subculture about how terrible managers are and how they're basically protect yourself from a manager and oh, God, if you turn into a manager, then you've gone to the other side.

I think a lot of that probably comes from people who have had bad managers for most of their careers. I certainly just picked that up sort of by osmosis, just by being in the culture in the early parts of my career and it wasn't until I actually had a good manager and this has really been just in the last year or two, that suddenly I'm like, "Oh, now I see what the possibilities are. You see, it's not just this adversarial thing. It's teamwork where we can work together to develop myself and to work for the company to make everything better."

Suddenly, seeing that possibility show up, recently has been really great for me and certainly, you have your work cut out for you, trying to change a lot of these ingrained cultures, not only from the engineering nerd culture side of things but also from the business side of things, where they may not see manager roles as constructively as you do either but I wish you the most success that you can have.

CORALINE:  Astrid, what are your thoughts?

ASTRID:  What struck me the most, Brandon is you talking about the power dynamics that exist, that are untapped in a way, in engineering, like what it means to be an engineer, kind of impact you're making on your team, on your company, which I think is really important because I know that we talked in the macro sense of what types of things we created in the world and what that can mean in the world and I think that it's very hard sometimes to find how you scale that to just you at any level because you oftentimes, at least the way that I've been told, your job as an engineer is to get really, really good and then, once you get really good, then you can think about these other things.

It feels like a lot of people are really so focused on trying to improve their own skills and they're not thinking of these other things as part of that skill set. The way that you've described this today makes me think about what it really means to be embarking on an engineering career in any form and the highest levels that can achieve or probably things that are not even really been thought about yet, which is a different way to think about what a career means.

CORALINE:  For me, I am really struck by what you said, Brandon about people who are at the end of their careers, in their last job. I've been doing software development for almost 25 years now. I probably still have another good 20 years ahead of me, especially because of some bad decisions I made with retirement accounts but I'm interested in figuring out what my legacy will be. I'm well-known for a lot of things in the community, for the Contributor Covenant and for the Post-Meritocracy Manifesto and as a speaker and as a mentor but I'm wondering, if I'm the only the technical contribution behind this or if it even matters if I leave these technical contribution as my legacy, maybe my legacy is a generation of empowered engineers who stayed in the industry but that's something I want to think about and that's something I want to think about actively and plan for and start working toward, so thank you for that. What are your thoughts?

BRANDON:  Well, first off, to respond to that really quickly, I think a lot of engineers, including myself would aspire to someday have the kind of legacy that you have already had. Having the time and energy to think about additional things that you might want to accomplish is really great. I think that's terrific.

Something that struck me when Astrid was talking about trying to translate the skills that she had in a previous career to her career as an engineer reminds me of how much I've discovered, in my career, this being my second career, I didn't write a line of code until I was 30, how much of my skills and abilities and the things that make me good at what I do when I'm working at my best come from that previous career and how little I understood at the time of what that translation was and how important it is to be able to take time periodically to look at the stuff that you're good at from those other career tracks and look at situations where that can apply and recognizing your own value in that context and helping people recognize that value and actually, writing job descriptions that take advantage. Job descriptions and interviews that take advantage of the kind of skills that emerge from other career tracks is the responsibility of this emerging group of managers.

What I'm going to takeaway and literally do with this is I'm going to evaluate the job descriptions that we do and write and make sure that they're not skill lists that you could pull from somebody's GitHub profile but actual things that would take into account. If this person had been doing and working in an operational role in some other industry for 10 years, what sort of those skills will translate over and how do we make sure we interview for that and get those people to apply. I really like that take.

CORALINE:  If I can self-promote for a moment, Brandon, I was involved in rewriting the job description template at Stitch Fix and we got a really good response from people about it. We had a sharp uptake in people from under-represented population that ended up applying. I wrote about the experience in a blog post called 'Not Applicable: What Your Job Description is Really Saying." Maybe that's something that you'd want to take a look at and I'll share the link in the show notes.

BRANDON:  Absolutely. Thank you.

CORALINE:  That wraps up Episode 97 of Greater Than Code. Brandon, thank you so much for taking the time to talk to us. It was a very illuminating conversation and I think your quest is both fascinating and necessary and I wish you all the luck in the world.

BRANDON:  Thank you all so much. This was great.