Christian Mccarrick: [00:00:00] This is simple leadership. Welcome.

We’re here to learn from new and seasoned technology leaders who all share a passion for improving the craft of technology management. Let’s take a deep dive into management, leadership challenges, and best practices specific to software engineering and technology teams. Do you want more engineering management, leadership, tactics and information.

subscribe@simpleleadership.io to receive the latest updates from this podcast. Hi, I’m your host Christian McCarrick. This is the simple leadership podcast. Welcome back. Today’s guest is Johnny Ray Austin. Johnny is an experienced hands on engineering executive focused on shipping world class products, his built and led high-performing globally distributed engineering teams.

And as a strong advocate for engineering, operational excellence. Johnny is also an international public speaker speaking on engineering leadership system design and the JavaScript programming language. He sits in the board of directors for bite back and organization providing pathways to inclusive tech training that leads to living wage careers.

He’s currently the chief technology officer for Till. Till’s mission is to provide powerful financial tools to help renters pay, stay and thrive in their homes. On today’s episode, we’ll discuss his talk, the depth of the full stack engineer, as well as the benefits of hiring junior engineers. Good morning, Johnny. Welcome to the show.

Johnny Ray Austin: [00:01:17] Thanks for having me, Christian. I appreciate it.

Christian Mccarrick: [00:01:19] Yeah, absolutely. And where are you calling in from today?

Johnny Ray Austin: [00:01:22] Yeah, just North of Washington, DC and Montgomery County, Maryland.

Christian Mccarrick: [00:01:26] Perfect East coaster. I grew up on these coast a little bit North of New York,

Johnny Ray Austin: [00:01:29] but awesome. Thank you. Glad to be here.

Christian Mccarrick: [00:01:32] Yeah. And for my listeners, you can’t see this and sometimes you’ll see me like gesturing with my hands and I always have to talk about that, but this is a podcast. Johnny has a really cool background. He’s got some great art. He’s got actually a great podcast microphone sort of set up here. I feel like I’m working with a pro, so guaranteed to have good sound quality in this one.

Johnny Ray Austin: [00:01:48] Excellent.

Christian Mccarrick: [00:01:49] And I am super excited to be having this chat with you today, Johnny, as I was just mentioning briefly before we started, this is my first podcast in a few months. I took a bit of a break. I just wasn’t feeling it for a bit, right with COVID and the social unrest happening. And I start a new job, but I did realize that I needed to return normalcy and I’m sure some of my listeners do and some of my guests. So I’m super excited to be talking with other engineering leaders again on the show. So thank you for sort of being my first guest again in a few months. I do appreciate it.

Johnny Ray Austin: [00:02:18] No problem.

Christian Mccarrick: [00:02:19] hope I’m not too rusty, but let’s get back into it. Okay?

Johnny Ray Austin: [00:02:22] Cool. Sounds good.

Christian Mccarrick: [00:02:23] Alright. As I asked, most of my guests on the show here, if you could just give me a brief kind of background, like the highlights of how you got to be where you are today.

Johnny Ray Austin: [00:02:30] Yeah. So I have a pretty traditional background in that computer science degree. I went to Tuskegee university down in Alabama, right out of college. I had a job offer to go work for a government contractor in Washington D C area. It’s how I ended up here. Just never left. Did that for a few years, wasn’t really, for me, the big corporate culture combined with the slow movement of government, just like wasn’t really my thing.

And so I kind of looked outwards to kind of figure out what was for me. And so I started looking at startups and apply it to a few. And I went through like the whole like interview gauntlet with whiteboards and all that other stuff back in the day when this was like, still very, very prevalent and ended up landing at a startup called Everfi here in Georgetown area, basically ed tech stuff, and had a great time there.

And that kind of just launched this career of working in startups and doing that sort of thing. Yeah. And I got into management just by sheer luck. Yeah. Tech lead asked me if I wanted to manage, you know, one of our leaders had left the company initially turned it down. Never viewed myself as a manager in any capacity, but I did end up taking that job and never really went back.

I’ve been doing that ever since it’s been great. I get a lot of fulfillment from there. And so for the past year and some change I’ve been here at till working as a VP of engineering and basically just trying to help people pay, stay and thrive in their homes. As you might imagine, that’s a big problem these days with everything happening.

Christian Mccarrick: [00:03:59] Absolutely.

Yeah. It’s kind of good to be working kind of with the mission driven company as well. How do you kind of mix profit and mission? I think if you can find that overlap, I think that certainly can help with motivation and yeah, you feel good about yourself, right. And you mentioned a little bit about how you kind of got into being a manager and I’ve noticed that some of the best managers I know are the reluctant ones, right.

They didn’t wake up in college and say, I’m going to be an engineering manager, right. They just kind of take it over and then it’s just something that I think, as you mentioned, you kind of get some satisfaction from that and fulfillment of helping other people. Right. We’ve all made them Johnny. So any mistakes that stand out to you in your mind that you’ve made over the years?

Johnny Ray Austin: [00:04:39] Yeah, this is a personal one. So I mean like most people there have been many, I think one are the ones that I tend to revisit every so often in my mind is just when I got that first employee who is. Truly somewhat of a toxic personality, not in a very explicit way. This is not something I would actually tolerate on my team, but in a very subtle way behind the scenes, which made it really difficult because this person was a very positive person in front of me, groups of people and in meetings, and like this led people to believe, including myself that this was.

Reflective of how this person engaged in private conversations and whatnot. It turns out this was not the case. I got a little bit of warning signs from people on the team, but this was not something that jumped out at me. And I just sort of like put it aside and it was, and until later on down the road where I really engaged in looking into this person’s particular behavior, that it became very clear to me that this was sort of like a problem. And obviously it was dealt with at that point. But I really want to believe that if I had another opportunity, I would go back and act sooner. Simply because I don’t know what sort of damage person left in their wait, why they were there and private conversations.

And knowing that I had a team of people who trusted me and who were  counting on me to kind of help guide the team morale and the direction that this person was still around. And I was potentially perceived as some people as quote unquote, not doing anything about it. That’s something that sticks with me because I really do care about my teams and I want to make sure that they’re healthy and always possible.

So that’s something that comes to mind that I think that. I probably would have revisited if I had an opportunity to do so.

Christian Mccarrick: [00:06:20] Yeah, I’m not going to get into all the details are, and I’ll have a very similar story. And I think a lot of managers also, if I was to categorize some of the groups of mistakes, I think most of them say I didn’t act sooner on whatever it was.

I had that spidey sense maybe. Yeah. I sorta knew, but I didn’t. And then I put it up off because something else is going on and suddenly. You wish you would have done something sooner, right? Yeah.

Johnny Ray Austin: [00:06:42] It becomes hard because I don’t know. I find myself struggling with this duality of Wendy used the data versus when do you listen to your gut? Because your gut can be very helpful. And I found that is very helpful, but you also want to recognize that with that comes all of the biases and things that. Are inherent in, within you as a person. And so trying to balance that is really difficult at that point. My spidey sense. It wasn’t just tingling, it was like vibrating. I really wanted to make sure that I was grounded in data and what I was trying to accomplish, but that was one time I really should have paid closer attention there.

Christian Mccarrick: [00:07:16] Yeah. Awesome. Yeah. Thanks for sharing that. I know. And the reason I do have engineering leaders share these on this show is I understand that we all make mistakes. We’ve made mistakes and we’re making mistakes every day, little and small, but it happens. You’re not alone. So that’s why I like to share it. So thank you for that.

Johnny Ray Austin: [00:07:35] No problem.

Christian Mccarrick: [00:07:35] On the other side, if you’re coaching any managers that are making that transition from IC to manager, maybe a new manager, what is like one of the top tips or some of the tips that you would give to sort of new managers making the transition?

Johnny Ray Austin: [00:07:46] Yeah, definitely. At the top of that list, it would be learn to trust your team. One of the things I struggled with going from IC to manager was it wasn’t so much interest, but I think new managers have this thing where kind of like new babies. They have to like touch everything in order to make sure it’s real, right.

This whole idea of like, you need to be in the code base, you need to like personally look at things and personally verify things or be a part of the solution that ends up happening. That’s hard to walk away from because those are the skills that sort of got you to where you were at that point. But as a manager, in order to effectively grow your team, you need to let go and trust that they will solve the problems you need to equip them, obviously with all the tools and things that they need and remove blockers and whatnot.

But you really have to get to a place where you’re handling people’s problems and expecting them to give you solutions and not giving them solutions to simply implement. And also to a certain extent, you have to allow them to struggle a little bit. I gave a controversial talk. I think it was a couple of years ago or whatever, “Setting your team up for failure.”

Wow. That’s a very misleading title. Obviously. You don’t want your team to quote unquote fail, but the whole thesis was about allowing your team to kind of grapple with problems for a while and being a coach and not someone who just like gives them the answers all the time, because that’s really crucial for their growth and their understanding.

I mean, you probably experienced this for yourself. I mean, the things that you learn the best that are really ingrained within your mind are the things you learn, the hard way that bug you shipped to production. Or whatever. And you really want to balance allowing your team to accumulate those lessons for themselves with obviously not doing anything, that’s going to put your company out of business.

Christian Mccarrick: [00:09:30] Sure. Yeah. I could probably have a whole episode, I think, and maybe a will in the future on that fine line between just as you mentioned, when do you step in, when do you step back, you do want to let them fail. You don’t want to maybe have your entire site go down for a day. Right. So there is that when you step in similar to, I’ve got three daughters and even as a parent, you want them to skin their knee. Cause you want to know that it’s okay. And they’re going to get up again and do it. So it is that balance. Right?

Exactly.

Yeah. So now let’s talk just a quick minute about remote work. How’s your team doing with that? How have they switched during COVID? How are things going?

Johnny Ray Austin: [00:10:04] Yeah. I mean, I think it’s important to distinguish between remote workand remote COVID work. .

Yes, absolutely.

Christian Mccarrick: [00:10:11] I’m gonna interrupt you there because I say that to everyone, right. There’s remote work, which I have been doing, especially before at Auth0 for years, and then remote work in a pandemic. Right? Totally.

Johnny Ray Austin: [00:10:22] Yeah. All in all. I think that, and then based on my conversations with other leaders, just in the DC area and around the country, my team seems to be doing very well. And I think I have a theory why, but. We face the same challenges as everyone else. I mean, it’s not so much the remoteness of it remoteness on a dime one day, we’re all in the office. I remember the last time I actually talked to our CEO, David Sullivan, we’re both in the office. Most of the people had left and like things were happening with COVID, but it wasn’t clear at all how big it was going to be in the States.

I think we only had like a couple cases. Yeah. And before we left, we were like, I think I’m going to work from home most of the week next week. We’ll see how it goes. Maybe I’ll come in Thursday and Friday. This islike the last time I saw, at like the end of   Feburary. So it happened very, very, quickly. So dealing with the whiplash of everyone being in the office, pretty much every day to everyone being remote all the time, we did have to do some adjusting there, particularly with onboarding new employees, a few people we have now onboard it remotely, and they’ve never actually met the rest of the team.

So thinking of ways to kind of help people foster those relationships has been a bit of a challenge, but I think we’re just now getting into finding our footing to the place where we have a good model moving forward. Okay. That’s just straight up remote. The code pieces is the much more challenging piece.

I think we have a more mature demographic than most startups, so I’m actually pretty proud of that. Most people have families and young children and so we’re dealing with that all the time. So we have people working odd hours. Some people will come in very early and then kind of fade away middle of the day and maybe come on later in the evening or whenever their schedule permits.

And we very much have a culture focusing mostly on outcomes. We don’t want to manage people’s time. It’s like, look, do what you gotta do, deal with your family. Let’s regroup about tasking later. And if we need to kind of help out and cover for you, we can absolutely do that. So up until this point, it’s been manageable. We’ve been fine. The real test is when school start here in a couple of weeks. So ask me again at that point, but it’s definitely been a challenge, but I think that all in all, we’re dealing with it probably as well as anyone can be expected to at this point.

Christian Mccarrick: [00:12:34] Good. Yeah. And I think for my listeners out there and other managers, this is not easy for people who have been doing this and leading teams for years. And if you’re a newer manager, it’s okay to sort of ask for help. It’s okay to be a little overwhelmed, but you don’t have to be perfect. We’re all doing this together. There’s no book on remote development in a crisis like this. So reach out to peer networks. I think they’re so important. I’m sure if you’re looking for work, I don’t know, Johnny, are you hiring?

Johnny Ray Austin: [00:13:00] Not right this moment, but things are looking really well. So one of the reasons I mentioned, I think we’re doing pretty well is because just the mission of our company is to help people pay rent. And right now people need the solutions we build more than ever. So I think. I think one of the reasons we do so well is because we have a really strongly mission aligned team.

And so people, despite the challenges , they know why we’re here. And we’re relatively priveleged people obviously get to work in tech. We get to work from home, all this other stuff. And so people definitely understand that. And so they to continue to work hard and not because I’m out here saying like, “You gotta work hard”, but they recognize the problem we’re trying to solve.

And we firmly believe that if we don’t solve this problem, no one else is going to be able to do it as well as we can. And so I think that’s what is a real driver. So I say all that to say, things are doing well. We’re super busy. We have some really great stuff. We’re going to be releasing here over the next weeks and months. And we’ll definitely be hiring at that point. So keep an eye out for HelloTill.com.

Christian Mccarrick: [00:13:58] Absolutely. Absolutely. I want to pivot a little bit to going over some of the things you’ve written online and some of the talks you’ve given in the past. I know you do a lot of speaking and one of the talks you gave =, “Death of the Full Stack Developer. it’s so interesting. I’ve been in tech for quite a while now, and I have sort of seen that evolution, but how has full stack changed over the last number of years? And does that term even make sense anymore?

Johnny Ray Austin: [00:14:23] Yeah. So when I was pondering this. Talk, it was basically a combination of things I’ve seen in the industry. And as I came of age as an engineer and as a manager as well, and just seeing this evolution from mostly computer science graduates, going into software engineering jobs, and boot camps coming up, and then people career switching and actually becoming successful engineer. But I just had this observation that the folks who are career switching in sort of like jumping in.

They tend to have somewhat of a harder time, not because of just the material, but the expectations we put on people of what they should know when they come on to a software engineering job. And I was just thinking about what it was like when I started as an engineer. And this was, you know, like early two thousands and things were just very different, right?

Like software engineering was just back in software engineering and the whole idea that you would use JavaScript for anything other than like foreign validation, you know, it was just sort of laughable. But as you transform and you know, back then, If you knew jQuery, like you were a JavaScript Ninja like that, that’s all you needed.

Everything else is server side rendered and whatnot. And so the idea that you could catch up to verything that’s happened over the past 15 years kind of struck me as silly because even as someone who started off strictly back-end, delved in the front end, like learned a bunch of stuff. I’m not even able to keep up these days.

There’s just too much new stuff out there. And in one of the slides, I just try to list as many of the front end technologies as I could think of. And I’ve probably only covered a fraction of them. There’s just too much. There’s too much. And so taking a step back, I was thinking about, well, what do we actually mean by the stack?

Right. About 80% of the people who land on HelloTill.com come from mobile devices. And so you have mobile responsive development, but no one talks about mobile applications. When you talk about the stack, not really, we’re still like full stack is very much shorthand for front end back end. Well, what is front end?

You know, it’s just a client. Well, there are many clients that are not browsers. So when you start to think about those things and internet of things and devices, and when you look at the back end, what, what do you mean by a backend? Like attractions are pretty good these days that could mean just straight up API end points.

It could mean distributed system designs. There’s the whole serverless movement. There’s dev ops and like there’s all kinds of things. And so when you think about what it takes to build a differentiated non-trivial SAAS product from beginning to end, like the full stack encompasses a lot more than what we refer to as full stack these days.

And when you look at it that way, it’s completely unreasonable for anyone to be an expert in the entire stack. There’s just too much there. And so it kind of led me to this whole thesis of, I think the true full stack developer is dead and gone, but you can, you can still be, you know, pretty good in more than one area.

I don’t mean to discount a lot of people who are pretty darn good on backend and front end. But I think we need to be honest with ourselves when we say what we want. When we say we want a full stack developer.

Christian Mccarrick: [00:17:29] Yeah, I know. It’s very interesting. I even know now, and you talk about two levels and layers of abstraction, right?

Cause you can talk about you just look at the whole Amazon ecosystem, right. And you just use RDS and in some cases you’re abstracting out half the database and you don’t need to know about setting up it probably at some point and set up time. My sequel and Postgres and sequel server got, who knows how many different databases and gotten into the nuts and bolts.

But now it’s sort of spin it up. Here’s your end points. Let’s just start inserting. Which is interesting when I was reading through your talk, I reminded a little bit of a way back in the day, right? Like Leonardo da Vinci. Right. And that kind of era, he was an expert in so many things. Right. But today you can’t, as you mentioned, I think that kind of fit in with the paradigm of your talk a little bit.

Johnny Ray Austin: [00:18:18] Yeah. And it’s not necessarily a bad thing. It’s just recognizing that there are specialties. I’m in an early stage startup. So I definitely understand that temptation there, you want to get as much bang for your buck as possible. And so you bring in people who are very versatile and they’re certainly very versatile engineers, but at some point you’re going to hit your limit.

And then just recognizing when that is. So you don’t burn people out and make sure we set our expectations accordingly, but yeah. It’s a hard balance to strike, but I have seen the models where people just quote, unquote only hire full stack engineers. And I don’t think you can get very far when you’re trying to scale with that. You need some specialists in there.

Christian Mccarrick: [00:18:53] Sure. And then something that you mentioned just a few moments ago, how to keep up. I know it’s a struggle for myself. I’m going to talk to other engineering leaders. How do you recommend if at all that engineering leaders stay up with all of the new technology and frameworks and code coming out, especially with people on their teams or like, “Hey, I want to try this. I want to try this. I think this is cool.” How do you, as a manager kind of manage that?

Johnny Ray Austin: [00:19:16] Yeah. Knowing your limits, righ? You can touch every technology that comes out that becomes popular, but you’re not going to be able to become an expert in all of them. One of the things that does come with experience is the ability to recognize patterns

and to know that if all I know a new framework comes out, it solves these particular problems. Oh, it’s comparable to this framework that I have a lot of experience with. Then maybe you only look at what are the differences and maybe that’s a good enough, right? You don’t have to necessarily be an expert in all these things.

I think just general awareness is probably good enough. This is where trusting your team comes into play. Right? I myself, I’m more of like a VJS fan. I’ve like written a little bit of react, but I find myself just not really crazy about the framework, but if we need to build something in react, I have experts who are react developers and really love it.

I’m like, I know what it is. I know the concepts and that’s pretty much all I need to know moving forward. And so I think it’s all about just general awareness and seeing where the industry is going and being aware of the trends, but not necessarily needing to dive into every single particular technology that comes along your Twitter feed.

Christian Mccarrick: [00:20:27] Yeah. And I’ve often had in the past, you know, you have engineers, they read an awesome blog posts from something, and it’s sort of it’s that technology and looking for a project or a solution instead of the other way around.

Johnny Ray Austin: [00:20:38] Right. Exactly. Exactly. And that could be very fun. So I understand that temptation.It’s like, “Oh, I read this new thing now I want to go find a problem to solve with it.” And that can be very fun. I definitely encourage people to do that if you have free time to do it, but we need to be mindful about the solutions we bring into the workplace.

Christian Mccarrick: [00:20:56] Sure. When you talk about full stack engineers and you talk about some managers or some teams only hire full stack versus specialization. I think one of the other challenges that engineering managers have is building teams. And what do you think in hiring …so what do you think some of the mistakes new managers make when they’re sort of starting, when they’re building out their team and they’re trying to hire quickly?

Johnny Ray Austin: [00:21:17] Oh wow. You can definitely do a whole episode on this.

I think that one of the things we make mistakes with as an industry is that we assume that one process is going to work for every company out there. What is the best way to hire? I mean, we know some of the worst ways to do it, but I think that you have to find a process that works for you and your team that allows you to find the right fit.

Because, you know, we talk about bringing the right people in at the right time, and making sure you can take advantage of their particular skills. So I think that one of the mistakes that we tend to make is not thinking about how does this person grow into other roles. We hire quickly and we place people into the thing we needed yesterday.

But not really taking into account. “Well, yes, this person fits that role, but can they like grow into what I might need in a year or 18 months?” Right. And making sure that where you as a company plan to go is in line with what this person wants to do in the future. I think that’s one of the biggest mistakes I’ve seen.

I mean, so what happens is you bring people on and they may do very well, but the company moves on. You need them to do other things or to expand their horizons a little bit. And you find that they’re just really not interested in that, or they’re very interested in solving those ground level problems, but once you’re just sort of like operating at scale, they’re not so much interested in that.

So I think that’s one of the biggest mistakes we make as engineering managers. And again, understanding, sensation, things that happening customers, what features you need to scale. So you hire people for the day. Yeah. But whenever you can and should always consider people’s growth and what they want to do in the future.

Christian Mccarrick: [00:22:51] Yeah, that’s a very good point. I think you’re right. It’s hiring for the now, when you really should be hiring for tomorrow, that now is staring you right in the face. So you need to solve that as problems. And I’ve seen that before, especially with the startups, right. You start with a team of two, 10 people, and then you go to 50 and some of those engineers, they’re awesome. They’re amazing. Kind of that, that trajectory or that piece of that trajectory, but they’re not fairly interested in all the things that come along with a larger growing company. Like you said, the scaling, the potentially compliance and support and everything else. And as a manager, how do you have those conversations with someone who’s, they’re excellent, but maybe they’re excellent at a different phase of a company than where you are now.

Johnny Ray Austin: [00:23:37] Yeah, that’s one of the first things I do. And like the, uh, in the phone screen, you talk about Till and where we are and what we’re trying to accomplish. But I also talk about our ambition and what type of company we expect to be in a year and 18 months. And how does this person I’m talking to fit into that?

And it’s more of a conversation. What do you see yourself doing right when I bring you on to work on it, this thing when that’s built out and we have 10 other engineers on the team, are you interested in leadership? Are you going to be good, mentoring other engineers? How do you think about operational excellence and maintaining things over the lon-term versus building a new thing?

Right. Everybody wants to get in to the Greenfield portion of the project, but it’s all about maintaining things in ownership, moving forward, and just being very honest about it. My expectations moving forward. I think people really appreciate that. And some people don’t want to move forward. They’re like, yeah, I want to like build a new thing, but I don’t know about all the other stuff.

So we’ll see. But some people are like, yeah, I do want to grow. I think I want to lead. I want to do X, Y, and Z. I’m great with mentoring. I know all those things I’m aligned with the mission and whatever the company needs at the time in order to accomplish that mission, I’m willing to do so. Those are the people I tend to bring up.

Christian Mccarrick: [00:24:47] Cool. Yeah. Thank you for that thoughtful response. Appreciate that. And in that talk, you also said hire for strengths, not lack of weaknesses, sort of what was that quote and what does that mean for you?

Johnny Ray Austin: [00:24:57] Yeah, so I first heard it from Ben Horowitz. I think he attributed it to either Colin Powell or someone else. I don’t remember, but it really jumped out at me as yes., that’s exactly the way we should think about it because so much of hiring. I mean, you understand why, right? Hiring is a very risky endeavor, right? You bring on the wrong person. There could be a lot of damage to the team. And so what we do is we’re trained to look for the gaps and you definitely want to be aware of them, but you don’t want that to be your, the thing you make your decision on, you want to figure out where are people spiky, where they’re really, really strong because the gaps are always going to be there no matter what.

And so if you hire people for their spikes and for their strengths, you can always hire other people who fill in the gaps. And then this is the definition of a team. You bring people together, they compliment each other. They help each other grow in the areas where they have gaps, but they really lead the charge with their strengths.

And so. That’s kind of what I mean when I say that. And so when I hiring people, I figured out like, what is this person really good at? Where are they really strong? And even when they’re in the door, which projects they work on, what are their interests and what are they really, really good at? You have some people who it just really, really good at being heads down and just cranking things out.

Not necessarily antisocial, but that’s sort of where they thrive. So you really want to make sure they’re working on things that allows them to do that. And most of the time you have some people who are they’re great engineers, but they’re really, really good at communication and gathering requirements and working with people and getting feedback.

So you really want to have those people on teams where that is necessary, right. And pairing those people together can actually be very, very powerful because then you have a team that can talk to the internal or external stakeholders and gather requirements and really figure out what the pain points are.

And then you also have a part of the team that can just really go heads down and actually build solutions to present to them. And so I try to really look for the spikes and people’s profiles and figure out how they fit into the team.

Christian Mccarrick: [00:26:55] Yeah, no, I think that makes sense. You’re not going to pass on like the league’s top tight end because they can’t throw well, right.

I mean, exactly.

Yeah.

And I think that goes back to the point of building teams that are not, um, homogenous, right? I mean, you want diversity in teams across all dimensions, right. Because that’s how you, because some will cover the other maybe weaknesses and together you have something that’s so much greater than some of the parts there.

Johnny Ray Austin: [00:27:22] Exactly. Yep.

Christian Mccarrick: [00:27:24] Yeah. Now want to move into some a little bit-things you  talk abou- junior engineers and from a manager’s perspective, specifically yours, what do you believe the benefits of hiring and bringing a junior engineer onto a team or?

Johnny Ray Austin: [00:27:36] Yeah. Indoctrination. I may actually mean that you bring on a junior engineer… so if you bring on a senior engineer, you get a lot of benefits, but you also get a lot of drawbacks. You get a lot of experience and this person has built things and all this other stuff. And so there’s much less to sort of like front load onto them. But at the very same time, they’ve done things a certain way. That’s the way they want to do it. moving forward. You cannot convince them that there’s a different way.

Christian Mccarrick: [00:28:05] They’re going to tell you about it too. Yeah.

Johnny Ray Austin: [00:28:07] The way that they’ve done it. And they were successful regardless of the fact that other people have done it. Yeah. Different ways. And we’re just as successful and it’s not always, but that’s generally what you see and there’s a time and a place for that.

Don’t get me wrong. But junior engineers, you don’t have that. Right. You don’t get the experience and the scar tissue, but you have somewhat of a blank slate. Right? You can grow someone into doing engineering in the way you do it at your company. And also what I’ve found that to be very beneficial is the mentoring piece.

I used to teach courses for general assembly part time. And one of the things I like most about doing it is that just going back to the absolutely basics to kind of explain things to people, really help for me identify my gaps in knowledge or things that I took for advantage. Right. Months and months ago it was probably last year.

As a matter of fact, I was having a conversation with one of my engineers. We’re all out to dinner. You just hadn’t new engineers started back when we could all go outside

Christian Mccarrick: [00:29:01] back in the day. Right?

Johnny Ray Austin: [00:29:02] Yeah. And we’re talking about a very similar topic and we’re talking about like a website and we said something around, “Oh, we’ll just throw it in S3 and behind  CloudFront or something like that.

And. It sounded like a very easy task, but we were like, I was like, “Okay, let’s dissect what we just said. There’s a lot of sort of implied knowledge. They’re like, what is S3? How do you actually get things into it? How do you permission your bucket appropriately? What is a bucket? What is this? CDN? How is it beneficial? Why would you even use it? Like, there are a lot of things that we take advantage of. Take for granted as more senior engineers that forces you to kind of revisit the basics at the ground level when you’re sort of training people up. And it really reinforces you’re learning so like it for their benefit, but also for selfish reasons, it helps me as well. And also it helps my team to kind of have them revisit some of their knowledge as well.

Christian Mccarrick: [00:29:58] Yeah. I think one of the things too, which I find helpful is you also want for your senior engineers to grow as well, kind of mentorship and coaching is also part of that journey for becoming more that senior principal engineer. And it gives them an opportunity to help share some of their knowledge as well.

Johnny Ray Austin: [00:30:14] Yeah, exactly. One of the requirements for seniorsship at Till is it’s not a nice to have to be a mentor. Like this is a thing you have, you have to do or be willing to do. And like you said, is it’s very key to their growth.

We have a couple of engineers who are like pretty senior. Like there isn’t much I can teach them technically. But they still need to grow in a lot of ways. And as the company grows, having that influence across the organization and being able to help train people, that’s going to be a very key skill set that I look forward to making sure everyone has at that point.

But yeah, it becomes very, very crucial and it’s extremely beneficial. I can’t imagine necessarily having senior engineers who refuse to do that, it’s very easy to imagine engineers who aren’t good at it, but as long as they’re willing to learn, that’s something that I can definitely work with.

Christian Mccarrick: [00:30:59] Sure. Now, is there anything specific you look for if you’re hiring a junior engineer or someone right out of university, kind of what are some of the signals you can get that because they don’t have that experience, but I think there’ll be good here.

Johnny Ray Austin: [00:31:11] The intellectual curiosity, the types of questions they ask, those are always good indicators for someone who is willing to level up and learn. Because, like you said, they don’t have the experience. A lot of the time they don’t have code they can show or anything like that. So just the engagement in the conversation and the level of intellectual curiosity is something I’ve found to be a very positive correlation with great performance and leveling off as a junior engineer.

Christian Mccarrick: [00:31:38] And for managers today, especially with COVID working from home, anything that you have an advice for them to be able to coach her guide their junior engineers today, because you know, you can’t just sit them next to someone and like all day, I mean, you know, at least in person, what tips would you give to managers to help them make their junior engineers successful in the time of COVID.

Yeah, I take advantage of tools, you know, screening, sharing, and pairing that way is always a good way to kind of get people together. Obviously you can’t have that, that connection you have when you’re sitting side by side with someone, but tools really do enable you to do that. One of the tools we use here is, I don’t know if you’ve seen Miro.

Oh, yeah. Yeah. I’m not endorsing Miro or anything, right. But it’s been really great. Right. Because one of the things we used to talk about is like, “Oh man, the worst thing about being remote is that we don’t have that whiteboard. We can like stand up and sort of gather around it.” But Miro actually gives us that and we have all these boards and we can actually draw it’s real time.

I think they have a video chat feature embedded in the tool itself, although I haven’t used it. And that’s been really great. Just the idea of, you know, getting engineers in a place where they can actually sort of like draw their thoughts because a lot of them people, particularly junior engineers are really visual and their learning process.

Johnny Ray Austin: [00:32:48] And so I could speak at them or like show them code and it still may not click, but if just draw three or four boxes with a few arrows, there’ll be like, “Oh, I see I get how this works now.” So really leveraging technology to the extent that you can. And just knowing that some of these things aren’t cheap, but they’re well worth the cost of allowing people to communicate and understand each other better.

Christian Mccarrick: [00:33:11] Yeah, absolutely. That’s one of the great tools I’ve found and is a great, you know, if you happen to have an iPad with an Apple pencil, you can also kind of use that as well, which is helpful.

Johnny Ray Austin: [00:33:20] Yeah. And I was going to say, helping invest in like good communication tools as well. We bought everyone microphones.

I forget which kind  it was, but yeah, people are  on calls and like that. And like, David was like, we want everyone to sound as good as Johnny does when he gets on the call. So he’s like “Go find microphones and we’ll just like send them to everyone in the company.” And sure enough, we did that. So it’s a small thing, honestly, in the grand scheme of things, but to really show your team that you’re invested in helping them bridge. That communication gap is really important.

Christian Mccarrick: [00:33:51] So now I know why no one can get microphones anymore. Your team bought them all. Oh, it actually would have been a decent business model right now. You but em for 50. and sell them at 300, like they’re doing an eBay. It’s kind of crazy. Yeah. But you’re right. I think. Yeah. Microphones and cameras and lighting. Right. How often do you go in zoom? And it’s like witness protection program. You’re like, who is that?

Johnny Ray Austin: [00:34:13] I didn’t know you were on the run.

Christian Mccarrick: [00:34:17] That’s right. That’s right. Another piece of that– talk you kind of talked about too, is.You mentioned for junior engineers to not kind of rush through that junior phase, right. To not kind of skip that. Yeah. How do you give advice?  () Cause most of my listeners are engineering managers. What kind of advice can you help to give engineering managers to help guide and give advice to their junior engineers to say, Hey, slow down, you don’t want to rush through this?

Johnny Ray Austin: [00:34:41] Yeah. That’s a hard one actually wrote about this long before I gave this talk to the years ago, I wrote a blog post called “It’s Okay to be a Junior Engineer” because I observed this phenomenon where like people would go into a junior role and then like three months later, they’d be like, how can I be a senior?

And it’s like, well, that’s a loaded question. And it can be very disheartening because you can point people to all these resources and say, go learn this thing and go learn that thing. But the fact of the matter is there are just some things that only come with experience. I think I put into post, like just very plainly time has to pass, right?

Like you have to try things. You have to fail. The things that make seniors valuable aren’t necessarily the, their accomplishments, but they’re also their failures and not how to do things, but how not to do things definitively and ensure you can absorb some of that knowledge at an accelerated rate, but you really want to have that knowledge for yourself.

So I don’t know. The advice I would give to managers is to have that honest conversation with juniors who come to you with that problem and just let them know your expectations. I mean, it becomes really tricky because you start talking about years of experience, but that’s not really a good thing indicator as well.

Cause I think some juniors actually do get to seniorship pretty quickly, at least senior ship in the way that I define it. I’ve also seen engineers who have been doing this for 20 years and they’re not actually senior by my standards. They’re just kind of been coasting for about 20 years and. And I guess that’s fine if that’s what they want to do and that so their organization.

So I think that settling on what a good definition of senior is, is within your organization and then helping to benchmark juniors, where they are and talking about, well, what are the gaps that you could potentially feel just by picking up a new framework or learning some things, but what are the more qualitative experiences you need to have in order to get there?

And it’s one of those things where if you talk to a junior. It won’t be very clear to them. They’ll just be like, why can’t I just like these things and just get my senior title. But the moment they realize they were wrong about that, they’re probably a lot closer to being a senior than they ever were at that juniors phase.

And I don’t want it to sound like very gatekeepery or anything like that, that, but it is something that you just know at a certain point. Like you look back at your career and you think about the things that you thought you knew at that time and about. Now you’ve, you may have been in terms of the process of getting there and, you know, based on your experiences you’ve had since then, that you couldn’t have gotten there at an accelerated pace, you had to go through those failures.

You had to build up that scar tissue in order to really be considered a senior in most places. So I would say, just have a very honest conversation about that and see where that takes you.

Christian Mccarrick: [00:37:18] Yeah. And I think one of the point you mentioned too, which is spot on, especially at some larger companies, which are a bit more rigid. When you get that senior title, you might’ve been exceeding the expectations at a junior and now suddenly the next day you’re not meeting our expectations and it’s all because of that. So enjoy less pressure for as long as you can, until you feel ready. I think that’s another important part you made.

Johnny Ray Austin: [00:37:40] Yeah, definitely the idea that as a junior, you’re very much expected to make like a bunch of mistakes. And I mean, granted, if you’re senior respected to make mistakes as well, but. Implicit within the senior title is senior level compensation and expectations do go up from an engineering perspective from an engineering manager perspective.

And so if you don’t meet those expectations, I mean, you can get yourself into a bit of trouble. So before you really go off and start to hunt down that senior title and make sure you’re ready for it, but there’s nothing wrong with being a junior mid level engineer for a little while, and like really gathering that knowledge and then making the jump at that point.

Christian Mccarrick: [00:38:15] Sure. And kind of one final question on the topic. Bootcamp graduates. Right? Kind of what’s your thoughts? How would you recommend managers to sort of take advantage of, of campers people graduating from boot camps?

Johnny Ray Austin: [00:38:27] Yeah. Well, I’m definitely an advocate of hiring out of bootcamp. Some of the most successful and sharp engineers I’ve ever worked with came out of bootcamps or had no formal education of any kind, the biggest difference between bootcamp devs and people coming out of college with CS degrees.

It’s funny, you know, you start talking about those spikes and gaps. Someone with a CS degree, knows a lot of theory and can talk about data structures and all this other stuff, but they had no clue how to be a software engineer day to day. And this is very much me when I first came on at school. And I was like “Yup. I did good on my white boarding. I drew that algorithm for that linked lists, doubly linked list, as a matter of fact, and it was great”, but version control and like versioning and general and security, like these were things that at the application level, I was completely ignorant about it. I didn’t know how to ship software or be a software engineer.

Whereas bootcamp developers, that’s all they learn. They learn about how to set up  APIs and how to work this and these frameworks. And so they’re very much software engineer ready. Granted, there are some concepts there that aren’t there. And so those are gaps. And so I think we, you need to figure out as an engineering manager, is which gaps do you want to feel?

Right because there are going to be gaps. And if you want someone to come in as an engineer, you should strongly look at bootcamp devs and figure out how to get them. Sort of like caught up on all of the theory, at least to the extent that it’s actually needed. But if you just want someone who’s very strong and foundations, and like you really want someone who’s going to dig into systems that don’t necessarily require all of the day in day out software engineering practices that we come to associate with.

Then maybe you get someone that’s out of college and teach them how to be a software engineer over the course of six months or so. So I don’t know. It depends on what you’re looking for or what you need, but you certainly should not discount. Bootcamp grads. Cause there are a lot of smart people coming out of those programs.

Christian Mccarrick: [00:40:22] Yeah, totally agree. But I recommend to, to definitely, if you’re looking for people to look into those, as well as what you mentioned before coming full circle for a build out that team. So as a unit, right, that team has strengths and weaknesses at different points that can help you actually be successful.

Johnny Ray Austin: [00:40:37] Yeah. And a lot of the people who come out of boot camps are career changers. So like they’ve done other things within their lives. And so there’s sort of this untangible level of. I don’t want to say maturity, but industry experience that maybe not, that comes with someone who is 21, 22, right out of school.

And so there’s something to consider as well, particularly if that person used to work in the industry that you’re serving, right. If you’re writing accounting software and this person used to be an accountant, like you really need to consider hiring that person hardcore.

Christian Mccarrick: [00:41:07] Absolutely. No, a hundred percent agree there. That’s an awesome point. Yeah. Great. Now, one thing I do ask also all of my guests, Johnny, any recommendations you have for books or podcasts or anything, this could be something like a seminal book that changed your life or something you read last week.

Johnny Ray Austin: [00:41:21] Yeah. A couple come to mind. I think Radical Candor by Kim Scott is a really a good one. One of the things I’ve seen, a lot of engineering managers, even leaders struggle with is having very honest conversations with the people that they’re working with and being able to give good feedback. One of the great points of the book that really jumped out to me when I first started looking into it was the idea that most of the time, you want to be very compassionate with people, but it’s very in-compassionate to not give them the direct feedback that they need or to improve themselves, you are literally robbing that person of that opportunity to improve. And so even though it may be a little bit uncomfortable in the moment, if you consider yourself a compassionate person, you are doing the right thing by giving them the candidate feedback.

And there’s a way to do it without being rude or condescending or anything like that. So I definitely recommend picking up the other one is An Elegant Puzzle: Systems of Engineering Management by Will Larson. I really, really, really love this book. This is a very, no nonsense, like blocking and tackling, like step by step.

A lot of engineering management books, very philosophical about like the way you should, I think about things and all this stuff. And then like, we’ll just break it down. Like, this is how you think about it reordering. Right? This is how you think about like, hiring very specifically. And it’s a very good book.

It’s very coachy right. He gives very few like straight up answers, but he gives you a. Frameworks to think about how to do your job day to day. And it’s a very good reference book. You can revisit it out of order all the chapters to like really dig deep and like individual pieces. So I really love it.

It’s a great book.

Christian Mccarrick: [00:42:53] John, if you can look, my listeners can’t but that white book, I, my table behind me, that’s like dog ear and face down. That’s the book you just mentioned. That’s an elegant puzzle. Yeah. And you’re right. The point that you mentioned is you don’t have to read it really in any order, you just kind of go through it.

And boom reorgs, boom, vision statements, career planning. Like it’s a really good book. Yeah. I highly recommend both of those as well. And from our listeners as usual, go to simple leadership.io, I’ll put those links to both of those books in my show notes, Johnny, what’s the best way. Any of my listeners want to contact you? How could they reach out?

Johnny Ray Austin: [00:43:28] Yeah. Twitter is probably the best place. I’m a recursive funk. That’s funk with the K and Twitter, or you can just land on my website. RecursiveFunk.io.

Okay. Excellent.

Christian Mccarrick: [00:43:39] Well, Johnny, super glad I had an awesome time talking with you. Maybe realize how much I miss talking with other engineering leaders and getting to jam a little bit. So thank you very much.

Johnny Ray Austin: [00:43:47] No problem. Thanks for having me.

Thank you for listening to this episode of the simper leadership podcast, hosted by me Christian McCarrick. If you’ve enjoyed the show, please subscribe and don’t forget to leave a review on iTunes, full show notes, and additional information can be found on simple leadership.io.

If you know someone who would be a great guest for the show, or you want to share your own experiences, please drop me a line. We’ll see you back next week for more technology, leadership tips and advice. As I interview more top software engineering leaders.