Christian McCarrick: This is simple leadership. Welcome
you here to learn from you 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. Good morning, Jon, welcome to the show. Thanks for having me, Christian. Yeah, absolutely. And where are you actually connecting in from this morning, Jon?
Jon Thornton: Actually in upstate New York at my parents’ house. I grew up in Socrates, New York and decided to get out of New York city for the week and get some fresh air. So it’s been a nice week up here,
Christian McCarrick: Right? Yeah. Nice. Now, is that area known for, is it racing or something up there?
Jon Thornton: There is a Speedway in upstate New York.
I don’t know. I’m more into the hiking and camping and things like that.
Christian McCarrick: Absolutely. I remember I grew up in New York and long Island and we took a number of sort of boy scout trips up to the Catskills and the Adirondacks.
Oh cool, I worked
Jon Thornton: at one of the boy scout camps up here.
Christian McCarrick: Oh, did you? Oh, cool. Cool, excellent, excellent. Lots of good memories of kind of camping trips. All the way up to like thousand islands and Lake Placid and all, all sorts of great areas. So, yeah, that’s a great memories of kind of getting to the great outdoors and upstate New York. So I’m glad you got to get away from Manhattan. So awesome. Jon, like I asked most of my guests on the show, just so people can get to know you a little bit better.
If you can give me a little bit of a brief history of your background, pretty much how you got to be where you are today.
Jon Thornton: Yeah, so I got started with programming when I was 12 using the view source option. Gosh, I think it was internet Explorer three at the time. Oh, wow. Maybe dating myself a little bit, but I was a self-taught programmer in high school.
Got some odd jobs, building websites for local businesses. When I went to college, I kind of foolishly thought that I had already learned everything about programming. And so rather than studying computer science, I studied electrical engineering, learned a bit about hardware, and that was a fun experience.
But after having a career in software. I realized that it would have been nice to have a more academic grounding in computer science. After college, I kind of stumbled into co-founding a parking company. I had done a senior thesis project on building little sensors called moats that could detect if there was a car parked in front of a parking meter and the natural extension is built an app that tells you where all the free spots are and ended up working at that startup for eight years, bootstrapped it for awhile, got to do front end backend database administration raised a bunch of VC money.
Burned myself out, took a bunch of time off after that and realized that I had a bunch of like mentorship gaps. Basically. I’d been self-taught my whole career. Yep. And so deliberately decided to go find a company to work for had an engineering organization. I respected a place where I could get mentorship and worked at a couple of smaller companies in New York city, worked with some great managers, learned a ton, and eventually ended up at Squarespace where I got this amazing opportunity to build a new product and a new team at a company that already had an established and successful product.
So I got to build Squarespace’s email marketing, product, email campaigns, launched that. And since then I’ve been supporting some other projects at Squarespace. Y eah. Yeah.
Christian McCarrick: Well, great. And I’m pretty thorough, usually Jon, in my kind of digging into people’s backgrounds and I completely missed that about you probably cause I do this on the side. So my day job tends to turn into my night job sometimes as well, but I’m putting two together now, Jon and I thought I knew why your name sounded so familiar. I actually had started a company called Parking Karma.
Jon Thornton: Oh, Whoa. So small world.
Christian McCarrick: Yeah, completely. So we can have that discussion maybe offline, but certainly again, I normally am pretty thorough, but I didn’t kind of go that far back and your bio at this point. So anyway, I don’t need to kind of borrow from our listeners about this, but totally. I think it’s a very small world as it gets to technology and startups, which I kind of, it’s just a theme that always happens. So. Awesome. Awesome. Great to finally meet you. I’ve heard about you and stuff for years. I didn’t put two and two together, but yeah.
Awesome. That’s a total other thing we can discuss later, right. Okay. So one of the things, and I appreciate the background on that. I think, again, I do this again and again, just to make sure that people understand there is no true path to how you get into technology, how you get into software engineering, and then also how you get into software engineering leadership. If that’s kind of the path that you choose to get into, right? Yeah. Yeah. So we kind of talked into a little bit, you just kind of went over how you got into sort of being the manager, but when you went into being the manager, you had a kind of a roundabout way to, you started to sort of a company and then you were maybe instantly a manager.
And then not that you didn’t kind of go through like, Hey, you an, I guess you were an IC, but what were some of those mistakes you made early on? You said you had gaps in mentorship. Like what might some of those have been?
Jon Thornton: Yeah, yeah, exactly. Like you mentioned, when I started a company. I didn’t really think too consciously about moving into a management role.
I just thought, “Oh, I’m the founder. So therefore I’ll be the CTO. Therefore I’ll be the manager.” And it didn’t really introspect that decision too much. And also didn’t really understand that there was a whole practice of management and a lot to learn there. So right off the bat, one of my first big mistakes.
My first hire, I knew I needed help building more features and supporting the system we were building, but I didn’t really do the work to define the role before I hired somebody. And once that person was onboarded, there was a total mismatch of expectations about what needed to get done. And it was really uncomfortable for me.
It was really uncomfortable for the engineer hired and it ultimately didn’t work out. And that was right away. My first big lesson that when you hire somebody, you need to have a plan. You need to know what that person’s role is.
Christian McCarrick: Yep. Yeah, that’s a pretty good advice. And it’s something I think I didn’t consider right away to hear about writing a job description. And I think that’s the only half of it as well. Right. I mean, there’s the, even my engineers today or my managers today, I need to hire and it’s unclear, like trying to go into a little bit of depth, like, why do you need to hire, like, what is this problem? This person is going to solve. How are they going to fit in with the rest of the team?
How are they going to combine to make something additive versus negative? Cause that’s a strong possibility as well.
Jon Thornton: Yeah, totally.
Christian McCarrick: Now, I think if there’s a path, you know, you’ve gone through this path, anything you would’ve done differently along the way?
Jon Thornton: I certainly would have tried to build a stronger network of mentors while I was running my startup company. Once we had VC funding, we got connected via our investors to some advisors and they were super helpful, but. We were bootstrapped for almost five years before that. And I definitely should’ve put a lot more effort into building my network of not just peers, but people who had walked this path before and could kind of help me understand what was coming down the road.
Christian McCarrick: Sure. Yeah. No, I totally agree with that mentors for every aspect, right? I mean, multiple ones, one for leadership, for business decisions, for raising money, for all sorts of things. I think it’s important to sometimes stop and just raise your hand and seek help, because that can cause you right. If it takes you a day, maybe to sit down and just kind of network with people or send cold emails or try to work through introductions that can save you millions of dollars and tens of hundreds of hours of sort of work or rework later, uh, you know, like teaching yourself can be quite satisfying, but it can also be quite expensive and time-consuming.
Jon Thornton: Correct.
Christian McCarrick: Yes. Yeah, absolutely. As a leader now, Jon, how do you advise any new managers making the transition? Like if you had any that were going to be kind of coming up, what are some of the tips you would give them?
Jon Thornton: Yeah, I think a big one that helped me was realizing that in a management role, it’s not about your individual output. It’s about the output of the team that you’re supporting. And once I realized that for myself, it was helpful in shifting the things that I spent my time on rather than trying to. Plug all of the leaks in the team or a common phrase I hear with managers is being a human shield for the team. And I realized that that wasn’t the kind of manager I wanted to be, kind of wanted to get out of the way and focus on how do I make the people on my team and the team itself as productive as possible and not make it about the things that I’m doing directly.
Christian McCarrick: Yeah, definitely. Definitely a good point there. Now, as I do with all my shows, I kind of want to focus it’s on a specific area. And one of the reasons I reached out to you, Jon, I had seen a talk you had given with the lead dev and some of the other things you’ve written online about the topic of good technical debt.
And I think in some cases that can be somewhat link baity. Right. But I think also there’s some validity to it, so I’m sure all of my listeners possibly should know what technical debt is, but I also have people that listen that aren’t necessarily in technology. So if you could kind of give your definition, Jon, of what does technical debt mean to you?
Jon Thornton: Yeah. So I think that the more commonly accepted definition I’ve heard when talking to other engineers is really. Code that you don’t like, and that you feel like you’ll need to change later, need to fix. And I tend to think of it with a bit of a narrower definition, which is work that I expect to have to do in the future on a particular piece of code.
And that typically means like scaling work or work to better factor something, but not necessarily just code that. I don’t like if it works and it doesn’t have to be changed. That doesn’t mean it’s tucked up.
Christian McCarrick: Yep. Yeah, that’s an awesome, I think sometimes people do want to have perfect code in every nook and cranny of the code base, but that isn’t always is worthwhile from an ROI standpoint, other than some personal satisfaction someone has, but it’s not really going to make any money, any money or provide more value to customers.
Jon Thornton: Right, right.
Christian McCarrick: Now you also mentioned Jon, the difference of financial debt and technical debt. They’re not always seen the same way, right? One tends to have a negative connotation and one can potentially have both. Can you explain that a little bit?
Jon Thornton: Yeah, well, financial debt is a pretty commonly accepted thing. If your friend goes and buys a house and takes out a loan to buy that house, you’re going to congratulate that person. And that’s it very reasonable, responsible use of debt to acquire something now and sort of pay for it over time. And the analogy that I’ve tried to use when thinking about technical debt is you can do the same thing. You can use technical debt to get valued now for your team or for your users. And then you can pay that down over time.
Christian McCarrick: Yeah. That reminds me of a popular book that came out a little while ago. I think it was called Bari way to wealth. Right. And the premise is using that debt to provide leverage that can help you provide value now.
Jon Thornton: And in the future. Right, right, right. It’s a tool, you know, it allows you to reorder when the value and when the payment happens and the trick is to use that tool responsibly.
Christian McCarrick: Exactly. And you also mentioned, and I like this term sort of time is our currency, especially as software engineers. And what do you mean by that? And how does that apply?
Jon Thornton: Well, when you think about starting an engineering, a new engineering project, typically you’ll be doing some estimates. And often the words I hear people use around that is like, how much is this project going to cost us? And that’s typically in terms of man hours or engineering weeks, or how long is the team going to spend building this thing?
That is the cost of the thing. So you can sort of use time to do your accounting. If you’re following this financial debt analogy where you can say, okay, we’re going to take out a tech debt mortgage, and we’re going to kind of borrow some time that we will then pay back later. And ideally you’re doing that in a way that creates more value than if you spent the time on that thing now and got the value later.
Christian McCarrick: Yeah, no, exactly. And I think the interesting thing that sometimes I think us in engineering, especially maybe specific ICS and engineers, that the main reason that we exist is really to provide value. We’re providing value to maybe our shareholders, our company, the users of our product. Right. We wouldn’t exist without that.
And I’ve always find it. Some things I coach and some of the managers I coach too is, but yeah. A common scenario is a manager taking over a team from another company. Right. And immediately being presented with what’s clearly going to be some sort of technical debt or risk, right. That is accumulated over the years, right? And how would you manage, how would you kind of coach one of those managers when they come into a new team to kind of evaluate like, Oh my God, how could this decision have been made? And clearly decisions were made at the point in time. I usually, for a specific reason. Right, right. But how do you recommend kind of new managers coming in and hurting a coal-based base and then looking at what they should do with it?
Jon Thornton: Yeah. Well, ideally you can talk to some people, or you can read some commit history to better understand how you ended up with the system that you have today, because there’s almost always a reason for these things, even if. That reason gets lost the time. Yeah. But I think the next step I would do is to try to assess what kind of technical debt you’re dealing with.
And I typically sort it into two groups. Technical debt is actively accruing interest, meaning you are either actively spending time on that technical debt with bug fixes or other maintenance or it’s technical debt that is growing larger. And you’re not necessarily paying interest on that debt, but it is.
Growing. And an example of that would be an API that, you know, has some design issues with it. And if you continue building things on top of that API, it’s just going to get harder and harder to evolve later, versus other kinds of technical debt where perhaps there is. A scaling issue where your performance is.
Okay now, but you know that six months from now, you’re going to run out of disc space or your database. Won’t be able to support the amount of data you have. And in that case, you have a few more options because your debt isn’t increasing literary leader exponentially with time. You know, you have some more time to maybe not work on that technical debt and do some other things in the meantime.
And maybe three months from now is the right time to address that debt. So I think. Once you have the history sort of establishing the urgency with which you need to address that debt is kind of the next step.
Christian McCarrick: Yeah. You made a couple of good points there, right? Kind of assessing the urgency as well as the time is the time right now, the time to deal with that, because there might be some valid reason that this should be dealt with, but there also should, could be a competing.
If you don’t launch this new product, you’re not going to get your next VC round. And then by, by tech debt, you don’t have to worry about it anymore, but you had to get a new job too. So yeah, certainly I think those are definitely two points, two good points you made there. Now, as we kind of flip on the kind of the technical debt side and some of the negative aspects to it, let’s talk about the good technical debt, right. And you say good technical debt is intentional. So when you talk about being intentional with good technical debt, what are some of the things you mean by that?
Jon Thornton: One example from a project I worked on at Squarespace is that we had this access control list where only certain people were supposed to have access to certain features and the, probably the right way to build this would be to have a database table and maybe a management UI or some end points that would make it really easy to add, remove people from that list.
But we realized that the list didn’t change that frequently and it didn’t need to be updatable. Within the minute. And it would be a lot faster for us to just have a hard-coded list of IDs and our code base. And if we needed to give someone else access, we would just go and make a new commit and deploy that.
And that was fine for the first two years of the project. And it allowed us to take the time that we would have spent setting up that database table, building that UI. We were able to spend it on things so that we’re more immediately valuable to the project we were working on. And then two years later when updating that hard-coded list got to be a bit of a drag, then somebody could go in and make that list a bit more dynamic.
Christian McCarrick: Sure. Circling back to your sort of time is currency comment. You only have a certain amount of that currency Ika time. So let’s spend it on things that matter to them.
Jon Thornton: Yeah. And I have a really strong philosophy about trying to do the riskiest parts of your project. First, a lot of this. Idea of reordering the thing reordering the way in which you build things is to enable you to tackle your riskiest parts of your project first, because with any project there’s usually going to be some problems that you have to solve that are going to make or break the success of that project.
And you want to figure out how those things are going to go as soon as possible so that you have as much time to deal with any of the consequences of those things. So going back to the hard-coded list example, managing that list was not going to make or break our project. And so building it. Didn’t de-risk what we were building in any way.
But the email editor that we were building was going to make or break our project. And so that was the thing that we wanted to spend time on first, get that problem solved before we move on to the more mundane things.
Christian McCarrick: Yeah. I think that’s definitely a great cause then, you know, a lot of the stuff we do is time on task. Like it’s not complicated, it just takes time. Right. And others are. Right. You don’t know if it’s ever going to work. Right. You don’t know how are you going to solve it. Right. Right. And sometimes you might realize you can solve it and that’s okay, too. Right. Because then you’ve learned a valuable lesson instead of spending months doing the work that was just menial.
Jon Thornton: Exactly. Exactly.
Christian McCarrick: Cool. Now, one of the things you kind of talk about. You’ve brought up some of the items and how you’ve used this at Squarespace. You also talked about a framework for utilizing some of that good technical debt, a little more on one of your blog posts. You talked about a couple of things. And then you talked about specifically about kind of building out and overhauling your email campaign product there. You talked about things like scaffolding, hard coding, edge cases. Can you kind of go into some examples of maybe each of those that make. Kind of good use of this good technical debt.
Jon Thornton: Yeah. So all of these techniques, scaffolding, edged cases, hard coding things, or even building things that aren’t necessarily scalable are all based around the idea of accepting that. Sometimes it’s okay to build something twice and using that to help you reorder the way in which you build things and scaffolding sort of inspired by.
Physical buildings, where sometimes when you’re building a structure, you need to build a temporary structure to support parts of it while you’re constructing the rest of the building. Later on, you’ll take down that scaffolding and maybe replace it with something more permanent. And the software version of that idea is pretty similar.
Where with the email campaigns product, we knew that we’re going to have to be able to send billions of emails, but we didn’t need that capability to test out the email editor that we were building. And we really wanted to build the email editor before we built the sending capabilities, because in a way the sending capability has felt a little bit more like plumbing.
It felt like there was less innovation to solve there. And so we built an incredibly un-scalable email delivery pipeline that allowed us to test and internally dog food, our email editor, and get a headstart on that before we built the real scalable delivery pipeline and big part of that was everyone involved, accepting that we were going to build.
This delivery pipeline twice and making that successful meant bringing along the product and design team and the rest of the stakeholders of the project to say, Hey, look, we’re deliberately doing some throwaway work, but here’s why we think it’s valuable. And even though we have this prototype that can send emails, everybody needs to remember that we still have the work to build the real email pipeline on our timeline.
So don’t forget that that work exists. We have this debt that we have to pay down.
Yep. Now, that brings
Christian McCarrick: up a good question. And I’ve run into this before, too, especially when you’re dealing, maybe with CEOs or VPs of sales or sort of companies like that, and they see something working like it’s hard for them to understand that no, that is a prototype. Suddenly the prototype becomes the product, right? What are some strategies to sort of making sure that that’s very clear that it’s not the case and then getting that support to me is able to go back and like build it the right way.?
Yeah. If it’s a
Jon Thornton: user facing feature. One tactic can be to deliberately build it so that it doesn’t look right and make it really obvious when you’re deliberately using tech debt. That’s a bit harder to do on the backend, but kind of one social tactic we used is that we celebrated the tech debt and, you know, the team kind of took pride in how quickly and sort of slapdash, they built this thing.
And just by socializing it a lot and everybody talking about it that helped us create that awareness that we were still going to have to build the real thing later. Yeah, I think that is pretty good. I’ve never thought about that. Kind of usually a strong visual indicator. Cause usually it’s someone who sales, who gets a whiff of something and it’s like, pre-selling the thing you have right before it’s ready.
But if it looks unready, then, then they might be like, well, we can’t ship that. And if that’s right, that’s the point you can’t ship them. All right. Yeah. It’s important to call out that these techniques really only work on a team that is able to be very deliberate about how the team spends their time and how they schedule things. If it’s a team that is struggling to hit their sprint commitments or struggling to complete projects and the expected amount of time that team often won’t have the trust of their stakeholders to make these kinds of decisions. And so you got to start with a solid founder.
Christian McCarrick: Yup. And I think you hit it very close to that trust. That’s such a big thing, getting that trust between not only your team, but the related teams and the rest of the organization as well.
Jon Thornton: Yeah, absolutely.
Christian McCarrick: Another thing too. And this, this comes up, there are some very dogmatic engineers and everything has to be built the exact perfect way, whatever that happens to be in their head versus cutting corners. Quote unquote, you can’t see me doing that in the air. And how do you, you, as a manager, kind of, what are the conversations you have with individual p eople or teams to sort of, kind of explain what the purpose of what you’re doing and why we’re doing it and why this is actually the good thing for right now?
Jon Thornton: In that conversation with engineers, that trust is again, really important and reassuring the engineering team that they really will have the opportunity to build these things, quote unquote, the right way when it is the right time.
And building that trust takes time and it takes an already good approach to the team’s existing tech debt. And some tactics I’ve used for that are having teams devote 10% of their time or one day out of the two week sprint to just work on tech debt that the engineers want to address. And that also sort of sidesteps a prioritization problem of in the sprint.
Do we prioritize product work or tech debt work? Sure. Instead we sort of just carve off some time for it. Another tactic that we’ve used is scheduling whole sprints to deal with tech deck. If we know that we took out a tech debt mortgage to ship some value to our users, we will put on the timeline, a sprint or two to pay down that debt after we’ve shipped those features.
Christian McCarrick: Yeah, no, that’s definitely good. And do you have any framework from a prioritization standpoint about how you kind of tackle that tech debt. Is it every engineer just picks their favorite one or do you have sort of an ongoing backlog? That’s like, here’s our highest interest at the top and you maybe the lowest ones down to the bottom.
Jon Thornton: It tends to be more, every engineer picks their favorite one, but we will frequently meet. As an engineering team kind of separate from the product and the design team to go through the backlog of technical items and just talk about them and socializing the different ideas of what each person thinks is the most important technical thing to work on is a good way to help the team coordinate and calibrate on what the team actually thinks is the most important thing to work on rather than just like a collection of individuals.
Christian McCarrick: Yeah, that’s cool. I think that’s a good way to do that. Jon. I ask all my guests on the show, any recommendations you have for books or podcasts, either something you’ve read recently, or, you know, some books that sort of changed the way you think about things, anything you might recommend?
Jon Thornton: Yeah, well, I wanted to plug two of my coworkers blogs. Tanya Riley is a principal engineer at Squarespace has a really brilliant blog at noidea.dog. Okay. And Dan Na, another coworker of mine blogs at blog.DanielNa.com. They’re both totally worth checking out. But as for books, a couple of years ago, I read a book called Nonviolent Communication by Marshall Rosenberg and it’s not about management, but I found it.
It really did change the way that not only I communicated with other people, but it helped me better understand my own thoughts, my own feelings and reactions to things which has been super helpful in stressful situations that arise at work.
Christian McCarrick: Yeah, that’s excellent. I think there’s always a theme with a lot of the management books or just books in general that people recommend and a lot of them are not necessarily about management, but I would say there’s a huge cluster around communication. And I think that just shows how important communication is as well. Part of a manager’s and a leader’s job.
Jon Thornton: Yeah. I mean, it is the job if you ask me.
Christian McCarrick: Yeah, absolutely. And Jon, if anyone wants to kind of follow up with you about any of the topics we discussed on the show, what’s the best way for people to reach out to you?
Jon Thornton: JonThornton.com. My website is links to my writing and all my contact info.
Christian McCarrick: Okay. And as usual for all my listeners, All of the things we’ve talked about in the show, I will put on the show notes for simple leadership.io. Well, Jon, appreciate your time. I know we’re all super busy and thank you very much for being on the show.
Jon Thornton: Thanks for having me Christian.
Thank you for listening to this episode of the Simple 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 knew 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. .

Christian McCarrick: This is simple leadership. Welcome.

you’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 it’s simple leadership.io to receive the latest updates from this podcast.

Hi, I’m your host Christian. McCarrick. This is the simple leadership podcast. Welcome back. Good afternoon, Matt. Welcome to the show. Thanks. It’s a pleasure to be here. Yeah. Awesome. And where are you calling in today from him today?

Matt Newkirk:  I’m in San Rafael, California, just North of San Francisco.

Christian McCarrick: Excellent. So we’re kind of not in the same zip code, but they’re pretty close.

Matt Newkirk: Yes.

Christian McCarrick: Awesome. Do you typically work from California at Etsy or is this just sort of, kind of the lockdown period, normal conditions?

Matt Newkirk: I work out of our San Francisco office, which is beautiful. It’s much smaller than our headquarters, but I’ve been living up in Ren for. A couple of years now. And so I tend to work out out of my home some of the time in the office, the rest of the time and have not moved during the pandemic.

Christian McCarrick: Okay. Okay. And like I ask all my guests just to give a little context, Matt. If you could give me a little bit of a, kind of a brief background about your story, how you got to be where you are today.

Matt Newkirk: Sure. So I learned to program when I was a teenager working on a Lord of the rings themed MUD, which is a multi-user dungeon or a Telnet based text game.

And I did that for about 15 years before I figured out how to actually make money off of these skills. And one of my first ventures in software development was as a quality assurance analyst working on some games. And from that piggybacked into an engineering job, working in both tests, automation, and some more like infrastructure operations, kind of all in one work.

And from there, I got an opportunity to be the first quality assurance manager for my company and with my prior QA experience, both through the mud and professionally, I thought, “Oh, sure. Let’s try that.” And so, yeah, before I knew it, I had another engineer on my team, kind of doing what I had been doing and six analysts reporting to me.

And it didn’t take long before I figured out that recording people and empowering people to solve. These bigger problems that I am not skilled to necessarily do was a lot more fun than trying to read, like outdated API documentation and try to put all the puzzle pieces together. They’re awesome. So that led me to Etsy.

That’s funny.

Christian McCarrick: I was just looking at a Twitter thread recently and it kind of showed like API docs. You just jarred my memory. It was like, it’s like, it was one of those learning to draw sort of templates that had like the star. It was like drawing an owl. I had like the circle and then like two eyes. And then suddenly this, like Bob Ross has asked like owl and it’s like API docs versus the final thing.

And it’s just, it’s a big stretch to get there. Yeah. Yeah. One thing. So right now you are, are at Etsy, correct? And what’s your role there?

Matt Newkirk: So I’m a senior engineering manager for our international customer experience group. And so basically my teams cover a lot of ground, but we try to make se an easier site for people to use regardless of where they’re coming from.

So whether they’re working with Etsy outside of English, or they are purchasing things from somebody who doesn’t speak their own language, We try to make it a lot easier for folks to find what they are looking for and then to actually complete that sale. So we do things with localization. We do things with search optimization, machine translation, kind of all of those different things.

Christian McCarrick: Cool. Cool. And yeah. You kind of talked a little bit, how you got into being a manager and this is something I asked because we all have them, right. Any mistakes that are like stand out ones that you can actually still legally talk about, right?

Matt Newkirk: Yeah. Yeah. I think the biggest mistake that I made is probably the largest, like fundamental impact on how I see now, which is when I first started, I spent a lot of time kind of gathering requests and needs.

From my boss about what other people in the company you needed from me and my team. And then I go tell him my reports, like, Hey, this is what everybody needs from us. Let’s figure out a plan. We’ll tell them what the plan is and then we’ll do do it. And that’s it. And I kind of forgot to actually work with any of my peers.

That I was actually serving. So all those products, engineers, product managers, engineering managers, design managers. I didn’t talk to them very much at all. And I also didn’t talk to my bosses bosses to understand kind of how my group’s work was being perceived in a broader context. What we could do to look ahead, basically.

I didn’t do anything that communication, but I didn’t send a great, I can expect. Yeah. Yeah. I can say that you can only fail at that level of communication for so long before somebody makes you stop. Yeah. Yeah. It gets pointed out pretty quickly at that point, right? Yes. Yeah.

Christian McCarrick: So how did that end up with the biggest thing you learned from that?

Matt Newkirk: And the biggest thing I learned is that you can’t grade your own success for the most part. And so, especially if you’re in a support organization, You really have to understand the people you’re supporting, like what do they think of what you’re doing? Are you actually doing the job that you we’re tasked to do?

And the it’s kind of like when you give a presentation, there’s no way to tell if you successfully communicated things, unless you ask people afterwards. Or they actually like took the information that you gave them. And. Yeah. Yeah. So working in a QA organization sure. Trying to improve the quality of our code, improve the efficiency of how quickly we could launch releases.

I found a few poor metrics to try and grade myself, but it was nowhere near as effective as just talking to people and saying like, am I doing what you’re looking for? Yeah. I think that’s definitely a good point that people sometimes do tend to. Okay. They get so focused like far. So the trees, they have a discrete problem.

They look down it’s heads down. Hey, I have this great thing that didn’t solve anybody’s problems for them. Yes. That’s definitely a good point. I’ve made that mistake myself. It’s something, as I work with other managers, they certainly make that mistake as well. So on that note, something I’d like to ask also is what.

Christian McCarrick: Advice or tips that you would give to a new manager today, like they’re, they’re transitioning to, from an IC to a manager, what are some of the most fundamental things that you would recommend that they start to do?

Matt Newkirk: I think the biggest thing is like listening, but I think a more tactical approach to that is meet with people. You have to actually like have meetings with other people where they’re talking in order to really hone that listing skill. And I found, especially joining a new company in a different domain. I didn’t work in an international sector really before this that’s the biggest thing I could do is go out and talk to as many people as possible and talk to them in one off meetings and weekly peer one-on-ones in monthly or quarterly.

And just talking to everybody. Cross-functionally my peers. I found that in my former job, I overly relied on my manager to give me like the full context of everything. And now I find that my manager is like, I don’t know, 10% of the full context that I’m gathering from everybody at every level. And I think you made a good call out there too.

Because that’s something that’s not useful just for new managers, but if you take over a new role in your new company or even a new department, right. That’s great advice for even an existing managers that go into a new role. Right. Talk to people, ask questions, get the context, right? Yeah. That also helps another thing.

I can’t remember who said the quote, it was sort of. Relationships over process or something as well. Right. And those kinds of conversations can help build that when some of the process might be breaking down and you need to still get something done, right?

Christian McCarrick: Yeah, yeah, absolutely. Yep. One of the reasons kind of reached out to you was I had known you had sort of done a talk and written a blog post on parental leave as a manager.

And I think, I remember it was like a one sentence conversation I had in a podcast like a year and a half ago with another, I think father who had kind of come back and I said, that will be a great episode topic. And then I have never really revisited that. Right. I think it’s super important. I am the father of three girls, but I think for me during the birth of my daughters, I was either running my own startup or working at as an executive at more smaller startups.

And I was never really able to take that parental leave. Right. And I feel I missed out a little bit on that experience and not only did I miss out, I also feel I have a gap in helping people plan for taking the leave and then successfully returning from it. So that’s why I’m super excited to have you on the show to have you talk about this topic today.

So tell me about you, your kids. We were able to take parental leave for both just high level, and we can kind of go into some of the details.

Matt Newkirk: I have two children. My son is about four and my daughter is about two and I joined Etsy when my son was seven weeks old.

And so I was actually very fortunate to receive some parental leave from the company, but I. Also felt kind of that tension of I’m just forming these relationships. I don’t know what I’m doing yet. In a professional sense. It feels strange to just disappear for a few months. And so I ended up taking that leap very sporadically and taking a week or two at a time.

And I think that was good bonding time with my son as he got a little bit older, but it was very different because. When I went out, it was like I was taking vacation. And so it’d be like, see everybody, I’ll be back in a couple of weeks. If you need to make a decision, go for it. This is what I would do.

This is what I do care about, but ultimately go for it. And in reality, most of the decisions would, would either be made before that or after that. And so there was very little true delegation that had to happen other than who’s going to run this meeting. Who’s going to send that email very, very like lightweight stuff, which would happen like just normal light when anyone’s once taking a vacation for a week or two.

Anyway. So it was just kind of a series of boats. Yeah, exactly. And then when my daughter was born, I really wanted to, to take the full leaf and. I’m very, very fortunate that Etsy provides six months of leave. And so I wanted to do it for a few reasons. The first was like my wife and I have been working a lot in the lead up to that.

And it felt like kind of an opportunity to just reconnect with my family and kind of disengage from work in a healthy way for awhile. And so that was a big thing. And another thing is like, you still, you look out. Across leaders here and there. And when anybody in any position of leadership takes even a little bit of time.

Yeah. There’s articles, it’s still news. And so I wanted to add at least another data point into that pool and say like, it is possible. There are ways you can do this productively. And so I ended up taking the full six months off, which I think it was really great. I feel like I have a tighter bond with my daughter than I did with my son, because after those first seven weeks, I only saw my son the nights and weekends.

And whereas with my daughter, I was with her every day for six months. Also my being home really empowered my wife to further her career. She’s a partner at her law firm. She was able to go to her partnership meetings instead of sure. Kind of missing out on that. So I especially think that like parental leave has a huge opportunity to influence ones like partner or spouse or whomever and their career trajectory as well.

So I think that was, it was really important to me that I. Take advantage of it and not just leave it on the table, kind of let it atrophy. Like I had my son’s parental leave.

Christian McCarrick: Yeah, no, I think that’s good. And you brought up a point too. It makes news or there’s articles about it, but I think so by taking in more people taking it, it’s also role modeling that it’s okay.

And then if you have the ability, which we’ll talk to him a little bit later and you are lucky enough to have that ability that it would be okay to take it. And it’s not just a paper sort of benefit that no one uses. Right. Like unlimited vacation. Exactly. Which is another thing. So now, I mean, as a father, too, on that topic, did you feel any stigma at all, either inside or outside the company, the community for taking that much?

Matt Newkirk: No. It was interesting. When I went out, there were two managers reporting to me and I looked at it as a way for them both to. Kind of get out from under my shadow in some ways, because also as a manager of managers, it takes time to develop the skills of letting the people reporting to you, like do their own thing, like figuring out their own processes and their own practices and all of that.

And so I wanted to take me out of the equation for a little bit and give them the opportunity to really think about a lot of these things. And they did, they really rose to the occasion and I think had a great six months while I was away. Yeah. And I think that’s a great point, right. That you just made, I think is a great opportunity for other managers too.

This is an opportunity, as you just mentioned. Having people be able to step up a bit, maybe not even a manager, maybe they are wanting to test out being a manager a little bit. Maybe we want to trial it a temporary position. There’s no real like, guarantee that they’re going to stay in it. So if it works out great, if it doesn’t no harm, no foul, hopefully, but yeah, no, that’s a great point you did there.

Yeah. So I think there wasn’t really a stigma. I think the biggest thing, like pre companies that have. Maybe there are windows where there are more planning processes or performance reviews or other things. There were some places that I needed to make some extra plans to either say like, I am fully relinquishing any input into this, or here is all that I can provide in anticipation of these decisions.

Sure, but I didn’t really get any pushback and it was relatively easy to decide to take that six months.

Christian McCarrick: Well, that’s great. And congratulations to Etsy too, for being such a supportive company that does support that even at Facebook. Now we have a really good parental leave for maternal and paternal leave too.

So that’s really good. And I do encourage people to do take that interesting enough for me. I have three employees right now that are currently on leave all at the same time, which does make it a little interesting. But like you said, it does, some people are stepping out. They’re stepping up, they’re backfilling a little bit.

So I think it gives people, allows them to stretch a little more in ways they might not have had the opportunity to do in the past. Right. Yeah. And I think one thing you talk about Matt, especially on your kind of blog sites sort of thing. When you talk about this, you go into pretty good detail of all the steps that you went through kind of as a manager to prepare to go on leave. Maybe if you could kind of go through some of those highlights of those best tips for some of my listeners who might be planning to go on leave.

Matt Newkirk: Yeah, I think at the high level, the first thing is building out plan. And for me, I was managing many different teams with kind of different scenarios.

Yeah. Sometimes it’s easy and you just say, all right, one person, you are going to be my delegate for all things. And sometimes it’s way more complicated and ultimately building out a plan where it’s clear to all of your stakeholders who is going to take on your responsibilities and it’s clear to the, to your delegates.

Yeah, that they are actually going to do those things. I think building that plan out, it takes a bunch of time. It took me probably two or three months to actually iron out all of the details. And you also, I think when you go through that process, you find that you hit a bunch of like, Local Maxima. So first pass is okay.

All the people that I can think of these are, who could actually do this. And then you talk to your department lead and they’re like, Oh, have you thought about this person? I think we’d be in a great position to take this on. And then that passes up and it’s like, Oh, have you thought about this? And it does take a little bit of time to find something that is lower friction.

Little smoother. So I would definitely recommend that folks take the time to figure this out and try and have this done. I would say at least a month out. I know so many folks that have scheduled their time leading up to parental leave and I’ll finish these things three weeks before I go out and their baby comes early.

Christian McCarrick: Yeah, yeah, yeah, exactly. Typically the good thing about parental leave is. For the most part, except for maybe some early than expected deliveries, you pretty much have an idea that it’s coming so you can plan for it. So would you say then maybe two months out might be a good starting point or even earlier?

Matt Newkirk: I would say that around the time you’re comfortable telling your boss. Okay. You’re going to go out is the time to start thinking about it? Yeah. I think those are different conversations. The hello, “I’m going to be going out” and “Hello, this is what I was thinking about for handing off my projects or delegating responsibilities.”

Those should have a firewall between them. But I think that’s not too early. And I think for most of these plans, they don’t really expire. So even if you’re working on this project and it wraps up earlier than you thought, like, that’s fine. Just cross that out and then just don’t sign up for the next big thing that is coming down.

Christian McCarrick: Sure. Kind of interesting conversation part there, but what do you recommend the best way is to tell your manager that like, Hey, I’m going to be gone for six months. I know we have a lot of work on the table and. Were you nervous at all where you’re like, what, what is his response going to be?

Matt Newkirk: I was not very nervous.

And I acknowledged that. Like, I think I have plenty of privilege that makes it a easier situation for me being a white man. It’s a lot easier to say, like, I’m going to go out on parental leave. I think there are some assumptions, whether that I will not be the primary caregiver for my children or. That when I come back to work, everything will be normal, whether it is so it’s certainly not something you want to wait till the last minute to do though, also.

Right. And I would say like for managers, I think your job before that happens is to make sure that your reports trust you enough, that they don’t have to wonder, like what’s going to happen. Am I going to miss out on opportunities? Am I going to. My job, am I going to get reassigned? Am I going to get the side eye for the next six months until I have to go out like as a manager, like your job is to make sure that none of those things are happening.

Christian McCarrick: Yeah, totally. Makes sense. Kind of one of the things you talked about, and during that time was. You also had a plan for kind of coming back, right. So there’s a plan for leaving and then another plan read for coming back. I think you called it reintegration plan something. Right? What are the most things that you kind of had in that plan?

And did you share that with kind of your boss, like before you were back officially and sort of walk me through how that worked a bit.

Matt Newkirk: Yeah. So what I knew was for me in particular, I was coming back to a reorg. And so I had a new boss. I wasn’t really sure like how all of the business units fit together anymore.

And I just knew that it wasn’t my job figure that out yet while I was out, my job was to like change diapers, spend time with my kids and my wife. And that was it. And so. The first thing I did was I contacted my new boss and said like, Hey, I’m thinking about coming back around this time and I’m not gonna really do anything until yeah.

Then I started thinking about how I would actually spend my time. And when I had first started at sea, my boss. Put a book on my desk, which was like the first 90 days. And I didn’t, I got sidetracked with onboarding. I remember very clearly that it was spend the first 30 days, like figuring stuff out and really like listening to people and understanding what perceived problems are.

And don’t worry about acting too much in those first 30 days. The next 30 the days is about like building hypotheses and then. Trying to test those with new data. Then the third 30 days is like acting. Maybe I’m misremembering. If you read the books today, you have a different thing, but that’s what I took away from it.

And that’s what I heard I would do with this returning from parental leave as well. So. I just knew. All right, I’m going to spend the first month having one on ones with everybody in my group. I think there were about 25 people. Or so when I went back, I knew that there were going to be a lot of people around the company that I wanted to check in with and see, like, how has the company changed its mind about all of these different things or hasn’t.

And, and I also knew that for me with two minutes under me and this initiative to care about. Something else was going to come up, but I couldn’t planned for, and didn’t want to plant for playing for other than to say sometime, maybe in the third year, I’ll care about this. And so I wrote that down in a very concise couple of bullet points.

Shared that with my boss. And he was like, yeah, that sounds fine. And so it was a very informal thing. Well, formal thing that I wrote down and shared with him for both, and then I just told him, yeah, everybody else, what I was doing when I came back and said, this is the time that I’m talking to people.

Well, don’t feel afraid to put time. Well, my calendar, because all I’m doing is talking to people. So you’re not going to interrupt my many other things. There are no many other, yeah. Yeah, it’s actually a perfect time. Right? Kind of everything, the avalanche and everything, you get knee deep and everything again, and then sorry to get on the calendar.

Christian McCarrick: Yeah. So you mentioned a couple of things, communication kind of upward and outward and downward seems to be the, I think a theme too, of just good management practice in general and especially during times of transition. Right. So continuing doing that during this. You also, I think mentioned that once you came back, it felt a little bit awkward. I want you to describe that a little bit.

Matt Newkirk: Yeah. I would say that, especially having my first kid, I would say that my and degraded a little bit. And the second one, push that further. To the point that the office I was working out of had also grown somewhat significantly while I was out. And yeah, so there were quite a few people that I just wasn’t sure if I had met them before I had gotten out or not, and I was wrong many times I said, hello, and the people with the wrong name.

And it was very embarrassing, I have to say. And there were a lot of times when I really wasn’t sure like the managers who had been kind of covering for me had done a really great job. It delivered a lot. They built out great plans. They had started executing on them and done. And a lot of things that I had found like self care it’s in like, Oh yeah, the team likes it.

When I do this, the team can rely on me for solving these kinds of problems. And I think, yeah, it was Molly Graham who had the whole like giveaway your Lego thing and. I think that’s the, I can’t remember her exact words, but like eventually you have to give away the things that you’re good at. And then you got other things.

And for me coming back, it was a bit of a mixture. Like in the one hand, some of the things, it was good to let other people keep owning. And then there were other things where at first, so it was like, Oh, everybody’s doing a great job. I don’t need to do this anymore. And then you dig in a little bit more and it’s like, Yeah, savings be great job.

And your contributions are wanted. That’s right. That’s right. And so it really didn’t take very long month or so of getting more than this surface level understanding of how things are to figure out like where you can start to provide value. And. At least for me as a manager, like I get those little dopamine hits every time, somebody like, how do I do this?

Who would you talk to you about this? What kind of solution would you suggest for this problem? Like all of those little things, I think make it a lot clearer, like, Oh, I’m in the right place. I’m providing value to other people. It’s good that I logged on today. Yeah. Yeah. That’s good. I think it’s tough.

Right? When you, at that surface, it’s sort of like the Instagram view of things. So everything looks great. They don’t need me. But like you mentioned it again, you’re like they’re doing it, but the weight of is crushing them a little bit. They’re looking to hand things back and in some cases maybe they have grown and then that frees you up to then work on some other larger things like in the Molly Graham post.

Christian McCarrick: Yeah, exactly. I want to flip it a little bit. And as a manager, especially to some of my listeners. What are the things that you can suggest that they can best help support any employees they have that might be going or coming back from leave? Yeah. So I think the first thing, when somebody tells you like, Hey, I’m going to be going out on leave.

Matt Newkirk: And like you mentioned before, usually ahead of time, it’s the adoption that may not be the case. That may be a tomorrow. Okay. This is happening or today, but whenever it happens, I think just. Your one job there is to make them feel at ease. So congratulations. That’s great news. I hope not. And like put your head in your hands.

Like that’s probably not the right. Correct, exactly like that. How are we going to deal is not the right question at that moment. And so I think just. One letting them know that you’re there for them and to support them with whatever they need to do over the next, probably year of their life and beyond the next thing is figuring out when they’re going to share that information and tell it, they know that you’ll hold onto it until then your company might have some specifics around HR, but usually it’s like an employee should tell HR when they’re going to go on leave and your manager needs to tell them.

And then the next piece after that is. Like we’ll talk over the coming time. Assuming there is time about setting up delegation plans, no time, then that’s your job as the manager, that’s fine. They don’t have to worry about it. And then once they’re out, there is one question which is like, what information do they want from you while they’re out?

So for example, I have sent texts to reports who have been out because they got a raise and I wanted to know if. They just wanted a number or if they wanted a meeting, like happy to do both, I can front load some of those expectations for me. I wanted to know if I was going to go through a reorg. And so I ended up having a very nice but short meeting while I was on leave.

Just to understand a little bit more of the lay of the land. Sure. And then other than no’s expected, communications just kind of leave them alone. And so even if. Something’s on fire. Maybe they would be a great person who can come and solve something. Just leave your company is actually going to fold. It can wait, great opportunity for somebody else to dig in and invest Seagate and solve things.

So as you were saying, just kind of leave them alone. Yeah. So. Unless things are on fire. You really just want to leave them alone unless the company is that actually going to fold because they have the API keys or something. Otherwise it’s a good opportunity for somebody else to dig in gain some domain knowledge, get that leadership experience.

Like this can be a very happy situation for everybody maybe to take an extra few days, but you can play with those trade offs. And so assuming you’ve left them alone. Then eventually they’ll, they’ll be ready to come back. And I would say, as a manager, just be really flexible about their return schedule.

I’ve seen some managers look at things like, okay, so we have this project that is going to be due on this date and we have to start on this date and that we can push that back for this person to come back from leave. They can run that project. And I would say, do not do that instead. I would say. Work with your report to figure out what their return schedule is.

Something that a lot of very smart people like Tara Feener I have mentioned is really having this transitional return schedule. So maybe starting on a Thursday or a Friday, maybe having and have a part time first full week, because part of that is figuring out logistics, like maybe they have a new daycare or, or school or something, and that the household doesn’t necessarily know.

Who they’re in a better position to do drop off or pick up? How do all of these meetings fit in? I know with my family situation, starting with one thing and switching a few minutes later, just because it wasn’t working out. And so flexibility is really key there. And let your report know that they have the ability to tell you.

When they need to come back and it really helps if you can just be extra flexible, even if they’ve used up all of their principal these days or whatever, it just, those few half days, or whatever are not worth. Squabbling over. Yeah. And then from there, I think just like, don’t make any assumptions. I think some folks come back and they already changed person.

They heard sleep deprived. They have no memory. They are just having difficulty making sense of the world. And then there are people not like me. They find it a little bit easier to come back and you really can’t make any assumptions either way. And as I mentioned in my lead dev talk, like it’s helpful to not make any assumptive comments like.

Okay. You had a great time or you must be so exhausted. And I made the mistake not long ago enough wishing somebody just like huge congratulations for going out on parental leave. And they were like, Oh yeah, actually it’s the longer story. And I immediately felt that’s kind of regret and realized like I should not be making any assumptions.

Christian McCarrick: That’s a good point.

Matt Newkirk: Yeah. And then I think the rest of it is the stuff that you see in regular management training programs, don’t reduce opportunity for people coming back, be flexible, especially if they need to get drop off their kids, pick them up to use nursing rooms or anything like that. Just flexibility is really the name of the game and just kind of work with your report.

Christian McCarrick: Yeah. Yeah. That’s definitely good. And I think one thing I want to point out too, that. It depends a little bit. There’s some federal laws in States. Well, I was on top of it, but parental leave typically also isn’t you don’t ask your manager for it, right? It’s a given, uh, and it’s an informing thing. So as a manager, you can say, Oh no.

Matt Newkirk: And that’s why in a lot of companies too, that parental leave works strictly with HR and not with the manager, just because it’s the manager, except for some day to day logistics and how we’re going to make it work is out of the loop. Like there’s no approval, there’s none of that sort of stuff. Right.

Christian McCarrick: Absolutely. Yeah. Something else I want to talk at here is COVID, it’s sort of something we can’t ignore. It’s super challenging working from home and then working from home independently and kids and trying to like school. I know my kids start school tomorrow and I’m still not really sure how that’s gonna work.

So as a manager, how would you best support employees who are parents in this current time?

Matt Newkirk: Yeah, it’s really, I think that manager discretion can go a fairly long way and just saying, I’ve told my folks like, take it anytime you need, you don’t need my approval. Go for it. You already have it. Do what you need to do, let people know.

But otherwise, and I would say this goes for non-parents as well. I think. A lot of people have, are feeling the impact of this very long shelter in place. But I think for parents, the other thing that companies can do is provide more explicit guidance, listened to like Laura Hogan and. She’s very fine with like biceps or the scarf model, which are effectively the same thing.

And I think certainty is a really key fear in both of those. And especially now, when it’s not clear, how am I going to do? What’s expected of me while also providing distance learning for my children who might be in the same room as me right now, and making a lot of noise and tearing up my papers.

Hypothetically, of course. Yeah. I think in all of those circumstances like that uncertainty is the biggest detriment to folks feeling of safety, no matter what a manager can say. Sure. So I think like trying to. Be certain about these things. Like one thing that I found to be valuable is saying like, we’re all going to take a team mental health day off, and nobody has to feel special and taking a mental health day off.

Everybody needs mental health days off. Yep. Yup. And when we do it together, there’s no sense of missing out or like that person is moving ahead and I have to catch up with them or when it comes time for performance reviews, if that person is there and I’m not like, how is that going to be balanced out?

And I think these are all things that I’m seeing across the industry. People are trying to figure out how to provide more certainty. And I don’t know if it’s fully there yet, but I think at least as a manager, understanding when that certainty doesn’t exist yet that your people need much more support from you as explicitly as possible.

And I’ve learned from a lot of. Great leaders lately that having strong written communication is key. And then following it up on the ground is even more so, and I liked the written communication a little bit more because it’s written down, it’s a commitment and you can refer back to it. It feels like more of a compact then like Christian, I support you.

But no. Where is it written down? Like, no, here’s the paper. Right? Bring the receipts. Right. I want to flip that a sec too. And you’re an engineering leader with kids now, as you just mentioned in this time, you’re expected to have some more answers. You’re expected to have some more support, but MIMO, I know a lot of.

Christian McCarrick: Other engineering leaders are also sort of struggling themselves with certainty and where do they get their support from? So any tips you have as a parent leader yeah. And hear how you’re going through this and how you’re kind of dealing with it.

Matt Newkirk: Yeah, I would say like early on in March, I guess I ended up having to work a split shift.

So I would do meetings from about seven ish till noonish. And then my wife would then do her focus day and then the kids are good or bad around seven or eight. And then we would end up doing more work in the evening and it was not. Great.

I would say I’m very fortunate right now that our kids are getting enough, that they are going to daycare and not to other school. And right now, which I feel like is on a minute by minute, day by day thing. But right now our daycare is open. It feels like they’re doing things that are reducing the risk profile enough that.

We are somewhat guilty sending them, but as a results, now I have a more open day say that while I was working on that really reduced schedule, what I felt like I had to do was put myself out there more with the teams to be more visible Slack and meetings. There were entire sets of meetings that I couldn’t attend just because were during my non focused time.

And so. There are gaps. And this kind of goes back to that parental leave document, but you have to delegate something. And in my case, it means delegating technical decisions to other engineering leaders in our group, or kind of making concerns or constraints known so that other people can make good decisions.

Ultimately, I think it boils down to over-communication and really trying to repeat and reiterate. So, you know, Sending an email is good, but if you’re like me, you have no memory of it. What email you read yesterday? So you have to follow that up with Slack messages. And if it’s something that’s really crucial, you need to follow it up again in case you missed it, or like, let’s just revisit this thing because I don’t have any longterm memory anymore.

And even. Today, I knew you were going to ask me about my background and I had to really think about it in a way that I could put it together into a package thought, because I had to look at LinkedIn to figure out how long I’ve been managing. Yeah. Kids do do that. Yeah. I have a former employee that says Christian, you forget things sometimes.

So I was like, well, yeah, thanks. Appreciate that. He’s like, no, no, no, that wasn’t it. Bad thing. It was just, but you write things down, so you compensate. So it’s good. I was like, okay, thank you. I guess. So one thing I do want to point out as we kind of come to the, to the wrap of the show a little bit, that we are having this conversation, but you mentioned it briefly in the beginning, we’re able to have this conversation too, because we have a sort of privilege and we both worked for companies.

Our backgrounds afforded us a privilege to be able to take parental leave. And that is not always the case or available to lots of people for lots of reasons. So, I mean, I’m really glad we’re having this conversation, but I do want to point out that this is not something that is afforded to everybody and we should make sure that we can do the best that we can to bring this opportunity to more people.

Whether it’s in different companies or socioeconomic classes. I think it’s super important as a thing that we can do to try to support those more broadly. Absolutely. Yeah. And I think that is, I made a joking comment about how, when somebody, when a male leader especially takes parental leave it’s news, I think the more we can do to normalize that and make it so that this is one of those benefits alongside vacation or sick days or health insurance, and really normalize that, especially in places where.

State laws don’t provide these sorts of guidance. Before I came to Etsy, I was looking at six weeks of parental leave. And even that I did not know how I was going to make that work logistically in my last job for

Christian McCarrick: yeah, no, that’s great. And as we kinda wrap up one other thing, I want to ask you what to ask my guests to any favorite books, podcasts, anything that you’ve read a long time ago that stayed with you, or just something you read this week, which is according to you is all you can remember these days.

Matt Newkirk: So yeah, there were like three things that I recommend. One is five dysfunctions of a team really changed for me and understanding of like the value of understanding different business functions in your company and how your work directly impacts their work and there’s yours. And also just asking the question, like, do they even know that I exist? And if not, like let’s change that. Another was a lead developer talk that Lara Hogan and deepest you remaining cave. In New York in 2018 called revitalizing across functional product organization, it’s become the talks that I recommend that any new engineering manager or any engineering manager, joining a new company and recommending it to their people manager partner as well in really building out a partnership so that you’re fully aligned on message so that you don’t sit in a room with your reports and your partner and your partner is surprising.

All of you. Or you were surprising everybody else either. You can make sure that the number of surprises is very minimized. Sure. Yeah. I recommend that one too. So, yeah. And then I think the last thing is I follow a very broad group of people smarter than me on Twitter. So like a handful of people that I’d recommend, or like Michael Harriot, Alice goldfyss, Ann Hjortshøj, and pie bob AKA, Rachel Perkins. If you just followed those four people, you would find like a very informative feed of news events, whether in tech or in the world. And it’s definitely changed my perspective and I think positive way.

Christian McCarrick: Awesome. And like usual for listeners of the show. If you go to simple leadership.io, we will try to put as many of those links as possible. So you can just kind of click through to them. Matt. Is there any best way if someone kind of wants to take up this topic with you and talk in more detail about it, what’s the best way to kind of get to talk to you or catch up with you?

Matt Newkirk: Sure. I’m pretty active on Twitter at M Newkirk and I respond to almost every non sales pitch on LinkedIn. So feel free to reach out if you send a message, I will likely respond.

Christian McCarrick: Okay. Well perfect. Hey, Matt really enjoyed the conversation today. I thought it was timely. It was helpful and very informative. So thank you very much for your time and your on the job expertise in this area.

Matt Newkirk: Thank you. It was a delight to think back to my friends over here. One more time.

Christian McCarrick: All right. Great. Have a great day.

Matt Newkirk: Thanks you too.

Christian McCarrick: Thank you for listening to this episode of the Simple Leadership podcast, hosted by me, Christian McCarrick. If you have enjoyed the show, please subscribe and no forget to leave a review on iTunes, full show notes and additional information can be found on simple leadership.io.

If you knew 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 is I interviewed more top software engineering leaders. .

 

 

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.

Christian McCarrick
This is simple leadership. Welcome. Thank you to our sponsor, Auth0 for helping make the internet a safer place by offering identity as a service and supporting this podcast.

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 and leadership challenges and best practices specific to Software Engineering and Technology teams. Do you want more engineering management leadership tactics and information? Subscribe at simple leadership.io to receive the latest updates from this podcast. Hi, I’m your host Cristian McCarrick. This is the simple leadership podcast. Welcome back. Today’s guest is Emad Georgy. Emad is the founder and CTO of Georgey Technology Leadership. He’s an expert in execution of technology product development, digital transformation and leadership development for all levels of IT staff from coders to CTOs. His hybrid approach to technology management—focusing on both the practical and cultural elements of leadership—makes Emad a trusted and valued partner helping with domestic startups and global enterprises scale and grow. He is proficient in talent assessment, tangible leadership and organizational development, as well as data engineering and analytics pipelines, modernizing legacy applications, re-architecture, cloud migrations, DevOps and API integrations. Named a Computer World Premiere 100 IT leader, Emad is developing tomorrow’s industry leaders. On today’s show, we talked about leadership debt and the steps you can take to grow and mature as a technology leader. We also discuss leading in times of crisis. Good morning, Emad. Welcome to the show.

Emad Georgy
Good morning. How you doing?

Christian McCarrick
I’m doing well—as well as can be in some of the times that we’re facing right now. How’s everything going with you?

Emad Georgy
Yeah, these are very fluid times to say the least. But keeping it in perspective. Doing okay.

Christian McCarrick
Absolutely. And where are you calling in from today Emad?

Emad Georgy
I’m in Los Angeles, California.

Christian McCarrick
Okay. And I’m presuming from home since most people in California tend to be at home these days. Right.

Emad Georgy
We have been on lockdown for quite some time. Yes, even our beaches are closed. Everything’s closed, even the walkways along the beach are close. So yes, everyone’s wrong.

Christian McCarrick
Okay. All right. Now one of the things too, Emad, I that I asked all of my guests, if you could just spend a couple of minutes kind of giving you a little bit of your background, a little bit of the story of kind of how you got to be where you are today?

Emad Georgy
Yeah, I’ve been in technology now for over 25 years, I’ve been coding since I was a kid since I was 11 years old. You know, I’m the son of an immigrant family, we didn’t have very much growing up and they bought me a beat-up old computer. And I came out of my room after a week of fiddling with it, coding my first game. And I’ve been working in technology ever since. So it’s been a winding career path, as I’m sure many people have. But I’ve been coding and then became a CTO at a number of brands, as well as a few startups. So I’ve done the startup thing from zero to the big, huge bureaucratic companies and you know, how do you still figure out how to execute from there. So, now I run my own consulting firm. So I’ve been doing that for the last few years where I help clients grow and scale, both from a technical perspective, but also from a people perspective, like how do we move leaders in the right way. And that truly is my personal passion as well as growing better leaders. So I’m excited to be a part of this today.

Christian McCarrick
Excellent. And we share that passion, hence, this labor of love that I do this this podcast that I have. And, you know, you brought me back a little bit. I’m not gonna say my age, but, you know, I think the first computer game I ever programmed, I think (I didn’t do it myself. I copied it out of a book. Right?) like, yeah, you know, character by character, talking about debugging that when you know, you make a step on, like, 1000 line thing.

Emad Georgy
It’s all learning though, right? So…

Christian McCarrick
That’s right. That’s right. You know, another thing I kind of ask is…any mistakes that you have that stand out that you have made as a leader, that any parables or anything that my listeners might be able to take some advice from, and also to show that, you know, none of us is infallible. We all make mistakes, anything that stands out to you that you could share?

Emad Georgy
Here, I thought right up to this point that I was infallible, but now you gotta ask me this question. You know, geez, I’ll tell you like I make mistakes every day. I mean, you’re leading you’re making mistakes every day. I don’t know that I can think of a major mistake, but I’ll tell you that a lot of the mistakes that I can think of right now, are associated with, believe it or not letting people go. Okay, as a first time manager, I think every person that I fired, I should have fired several months prior. And as harsh as that sounds, you got to think about as a leader, what impact that’s having on the rest of your team. The jobs that are impacted by having a toxic personality in the team in the mix. Of course, I believe in giving people every chance possible to … and work as hard as possible and coach them through that. But at the end of the day, you got to make that decision. You know, accountability is a morale booster. And I learned also at the same time as you might be doing that person a service. You know, maybe that’s the wake up call that they actually need in their career. So If I think of mistakes, it really has to do with, you know, executing on those decisions sooner than later, rather than experiencing the impact that it had on the team. While I was trying to, you know, I don’t know, satisfy everybody, or people please or toe the line or whatever it might be.

Christian McCarrick
That’s right. And you do make a good point, because I think a lot of managers don’t understand that, especially if you’re managing other high performers on your team, that they are going to look to you as a manager to help with a situation and they’re going to feel like they’re, you know, not being able to perform like they do. They might have to be, you know, backfilling or whatnot. So I think as a manager, that’s that’s a very good point. And most of the times, I’ve found in my career, if you feel like you should do something, it’s probably past the point of having to do it. And yes, I think you’re absolutely right.

Emad Georgy
I think it’s also a test of your values as a leader. Like your team looking to you and you’re talking about all these values that you’re supposed to espouse as a team, and now it comes time to put into action and you don’t put into action. What kind of messages are sent to your high performers? Yep. So you know, everything’s on the line. But that’s definitely a thing that I look back on.

Christian McCarrick
Excellent. And, you know, something else that I tried to get some advice for, for new managers this specific question, anything that you would coach or guide any new managers becoming from an IC to a manager for the first time that you would say, what’s kind of one of the most important things that they should focus on or tip for them?

Emad Georgy
Yeah, I think that’s a great question. I do end up working with a lot of new managers. And you know, it happens in all sorts of different ways, right? Sometimes you just promoted because you’re the next guy up, or maybe you’re the most competent voice in the room or the most technical voice in the room. And all of a sudden, you know, coding is so black and white. It either works or it doesn’t. And now we’re in the face of gray matter. Like, what is that? What are we doing with this? I think there’s lots of advice, but I think the first thing I would say is really continue to be an engineer. I think not a lot of people say that. They say, “Oh, this is a different world. You gotta adopt different skills.” and all that’s true, but we really got to hang on to being engineers. And by that, I mean, you got to dig in. When there’s an issue in the code, we dig in, we understand the root cause. We take the time to troubleshoot and debug, you got to do the same thing with people in leadership. Right? What happens is if you don’t have that mentality, you get lost in the rush of meetings. And before you know it, everything is second hand knowledge. And my recommendation would be have the discipline to dig in, you know, trust but verify things from firsthand experience and continue to operate from that engineer mentality in that way.

Christian McCarrick
I like that someone else I was talking to recently had another analogy, which is very similar to that vein, is sort of like how people and engineers do stack tracing on code. Well, sometimes I do a stack trace on the problem, like you said, let’s think about it that way. And using those analogies. Yeah, that’s a great point. That’s a great point. You know, I do want to focus some of the next part of the show here. Diving into a content concept called leadership debt that you have previously spoken about. Right? I think most of my listeners are familiar with tech debt. But can you define what you mean by leadership debt?

Emad Georgy
Yeah. So, you know, I sort of thought of this term, because as technologists, we’re always talking about technical debt. Right. And we could go on and on about that, that that could be a whole nother show altogether. But it’s gotten to the point where now it’s like, it’s actually conversation at the boardroom level where most of the people in the room don’t even understand what that is. Yeah, it’s in that same vein, we just talked about, about digging in, understanding root cause. So over the years, you know, as I dug into issues, problems, on the technical side, it all comes down to something in leadership, you know, “Oh, we had that one manager years ago that made a bunch of bad decisions. And this is why we have all this technical debt on the code”, right? Or “he over-architected this”, or “she did this” or whatever it is. Or it can be even well intentioned, it could be a manager just, they’re doing the best with what they have and just didn’t have experience for the role. Or it could be a CEO who doesn’t understand the impact that his or her decisions are having on technology. So it felt like you know, it’s like six degrees of separation. It’s like everything led back to something in leadership, which came back to the passion that I have—the passion you have—around… Now, if we really want to solve the root cause of technical debt, let’s start talking about leadership debt. You have, I think, a huge vacuum of really understanding what good leadership is in society in general, but it’s…technology. That’s where I sort of came up with the term is, “Hey, let’s start talking about leadership debt. Let’s start talking about the hidden cost the rising debt that accumulates over time, based on decisions”. Like you don’t rewrite an application, or you don’t wake up one day and said, We got to rewrite our whole platform over you know, one decision, it’s all little decisions that occur over sometimes a number of years, right? That’s leading to death that’s accumulating and so I think I think it’s our responsibility as technologists to bring that to the surface, make it transparent, hold those decisions up and go, “Are we making decisions that enable the durability of the company and/or architecture?”.

Christian McCarrick
Sure. And, you know, the news and over the last couple of years to I think it’s really played out some of the downsides are the impact of having that leadership debt, whether it’s some of the things that Uber or some of the other companies that I call, you know, behaving badly, and, and it just the downstream effects of that are tremendous.

Emad Georgy
And it’s much like technical debt, Christian, where it’s like, you know, when you start to see the effects of it, it’s too late. It’s like mold in your house. When you start to see mold, it’s over, you got a real project on your hands. So, you know, it’s very, very similar.

Christian McCarrick
Okay. And you have identified a number of traits, I think that you’ve called out that it’s important for technical leaders to possess, right. And I want to kind of go over some of these in the show and, and maybe as we go over each of the ones if you could provide a little guidance and tips for my listners on 1) why they think that why you believe that’s important and 2) how they could potentially, you know, work on or approve or get an opportunity to build upon some of those things. Right? And I think the first one you mentioned is, is the concept of ownership. So let’s dive into that one a little bit. What does that mean? How do people get that experience?

Emad Georgy
Yeah. So excited to talk to you about this. Because one thing our industry lacks to the standard, like, what does it mean to be a good technology leader. So I’ve put these things in place. And this is sort of what I coach against, you know, that first values ownership, so it just starts there. And what I mean by that is really, the leader must have a collective sense of responsibility, not just about his or her actions, but about the actions of their team, and the organization. You know, how many teams are we a part of where there’s finger pointing? Every team? Right? You know, we have this like, we bought into this myth that if I can only find the person to blame, we’re done. But guess what? The problem is still there. Now you just pissed off more people. That’s all. Right? So I think it starts with ownership. And by that I mean, you know, we need to engender a culture and also lead by example, as leaders to be problem solvers. Not problem reporters. So, I mean, I know how hard the job is, I mean, let’s, let’s talk about that. But what are we gonna do about it? Right, at the end of the day, we’re engineers, that’s what we do. We solve problems. You know, the analogy, I like to use them a big basketball fan is like, you don’t get the luxury to be a fan in the stance and go, “I can’t believe that shot Emad took”, like, “What is he doing out there?”. You know, at the end of the day, we’re all on the court. So if we miss, then it’s all on us to go and figure out what to do about it. And it really doesn’t matter who is to blame. You know, what matters is how did we get here? And how are we going to solve that at the root cause level. So I think the first tip around ownership is role model it yourself. Something goes down, something goes wrong, you step up and take the ownership for it. Don’t go find someone on your team to blame. Do that privately with that person, right? But role model that yourself, get out of the ambiguous, right, you know, start to change the ratio of time that the team is spending on complaining, and on bitching and moaning. And you know, I always say like, as an example, you know, people always talk about culture, right? What is your culture? Nobody knows what culture is, right? At the end of the day culture is just the stories that you tell every day. So if you spend all day bitching and moaning? Well, that’s your culture. That’s your contribution to your culture. So you want to shift the ratio of time that you’re spending and your team is spending to problem solving. And your contribution to culture, right, growing people and coaching them and you know, contributing positively to the culture every single day. So, to me, those are some of the points of the prism of what it means to have ownership as a leader.

Christian McCarrick
And as you mentioned, taking being the role model because if you’re doing that then that trickles down, people are going to see that that’s what you do. They’re going to take ownership because they see you taking ownership.

Emad Georgy
Absolutely. Yes, that’s right. Yeah.

Christian McCarrick
And ownership too, I think is important. Because a lot of times, it’s that wasted time between knowing something’s wrong, either trying to cover it up or trying to find someone else to blame, versus solving the problem that could be days to weeks or months, even. Where if someone just said, “Hey, here’s an issue”, you know, “I messed up”, or “I did this”, it doesn’t matter. Okay, let’s focus on solving that. That company is probably going to be about high performing and quicker to market or whatever you gonna do then another one.

Emad Georgy
And guess what, you’re gonna retain your people longer. That’s right. As techies, we’re part of companies to solve problems and engaging in challenges—not to complain every day. Right?

Christian McCarrick
That’s right. And I think the next one touches upon something you mentioned just earlier in our conversation about an engineering mindset. And you talk about when going to become the manager, keep being an engineer. So what does that mean as it relates to being a first Manager, being director, being a VP, being a CTO. How does that engineering mindset help you as an engineering leader?

Emad Georgy
Yeah. So I think that there’s I’m going to tell you the antithesis of that first, and then we’ll get into it. The antithesis of it is what I call management by assumption. And this happens in startups and in huge companies as well. No, I’m a first time manager, I’m a CTO, I just don’t have time. All this new responsibilities come on me. I’m getting pulled in 1000 different directions. And if my head a keyway, or at a DevOps tells me that this is a problem, I’m going to go with it. Right. And the issue there is that over time, all your knowledge starts to become secondhand. And it’s management by assumption, or by PowerPoint. I used to say on some of my teams, I said, “I don’t want any PowerPoint monkeys”. I want engineers. Right? So don’t Don’t show me a slide. Go prove it. All right. So I think the discipline that’s needed here is we don’t stop ever being engineers. That’s the principle as leaders. In fact, it’s more so needed, because we have leaders that maybe are not technical come from a business background that we’re working with, that are plagued by the same thing. Management by some. Yeah. Right. But we bring a unique perspective to the table. Because we have been engineers, we know how to dig into root causes we have been doing that for years, right? Right. So we bring a gift to that leadership table. And we’ve got to use it, not give it up. And so we got to build some systems to trust but verify. I’ll give you one example. I was CTO at a large enterprise brand. I had close to 1000 people under me when I started, I had these direct reports that were VPs and directors and they all have their PowerPoints ready to go, you know, and I, as the CTO started to dig into people’s code. Just every now and then. It didn’t take all my day. Everyone under me was saying they didn’t have time. I just did a couple trust but verify things. And so we can start to see like, when your boss, your CTO does that you have no excuse? Right? You’ve got to dig in. And by the way, it shows people that you care. So there’s that as well. And you’ve got to develop some mechanisms to help you with that. Because it’s not a scalable thing from a time perspective. So, metrics I think, play a big role. You know, I always say metrics are my love language. Like, okay, so what metrics are at least showing me the reality of what’s going on? I use them as a guideline, how do I operationalize them? How do I use them in my one on ones with my team? Hey, guys, this seems to be below average today. What’s going on? Let’s talk through that. It helps cut through the opinions. Last thing I’ll say real quick is one of the principles I have is when it’s just the tech team in the room. No opinions are allowed. And what I mean by that is, if you have something to bring to the table, you better have proven it somehow. Did you try it out? We’re not here to debate articles and things that you read. That’s conversation for you know, at lunch or after work or whatever it might be. Bring new ideas to the table, but you better know. Or if you come table and say, “You know what, I found the root cause. it was a QA issue”. You better be able to prove it to me on the screen right then and there. Where did you find that? Can you show it? Can you prove it? So that’s the standard, we got to hold each other on. And as a leader, you hold yourself to that same standard. So when you present to the team, you show them your work, you show them hey, I’m not afraid to show you that I dug into this.

Christian McCarrick
A theme I keep hearing too is about that. You know, lead by example. And role model the behaviors you want your teams to actually exhibit as well.

Emad Georgy
Yes. I always say I never expect from my team something that I would not do.

Christian McCarrick
Yeah. Great principle. Yeah. As we move on, maybe from the engineering side, to kind of the next point you make is around having a deliberate people strategy. Now I think some people like Well, of course, I’m a manager, but but you’ve specifically put the word there deliberate. Yeah, right. And So let’s dive into that a little bit.

Emad Georgy
Yeah, nobody’s career or leadership growth by accident. You know, everyone says “People are my priority. People are my priority.”. I had a mentor many years ago, my first management job. And I said the same thing. I’m like, “Of course, I’m a people leader”. I’m the people guy. Look at me”, you know. And he had me do an exercise where I took inventory of my time, just for a week, right. And I found that I was spending less than 20% of my time on people. So what’s in your mind sometimes is not what’s actually happening. I think that’s what I mean about deliberate is, we need to apply a very tangible growth path to our team. What do you see your team being in the year? What types of things do you are you gonna do for the company and for the architectur? By individual, what do you expect out of each individual? Do you have a career path that you’re managing against it? Do you do your one on ones and then check in on that career path every once a month? Right? It’s accountability on those teams. Accountability, I believe is a huge morale booster, right. So I think the biggest metric of success for me as a leader is, am I growing? The leaders around me? Have they grown since I’ve known them? So, you know, by deliberate, that’s what I mean, it’s not checking the boxes of, let’s just do what HR is asking us to do. Right? But how are we advancing people, both from a technical perspective, but also from their EQ as well.

Christian McCarrick
Mm hmm. And you mentioned before previously, that these things not only help to build high performing teams, but they help with your retention. Because if your directs and the rest of the company sees the effort you’re putting towards them and that you care, like you give a shit and you want them to succeed, that engenders loyalty, and, you know, better productivity and increased morale and all those other things.

Emad Georgy
That’s right. That’s right. And it builds trust, you know, I mean, yeah, you got to do the work to build trust. One leader I was coaching a while back who talked about his team in the third person. So he wasn’t part of the team. And I was like, Well, wait a minute. Wait, no, no, no, “You are part of them. You are part of the issue”. So, you’ve got to start there. And like you said earlier, like, if you can role model it, that’s where it starts. I’ll give you one more example. You know…every one of my engagements and before I started my consulting practice when I was a CTO, no matter how big the job was, my first two weeks, my first month, were primarily focused on having a one-on-one with every single person on my team. I cannot tell you how much people appreciate that. I mean, to me, when I first started doing it, it was like, “Oh, I spent 15 minutes with you”, but people want their voice to be heard. They want to know that they’re working on relevant things, and just the gesture of taking the time shows deliberation. Right. And that just spoke volumes. I mean, it kind of surprised me when I first started doing it, how much it meant to people that that’s how I started, you know, every project,

Christian McCarrick
You know, a little anecdote: I was interviewing a while back for a leadership job and to be unnamed company, kind of a larger company. And I remember during the interview process I was interviewing well, my team, my potential future team was interviewing me. But when you talk about, you know, starved for attention, I think it was basically time for those people (who I don’t think had a manager for months at that point or had a manager that wasn’t talking to them). It was like a therapy session. It’s like, “Wow, this team, this team needs some help”, because no one had been talking to them. And I was the first person that listened, as you mentioned, in months, and it just was such a good experience for them. I didn’t take that job. But, still, it was very interesting anecdotally to be like, “Wow, there’s a problem here”.

Emad Georgy
Yeah. I mean, I think it’s a core human need, right to have your voice to be heard and to be seen and to be understood. So yeah, I’m not surprised to hear that.

Christian McCarrick
Now, your next point that you make, and I really like this one—It’s embrace problems. I could go on to this one a little bit for a while. But tell me a little bit about what you specifically mean by embrace problems here as a tech leader as a CTO?

Emad Georgy
Yeah, I think sometimes we get wrapped up and “Oh my god, all these problems” like s%*t, like you know, go into…today and “Here we go again”. And guess what? That’s why you’re there.

Christian McCarrick
That’s your job.

Emad Georgy
Like, what is it that you want? Like, if there were no problems, you wouldn’t have a job, you wouldn’t have a job. Period. Right? Especially as engineers. So, you know, the perspective I take is, that’s part of our core purpose. Like, let’s embrace it. Let’s face these problems as things that, you know, there are opportunities for us to grow to do something of impact to the company. I especially love problems that people have given up on like, “Oh, that’s just the way it’s always been”. I’m like, “Okay, well, let’s do something about that”. Right. You have to have a hunger to understand root cause of problems. So it’s not just solving the problem. So first, embrace it, right? Great. But then you have people who do embrace it, but then only solve the symptoms of a problem like just enough to get by. You’ve got to go deeper, especially as a leader, you got to understand the root cause because then when you solve it, the root cause you’re actually helping the company grow. And you’re helping the technology grow from a durable standpoint. And so every problem you solve or your team solves, you’re maturing the company and you’re maturing the team. If you just solve symptoms, they’re gonna come back and you’re not really engineering it. So, yeah, I believe, like, you know, you got to eat problems for breakfast, like, I love them. Well, that’s what I’m here for. I’m excited. Let’s go do this.

Christian McCarrick
And you mentioned basketball before, too. It’s sort of like, you know, if there’s a player and they can’t shoot free throws, well, they’re not going to ignore that. They’re gonna double down and try to fix that. Right. Yeah, I want to add one other thing to this too, because if I add a qualifier to it in—appraise problems as early as possible. Yeah. And it goes back to I think what you mentioned first, about letting people go, potentially waiting too long. I think the longer you wait to embrace a problem, actually, the harder the unnecessarily harder it’s going to be to solve.

Emad Georgy
Oh, yeah. And I’ve seen people also just with harder technical problems, you know, look at the end of the sprint, or maybe the last sprint in a release. It’s like “Well, no, no, let’s let’s go attack that right now. Because we might find that a whole host of other things that we’ve gotta focus on”. So you’re absolutely right there.

Christian McCarrick
Mm hmm. When your energy is actually at the highest to and you can de-risk that by doing other things like you mentioned. Yeah, absolutely. This next one, I think is super important. And I think sometimes tech leaders, well, maybe not so much tech leaders, but ICs, other people lose focus of the customer. And, you know, that’s why we’re in business, right. So a little bit, how can leaders really help to improve their customer focus? How can they help bring that to their teams? What are some tips that you recommend?

Emad Georgy
Yeah, this is a great one. I love this one. You know, everyone talks about customer focus but it’s really hard to make it real on the tech team. So the number one thing is more of a philosophy, which is, you know, what does it really mean to be agile? like I always say, everyone says they’re agile, but it’s bullshit. At the end of the day, one of the core principles of “Agile” is I deliver customer value every day. Yeah. Right. So, you know, you walk away from your day and you look back and go, “Well, I attended 80 meetings, not sure what I did”. So you really, as a leader have got to drive that. And I think there’s really pragmatic ways to do it. And one is that you got to increase the number of touchpoints and feedback loops to your customer, between your customers and your team. It could be your direct customer, it could be people who are on the front lines with customers, and building those relationships. Oftentimes, those relationships are contentious between those folks in the technology team. It’s when you have several layers in between. So cut through that, you know, I believe in bringing customers in as much as is appropriate, of course, bring the customer into your next roadmap planning session, have them talk about the impact of the last release that it had on their business, right? Bridge that gap and start talking through that like some of the roadmap planning sessions. I do with teams. Where, instead of the product owner talking about what the priorities are bringing in a stakeholder, or even the customer to talk about, why is this important? All of a sudden, when developers are breaking down tasks, they’re not fulfilling the task for the story. They’re thinking about the spirit behind it. They’re thinking about the use case. They’re thinking about the business case that they heard they think about their contributions to the company’s growth. So that’s, that’s definitely one way. I also, there’s all sorts of touch points you can develop, like, I’ve done like user groups between QA and customers, help us help us test, right? So you’re teaching QA how customers use the product. So again, that goes back to QA’s job is not to just test the story it’s to test the customer experience. Right. So there’s, I think, a number of ways where you can bring that in. Also, I think, consistently streaming in good news about the impact that releases are having out in the market, back to your team directly as directly as possible is very important.

Christian McCarrick
You know, on the opposite side of good news, as a leader, you’re going to have to do customer apology calls at times if you have a bug, an outage, an issue, and some of those can be pretty unpleasant. And I recently recorded one, and had my team watch it afterwards. You know, I needed to have them have that empathy of not that I wanted to share the pain, like my pain, but I wanted to share with how something we did impacted the customer and how it affected them in a negative way. And I think it was really it was important to help the empathy cycle between engineers, which sometimes can get distant to the actual users. And that’s again, that’s why we’re in business or providing value to them.

Emad Georgy
That’s exactly, yeah, you just triggered like one of the principles that I have that I learned over time was: you always want your customer to react some way to your software. hate or love. Right? If they love it great. If they hate it, it means they want it to work. They care, you know, so I had been on a number of apology tours. I fully understand your pain. But the worst thing you can get from a customer is apathy. Yeah, that’s what you don’t want. So, you know, I used to, you know, when I first became a manager, I tried to avoid those apology calls, you know, not until I had the perfect solution, and I could report it. But actually, what I learned is they want to talk about it, and they want to know that you’re on it, even to just recognize it and say, “Look, I don’t, I don’t have a solution right now. But I’m here. I’m not avoiding it. We’re talking. You’re important to me.”. That means the world to them. That’s all good stuff, ultimately, right? Yes, they care. And they want it to work. And that’s a critical part of the business.

Christian McCarrick
Absolutely. And kind of moving on to the last point you have about great CTOs. You see a good trade of them is really being processed ninjas. Well, let’s go into that a little bit.

Emad Georgy
Yes. Yeah. So I think the good technology leader beyond a lot of the values that we talked about, they also seek to understand how software has been built. What is the process that we’re using? And it’s not you know, even in this day and age, I still hear too many teams get into these philosophical debates about “Are we agile? Or waterfall? Or Scrum or fall? O are we con bond? Oh, you know, Scrum sucks Scrum doesn’t suck”. I mean, none of that matters. That’s all bullshit for happy hour. You know, we’re in a business that’s making money and making an impact. So I think the leader, the technology leader needs to have a very pragmatic view of process. And one of the metrics that I use with teams is how often processes talk to them. That tells me how mature the process is.

Christian McCarrick
Or complained about.

Emad Georgy
Yeah, exactly. If I’m just talking about it, and there’s still meetings about what’s green and what’s red and what’s this, right. That’s an immature process. Very mature process is lean. It supports velocity and quality and value. It’s not talked about because it’s like a utility like the light turns on. And that’s that we don’t talk about how the electrical current went from the light switch to the light bulb, and let’s sit down and talk about like, what kind of voltage are we talking about? And like, nobody cares, once it works, it works. And that’s it. That’s what you want. You want your process to be a bit invisible. So when it’s not, you got to stop. And you got to say, all right, what went wrong here? What do we do about it? That’s what you want. So the way I assess a good technology leader in this respect is, are we getting away from all that philosophical bullshit. And are we getting down to the detail of how am I going to help my team make their job easier to improvement? label it, whatever you want.

Christian McCarrick
And be open to change. Right? And be open to be flexible with change.

Emad Georgy
yeah. And, you know, how do I increase more feedback loops? What are these metrics telling us? How do we get more efficient in this? Oh, this took us seven days. What would it take to get it three days? Right? Oh, our builds are taking you know, over an hour. Well, why is it Everybody living with that? Okay, techies, we have such a high toleration of pain. It’s ridiculous. Right? Like, why are we accepting that? Let’s actually get together and talk about what we can do about it and make people’s lives easier. So, you know, those are my thoughts. It’s more of a pragmatic view, I think and choose how to do it right and purely like there’s no such thing.

Christian McCarrick
Oh, you just triggered an interesting other podcast episode topic. Why are techies gluttons for punishment and pain?

Emad Georgy
Oh, that is a good one. We could tell stories about that—let me tell you.

Christian McCarrick
It’s true, why do we put up with that crap? Because we’d like to make nothing complain about that. That’s another part of the personality. So I want to switch gears here for a minute after all those and those are pretty awesome. And I think for the listeners out there, probably summarize a number of those items for the show notes as well, SimpleLeadership.io, you can go look at those. And we’ll talk we’ll give some time Emad—we’ll put all his contact information too and everything online, you can look at that. But what’s going on today? I know that you have also spoken about the importance of resilience and engineering leaders. And with today’s crisis and the anxiety and everything else going on. Do you think that’s even, you know, more important in in sort of a crisis situation than we have today?

Emad Georgy
It’s definitely more important. I think that, you know, when we’re in the physical world, I mean, we’re in the physical world, I guess, but we’re online. But you know, when we’re physically together, co located, ironically, it’s easy to cover up some of your leadership gaps. Because, you know, we’re all day meetings or this or that. But now when you’re digital, I think as a leader, you have to step up your game a lot more. And that starts personally like having the discipline of how you start your morning, putting the energy and the thought behind, you know, because not everyone’s designed to work from home. Right, well we’re all required to now, but not once designed to do that. I mean, some people need to be around people need to be around the office. So as a leader, you’re gonna have to do that much more to get that engagement going. And it’s also starts to expose to the surface, you know, leadership gaps and skill sets right away. Process gaps, like we were talking about, like if we don’t have good metrics, or we have a bureaucratic process, guess what, it’s gonna get even worse digitally, like, show even more working from home. So there are things like that where personally as a leader, there is no more important time than now to really step up. And it’s a really great opportunity to do that. Both getting your team together, but continuing down the path aggressively or out with your individuals on their current growth plans, continuing recognition and thank yous, you know, like, we’re all focused on the task and let’s keep business operating especially with a lot of businesses just trying to stay alive right now. Right? We got to get Finish Line, but you still have responsibility as a leader on recognition, and making sure that people are recognized and they feel that they’re part of something greater. So yeah, I agree, I think never has there been more of a time where resiliency, and that kind of leadership is needed today on teams at all levels. Really, you can argue, especially at the middle management level, you know, if you’re a manager, or a second time manager, whatever it might be, I actually have the most important role in the company right now,

Christian McCarrick
Because you’re on the front lines. Yeah, exactly. Mm hmm. Any other tips you have for managers to help lead through crisis like this? You know, that if you were to come in and do an engagement company calls you and says, “Hey, what are some of the first things you might look at to help with their leaders to and even the middle management leaders to help get through this?”

Emad Georgy
Yeah, couple. You know, one is also a life principle of mine. I believe that today is part of a larger story. So as a manager, what is that larger story for your team? Like Where are we going? What is the larger story for the company, right? What’s the context, because then if you have a good day, or you have a bad day, you know, it’s part of a larger story. So let me tell you how it fits. And so I think the first thing is, you have to know what that is. So you know, take some time, take advantage of the fact that we are working remotely. And if you don’t have a vision, develop, develop a vision for your team. What are we about what kind of team are we? Where are we going to be in a year? What do we tolerate? What do we not tolerate? Right? And then once you have that clearly communicate it, then reinforce it every time something happens. So every time something happens, I say “See guys, this is what we mean when we say we’re a team, we’re accountable. Like we’re the most accountable team in this company. We’re modeling accountability. You just did XYZ yesterday, and we stepped up we helped each other even though it wasn’t your responsibility”. So now you’re reinforcing saying you’re taking, you know, pragmatic stories or tackle stories in real life, translating them back to the vision and say, let me show you how this is becoming real. So I think this is a time where your folks, as a leader, they want to believe that they’re part of something greater than just our communication medium, the virus. Let’s go out of this situation, right. They want to believe that they’re still part of something greater. We’re not just trying to make it work over Zoom and that’s that.

Christian McCarrick
Sure. Right. Yeah, no, definitely great tips. Definitely great tips for, for this, you know, just unparalleled time. We’re going through right now. Yeah. Something I do ask all of my guests too is if you have any recommendations, or resources to help them through the journey of management and leadership, it could be something you’ve read recently or a book that you was like the foundation of kind of what you’ve built here, your management style on, you know, anything like that, that you can help my listeners out.

Emad Georgy
Well, I’m a voracious reader. So I can go on and on and on and on. But that two that I’m thinking of right now is what is a classic work, “Servant Leadership” by Robert Greenleaf, really great in terms of the principles that are there. I think it’s a foundational book, and then one was written by a mentor of mine. ho I absolutely love. It’s a book called “Integrity” by…cloud and defines integrity, not the way we would think about it, like ethical sort of behavior. No, it’s your equity is the courage to meet the demands of reality. And it’s all about what we’re talking about here. So I highly recommend both books. I think I can go on and on. There’s so many. Great,

Christian McCarrick
great, yeah, no, thanks for those. And for the listeners, like usual, they will be on the show notes. So you can find the links to those. And Emad, what is the best way right now for anyone to get in touch with you? Whether, you know, they want to follow up with something that we talked about in the show, or as a company they might want to have you come in? And kind of have you help them out through this time or something else?

Emad Georgy
Yeah, I appreciate that. The best way right now is to get a hold of me via LinkedIn. I’m very active on LinkedIn. And that’s primarily how we interact and, you know, my passion is to help people grow and technology teams to grow so, you know, happy to help where I can, but that’s where people can engage with me.

Christian McCarrick
Absolutely. Well, again, I appreciate you taking your time and your day to have this conversation. I greatly enjoyed it. It was great to meet you. And I enjoyed our conversation. I always, you know, it’s feeling a little, this whole situation right now as it affects everyone, I think a little bit emotionally. And, and I think definitely even just having this conversation has made me feel a little bit better got me more engaged about the day. So I do appreciate you helping with that. And and I’m sure that’s a good point for other people too. If you are a little isolated, reach out to someone else during this time. It can certainly help.

Emad Georgy
Yeah, and likewise, Christian, really appreciate it. And thank you for the opportunity. I really appreciate it as well.

Christian McCarrick
All right, well, be safe, and have a great day. All right, thanks.

Thank you for listening to this episode of the simple leadership podcast hosted by me Christian McKarrick. 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 SimpleLeadership.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.

Transcribed by https://otter.ai

Christian McCarrick  [0:00]  

This is simple leadership. Welcome.

 

Thank you to our sponsor, Auth0 for helping make the internet a safer place by offering identity as a service. And for supportig this podcast. 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 and leadership challenges and best practices specific to Software Engineering and Technology teams. Do you want more engineering management leadership tactics and information? Subscribe at simple leadership.io to receive the latest updates from this podcast. Hi, I’m your host Cristian McCarrick. This is the simple leadership podcast. Welcome back. Today’s guest is for Farhan Thawar. Farhan is currently VP of Engineering at Shopify via the acquisition of helpful comm where he was co founder and CTO. Previously he was the CTO of mobile at pivotal and the VP of Engineering at Pivotal Labs view the acquisition of extreme labs. He’s an avid writer and speaker and was named one of Toronto’s 25 most powerful people prior to extreme For Han held Senior Technical positions at achievers Microsoft, Scholastica, and trilogy, Farhan completed his MBA in financial engineering at Rotman in computer science he at Waterloo. Farhan is also an advisor at Y Combinator and holds a board seat at Optiva, formally Redney. On today’s show, we discuss management challenges around the current COVID crisis and focusing how broad or deep and technical should an engineering manager be, including should managers write code. Farhan, welcome to the show? Thanks for having me. random question for you. I was on Twitter before and it showed up the today might be your birthday. Is that true?

 

Farhan Thawar  [1:34]  

It is my birthday today.

 

Christian McCarrick  [1:36]  

Excellent. Well, Happy birthday. I don’t think I’ve ever had a guest at least you know, admitted to me that I was recording on my on your on their birthday. So I think you’re a first so congratulations. Thank you.

 

Farhan Thawar  [1:46]  

Cool. Very random, but we planned it in advance and I do work on my birthday.

 

Christian McCarrick  [1:51]  

Excellent. Yeah. And it is St. Patrick’s Day, although I’m not wearing any green and it’s a bit muted this year due to kind of circumstances but…Certainly Happy birthday. And for those listeners, it’s not going live today, but we are recording this on St. Patrick’s Day and Farhan’s birthday for point of reference in the future. Okay, well,

 

Farhan Thawar  [2:09]  

I never got into the green beer thing, but no, whoever’s interested in green beer, go ahead.

 

Christian McCarrick  [2:13]  

Sure. At least if they’re socially distancing, yes. Okay, so now speaking of that, where are you calling in from today?

 

Farhan Thawar  [2:20]  

So I’m in Toronto, based in Toronto. Yeah, most of my career.

 

Christian McCarrick  [2:23]  

I can see you but my guests can’t you’re calling in from home. Correct?

 

Farhan Thawar  [2:27]  

Yep. Everybody’s working the remote life these days because of COVID-19. For those who are listening to this, many, many months from now and life returns to normal. We’re working from home for the next little while.

 

Christian McCarrick  [2:37]  

Yes. And now is that all of Shopify? How is that working?

 

Farhan Thawar  [2:40]  

Yeah. So we made a call pretty early on that the safety and health of our employees and doing our part to stop the spread would be monumentally important. We’re about 5000 people. And so we made the call early to go remote. Hopefully, that’s something that’s possible for us to do while continuing to build things for our merchants. We’re also very lucky in that we have a large part of organizations support, which has already been working remote. And so we’re learning a ton from them, about how to how to make the transition,

 

Christian McCarrick  [3:08]  

Mm hmm. Yeah, great. You’ve kind of had a head start with with a big part of your team. I’ve read about your support org, and not a small one either like 1000 or something people?

 

Farhan Thawar  [3:17]  

It’s in the it’s in the four digits. Yeah. And it does. It’s It’s a secret power of Shopify, but it’s also a secret power and another way right now, because they’re teaching us how to be effective, maintain a culture, be a team, stay connected, while you know not being physically together.

 

Christian McCarrick  [3:36]  

Yeah, awesome. Now, a kind of an aside, I know a lot of retail stores, right are sort of closing and whatnot. Have you seen an uptick then in your online merchants, you know, being able to kind of stay open and sort of satisfy that kind of demand right now?

 

Farhan Thawar  [3:53]  

Yeah. So I haven’t looked into the particular data. Sure. What we’re seeing happen across the industry is quite interesting. So for example, you know, not Shopify specific, but you know, people are still going to restaurants, they’re just getting takeout. People are still trying to get the things they need, but then they’re going online, right? So I know for myself, you know, we announced that we’re furnishing everybody with $1,000 to make their remote office work for them. And so in the last few days, I bought a camera like a better webcam, you can you can see that my camera sucks. So I bought a better webcam. I bought a ergonomic mat because I tend to stand up and sit down even though my desk is not a standing sit down desk. I bought a UV light, right and all these things were a combination of either buying them online and pick up in store which some stores are doing right staying open just for pickup only so not browsing. Or online, where they just deliver it to you. So I think that there is an enablement and happening happening there where you might just change the way in which you’re consuming the thing you want to consume, but still available for you.

 

Christian McCarrick  [4:55]  

Sure, sure. And I think you know, to call it out to Shopify, you know, your organization. I’d read about that giving $1,000 for the employees to help make their work from home experiences better and more productive. Kudos to that, that’s a great move. And I’d like to see more organizations kind of stepping up like Shopify did. So, you know, congrats on that.

 

Farhan Thawar  [5:13]  

It’s an amazing thing for a couple of reasons. One is just making sure the employees are productive at their work. But what I think the connective tissue is that you end up buying these amazing things that our Shopify merchants are already providing, right? Like, it wasn’t like, we all went out and went to some random place. We were like, looking for the great individual entrepreneurs who are already building these things. And so you know, I, you know, maybe maybe it’s talking my own book, but I ended up spending all my money on Shopify stores, right, like,

 

Christian McCarrick  [5:41]  

excellent. Yeah, yeah no, and that’s good. And I find, as an engineer, as an engineering leader, being able to kind of work in organizations where you can sort of empathize with your customers because you’re your user yourself and it allows your product to become better right at Auth0, or or the places that they just, if you Going to use it, you’re solving a pain you felt before and other people felt before. I think it goes hand in hand with just having a better product.

 

Unknown Speaker  [6:05]  

Yeah. So there were no shortages of messages from me to the merchant success managers of those stores when I was like, you know, “this could’ve have been better if it showed me this or if this happened”. And so you’re right, where we’re using that as an opportunity to be like, “Hey, I really expected this and I got that” or “You know what, I did this on mobile, this happened to me”. I actually was checking out on mobile, and I noticed a few things that could have been better, and messaged the merchant success manager who messages the customer, and then we can make the experience better for everyone.

 

Christian McCarrick  [6:34]  

Nice. Awesome. Awesome. Now, as he kind of mentioned a little bit, we can’t ignore the context surrounding the timing of the show. I think the this this code the 19 crisis is going on. So you know, we have a topic I do want to get to in the show, but kind of ignoring what’s going on, I think is disingenuous a little bit. So I mean, how are you doing as an engineering leader? How are things happening for you? And if you could give kind of two parts of that and If you could give any advice to other managers right now leading teams through this crisis with uncertainty, what might that be?

 

Unknown Speaker  [7:06]  

Yeah, you’re totally right. And that nothing can be talked about, without thinking about what’s happening with COVID-19. I think there’s a few things going on for myself. I think I’m somebody who can probably get away with like one remote day per week, as like as like a maximum. It’s not something that I actually do. I actually do go to the office every day. But if they’re in a bind, I can work from home I do. I have worked at jobs where I’ve worked one day of the office a week, but I think that’s probably my max. So I’m at day four now, and it wears down on you because as I tell my wife when I travel that I’m unfortunately better in person. It’s like I like to be in person, I like to have that high fidelity conversation. And so what I’ve been working through myself and learning from others is that the higher fidelity you can make something the better. And so what I’ve been defaulting to is actually more hangouts, zooms, audio even async video than trying to default to text because I do want to have that connection with folks. And I find that when you do put yourself out there with that connection, you’ll get the same connection back. I’m already noticing that for those folks who will we have this pod structure at Shopify, where we have these teams of 10 to 20 people in a room. So it’s not an open office, but it’s not a everybody gets an office, I’m already finding that I’m chatting more with the people who were in my pod, now that we’re remote, even though we’re not in the same room anymore, and I’m still continuing to chat with them more because that was our natural state of being when we were in the office. And so those things have helped me kind of bridge the gap. I’ve also seen people do some amazing things like, “Hey, I’m actually just working for an hour they just put a Hangout link up and if anybody wants to shoot the shit, and you specifically say not about work, if anybody wants to come in and just talk about what they’re watching on Netflix, what they’re wearing when they’re at home, what are they eating? Are they gaining weight or losing weight?”. Which is a big debate in the office because there’s some people losing, some people gaining, you know. There’s all kinds of things you can do. To encourage and I think especially as leaders to specifically go out and say, “here are the allowed topics on my chat, Netflix, what you’re wearing, what you did on the weekend, what you’re eating, not work related topics”, because people assume that you have to talk shop.

 

Christian McCarrick  [9:15]  

Yeah. I mean, that’s a good point. I think at Auth0 85% of a team, at least in engineering is somewhat distributed. Right? So there’s a lot of best practices that go along with that. I was chatting with Dana Lawson, VP of Engineering  from GitHub the other day, and you know, it’s the same thing. It’s, it’s people assume that it’s all business all the time. Once you get in, get in a zoom call. And it’s important to understand you have to have a human connection. Right? So such a huge part of that. There was even something we a couple of people at the teams do. It was sort of like Mystery Science Theater 3000, right and love that connection. You can stream a video and do live kind of chat and commentary over it so you can watch a Netflix film or something from iTunes. Get your team together, you know, whatever it is and some of the movie. There’s just announced that they’re, since they’re closing they’re going to be doing in theater movies for like 20 bucks, which you can actually kind of rent at home, which is kind of a cool idea. And you can kind of watch that with your team. And you can do the kind of, you know, mystery series that you can you can do the commentary over it and you know, have some popcorn. So yeah, keep the keep the personality stuff i think is huge. And just, I think as a manager, too, I think it’s important right to be vulnerable. The managers themselves don’t have to be kind of completely stoic. Everyone’s going through this rough time. So admit it, and just be open to having people just call you up and say, I’m just I can’t work the rest of the day, because I’m just if I did I’m not gonna get anything done,

 

Unknown Speaker  [10:38]  

Right, yep. And I’ve seen that I’ve seen actually, a bunch of leaders come out and say, “Hey, by the way, I’m adjusting my working hours because I’ve actually got childcare things to do in the morning in the afternoon. And so I’ve got to cut an hour off in the morning and cut an hour and off the afternoon” and it’s totally fine. I think that’s, you know, I would say just two things on that. One is one of the values we have at Shopify is actually called “assume positive intent”. And what That means is when anything kind of comes through. If it’s a short message, if it’s a direct message and you’re you’re feeling like why is this person coming after me? actually think about it from the other side, maybe they’ve got a kid on their lap or something. Something’s somebody’s at the doorbell. Like, who knows what’s happening in their life? Assume that it’s positive and just figure out, hey, how do I help them with what they need? And I think the second part you said is really important, which is the admitting mistakes like I made, I made this mistake, a few companies ago where people thought like, of course, I made mistakes, but I never really shared them. And I remember being out one time and I called somebody by the wrong name. And everybody would, like gasped, they’re like, wow, you make mistakes. And I was like, What are you talking about? I make tons of mistakes, but I never shared them. I never went out there and said, oh, by the way, we tried this, and it’s on me and they didn’t feel like they could share their mistakes. And so it’s not a collegial learning environment, if everybody’s like, trying to be perfect,

 

Christian McCarrick  [11:52]  

which is, you know, I’m gonna get into that portion of a show in a second. I’m going to ask you about some of yours. But you know, we skipped a little bit and I want to give my listeners some context. So, just a little bit, the highlight reel, what got you to where you are today? What does that look like?

 

Unknown Speaker  [12:06]  

I’ve kind of oscillated between smaller companies and larger companies. And I got very interested in the smaller kind of startup scene right out of school, I worked at a small company called Trilogy. They’re doing lots of different roles. And I think that’s what’s amazing about these smaller companies. But then quickly transition to some larger ones like I was at Microsoft, for example, which was quite large at the time and is even bigger now. And saw how that type of organization worked and enjoyed my time there as well, but eventually ended up back in early stage companies, and was at a couple of startups. So I got super lucky that a buddy from school called me up to join his early stage company when it was 10 people—Extreme Labs—and he actually called me to join when they were starting, but I joined when it was 10 people and got super lucky there and that the him and the other co founder, basically let me try all these weird and crazy experiments in this startup and we, you know, we grew to about 350 people over four years. We got acquired as I went through that process, then worked for a larger Silicon Valley company for a few years, got the itch again started a new company called Helpful with my co founder, Daniel DeVoe in 2015. And we built a bunch of—now it sounds funny—but a bunch of engagement tools for remote workers like an asynchronous video messenger like a snapchat for work. We built a AI powered employee directory so people can feel more connected with the organization. We built a live interactive audio platform, kind of like what we’re doing at the podcasting but with live audience portion. We were again, super fortunate in that we were pitching and deploying our solution in a bunch of companies and one of them being Shopify. And so spending lots of time with Shopify on how we thought about the problem. Learning from how they were deploying this. It made sense in late 2018, we started chatting about, shouldn’t we like, be inside of Shopify doing the same thing. And so we ended up being acquired January of 2019. And so now I’m at Shopify.

 

Christian McCarrick  [14:00]  

Excellent. It’s the engineering team like at  Shopify right now kind of what’s the size?

 

Farhan Thawar  [14:05]  

So we think of engineering actually, as we think of actually r&d as the group that includes engineering data, UX and pm. So that team is in the 1500 person range, depending on who you are, that’s big or small. And that’s across a bunch of different offices now. So we have a majority of our presence in Canada. Canadian offices is the Ottawa based company. So Ottawa, Montreal, Waterloo, Toronto, and then we, you know, we just announced Vancouver, but we also have some great offices all over the world, including the US, New York, San Francisco, Berlin, Lithuania, so a bunch of different places all over.

 

Christian McCarrick  [14:43]  

And what was the transition point? Was there one point where you actually became kind of an engineering manager? Did you go back and forth a bit? You know, tell me about that.

 

Unknown Speaker  [14:51]  

In meeting lots of different folks in different stages of their career, and let’s go back and try to figure out how I made my decision. I think what I noticed about myself is, you know, while when I was at trilogy, obviously it started in my career, early career was just writing code, not just writing code, which I still love doing, but don’t get the time to do. And very quickly though, I realized that part of my skill was in getting the team aligned. And so when I left Trilogy, I was actually like a tech lead, which meant not having any HR direct responsibility, but actually leading the team from a technical perspective and making sure that combination of making sure we were working on the right things, which you know, some people would call like product management’s. I’ve always had a bent of like, should we be doing this? Or in what order? Should we be doing things, along with the technical architecture of the product, but also still coding? And I realized that I don’t think I knew this at the time that it is a skill that not everybody has. So there are amazing individual contributors who have skills that not everybody has probably including me, like there’s definitely better software engineers or developers than then than me. But at the same time, there were lots of instances where I was able to kind of get the team to rally or reprioritize, or ask an important question that made me think, wow, this is something that I was able to have leverage better leverage than writing code. And that started me on my journey into like tech leadership. And but I don’t think I actually ended up having my first direct report for many, many years after that, I think I stayed in the tech leadership software architecture realm for a while before I started thinking about, like human resources.

 

Christian McCarrick  [16:32]  

Sure. Anything that stand out to you is kind of a manager could be yesterday, it could be you know, seven years ago, you know, protect the names to protect the innocent, but you know, anything that stands out that maybe has a lesson that you’ve learned from?

 

Unknown Speaker  [16:45]  

there’s so many mistakes. One mistake that you know, many people make is that when you’re a technical manager, even though you came from a technical background, it doesn’t mean you have the context of the current problem and so on. One thing that I think I’m good at, but maybe too good, which means like I don’t make the right trade off, is letting the team really struggle with the context that they’re in and try to be in there unblocking and helping them make the decision. Like I think I’m actually quite good at not giving my opinion. The reason I say I’m too good is that sometimes I probably should give an opinion or approach it as a student. Like one of the things that’s interesting about Shopify is because it’s grown up in this world, and growing up quickly, in this world of like, become being a small company to a larger company, is that there’s there’s a bunch of mental models that we use, and one of the mental models is when you go into a technical discussion, are you going in as a teacher or going in as a student? And what do you think you’re going in as in what is the team things are going in? So sometimes if you walk in, right, like you’re a VP engineering, you walk in as a VP engineering, people are like, “oh, VP, engineering here, whatever they say, I should take it as a direct, you know, not giving me advice. They’re just actually telling me exactly what to do” versus sometimes you’re actually just saying “You know what, I actually know all about this. But as a student, let me ask you a few questions or here’s an example of a time and take that as data to then inform your decision”. And I think the mistake I’ve made is not being super crystal clear when I go into a meeting that I’m in this student mode. And then conversely, when I actually do know what I’m talking about going in and saying, “Oh, by the way, I’m not actually giving you advice, I’m actually telling you that we should go this way. Because you know, we’ve tried it X number of ways already, or actually have this domain expertise, or I’ve built the thing. And I think I can help you unblock if you trust me and go this way”. So I think that’s a mistake. I definitely I make I’ve tried to help others kind of see that as a place that they could have leverage as well.

 

Christian McCarrick  [18:45]  

Yep. Great point. You know, I think that’s you articulated that really well, not only how you’re preparing it, but going in and setting the expectation so everybody’s on the same page. They might not be on the same page at first. So you might have to get them on the same page.

 

Farhan Thawar  [18:57]  

You may not know if you’re going to the meeting with that. So I think it’s two pronged. It’s what do you what do you think you’re doing and what do they think you’re doing?

 

Christian McCarrick  [19:03]  

Sure, excellent. Now, I do want to spend the rest of the show discussing a little bit of a common theme of conversations that I have that recurs a lot when I talk to the managers. And that’s their kind of this, this fear about losing technical skills like and should they go broad? Should they go deep? Should they still code? Should they not? You know, is this something that you also kind of hear from New managers that you kind of coach and have in your teams as well?

 

Unknown Speaker  [19:29]  

Yeah, it’s such an interesting conundrum, because I think there’s different personality types, which would let you go one way or the other. So one way to think about it for me is that my natural inclination is always to go broad. And the reason for that is, is that I try to ascertain lots of different pieces of information and try to come up with a coherent narrative. And it goes back to what I mentioned earlier is that I think I have a particular skill that allows me to try to traverse different parts of the organ to kind of put together a complete picture. Now, while that may be useful in some contexts, many times, it’s the wrong thing to do. Many times I have to, I should fight my instinct to go broad and instead go deep in order to go deep. One must have the necessary technical skills, and or be able to rely on a set of people, but have enough of a technical depth to be able to have the next layer of questioning that you can ask those people to say, “let me try and understand this”. And then to replay back what they’re saying. So what I’ve realized in my career is that while I think I’m quite naturally good at going broad, I think that served me not well, in many contexts, and I should go deeper. And now one of the ways to go deeper, this is the age old conundrum. Should you still code? Yeah, right, as a manager. Now, there’s a bunch of different answers to that. One is, yes, you should still code but not on production things or Yes, you should still code but on the weekend, or Yes, you should still code but you know, during hack week, something called hack days, hackers. Now that’s one way to approach it. Another way is actually Yes, you should code. And you should carve out time in your schedule to do that on a regular basis. So for example, and let people in them, a little secret of mine is that I try to and try because it doesn’t always happen. I try to code every Thursday morning. And it to me, it doesn’t have to be production code. It doesn’t have to be on a technology stack that we use at Shopify, it just means how do I get closer to the metal for half a day a week? such that it lets me ask that one layer deeper of question to the team because I was I was able to go deep and explore. There’s something our exec team does, which is quite, I think, re markable for a company of our size and our scope, is they do something called a studio week. And what a studio week is, is you take a week off and you off from your like you’re not working but you take a week off from your regular job, and you go deep into something. So if you’re an engineering, a studio week is you’re going to write code. If you take a studio week and you’re a PM, it means actually going deep into the innards of a certain product that you actually wouldn’t have the time to go deep into. If it’s UX you’re designing, if it’s talking to customers, it’s a go deep practice your craft week. And it’s super inspiring to see our leadership do that. Because, again, you’ll see the benefits of it because they come back and they’re asking the next level question of things that you’re like, wow, how did they even know that level of detail is because they had the time and foresight to carve it out?

 

Christian McCarrick  [22:27]  

Yeah, I like how you did that, and how you said that it allows you to go one layer deep. That’s really the important piece, right? And whether that’s actually writing code, or whether that’s diving deep into tech docs, some AWS, you know, thing that’s coming out or anything. And that can allow you to at least be a little bit more informed, and kind of look at maybe parallels or patterns or similarities between that and something else that you might have had more experience with to be able to talk to your teams. That’s, that’s such an awesome point. I really love that.

 

Unknown Speaker  [22:53]  

You totally nailed it because what happened one Thursday was I spent four hours just fighting with my laptop and the environment. Somebody came over and said, “Oh, isn’t that a waste?” I’m like, “No, this is exactly what our engineers have to do”. And so I fought with our environment, I had the wrong version of a library, I had to uninstall then reinstall. Like it was, it was a crazy set of cascading circumstances. But by the end, I didn’t feel unproductive. Even though I didn’t write code. I was just like debugging, you know, like my Mac OS. But I came back going, I really now understand how these things are all linked together. It was valuable. And you’re right. I think the key from that statement around going one level deeper is going one level deeper, only. Not going all the way. Right. I don’t have the context. I don’t want to pretend I have the context. And if I go into another meeting as a student, of course, and I can ask one level deeper of question, then hopefully, that’s valuable for me and for the team, because I’ve now got that context. So I think that’s the thing that I found super exciting about how Shopify works. Maybe this is a controversial statement, I would assume that in 99% of others. jobs I would have taken instead of this one, I would not have been asked to code one half day a week.

 

Christian McCarrick  [24:05]  

Mm hmm. Yeah, you brought up a really good point, which is something, even if managers aren’t coding, if you take over a team, or if you come to a new company, just the aspect of I recommend this to every manager at every level, get the dev environment up, see what that takes and try to push something to production, even if it’s a space, right? Because that ci process, that developer, you know, process that has so much impact on frustration and efficiency. And if that’s not right, and your team is growing, it’s going to have such an exponential effect on their overall output and happiness, right. So, and it’s worthwhile, even if you can’t fix it, you know, then when you say, well, that should take you know, that should only take a day, right? And you look like a moron because everyone’s like, well, it takes a day just, you know, just to you know, compile the libraries here,

 

Unknown Speaker  [24:55]  

right. Yeah. And I think you’ve hit upon another controversial point. Which is there’s again, two approaches to the engineering leader, engineering leader spending time in code. One is start from scratch, like clean laptop, clean environment, clone the repo, get, you know, the environment running, make a change, you know, get your GitHub credentials. You think everything’s set up, and then push to production. And then there’s the other side, which is, well screw all this stuff that’s going to take you days to get your environment going and just pair program with somebody on something that’s really in production. Mm hmm. I don’t think it’s an either or. But there’s an argument to be said that you should do both. But I think there is a different reason to do both right? One is, what’s the initial developer pain? Can I are the engineering Doc’s written well enough that I don’t have to bug anybody? Should I update the docs myself? Can I connect to the data? like all this stuff that you think you’d have to do as a solo IC on the team? And then there’s the other side, which is like, why don’t I just go to my team and pair with them? They’ve already got the environment set up. And now just get into this flow state of like, we’re just solving problems. Can I bring my expertise and architectural ideas to this team? See how they’re thinking about it, learn a new language along the way to help them stay focused and intense. Maybe they run into some problems. So there’s there’s two sides of it, I don’t think, I don’t think people look at it as two different, like sides of the coin. I think people either do one or the other, like, I’m going to solo program and figure this out and put a space in production or let me pair but you don’t get the whole story.

 

Christian McCarrick  [26:23]  

If you heard a VP of engineering or director of engineering or something somewhere and out of the blue, you do like a skip level dm to one of your engineers and say, “Hey, I’m gonna pair with you for tomorrow afternoon”. Right? It’s probably going to freak him out. So yeah, how do you approach that? In a way though? I like it. I totally appreciate it. I think it’s good if someone wanted to start that, because that’s something I find with managers too. They’ll read something, or they’ll listen to this podcast. And they’re like, “Oh, I’m going to pair program with somebody” and they don’t necessarily we skip over the well, you know, how do you go from A to B?

 

Unknown Speaker  [26:54]  

I think there’s a couple of different ways. I mean, one is Yeah, you can tell I mean, look, you’re there. It’s a company. Nobody assumes that they own their own time fully. But I don’t think you’re right that that’s probably the right way. One thing that I’ve also learned in my career is that it’s probably better to set up some sort of cadence such that people don’t feel blindsided. So saying, “Hey, I’m going to pair with you tomorrow on Thursday” is probably not the right thing. If I’m going to start the practice at all, I would actually start with just asking for volunteers. “Hey, I’m gonna I wanted to pair program every Thursday with folks who’s up for the first few weeks?” and have that set up. And then and then even in that note, can say, hey, by the way, we’d love to pair with everybody not as an evaluation exercise, but actually as a way for me to learn the environment and the language, like phrasing it that way. But, you know, even so, people will still feel pressure. I think that’s maybe okay in some instances, but I would start with just the people who want to, and I think, again, approaching it as somebody who’s super vulnerable, like and here’s a good example, right, like we we recently made a big splash talking about how we’re going to build all of our mobile apps going forward in React Native and I have a great reputation and previous companies are building everything native. Right? So the fact that over the last many months before making the announcement that I was learning React Native spending time with the team on React Native pairing, taking, you know, Introduction courses with the team who were rolling it out, I think showed them that, hey, this person really just wants to understand the brand new environment for mobile. And he approached it with like, palms wide open and saying, “Hey, I’m here to learn”. And so it didn’t look like “Hey, I’m gonna pair with you to figure out if you’re a great engineer or not”. 

 

Christian McCarrick  [28:30]  

Yeah, that’s another whole different branch of podcast, I’m thinking about kind of doing. I mean, I barely have time for this. But you knows to get into a technical more of a technical track of Engineering Leadership podcasts around things like making a jump to say going to choose something like React Native for your entire org, right? And, you know, just picking like each CTO or VP event or something kind of going in and say, “Okay, let’s talk about a project that was of that scope. How did it come about? What were the decision processes? What mistake to learn?” because I think I mean, do you think that’ll be valuable as an engineer to just gonna hear other people’s…?

 

Farhan Thawar  [29:04]  

hundred percent, there was a really great post I think it’s probably my one of the favorite posts I read last year, it was called six software rewrites. I’m like that, I’ll send it to you, I don’t think, okay, it’s like a medium post. It’s like, I think it said, like reading time, half an hour or whatever. But it went into six software rewrites. And it was just like, so good of like, how, I don’t know if they got into as much of how because they weren’t the person who wrote it wasn’t the person who did the rewrite, but tried to figure out why each team did the rewrite and whether it was successful. And just like exactly what you said, which is just like they took a bunch of technical problems. They made a decision. Did it work? And it was just you’re right, that there is not enough content out like this. There’s lots of content of, “Hey, I want to do ABC”, there isn’t enough content that’s like “Here’s where I am. Here’s my view of the world”. And I can either go down path a or path B, and outside of like describing it over Twitter and seeing what people say like that’s not the analysis that we did this case, right to make this decision.

 

Christian McCarrick  [30:02]  

Awesome, maybe you’ll be my first guest. And we’ll deep dive on a different thing. Do a little proof of concept there. But uh, yeah. Okay. Because I think that’s pretty timely right now. I just happen to read a tweet about your kind of react stuff. So very interesting to me. But I want to go back to something too. And I read this Coursera had a post on I think was medium or something a couple years ago, too. And this one thing stuck with me It says, As a manager, the question shouldn’t be how much code to write, but where should I write code? Right. And I think we touched upon this a little bit. Right. And, as you mentioned, to, and other people have just not in the critical path, right, I think because when, if you’re a manager, and you have a tight deadline, you know, the first thing that’s going to suffer is your management duties. What examples do you have of other ways that are code that is not in the critical path? That are ideas that other you know, other managers, directors when I could actually start writing that isn’t like it’s a ticket in a kind of jurisprudence?

 

Unknown Speaker  [30:57]  

Yeah. So first, I’ll challenge that. I think there is a way to write code in the critical path. And that is via pairing, if there are teams and actually so some of the teams that Shopify, for example, actually put up pairing hours, “Hey, we’re gonna, we have pairing hours every let’s say, it’s Wednesday, from this time to this time” . So anybody including me dropping into pair with that team, no one should be surprised that I’m there. And, and we should all be in a learning capacity. But I 100% think you could be working on critical path items, because you’re not the only one touching the code. And you’re also just adding hopefully to the intellect of that team and to the velocity of that team at that time, and then you’re leaving. But I don’t think you’ve left anything because you’re preparing in a weird state critical path. So I would challenge that you can’t do that. But you’re right. If you’re working on your own. There are many times in which you don’t want to be part of the critical path. Now. I gave a few examples earlier, one of the things we do at Shopify three times a year is called hack days. So it used to be two days, it’s now three days in a week. And what we do is we just say, “everybody, everyone in the company, turn off your light chain. block your calendar, you’re not doing regular work, you’re going to be now focused on this new hack days projects”. And that could be, you know, I know my first my first hack days, I focused on a process for how we wanted to think about product priorities and rolling things out. So it wasn’t writing software. But then the next hack days project was a deep dive into some technology stack. Other people might want to solve potential merchant problems using those three days. Some people want to design something new to talk to merchants, other people want to design a new recruiting process. There’s all kinds of things you can do. But the idea is stop what you’re doing, and try something else. And you have three days. Now the goal is you got to ship it, though, in three days. So it’s not a you can’t build something. So even though I built a process, we shipped the process in three days, for other teams are shipping code. Now they’re submitting prs, there’s all kinds of things that we’re doing over the hack days, and that’s a great way to re engage with your craft connect with other engineers and designers and pm and data folks, and not leave teams in a lurch because you worked on some important milestone and then just left it because sure I’m back to being manager.

 

Christian McCarrick  [33:03]  

Yeah, that’s so awesome. How does that work just logistic a little bit, you know, you kind of you said you have teams is a teams or people that have pairing hours like going together.

 

Farhan Thawar  [33:11]  

So two things going on. So with hack days, we just actually put a pack days projects, anybody can submit an idea and people can join it for the pairing hours. This one team, what they do is they just have hours in the calendar. And they remind folks that they’ve got pairing hours and you just go and sign up, right in Google, you can set up your calendar, the office hours, and people can just sign up for slots.

 

Christian McCarrick  [33:32]  

What do you use? Just you just kind of zoom or screen share? Oh,

 

Farhan Thawar  [33:36]  

yeah, we use a tool called tupple. Oh, yeah. Okay. Sure. Yep.

 

Unknown Speaker  [33:40]  

So we use tupple for all remote pair programming. And then when it’s not COVID-19… At Shopify, we have we do have offices. And so we have like in person pairing, but we I mean, we have something interesting in Shopify, where we have like pair programming rooms, okay. And so we actually have multiple ways to pair you can pair on your pod, which is a collaborative space, like I mentioned, 10 to 20 people might be in there. You might decide that you’re going to go and you wanted to get some focus time with another person. So you can go to a pair programming room, which is set up actually with two monitors to keyboard to my side is actually properly set up with a long desk so you can sit and pair for a long period. And then like I mentioned, other folks have like office hours where you can join them on their parent journey.

 

Christian McCarrick  [34:19]  

Cool. And I’ll put the link Tuple in the show notes as well. SimpleLeadership.io I know one of the teams at Auth0 has been kind of testing that out recently, too.

 

Farhan Thawar  [34:28]  

I’m a huge fan of well, you will see my face on the website. I’m a huge fan.

 

Christian McCarrick  [34:31]  

Okay, excellent. Right. Yeah. I have

 

Farhan Thawar  [34:33]  

no yeah, no connection to them, except that I love it, you know, like, equity or investment.

 

Christian McCarrick  [34:38]  

Nice. Well, we have, we have a great acknowledgement and a good reference here for the tool. Now, what about super specialized teams you have—whether it’s AI or some of your data science teams? Do you change that? From a—you ‘retalking about broad or deep— the leaders in those teams? Do you think that changes at all, like how much experience hands-on domain background required?

 

Unknown Speaker  [35:03]  

you know, one of the things that important to realize is that in many companies as they grow, you do need to have domain specific experts, specialists that actually go super deep into AI technology. But what’s amazing about that is there are other people on the team that you’re going to bring along onto that journey. So they’re not yet deep technology experts. But by working with those world class, you know, let’s say make an example engineers, they will get up to speed much more quickly by working with that expert than they would on their own. The same is true of an engineering leader. You don’t necessarily have to have that deep domain expertise at this moment. But by being exposed to the sorts of people and the sorts of problems that you could potentially go after, you could build up that expertise. And I see this all the time, with people moving around the organization, whether it’s at the IC level or leadership level. Now all things being equal as an IC or leader if you have the domain expertise, it’s obviously it can be helpful. That being said, there is a lot of counterintuitive research that there are a lot of breakthroughs happen when people don’t have the expertise because they’re approaching it in a completely novel way. 

 

Christian McCarrick  [36:07]  

Sure.Yeah, definitely. Okay. And you know, one thing I want to pivot into a little bit too, it’s related to this as a VP of engineering or even as a director, and you’re going to look to hire engineering leaders. What are the some of the biggest signals you’re looking for? And, you know, how do you do that? Considering post by wire, too, I think you’ve quoted this many articles. Most interviews can only explain about 14% of an employee’s performance. Right. So what do you look for for the proper signal? And how do you look for that when you’re interviewing for engineering managers and leadership?

 

Farhan Thawar  [36:40]  

Yeah, so there’s a lot more recent research on this, but I’ve been a big fan of trying to focus my time and energy on real performance versus like interview performance data. And so what that means is, what I try to do as much as I can is figure out how we make the interview or the process by which somebody becomes full time as close to the real job as possible. And that means almost trying to not interview. I don’t think there’s like secret questions or approaches or standards you can use to be like, well, this thing gets us higher signal, then thereby we should hire the person because I think what happens in many processes is unfortunately, like unconscious bias creeps in. And we’re seeing this now, like I remember 20 years ago, the best source of employees was like referrals. And now everyone’s saying, oh, but referrals, you just end up referring people like you and referrals were like the best thing like 20 years ago, and now you’re like, wait a sec, you’re right. We just, we didn’t know it was unconscious bias. And so it’s clear now you want to do something different. I think it’s coming around now with interviewing that, you know, the old days was brain teasers, and then that went away. And then it became like whiteboarding interviews and then that slowly fading out and now it’s like more like technical design and pair programming. I still think the highest signal thing you can use is like real data. And so what that means is more likely trying to figure out ways to put people in the situation that you want them to solve and seeing that’d be how they behave, then it is trying to go back in time and ask them a question that their memory May, you know, report differently or because of the environment they’re in will be different than the new environment you’re about to put them into. So kind of a wishy washy way of saying, interviews are not that good, you have to do something. And so what we try to do is, we try to figure out has the person led an interesting and diverse life with examples of relatable experiences that we think can translate well into Shopify. We call this interview a life story. And the life story is really a way for us to explore someone’s past in as much detail and backward facing situational data as we can, which will potentially give us some insight into future performance, but nothing can be really determined until they’re enrolling. You’re like coaching them and saying, Wow, this, I’m surprised by this person’s strength in this area, it wasn’t uncovering the injury or I need to help them in this area, because that wasn’t uncovered in the interview.

 

Christian McCarrick  [39:11]  

Sure. And what about from a technical standpoint? Say you’re hiring a director on your team right now? What do you do for any kind of technical signal? If anything?

 

Unknown Speaker  [39:20]  

Yeah, so we definitely do a few things. One is we tend to do a technical deep dive into a problem that was in their past to see where are they passionate? Did they have the depth of knowledge and a problem that they were directly connected to? Such that we can have an interesting conversation about the trade offs that they might make, that’s one piece of signal that we use. We also try to look for the ability to look back on that and figure out what would you do differently next time? Like there are so many situations whereby you can recount something and now knowing what you know, what would you change about that? Because that, hopefully really shows a process of learning where you’ve gone back and be like, “You know what, but if I could do that, again, I would actually do A, B, and C instead”. So there’s a bunch of things there. And of course, you can look back on somebody’s examples and past history to say, we need somebody to run like a remote team. “Oh, look, it looks like they’ve run a remote team before I’m extremely strong and are super interested in doing that again in a new environment”, that might be a signal that they could be a good fit for what we need them to do. And we do really try to focus on the strengths of somebody like if we see a strength there, and then we can we can double down on that strength versus like, “oh, they’re missing this thing”. I’m not as worried about that.

 

Christian McCarrick  [40:37]  

Sure. And that’s becoming I think, more and more common, looking into those examples, diving in, and the constraints to—What were the constraints they were under to kind of go into a little more color of context of why they made that and that can make perfect sense. “Wow, I would have done the same thing”. That happens too when I do some coaching now, too. It’s like, sometimes people also just want reassurance that “Yeah, no, actually I would have done that”. And then they feel better.

 

Unknown Speaker  [41:00]  

Yeah, or or “I wouldn’t have done that. But that’s okay. Because that’s not my way”, right? Like, for me, that’s super interesting where you may have the same set of data as somebody and they might choose something else. And that doesn’t mean it’s wrong. It just means it’s not your way it might be actually not the local maxima, you would have led them to it might have been something better.

 

Christian McCarrick  [41:18]  

Yep. Great. So, you know, kind of getting towards the end here, a couple things that I do ask all my guests, any recommendations that you have for books or videos or something, whether it’s some seminal work that you always have or something you read in the last week that really stuck with you.

 

Farhan Thawar  [41:35]  

The six software rewrites was quite an insightful read on the decisions a few teams have made about rewriting our software from scratch. That was very game changing for me as a read in terms of books. I am reading principles right now from Ray Dalio. I do enjoy the pragmatic approach he has to how he evaluates people and leaders now. I don’t It can be taken piecemeal, kind of like anything in life. Nobody can come up to you and say you should do ABC and then you go and do ABC usually. Yeah, usually take him go. Let me apply to my contracts. That’s right. So I think the same thing is true principle. I just find it a very fascinating read that he’s able to define a few things that have alluded to me for a while. And I do enjoy how he goes through that thought process. I’m a big fan of that videos or anything else. Yeah, I think those two have really stuck out for me in the last little while principals of the last few months and then that blog post I think, is one of my favorite from last year out there and if it’s slast year, but I read it last year.

 

Christian McCarrick  [42:33]  

Send me that link so that I can put it in the show notes for my listeners. And it’s going to be a little bit of the genesis of a potential new you know, podcast I put together so we’ll see how that goes. Okay?

 

Farhan Thawar  [42:43]  

The tech side of leadershp. 

 

Christian McCarrick  [42:46]  

I’ll have to come up with a name. And the other thing too is if someone really wanted to take a little deeper on this conversation or reach out to you on any of the socials, what’s the best way to get in touch with you?

 

Farhan Thawar  [42:54]  

Yeah, Twitter’s probably the best. I think they’ve got the best way to help people triage like all sorts of issues. requests for conversation. So yeah, just my Twitter handle. You’ll put it in the show notes.

 

Christian McCarrick  [43:04]  

Yep. Okay, awesome. And, is Shopify hiring?

 

Farhan Thawar  [43:08]  

Always. So we’re Yeah, we’re hiring, I would say all the offices, lots of different roles, actually the best way because this happens to me all the time, people messaged me and they say, hey, how do I get connected? The best way is actually the checkout our career site. We’re very thoughtful about making sure that all the open roles are there, and we’re constantly refreshing those. So if anybody’s interested shopify.com/careers.

 

Christian McCarrick  [43:29]  

Excellent. I’m going to start getting a kickback from all of the recruiters at the companies whose leaders I talked to, right. I think you should definitely do that. 

 

So, yes, it’s a little bit of frenemies in that sense, right? Yes. We’re all kind of going after similar talent.

 

Farhan Thawar  [43:47]  

Well, yes. And no, I think there’s all sorts of diverse talent out there. The pool is large.

 

Christian McCarrick  [43:52]  

It especially when you’re distributed, which is good. So Farhan, I had an awesome conversation today. Thank you again for making the time especially in these kind of uncertain times right now. It’s been good Actually, I didn’t think about too much of the last half of this the craziness going on. So took my mind off thing. So I appreciate that. It was an awesome conversation. Thank you very much right. 

 

Farhan Thawar  [44:10]  

Thanks for having me. Take it easy. 

 

Christian McCarrick  [44:11]  

Thank you for listening to this episode of this simple leadership podcast hosted by me Christian mckarrick. If you’ve enjoyed the show, please subscribe. And don’t forget to leave a review in iTunes. Full show notes and additional information can be found on simple leadership.io. If you knew 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

 

Transcribed by https://otter.ai

 

Christian McCarrick  

This is simple leadership. Welcome. Thank you to our sponsor, all zero for helping make the internet a safer place by offering identities a service and support. 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 and leadership challenges and best practices specific to Software Engineering and Technology teams. Do you want more engineering management leadership tactics and information? Subscribe at simple leadership.io to receive the latest updates from this podcast. Hi, I’m your host Cristian McCarrick. This is the simple leadership podcast. Welcome back. Today’s guest is Dana Lawson. Dana has 21 years of experience as an engineer and engineering leader. She has worn many hats to complement a product’s life cycle through her leadership roles that helped to envision New Relic and GitHub, where she currently serves as VP of engineering. With a background in Fine Arts. She brings your creative vision to chart new waters and lead the engineering team to the future on today’s show. We discuss an interesting dinner with Al Gore and tips for managers suddenly having to manage remote teams. Dana, welcome to the show.

 

Dana Lawson  

Thanks. I’m excited to be here.

 

Christian McCarrick  

Yeah. For my listeners, where are you actually dialing in from today?

 

Dana Lawson  

I am dialing in from Damascus, Oregon. In Oregon, it’s outside of Portland, Oregon. So in the Pacific Northwest,

 

Christian McCarrick  

excellent. You know, you almost teased it you couldn’t you know, we’ll get to a little bit of remote work later in the show. It could have been from any number of Damascus’s that are out in the in the world, right. But today it’s from Oregon.

 

Dana Lawson  

Today Damascus, Oregon, not as exciting as the other ones.

 

Christian McCarrick  

Yeah. Well, excellent. As I asked all of my guests on the show, if you could just give me a little bit of a brief background kind of what’s your story and how you got to be radar today?

 

Dana Lawson  

I don’t know sometimes I think I’m like the atypical engineer, but then you talk so many engineers and you realize we’re all a typical, so I got my background started in not thinking I was an engineer. I had this dream of being an artist, you know, it was a great conversation. In talking to my parents when I was like, I’m going to go to college for art, and my mom’s like “to paint?” and I was like “and draw!” .Renaissance! But I found very quickly being a starving artist, maybe not the best path long term, and in college I had the opportunity to take some computer assisted graphic and design classes. And this was back when, you know, Microsoft front page and HTML, all the great languages that still exists today. And I took some of those well, long story longer on a whim I joined the US military. It’s kind of a crazy way how I got there, but I went from art school, to the military. In the military, you have to take a test called the ASVAB. And it’s a skills assessment, and I scored really well in science and math and mechanical engineering. And I saw this job come up that said Information Systems operator Analysis and I was like computers need air conditioning. Why join the army and choose a job that needs air conditioning I’m going to be inside. And here I am 21 years later, I’ve been in every kind of position that you can be in for technology system administration, network, Product Management, sales engineering, every bit that you could be in are probably have been in it— support. And so, you know, that kind of windy path of just trying things out being curious and probably signing up for stuff I wasn’t qualified for, you know, you got to do

 

Christian McCarrick  

that certainly applies to myself too. But as long as you don’t think you’re gonna completely crash and burn if you think you have some aptitude to be able to learn the job, we all learn the job. So if anyone thinks that you have to meet like 100% of any job requirements, like you’re wrong, just apply for it if you think you know, don’t lie, but if they can do it, go ahead and do it. And I think that path to getting to where you are today actually makes you a better leader. Right? You have more empathy with the other teams you have more experience. I always love getting people on my teams to that have a sort of a bit of a Background?

 

Dana Lawson  

Oh, yeah, I think you know, especially when you are trying to build a global product that reaches people from all over the world, you want to have the diversity the diversity in thought. And engineering is such a creative field you can give me and you the same problem. And we come at it produce the same outcomes in totally wildly different ways. And it’s kind of code is our paintbrush boy that I always think of it.

 

Christian McCarrick  

That’s right. You might use front page, I might use something else.

 

Dana Lawson  

There’s a lot of us front page people out there.

 

Come on the 90s were hot.

 

Christian McCarrick  

Oh, yes, they were, you know, they’re they’re pretty good. So interesting to talk about empathy, you know, GitHub, global distributed, and Auth0 globally distributed as well. And I’ve often found that, you know, we didn’t set out to sell our product internationally or globally To start with, but people just started seeing the need, or it’s a global need for identity authentication. And then a lot of our early users became employees. And as you talk about empathy of thought like, that really helped us, I think, to grow into all these different markets organically because we had people there. They were evangelizing us, as well as, as you said, “Oh, this will never work in this culture”, or this is “You have to work this” and I think it just makes the product so much better.

 

Dana Lawson  

Oh, totally. You know, and, and that’s one of the like, pros of distributed work is you immediately have this insight that you may have not had, because you’ve bitten the bullet to find talent and all these different pockets. And so as your product skills, it’s like, wait a minute, I have people that probably have a perspective here, I can just go ask from this part of the world or this part of society that I may not have even considered. So I definitely think having teams like ours is one of those opportunity points you don’t actually like strategically Think about it for ourselves. Well, yeah, it was a little more interesting because it’s the whole primitive of open source software and bring in a whole bunch of randos around, gather to create amazing things. It was just a natural thing to kind of follow that cadence on how the engineering team is designed. But at the end of the day, though, you know, as companies grow, you have different personas. So it’s always interesting to see how that turns out.

 

Christian McCarrick  

Exactly. And this podcast is really about, it’s aimed at engineering managers and leaders. How did you get into being kind of a leader? Did that happen actually in the armed services in the army, or did that happen post actually, once you got into sort of technology or a completely different thing?

 

Dana Lawson  

You know, I don’t know.I honestly think it’s just an attribute that I’ve had ingrained in my like personality. Anybody can be a leader. It’s just how much you want to unlock it. And I’m bossy naturally. I’m kind of in A type to the extreme where I’m like, “Oh, I got an idea. Let’s go do it”, you know? “Oh, wait,” let her go do it. I’ve always just spoken my mind—good or bad. And really, my you know, professional leadership did start after the military. I was an engineer. You know as a as an individual contributor. And I happened to be the individual contributor that was always like, “Oh, look at this problem. Here’s an interesting way how to solve it”, “oh, this problem” or “that problem”, and was just taking the initiative to like, move the ball forward for our team. And I remember the day, my boss was like, you already are acting like the boss, why don’t you just be the boss. I was like, “Oh, no, I’m not gonna be the boss”. I’m just trying to make stuff happen. And they’re like, you’re kind of doing it. And so that started, they’re like, you know what, we’re officially going to just give you the agency, because you’re already taking it, get things done, and that really just started it and just being curious, and I think it’s about having a growth mindset. You know, leadership is such a loaded word. People think that only people with management titles are leaders. And it’s like, No, you should lead from any seat. Anybody has the ability to go influence change and bring up the people around them to do great things and I do believe that we all have that calling in us as humans, naturally, we were empathetic and want to help people. But some of us gravitate, you know, like, gravitate towards it more than others. And that’s kind of how I got my start. I never had like my sights on I’m going to be a manager, I want to manage people. In fact, when I ask people when they go into management, I said, Why do you want to be a manager? If I hear somebody say, “because I can control stuff”, I’m, like, really unhappy. I was like, I think management is getting in your way. It’s the exact opposite. It is the opposite of getting your way. There is no way you’re trying to just pave paths for things to happen. And make sure people are aligned. It’s like horse trading. You know, it’s a constant. “Hey, I give you this if you give me that”, especially at scale, so that’s how I fell into it.

 

Christian McCarrick  

Yeah, you’re a glorified broker. I think of it that way. 

 

Dana Lawson  

right. I do. I feel like I’m on the stock floor. And I’m like, hey, these are three of those words all day long. It’s just you know, Moving.

 

Christian McCarrick  

That’s right. That’s right. Interesting analogies, something else, I ask all my guests to anything that you can publicly talk about, about any mistakes, you might have made one thing that stands out or something you’ve learned from over the years that, you know, you’re like, ooh, especially maybe early on or even more recently, because I know I still make mistakes.

 

Dana Lawson  

Oh, I know. There’s such a good laundry list of stuff, you know, some of the themes when you’re early in your career, but the mistakes you make are especially if you like I said, you you gravitate to enabling people right, like I find fulfillment out of helping others and seeing them succeed. More so than I even see my own success, right. Like this is kind of I think, allow a lot of us are and so some of the early mistakes are, like over capitalizing on people pleasing, right? And taking on too much not saying no, because you’re trying to establish who you are. You want to come out with some wins. You want to show people that you’ve got it under control, and then what ends up happening is you spread yourself too thin, you start letting stuff fall off. And it’s like, “Oh great”. Instead of really doing things quality for this one thing in this one area, you’ve gone and over-consumed yourself. And now you’re doing a little bit and it’s not giving any value. And in fact, where you came from wanting to please people it turn into a pissing people off. And we all almost all new leaders fall into that trap because they’re so hungry. We’re so hungry, I’m hungry, give me more. And you almost want to prove yourself, right? Because we all have posture syndrome, no matter what level in the game we are. We’re like, “Oh, I have got to show these people that I am the right person for the job”. insecurity is a great natural thing to push us and not think that we can’t solve anything and that we don’t have big egos. I think insecurity actually plays well with with leaders, but I think also having too much of that you just make bad choices. So I say find the right level of confidence. Don’t try to please everybody, do a few things really well. And it almost seems like the basics. But I mean, I made mistakes. Not only doing that, but just other mistakes, of implementing, you know, massive design changes, like technical changes and Greenfield technology. Like I’m in there for the rewrite,

 

Christian McCarrick  

right, the rewrite that has to happen

 

Dana Lawson  

that’s 1.8 I was like, like, but I think those are okay, mistakes, to be honest, as long as they you know, don’t really impact the business. But I think the common leadership ones are just not narrowing in your focus. You know, because really ambitious people do want to solve big problems, but it’s like narrowing your focus, have some great wins and it will naturally happen in a lot of places where you’re scoping impact grows you I think it’s a constant reminder of, you know, you don’t have to try so hard. I don’t know, it’s it’s kind of like counterintuitive. Like, you don’t have to try so hard. But you got to work hard.

 

Christian McCarrick  

Yeah, no, that’s a great point. And I think it applies not only to new managers, but I think as managers take new roles, it also happens because you’ve still you fall back into that same trap, proving yourself. So I’ve done it. Control your whip. It’s a great advice for project management for yourself for personal life or in a ship like, yeah, it’s a great category of things to work on. Right, great points. Now, a little anecdote for my listeners to Dana, you and I, a couple months ago had the pleasure of attending a rather unique dinner. Why don’t you tell my listeners a little bit about that?

 

Dana Lawson  

So me and Christian met at a dinner at Al Gore’s house, and it’s a podcast so it’s kind of always fun to see like visual representations of like how we show up so I saw the email and it was like “it’s gonna be casual”. I had a dinosaur shirt on and a dress like I’m from Portland is always casual. We get to Al Gore’s house and everybody was like, “No way are you going to Al Gore’s house” I was like, “Yeah, I am” and they’re like, “How did you get that invite?” I’m like, “I don’t even know”. But I’m going. I’m going! I didn’t know what to expect. But we walk into you know, the lobby of the place and it’s like, oh, shit, like, we’re actually we’re at Al Gore’s house. I mean, suddenly kind of hit me like, wait a minute, you’re wearing a dinosaur shirt, at Al Gore’s house. Like it’s alright. You just be you. So we go up there. And it was a really compelling conversation. We were all in a circle hanging out with Al Gore eating some food and just talking about tech and some of the challenges that we face and it was almost like surreal. Yeah, you know, at the end  of the day I was like, I” can’t believe this just happened” cuz there’s people there wasn’t many. But that’s how we met but and I have pictures to prove it. So if you listeners out there, just like all my friends, or whatever pictures I was like, I have to prove that I was actually here.

 

Christian McCarrick  

That’s right—pictures or it didn’t happen. That’s right. I that’s actually that reminds me I’ll actually I have one too. I’ll it’s not the best, but I’ll put it up on the show notes page too. It’s SimpleLeadership.io. If you have one, send it over. So we can both put it up there to you know, proof of life there because it was so I thought it was a scam when I first got the email.

 

Dana Lawson  

But I’m showing up! For me, the CEO, they know and I was like, hear me better not be pulling one over on me. Come on now. And I was I’m sure people didn’t believe me. And when even when I got there, I was like, is this gonna be real? He was a really lovely person. People say what is he like? I’m like, “Oh, he’s like a normal dude. I don’t know. Like, whatever normal dude means. I mean, he’s totally approachable. He’s funny”. I thought he was funny. Like, the biggest thing is, he’s very charismatic. He was cracking me up in like, you know, politician and world leaders, I guess have to be a little bit more stoic. But he’s funny.

 

Christian McCarrick  

No, he is and I think, you know, and he also mentioned too I think shout out here to Andela, you know, I think they were participating and helping to put that on. I’ll put Andela in the show notes too. I think you have worked with them a little bit. I’ve worked with him, so props to them. I’ll put them in there. So thank you everyone for Andela too for I think what you’re doing and for having Dana and I be able to have this great dinner with Al Gore, which is so awesome. I’d like to say the same thing “You’re having dinner with who? At his house?” Like it was one that was the first order was like dinner, and then at his house was like an exponential order. Like above that.

 

Dana Lawson  

Yeah, that was where they’re like bullshit meters going off.

 

Christian McCarrick  

You know, I think one of the things I have a million things I could jam with you all day about this, but I think timeliness here. There’s something going on. Remote teams, right. There’s a ton of things again, I can talk with you but current coronavirus, you and I both manage large distributed teams, I thought it’d be helpful to go over some tips and strategies for helping other managers that might be thrust into managing remote teams recently, right? Maybe they’ve been thought about it. Maybe they’ve been like dead set against it. But now suddenly Right here they are, you know, forgetting about all the great things that remote teams and distributed teams are about, like we can talk about that too. But like tactically, if you got someone asked you for advice, or some of the top things you would say to this to managers say How could you start helping today to support your teams working remotely?

 

Dana Lawson  

Honestly, the number one thing is write it down. Like if you don’t have a good practice of writing stuff down, like Congratulations, now you write it down. Second of all, is, you know, you need to form a daily structure for your team and for yourself, have a stand up, do a stand up. If especially if this is the first time and you’re just thrust into this. Take the practices that you do in person and apply them digitally. You have the tool set, be creative, but don’t stop the practices you already have in place just because you have a new obstacle. Find a way to continue on with your normal business as best as you do during this time. So if you have a stand up every day at eight o’clock, have a virtual stand up do it the same way, but write it down in case you have people you know, that had to drop off a kid or have some other, you know, problem come up or impeachment come up because they’re at home, you know, don’t change your rituals. Second of all, be okay with over communicating. Like say it multiple times throughout the days you also as a manager have to give your team a sense of comfort that they feel supported during this time. Because everybody, especially if you come from a button seats, culture, suddenly, you don’t have anybody watching you. And I believe that most people are adults and behave like adults. So you just need to remind them, I trust you. I don’t need to see you. Whatever you need to do as a manager, though, which is a part of your already ingrained ritual. Find a way to do it digitally. Like if you sit and talk to somebody, you know, maybe after lunch, the team gets back together to regroup, make that the thing that you do. You could even go in your—if you’re using Slack or other instant messengers, you could do things like in a stand up written. Another good tip too is like nurses notes. I think when you have a distributed team and you’re on different time zones, or if you’re thrust into this due to the current situation within the world, at the end of the day, just like a charge nurse does in a hospital is that everything you did that day, just write it down, replay it in a place that your team members can see. And then when you start off in the morning, if somebody’s starting off at different times, they’re going to see what was happening. It’s not this radical from how most important teams already behave. I think it’s really understanding that people the people side of it more than the toolset, side, keep your rituals, use new tools, write it down, but realize that people are probably going “How does my ex boss person coworker know that I’m actually adding value?”, you just have to say “I trust you. You’re on the team. This situation doesn’t change that trust that we have in each other, let’s find a way for you to feel good about it”. And so I find ways like, Cool, let’s keep a running one on one document that we write. And like if you want to write on it daily, we can asynchronously stay connected together without physically being in the same place. That gives you a sense of comfort for some devs. And some people on the team. You know, some engineers really, really like to have this kind of workflow because we already work in in epics and sprints and issues in JIRA, as we already have this kind of work take how that development workflow is that will be written and use it for also your people management. But those won’t be the the first few principles. And like, I think another big one, too, if you’re having an online conversation for more than five minutes, call them or make a video call. 90% of our communication is nonverbal, and so I’m kind of an animated speaker already so you can tell how I usually feel from how I thought Not everybody’s like that. And especially if English is a second language, you need to find different ways for people to feel comfortable. And if you’re going back and forth and having a communication barrier, while you’re remote, get on a call, talk, talk it out, turn on your video, you will be amazed how quickly you saw stuff. We seem to get this pattern of like, “Oh, just do it over instant messenger. And it’s like “No, talk to somebody”

 

Christian McCarrick  

excellent advice, all those ones. And kind of PSA too. I know that for video conferencing, there’s a number of companies out there just recently—I think Google for their Hangouts and Zoom and Microsoft have either you know uncapped there things for like the next couple of months or they’ve gone free. So if it’s a question of your company doesn’t you know they can’t afford it or they can’t do it or it’s going to be a purchasing thing. I think right now most of these companies are allow you to just kind of sign up. You know, I think go ahead and do that. I totally agree with that. I was actually on a phone call the other day. I can actually pick up the phone and it felt so odd like holding this thing up to my ear. That my ear was hurting. And because I haven’t been in a phone call that wasn’t a Zoom in so long, like maybe if I have to call the travel agent or something, like,

 

Unknown Speaker  

Well, I know but we’ve been at it for a while. Yeah, it is. I like I know if I have to use a phone, I’m like, “Wait a minute, you don’t wanna see my lovely face?”. They’re like, “no, we just want to talk to you”.

 

Christian McCarrick  

Yeah, that’s interesting. You know, the, the funny thing whole anecdote not about this, but our company get together every year for kind of an off site, and we do some quarterly ones with different teams. Now that’s a little up in the air. I think lately, you know, as a lot of companies, I think whether it’s conferences or just team offsites, right, I think that’s that’s coming into a little bit more kind of “wait and see” on what’s happening there. But we always see like the talking heads, and it’s always funny when you meet some people first time and you’ve worked with them for so long, and they’re like 6′ 7″. And you know, you didn’t realize that was like wow, you know, there’s just so kind of different in person, but the video gets you a little bit much better than a phone or slack. But still there’s another piece in person that was interesting.

 

Dana Lawson  

Always. We do the same thing. You know, have an annual wherever you put together. And our company’s getting to a size right? Where we’re way past on bars numbers for social interactions and relationships. So even though you have these, like, I talked to some of the people for months before I get to meet them in person, and then it’s like, it’s not like sizing up, but it’s always like, “ah”. I’m actually kind of tall and people are really surprised. They’re like, “You’re kinda tall” and I was like “Yeah, I am kinda tall”. People never know. I’m like, “You’re kind of short!”. But it’s kind of interesting too, because if you think about generations, the millennials and the generation behind them, like 90% of their communication is already driven through text, or Teamspeak and discord servers. So I think it’s easier by cases but also harder because especially at work, right where you haven’t established yourself, maybe if you’re in a young if you’re younger, into your career, not age, but actually Your career, like leverage the things that you already do and like make them better. It’s just interesting times and I think that there’s a ton of great resources for remote work out there like Auth0, GitHub, Zapier, Get Lab, there’s so many companies out there that have these workforces already, go read their blogs, go hit one of those up. Read their blogs, and you’re gonna see a wealth of information on how different engineering teams and product development teams have work distributedly. Like, look at those tips, see the patterns, see what worked for them and apply them to your own needs. 

 

Christian McCarrick  

Mm hmm.Yeah, good points, too. I’ll try to put some of those in the show notes as well, because there are like Buffer and a lot of them they have online docs, even if you look at Twitter recently, there’s just a lot of people looking to, hey, I’ve put this doc together. Our team does this. They’re kind of open sourcing, or at least making public some of their internal docs right now, so that’s awesome advice. And what you said before was, maybe if you’re a manager at a company and you haven’t done this before. Go to some of maybe your, you know, less tenured employees. Maybe they’re right outta college. And as you mentioned, this is how a lot of them function socially, and it’s not very different professionally. So grab some of them and say, Hey, anoint someone or help them. “Hey, let’s all get together in a room brainstorm. You know, how can we help? I’m new to this” and they’d be like, “Oh, I totally help you”.

 

Dana Lawson  

Krishna, forgot my most important tip of all for remote work, is learn your emoji game. Okay. You gotta learn that emoji game. I forget about verbal and nonverbal. It’s all emoji verbal. So, I have to say like, you can communicate. We’ve gone back to Egyptian hieroglyphs. Now It’s global enoji’s. There’s so much to be said with the right emoji after like, “Are you serious?” And like, “trust me, I’ve been working remote almosy five years—gotta be hot on that emoji game.

 

Christian McCarrick  

And each company has their own sort of norms around the emojis. And God forbid you like introduce a new one and confuses the hell out of everyone. Like what does he mean?

 

Dana Lawson  

I should make an emoji glossary like “You only use the party parrot if you really are excited. What that means you’re excited party parent equals excitement.

 

Christian McCarrick  

Oh the party parrot. Yes. Oh yes. And you can add your own in slack too. So lots of ones you can totally add your own if it’s open and that’s always fun to be gone back to hieroglyphics. That’s all we’re doing a more of like a you know, Asiatic pictoral based language now with our with emoji’s.

 

Dana Lawson  

I’ll bring it in a little bit… Wingdings!

 

Christian McCarrick  

nice for those with Word and a long time ago.

 

Dana Lawson  

My way I mean I’ve been 27 for a couple decades. I could talk about front page and wingding

 

Christian McCarrick  

So a couple other tips I’ll add to. One Yeah, like you mentioned it again on the video. Right? And once you get on the video, that’s not witness protection program yourself. Right like get a camera. Like order a $69. You know, what is it the Logitech 920 online it’s pretty good. It’s not the end of the world but more important than that. Just get a light. I mean, you can put a lamp in front of you sit in front of a window. No one wants to talk to the like the blacked out fuzzy all you need beyond that is like to disguise your voice, right? And you’re just freaking people out.

 

Dana Lawson  

Totally. And like, I probably am not best because I’m so mobile or one of those where I’m at my desk. I’m on my couch. I’m on the porch. But yeah, I have a light source of some sort. You don’t want to be the nefarious character in the shadows. Tey do think you’re up to something so then you have to really use those party emojis.

 

Christian McCarrick  

That’s right. And I think another thing you alluded to before that I’ve found sometimes gets missed in remote work is don’t avoid or skip like the the normal daily pleasantry stuff, right? I’ve been on waiting. It’s so weird, like you get on some town halls and there’s like 150 people on it and it’s silent. You know, if you walked into a room at a town hall, there’d be people talking and you could barely hear yourself, but everyone’s being silent but even just starting meetings with, “Hey, how’s it going?” Right? You know, “How you feeling? What’s going on?” Right? I think don’t lose that just because you’re remote.

 

Dana Lawson  

And I also think in addition to that is, like you said, like, forget the pleasantries. Like Don’t forget the niceties, it really becomes easy to just become transactional. There are humans on the other end of that message you fired off. And it’s okay to take a few moments to say, “Hey, how are you doing today? What’s up? What’s new?” Because if you went to their desk, you would probably be like, “Hey, what’s up? What are you doing?” Because you’re distracted by all the things going around, and then you’re gonna ask your question, and just behave the way that you already would behave. like it’s funny when people go and get hugs, and they get into slack where we are so slack heavy, where I’m sure you are. And they’re like, people just talk all day. And I’m like, because we’re in an office, people would be talking all day. And I was like, and we have a Slack channel for everything you almost want to encourage it. With the reason being is you want to build that empathy even when you won’t have that physical contact. So leverage, right like knowing somebody because subconsciously, or consciously if you’re not a really cool person, like the more you know about somebody, you’re going to be willing to help them you’re going to empathize with needs, and it’s not going to be this random flyby, you’re gonna be like, “Oh, Christian has this dog. You know, he really loves the party emojis and then hanging out with Al Gore. He’s pretty cool. Maybe he can help me with this”, “Hey, Christian radio and hanging out with Al Gore?”, you know, you cannot take away that. Because then when those moments when you get back together in person, it just makes it so much more special. It’s almost like a reunion. You’re like, “oh my gosh”.

 

Christian McCarrick  

That’s right. That’s a totally great analogy. And you talk about humanizing it. I think at times like this, people, especially if you’re a manager, some of your employees might be anxious, right? They might be anxious, they might need someone to talk to you And don’t forget, you maybe would have gone out to coffee. Someone in the past maybe would have gotten a beer. So just schedule a one on one. ask people how they’re doing just try to reassure them because as a manager right now, I think any type of change makes people anxious so and it’s your job now you might be anxious to get in contact with me and you can you know, you can, I’ll help you out. But for your managers and your employees, just make sure you alleviate any stress and anxiety they have because I know they’re having some.

 

Dana Lawson  

100% we’re our own worst enemy when we ruminate about how we feel with change, right? We have all these things, you know, humans, it’s like the evolutionary response of like, “be paranoid, you’re going to get eaten” exists all the time. And so as managers, we have to say, when change happens like this, you’re not gonna get eaten. Like I trust you, I care about you and it’s okay that you don’t feel okay. And I don’t feel okay either. But we’re here together, and we’re still going to solve great things. And I think it’s also as a leader being realistic about your deadlines. This is a time to start reevaluating and saying like, “Is something going to be impacted? Is the personal and emotional toll going to cause us a few delays?” so that we can re normalize. And I think really coming at it at both sides and ensuring one, what you can do with high quality is important, but not forgetting that it’s affecting everything. And so you can’t say, “Oh, well, this isn’t gonna affect that”. No, it’s gonna affect everything. It’s that change. Be realistic about the deadlines, because that’s what I think makes people really start nervous, especially in a professional setting is “Oh, you changed my world, but you didn’t allow me to figure out how I’m going to do it now”and the goalpost isn’t moving in or out and I think we have to be realistic there. Cut scope, which no product manager ever likes to hear. But hello, we should think about it as a group.

 

Christian McCarrick  

Yeah, special times call for some special measures, right? One very specific tactical thing too that I maybe you can let’s let’s jam about a little bit new employees. Right. So you’re onboarding potentially someone this week next week, and your office has said everyone’s working from home. So what tips can you give in it for new managers? organizations where they’ve never like how do you onboard them. In some cases, they might not even be able to give them a laptop like, so any tips for how people might be able to handle that?

 

Dana Lawson  

I mean, once again, it comes, you may have been, you may have logistic delays, if you’re sending gear where you would typically provision it when they’re in the office, I think it’s not just keep constant contact with those new employees. That’s probably the hardest part of going through it is being new. And especially if maybe this is temporary due to the response or even if you’re joining a company that already has a culture, it doesn’t matter. It’s still almost unnerving. I think being there more so than you would and not just saying, “hey, here, come hit me up”. You know, I think sometimes you’re like, “just tell me when you have a problem”. They’re not gonna tell you. They’re not gonna know how to tell you. Schedule stuff, schedule stuff, put stuff on their calendar, have their phone number, give them different areas caught like if they don’t have their laptop, call them. Call them every day that they’re onboarding. Check in with them say “How are you doing? Then give them actual details. Like, here’s where your inventory is, here’s where your laptop is, and continue to feed that information. I would even go even further and be more prescriptive, just like you do an onboarding, go ahead and fill out their calendar, but give them the tools that they need and the things that they should be seeing and make those connections. So if you have onboarding videos, maybe you haven’t recorded them, I would get one of your engineers go record a three minute video of what we typically present, go make a recording of it, let’s go share that recording. Schedule that onborders time, say, “hey, at two o’clock, watch this video”, and then check in with them. I would always clear the deck for your managers in some sense, especially if this is not a part of their culture, because they’re on the fly trying to figure out how to enable new employees. And so let them also figure it out. But treat it as you would and I think the best thing to do is bring structure don’t bring too much ambiguity during this time. The ambiguity already exists with the new situation that people are within. So doing anything you can cut back on that. And like I said with the team, check in at the end of the day, nobody matter what, just say, “Hey”, and it could even be like this is where it’s okay to be a slight message, “How you doing? How is day one? What do you need? What do you need?”, here’s some other things. And then make sure you have those days filled out. And eventually they’re going to get jelling and going. But I think you have to do a lot more outreach, and a lot more connecting. If you already have a really rich onboarding, documentation or experience. Like I said, don’t just give people hey, here’s an email with all these links—schedule their calendar, say, “Here’s a good cadence that I would read these”. Take the horse to water, I mean, can’t force them to drink. I think you have to actually say, you’re going to drink at noon and you’re going to drink this. And then at one o’clock, we’re going to have this Kool Aid and then we’re going to talk about it. And so just be really intentional. Continue to be intentional, just like you would onboarding class and be creative, right? creative logistics problems, find other avenues to get done what you need to get done. And if all of that else fails. Push the onboarding out, that’s okay too. Maybe not every company can do that, but maybe you can. I think with the tool sets that we have today, there’s no reason that most—at least technology companies—can’t find a way to make this work. You probably can.

 

Christian McCarrick  

I really like the point you made about doing screencasts screen recordings doing this up. One, it helps you scale anyway. And what does it take like you take an engineer, you take a manager, you take four hours in one day, and you can probably whip through almost all your onboarding stuff. Then you mentioned like a drip campaign of the onboarding, something I want. I want to reiterate here, and you mentioned at the beginning, the best practices of distributed are actually probably the best practices for what you should be doing in an office anyway, so it’s not something new. Now, I do want to ask you kind of philosophically, how do you think—and this could go either way and maybe it’s going to some company is going to be one or the other—company was thinking about it, they’re on the fence. And either this process goes terribly for them and it sets him back, you know, three years or it goes awesome for them and they’re going to accelerate maybe their distributed workforce. Like, what do you think about that?

 

Dana Lawson  

I think that if something goes that terribly wrong during this period, or or, you know, even if we want to call this an experiment, I would really go back and look at my practices because what is the big delta between having people with butts in seats in your office versus them butts in seats at their home office or coffee shop? You need to look at the people that you’re hiring would be my first like, I would probably step back and say, one, is our practices wrong? OR are we hiring the wrong people, because this is all about, you know, having people that believe in your mission that want to show good work, no matter where they are, about being a part of something larger being, you know, responsible to help their teammates. It’s amazing, like humans actually want to help each other. And if you have a culture that embraces that, if it’s going terrible, you probably have bigger problems. Now, I can imagine it may not go smooth. And there could be road bumps. But that’s what the process is your rollout and I truly believe there isn’t a huge difference between applying them remotely versus in office, you just need to take account for the things that we take for granted. That’s where it is, is like in office, you may not be as disciplined about writing everything down, or displaying it in different clients. Because you’re all co located. Well, remote, you’re going to do the same thing you always did, except you’re going to write it down, you’re going to repeat it and you’re going to share it in many different avenues for people to ensure that they’ve seen it. I think it’s adding a little bit more on to what you already do. But really, I honestly think that if you’re having that kind of problems, like take a look at your company culture, like how is it that you have such a narrow way to have people be successful. We have to be flexible as leaders and meet people where they are and build a company that really in a process that really take care of the majority and then the outliers you kind of deal with independently and that’s okay.

 

Christian McCarrick  

Sue, foundational problems, right. Now, here’s an interesting thing. It’s maybe not tactically related to just this couple of weeks. But in general, I think the majority of engineers, except for those that we’ve all managed, they are not the best at self advocacy, you know, especially from members of underrepresented groups. And, you know, how would you help? Having distributed… I think being distributed can exacerbate that problem, right? There’s a fear of missing out. How do you help people? What guidance would you give to people about helping to, you know, be their own little PR machine and do better at self advocacy? Because I do think, out of sight, out of mind a little bit, how do you make that better?

 

Dana Lawson  

That is really a real problem. And I think like it’s the same problem we’ll see in offices expectedly when you don’t just have diversity in how you show up with diversity in thought and just character. You know, like, if you’re an introvert and you’re in an office like you may be able to not fall in the mix, because you’re just sitting there like you’re reliable, they always see you at your desk, you don’t talk to nobody. Adding an extra layer of remote especially for just on just not the majority of people or and like you said, it’s a definitely underrepresented people that already feel like it’s harder to get their voice out of there. And a lot of us were raised to not have big egos and not to like toot our own horn because that ain’t nice. But you got to get people over that and say “You do good work, it’s okay”. Don’t do it in a way that’s braggy and that you’re stepping on people, but you should feel comfortable to advocate and so some of the ways that you can do this and like tactically, is, you know, think about having Employee Resource Groups thinking about having a guild that people relate to where they can help find tips to advocate and find those channels, but also finding mechanisms and putting in some, some processes that allow that seat at the table. For an example is every Friday for statuses we reproduce agile demos, as a manager rotate who makes a demo even the shy. Everybody on your team should have the opportunity to build a demo. Everybody on your team should have the opportunity to write an internal post about the work they did. I think as managers we have to recognize that. That’s where leaders do come in and say, hey, I see that this person may not because I’m a loud person too like our pot calling the kettle black. I can dominate if I don’t self restrict myself calling people out like I’m in a meeting and I’m overly conscious going, let the next person talk and I think it goes further even distributedly, but I also think about even those people that may not self advocate, you need to find a system so all people can advocate and help push their rotation. I think you know, having the value set with your engineers of like one of the you know, the values and skills that I think is important as a senior engineer is to lift up the people around them. Incentivize, bring up the people around you. It should be a part of them going to the next level. And there you have somebody saying like, I don’t have to have a culture of being a hero or a rock star, right? I always say, I don’t want to rock star, I want the Beatles. They’re all rock stars. And if you have that kind of mind set, then you want to enable every member on your team. But there’s many ways to do that. And I think you have to be intentional. The first step is being intentional and saying, we know with distributed work, that some people will not feel comfortable speaking up for themselves, because x, y and z. How do we build a system that enables them? But you know, you can’t always force people, but I think if you give them the right tools, and you build the right processes, and have the right incentive structure to lift those up around you, you take that down a little bit. But I think more importantly, is you put people that look and feel and represent those groups and positions. And then you know what, there’s suddenly this advocate and there’s also this reality behind it, that they can get to that level that they want to be and that maybe should be advocating for them because they see people that are like them in the positions that they wish to be. If you have all your senior positions from one demographic, you’re going to have even a bigger problem of people self promoting. You will. You’re going to be like, “Oh, I’m going to self promote”, but well, you know, maybe even unconsciously, where’s it gonna go? There’s nobody up there that I feel an affinity to, right. So it’s not like a one size fits all. And I think, find those ways. Once again, there’s so many resources out there that you can experiment with, because depending upon how your team is already composed or what you’re hoping to compose. Try things out, shift to learn, right? approach it like we do software, this may be a good way or not, but it’s one of the challenges. I’m heavily involved in two of our  groups for our women in our LGBTQ and I always go and tell those underrepresented groups like self promotion is important. I know what your parents and the people around you told you. But I’m going to tell you you’re special, you’re amazing, you work hard, be proud of it. work, you earned it.

 

Christian McCarrick  

Great tips. You have to throw off the shackles of like your upbringings, like Irish Catholic or whatever the things are. Now, as a manager, I think it’s important to not only advocate for individuals on your team, but you have to advocate for the team in its entirety to how do you recommend, you know, managers helping that PR upwards?

 

Dana Lawson  

Yeah, I think it’s about once again, like all work is important work. If you’re working on it, I would hope that companies are having their people spend their energy on prioritized work. And even if you don’t feel 100% that it is like be proud of what you’re doing. Right? As a manager, like, I don’t know. I think all issues are interesting in some form or manner like I’ve had the opportunity of getting to break down three monoliths, which sounds like the worst job, because it is because once you have a monolith you always have a monolith. These challenges, you can say, well, oh, what does that manager of the monolith breakdown I’m going to talk about one of the hardest problems that the company will ever face. Like, it’s all about looking through the lens of the value that you’re giving and advocating for it. Now, if you as a manager absolutely cannot see no value, that’s when I would start asking questions like, “How are we measuring this? And how is it going to make an impact?” So I think, taking the opportunity to really visually share, whether it’s written blog posts, you know, having agile demos, going and recording a video, doing an all hands, getting a team meeting and showing the great work that people are doing, it’s going to elevate it. And I think also to that it makes your company better. Because if you think about why open source is awesome, because a whole bunch of people can see that project and say, “Oh, I can go help and contribute”. Or “Wait a minute, I’m tackling the same thing”. When you raise the visibility as a manager for what you’re working on. You never know who has expertise and where they can help accelerate you. doesn’t mean they’re gonna be on your team. But share knowledge is so powerful, and so I just encourage If you’re working on it, like be proud of it, and like, show off that work, do not be ashamed to. And if you can’t, in a way measure how it’s impacting, then maybe you need to go talk to your next leader up or go to props and be like, “Why are we doing this?”. We’re here to ask tough questions, because I believe that, you know, especially in the way of the world now, the way products are developed, especially in our case, you know, we’re building tools for developers to build products or services for developers to build bigger products. Like we know some stuff about what we’re doing like it’s okay to have an opinion. 

 

Christian McCarrick  

Yeah, absolutely. personal question, now. Do you think you could ever go back to an office like it placed a job as an office every day? Like, what do you feel about that?

 

Dana Lawson  

No, no. I mean, I say no, because I haven’t yet broken my streak of pajamas over five days. It’s not like I will actually go past five days of never leaving my house or wearing pajamas, then I’m going to be remote for a while. But honestly, I think that I work more productively being remote because I get to—I 100% gonna manage my time. If I’m heads down and focus, I turn off Slack, I turn off Zoom, and I block my calendar. If I’m in an office and trying to do that, I’m not gonna be a rude asshole and be like, “Don’t come by and see me”. And this is not who I am. And people know I’d love to talk to ’em anytime. I think that it would have to be something so awesome. Like, I don’t know, I’m sitting next to Al Gore in his office. Maybe that would bring me back into an office? You know, it’s not about the perks in office. It’s about the work and me giving the best of myself. That’s why I say no, like, I don’t know, I feel like I’m giving the best of myself because I feel like I have control over my time and my attention. Moreso my attention. And that’s where quality comes is when you really focused.

 

Christian McCarrick  

Awesome. I mean, I have a list I could talk all day, you know, we both probably have back to back And this sort of thing. But one thing I do ask any recommendations you have might be a book, a conference, a podcast, anything you’ve read recently, or is a seminole kind of piece of work that you might recommend to managers out there.

 

Dana Lawson  

It’s kind of been out there for a bit, but I still resonate with this, especially when you’re working distributedly is, you know, enablement, not empowerment people come with their own power, how do we enable people it’s like, information to be informed. And I always go back to “Turn This Ship Around”. It’s a fantastic book that really is about working with intent instead of seeking permission. And when you really think about distributed work, you want people to work with intent and be informed and not seek permission because who knows where in the world you’re going to be and what the time zone is. And so having the ability to be decisive and go fast and be okay with failure, as long as you’re doing it in a way that’s written, repeatable and known, then you’re going to be alright, and so I love that book, “Turn The Ship Around”. I read a lot of management books, but I didn’t I love that book and podcasts, this one, hello? The Treehouse team have a pretty great podcast, too, that they realize for all sorts of different conversations, whether it be leadership remote work, it’s pretty good one. So I think that one’s a pretty interesting podcast as well.

 

Christian McCarrick  

Cool. And I know you had kind of an online sabbatical for a while. If anyone wants to reach out to you, what’s the best way? Should it you know, just GitHub or are you back? 

 

Dana Lawson  

I’m always on an online sabbatical. The internet is mean! I’m a happy person. You can hit me up on LinkedIn. I’m in a LinkedIn poll right now because I say that every time I go and talk to people. Give me maybe a month but I will get back to you. I read every message. I try to respond, but I’m in a hole right now. This weekend, maybe I’ll dig myself out. So LinkedIn, dg Lawson, you’ll find me on there hit me up.

 

Christian McCarrick  

Awesome conversation, the time and Al Gore. You know, this was awesome to love talking to fellow tech leaders jamming about all the things again, I call this my weekly therapy session for lots of reasons. It’s great to talk but thank you for coming on. Stay safe, stay in your pajamas and we’ll chat again soon. 

 

Thank you for listening to this episode of the simple leadership podcast hosted by me Christian McCarrick. If you’ve enjoyed the show, please subscribe. And don’t forget to leave a review in iTunes. Full show notes in additional information can be found on simple leadership.io. If you knew 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

 

Transcribed by https://otter.ai

 

Christian McCarrick
This is simple leadership. Welcome. Thank you to our sponsor, Auth0 for helping make the internet a safer place by offering identity as a service and supporting this podcast. 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 and leadership challenges and best practices specific to Software Engineering and Technology teams. Do you want more engineering management leadership tactics and information? Subscribe at simple leadership.io to receive the latest updates from this podcast. Hi, I’m your host Christian mckarrick. This is the simple leadership podcast. Welcome back. Today’s guest is Eric Elliot. Eric is the author of the books “Composing Software” and “Programming JavaScript Applications”. He is a co founder of EricElliottJS.com and DevAnywhere.io. He teaches developers essential software development skills. He builds and advises development teams for crypto projects and it’s contributed to the software experiences for Adobe Systems, Zumba fitness, The Wall Street Journal, ESPN, BBC and top recording artists including Usher, Frank, ocean, Metallica, and many more. He enjoys a remote lifestyle with the most beautiful women in the world. On today’s episode, we discuss how important it is for managers to focus on code quality and good software development process. Eric, welcome back to the show.

I’m excited to be back.

No, I’m glad to have you. I think i think you’re actually my first repeat guests, not the only one I’ve thought about having on twice, but certainly the first one I’ve actually had on twice in actuality. So you know, you can you are a pioneer in that aspect. So thanks for coming back.

Eric Elliott
That’s exciting. I’m really glad to be back. The last episode was one of my favorite interviews ever. So I appreciate that.

Christian McCarrick
I appreciate that. And I get a lot of good comments from my listeners too. So that’s definitely awesome. And I was actually just checking and we recorded our last episode, almost like a year ago in a week. So it’s actually been just over a year. So how time flies. Absolutely.

Eric Elliott
It does. I didn’t realize it been that long.

Christian McCarrick
This it has, this it has. So I know Eric, some of my listeners, I’ll post the kind of notes where they can go back to car or listen to our earlier episode. But for any new listeners I have, they haven’t done that just a quick, you know, kind of 90 second little bit of background about yourself.

Eric Elliott
I’ve been developing and software leading software development teams for, you know, the better part of my life now. So I started as a consultant, my promise was put me 100% in charge of your development organization, your software organization, and I will deliver bottom line KPIs, or you don’t pay me nice and that that got my foot in the door with some smaller companies. And then the smaller companies, as they became more successful, got purchased and acquired and grew up to be bigger companies and pretty soon as consulting with fortune 500 companies, and that was fun. That was exciting. I spent probably a decade doing that. So in that process, I got to see a lot of different development teams and how a lot of people did different things and it was really exciting to learn about all the best practices and all the worst practices in the industry and get to see that up close and personal in a lot of different organizations. So that experience was really great. Then I went in and did some client side architecture at Zumba when it was a little tiny startup crew that grew to be great big. And from there, I went in, during the music app company, I was like developer number three on the front end, and we grew to 30 million monthly active users number one music app on Facebook. It’s now YouTube Artist Pages. And from them a video social network used by 85 million monthly users. And then Adobe Creative Cloud was the small, Adobe Creative Cloud team that is now $7 billion business.

Christian McCarrick
Nice, small, little company.

Eric Elliott
Little tiny.

Christian McCarrick
Something you said those stuck out at me the very beginning. You’re like you’ve been leading teams and most of your life and I, and I was sort of doing some mental math in my head and going “wow, I think I have too”. I’m not sure how I feel about that. But I have now too. So that’s interesting. The majority of my actually work now has actually been in leading teams versus being an IC. if you maybe don’t count, the like 12 year old me hacking on some early early systems.

Eric Elliott
Yeah, there was a 12 year version of me too.

Christian McCarrick
So now, anything kind of in the last year catching up, so it has been a year anything interesting that you’ve been doing since then? Yeah, you want to kind of fill us in on

Eric Elliott
I put together a couple more teams and you know, building from the ground up brand new teams. So that’s always fun. That’s always a great challenge. I’ve been advising more. So been talking to a lot of a lot of other companies. And when you’re in an advisory position, it’s like you get to like pop in once a month and say, “Hey, how’s it going?”, and kind of learn about the progress in little tiny bite size snacks.

Christian McCarrick
Yeah, without the pressure of delivering

Eric Elliott
Yeah, no pressure, I just tell them what to do and then they’re responsible for delivering and that’s nice.

Christian McCarrick
I think I need to start thinking about that. Because even on a good day when you’re leading and things are going perfectly if you’re the one responsible in the back of your head, you’re thinking “Okay, it’s too good to be true”. Something could go wrong with technical risk of you not being notified yet or…yes, that sounds that sounds very interesting. We can have another show about that.

Eric Elliott
Yeah, that’s a totally different topic because it’s a really different skill set. And you know, you’re not looking at the same things like if your hands-on on the company like actually embedded in the team and helping to lead the team directly. You might be personally responsible for diving in and and looking at like, what is going right what is going wrong at a more detailed level, whereas like as an advisory positions, very, very high level. You don’t have time to go into the Those kinds of details. Yeah. So it’s really different. Like, you have to figure out what are the KPIs that are really, that they’re going to give me the most insight in an hour a month. Right. So it’s a lot it’s a really different approach.

Christian McCarrick
Exactly. You know, let’s jump right into the meat of this this episode, I think I want to focus a little bit on something near and dear to you lately. Quality software bugs, you know, how managers deal with them, you know, how people talk about them, everything else around that. So they seem to be a fact of life, people deal with them. Sometimes, unfortunately, especially if you go to some teams where maybe you’re parachuting into a team as a manager and they’ve been around for a while the there’s a sense of almost learned helplessness about “Oh, there’s bugs, there’s so many of them, there’s we can’t even deal with like, squashing them or anything” right? But everyone talks about the benefits of kind of reducing bugs, defects, improving quality in your code base in your product. What are some tangible benefits to actually reducing the number that are there?

Eric Elliott
The first tangible benefit is that you spend a lot less money fighting fires, which means that you can put additional headcount on actually getting work done. Because fixing bugs is not work that’s delivering direct value to your customers. It’s rework. Customers don’t look at bug free as a benefit, right? They’re trying to get a job done. And they just assume there’s going to be no bugs. And if there are bugs, then they’re like, “I’m out. See you”. So you will lose customers. If you produce buggy software, it’ll drive customers away real fast. Another thing is you’ll spend a lot more money on marketing because your customer is going to be too high. So your marketing budget goes up. Your development budget goes up a lot, like 20-30-40-50 or a hundred percent. It’s really a matter of saving a lot of time and saving a lot of money. Fighting bugs is the most expensive and time consuming part of software development. And it’s really good to understand that because then you realize how we do have time to do like code quality processes like TDD and code review, because it’s going to save us a lot of time. Every hour spent in code review saves 33 hours and maintenance. This is things are that are really good to know, having a good handle on the economic effects of having bugs in your software’s of crucial importance to every manager. And the hardest part of being a software manager is understanding that software takes the time that it takes, and rushing it is going to make it buggy. It’s gonna make it buggy and it’s going to slow down your process. So patience is everything. So investing in that process of reducing bugs in your application is it’s crucial. It’s hard to think of something that’s more important, other than just making sure you’ve got a good customer feedbacks. Like you’re actually solving the customers problems.

Christian McCarrick
That’s right. We’ll go into a little bit later about, maybe what you said is the most important thing will run up by the salesperson. And again, the head of engineering, right. But you do mention things like churn and retention, especially as a SaaS company. One of the top metrics you want to measure is your is your retention and your churn right and your customer growth. So clearly, you’re not going to have a good Net Promoter Score, you’re not going to like you talked about the marketing budget, all those things are going to cost more money. So we’ll get into a little about translating the benefits from and speak to, you know, business speak, because that’s important. But do you have any idea and this probably changes the type of company that we can go into some of the new ones, what should be maybe a baseline metric for about for a decently running software engineering with a decent product? About how much of your time do you think baseline should be spent on sort of fixing any kind of defects or bugs escalations?

Eric Elliott
So that really depends, because if you’ve got your code quality process, right Then you’ll spend almost no time on it. Because you’re catching all the bugs before they happen. And then your rework drops to like almost nothing. So for example, I lead several software development projects pretty actively. I’ve got people managing that I kind of pop in and say hello, right. But I keep a really close eye on those things, because they’re, they’re my business. Yep. So this the software that runs that actually runs my business, I keep a close eye on those things. And we spend extraordinary little time on rework and fixing bugs and things like that, because we invest so much in preventing bugs in the first place. Number one, because every engineer on my team goes through like six to eight months of really high quality training before they even start producing on the software. And you know, not everybody has that luxury but we do on this project.

Christian McCarrick
Yeah, we’ll come back to that topic in a second. Tell me where that Somebody.

Eric Elliott
Yeah. But then we also we have a good code review process. Everybody practices TDD. They’ve been really, really well trained on TDD and code review. And they’ve got really good examples of what good code review means, and things like that. And our rework is almost none. Right? So we spend very little time on doing that. But we spend a lot of time on things like training and code review and TDD. Right? So but that time, more than pays for itself, because it prevents us from getting interrupted later by some critical bug that we have to, you know, stop the presses and fix that before we can move on. Sure. You know, taking it back a bit to the quote, you mentioned about the hardest part of yourself a manager is understanding that it takes time. What are some of the things that happen if you don’t slow it down? Like what is something what happens when you rush engineers? Right, what are some of the things you start seeing? I run organizations with a mentorship culture like we talked about that last time, right culture. Yep. So the developers won’t feel like they have time to mentor each other and help each other out. And that’s extremely problematic. So that gets skipped. And when that gets skipped, knowledge sharing gets skipped and your ability to prevent bugs get skipped. Alright, so that it adds on itself, right? The bugs pile up, test gets skipped. Communication suffers developers burnout. And sometimes you’ll lose completely lose developers. When a developer burns out. It’s a really big deal because it impacts their health. It impacts their ability to do their job, and it can even impact their ability to do another job in the future. And those effects can be really long lasting. So you might think a developer who burns out can just you know, take a long weekend and come right back. That’s not how it works. A developer who actually burns out, can get physically ill can suffer heart attacks and die. There are people in Japan this is a severe problem. People work themselves so hard that they die.

Christian McCarrick
There’s a word for that. And I can’t remember what that is. Yeah, yeah. But it’s

Eric Elliott
a real, it’s a real phenomenon. And you don’t want to see that phenomenon on your team. I’ve never actually seen that in person, but it happens. And it’s something that you need to be aware of. So you really want to avoid getting anywhere near that line on the developer burnout scale, right? And then productivity because of all of those other factors, productivity really, really starts to suffer. Yeah. So when you rush developers, the opposite of what you want comes to fruition.

Christian McCarrick
Now, let’s go for an interesting side case, especially talking about managers. You’re late, you’re getting pressure. The manager decides to step in, you know, grabbed a bunch of tickets starts, you know, writing stories and doing code, like what’s the outcome of that?

Eric Elliott
The outcome of that is then nobody’s watching the overall process. In manufacturing. There’s a floor manager who is usually perched up high above a factory floor so they can see everything on the on the factory floor. And they can see where things are piling up. So on an assembly line, you know, work comes in one end of an assembly line and goes out the other end of the assembly line, but then all these different processes in the middle, take different amounts of time to complete. And optimizing that process is the job of the floor manager. And if you’re not sitting up a higher level, right, and seeing that big picture view, then you don’t have the information that you need to do your job. Know what happens when the manager jumps in and starts spending too much time on code a little bit here and there. I actually love to code myself. So a little bit here and there is okay if you’re just helping somebody else out, right. But if you take your eye off of the factory floor to do that job, you’re going to get pile ups in the assembly line and there’s going to be the parts of the process start to go wrong. Ideally, the manager kind of disappears from the organization, the developers don’t really have to interact with them very much. And they’re just like, up there overseeing the process and making sure this the process goes smoothly. And then the developers talk to you maybe like, once a month on your one on ones, all right. And you don’t really have to intervene very much except for maybe tweaking meeting schedules here and there or saying, Let’s focus on this or let’s focus on that, like chiming in once in a while and the check ins like daily check ins and things like that. And you can just like nudge things in the right direction, and then the developers do the right thing in response.

Christian McCarrick
You also mentioned an interesting analogy related to the assembly line and blog article you wrote, which is good, I encourage all the listeners to read it, it’ll be in my show notes as well. You said when, if I remember correctly, when the assembly line piles up, to kind of stop it and figure out what the problem is. That was software engineering. This is interesting because I just read the unicorn project book too. And like you don’t try to fix the sort of problem, you just try to shove more things in the assembly line.

Eric Elliott
Yeah, which makes the problem worse. Right, exactly. I don’t know how many of your listeners have ever tried to use a copy machine. But sometimes copy machines jam the paper going through like jams. And the only way to get that you can’t just keep pressing copy. All right, that just makes the jam bigger and harder to fix. You have to like pop that thing open, pull out the jams paper, reset the whole thing. Start again, that’s the same thing happens in software. You can’t just push from the beginning and say work harder work faster. That makes the problem worse instead of addressing the actual issue. And the actual issue may not be that the developers are moving too slow or that the project is even moving too slow or slipping behind schedule. The actual issue may be that your expectations are not aligned properly with what is actually happening in the software development? So you might give somebody a task and they take a week to do it. And you’re like, Why is it taking you a week to get this done? Well, maybe it’s a week’s worth of work. And you just need to realign your expectations with that. And you just assumed that it was easier than it actually was. That’s a very, very common mistake that managers make is they think, Oh, I could do this in a few days, or I could do this in an hour. And you’re not factoring in all the other components this like, maybe they’re solving a problem that’s never been solved before, which is ideally what you’re doing when you’re creating software. If there’s already a solution to the problem, just pull it in as a module and use it.

Christian McCarrick
Right. Buy it open source something like build versus buy. That’s a yes, I agree. 100%. Yes,

Eric Elliott
exactly. So by definition, your developers should be building something that nobody has ever built before. Right? And if you’ve never built it before, you have no idea how long it’s going to take to build right. There may be a lot of Hidden complexity that you’re just not seeing yet. And as the developer, they’re seeing it and dealing with it. And it takes how long it takes to get it done. And if there really is a problem, and one of the things that I like to tell my developers that are working on my teams is you should write commits that you can, like finish within like a day. And then they can be merged in the code base safely and shipped to production within a day. Alright. So properly scoping and sizing those commits can help you see the progress instead of the alternative to that as they go and disappear into this rabbit hole for two weeks. And you have no idea what they’re doing and what’s taken them so long when they make a commit. And you can actually see the PR, outstanding, and every single day you can see, oh, they’re solving this problem. They’re solving this problem. You can see the progress being made. And you have this built in sense of Oh Now I know why it’s taking so long. Right? And you don’t worry, right? So the real problem is often the anxiety of the manager, not the work being done.

Christian McCarrick
Mm hmm. corollary to that more frequent check ins, less massive merges, you know, catching bugs quality things earlier, you know? Yeah, better quality software, right. It’s, it’s the other side of that as well.

Eric Elliott
Yeah, exactly. And seeing this, because when they go down those rabbit holes and they disappear for two weeks, they might be running off in the wrong direction, and you don’t even know it, because you can’t see what they’re doing. So if you start to think that they’re going to slow on something, just, you know, encourage them to like, what piece can you break off and make a PR out of right now that we can get merged within a day or so?

Christian McCarrick
Yeah, I think that’s good, good, tangible advice. asking your advice on something else. If you’re a manager, and you have pressure from above because maybe the person above you Because ever again, maybe they’re further away from the code, maybe it’s the VP of engineering. Maybe it’s someone else, nothing to do with engineering sales or what? How do you communicate up? Or what tools would you give to manage screen upward? The benefits of slowing down? design? TDD, code reviews, all those things? How do they make their point?

Eric Elliott
I frame it completely differently. I frame it like it’s not slowing down. It’s creating an efficient development process. So you can move fast. And you’re right, slow is smooth, and smooth is fast. Right? So I’ve talked about it in terms of making a slow, smooth, but because of that fast process, all right. And then when you’re communicating reports to your higher ups, the key is to let them see that there is good progress being made and let them see where the investments are being made and what the outcomes of those investments are. And the investments if every question part of your code includes proper quality process code reviews, TDD those kinds of things, then those things are not cost centers, they’re just part of delivering software responsibly, right. So what your higher ups need to see is good consistent deliverables. And you can’t get that if you’re spending so much time on rework, that you can’t properly make a chart that shows really good gradual, smooth, consistent burndown. Right, because what you’ll end up with is you’ll get stuck on this many outstanding issues that need to be done. And the chart will like bounce up and down on one little spot over and over again and not start to go down. Right, which is perfectly normal in a project that is continuous that’s ongoing. That’s lik, there’s no such thing as done. But when you set some milestone it says we’re going to ship this features on this date or whatever, right? You set some kind of, we’re putting together this package that’s focused on these benefits, right? Then you have some kind of burndown, that should start to go down over time when you get close to the finished results. If you see too much upward growth in the outstanding tickets instead of more sideways linear with like little ups and downs, or downward. It’s the upward like the continuously growing upward kinds of charts that you want to avoid. So I always have burndown chart that doesn’t predict the future. I hate those future predicting ones because they always lie. The ones that try to say, “oh, we’re doing this many tickets a week” they ignore the fact that there’s going to be discovery, right? There’s there’s going to be scope discovery along the way. But you don’t want your chart to go up, up up, right. When you’ve got a deadline coming up. You want it to start to go sideways and then turned downwards. Right. So keep track of those kinds of metrics and report. So I produced two different kinds of charts right, those kinds of burndown charts that move sideways and then start to trend downwards in the ideal situation. And then I produce another kind of chart, which is percent complete month over month. So I’ll have a percent like you are 60% complete with this particular scoped project. Alright. And then the next month, we’re going to have more open tickets, because we’re going to discover along the way, but the percent complete is also going to move hopefully it moves up, which means you closed more tickets than you opened. So I do that month over month, and then they can see this kind of progress graph that usually will have this curve, you’ll you’ll get a big spike at the beginning and then it’ll curve gradually down, and it’ll move a little bit slower and slower towards the end. Because, you know, when you’re 90%, you’ve got the first 90% done, right. That’s right.

Christian McCarrick
That’s right. And that brings up a good point because I often find to that what a lot of other people are interested in is also clearly if it’s a deadline or some date driven thing, that’s important, but to typically more important is to predictability like you said. You mentioned if you can consistently show progress, movement features, iterative stuff. unease goes away. They focus on something else in the business.

Eric Elliott
Yeah. If you don’t give them that, they’re going to say, We want this done by such and such date. And if you don’t hit that deadline, you’re not doing your job. Right? The alternative is you give them demos, the finished features on a regular basis. So demos over deadlines, right?

Christian McCarrick
Yeah, yeah. But that’s great. I like that.

Eric Elliott
Yeah, show them consistent deliverables, and they’ll be happy. If you don’t do that. Then they’re going to say we want this done by x date. And if you don’t have it done, you’re out of here, because they have the same problem that you have. When a developer disappears down a tunnel for a couple of weeks, and you have no idea what’s going on. Yeah, they have that same visibility problem into your work. So if you’re giving them good reports, that show, that prove that you your team is doing a good job, then they’re going to be happy. If you don’t, then they’re going to say, “we want to see this result by this date or you’re gone”.

Christian McCarrick
been there before. Yeah, I know, I definitely understand that. So I want to go into, you know, you talked a little bit about the things that you you create some charts. And clearly, you must measure, I believe, anyway, you have to measure what you really want to improve, right? You can’t improve if you don’t know, your baseline you don’t know targets. So what are some of the things that you can talk to, to our my listeners about to about what are the things that should be measured? Like what are the tangible things that you would recommend to measure, not just for good project sdlc process but also that can help you with better quality software?

Eric Elliott
When it comes to measuring? I have to caution about what not to measure. Sure,

yeah. “what gets measured gets managed”, but that’s just the first part of the quote, the rest of the quote is, “even if it’s harmful to the organization to do so”. Yes. So there’s some things that you should not measure. Let’s talk about those things first, right, perfect. So the most important thing that you should not measure is an individual developers number of closed tickets. And the reason that you should not measure that is because then you could start to manage that. And sometimes your most productive developers are closing the least number of tickets. And that’s because your most productive developers are the ones with all the answers that everybody else comes to. Right. So they’re going to have a higher number of assists, they’re going to be looking at more pull requests, and giving more feedback and answering more questions. And they’re, ideally they’re spending most of their time doing that, because then they’re spreading that knowledge across the organization and helping your other developers improve. So your other developers are 1x developers. Hopefully, this developer is helping them become 2x developers. And then that’s multiplying the productivity of your organization, so you don’t want to discourage that behavior. So mistake number one is measuring individual developers contributions in terms of closed tickets. So don’t measure that. Instead, what you do want to measure that can really move your productivity KPIs is there’s this concept of bug commit density, I say, but commit density instead of just regular bugs per line of code, which is a different measure of bug density, because commit density tells you how much rework is being caused by bugs. So there’s a simple formula. If you have a file in your code base that has 51 commits, and 14 of those are bug fix commits, then you’ve got about 20% bug commit density, and that’s for that file. Right. And the interesting thing about this kind of measurement is that if you have a whole bunch of files in your project, and you probably do, right, what happens is you get a power law curve of those commit density metrics, right? But commit density metrics. That power law curve gives you this prioritized, refactored target, because the ones with the highest bug commit density are indicating the most rework has been done on this file. Alright. And if you also factor in the recency of rework, then you can see this file is causing us bugs right now, right freshness, right? This has been getting in our way actively getting in our way of our productivity. So you can actually see those and they become hotspots that you can then tell developers let’s refactor this in the next sprint, and that can deliver huge wins because a lot of your rework is concentrated on those particular files. Sure. So if you start to look at your project in terms of health, what part of this project is sick and what part of this project needs fixing? And then you concentrate on being the doctor Being the project doctor instead of the people police, right, then you’re going to make your developers a lot happier. Because those are the files that are frustrating them the most. And those are the things that are causing them the most problems. So you’re solving the problems to the developers on the team, you’re making the team more productive. You’re shipping faster. Everybody’s happy.

Christian McCarrick
I like it. I like your term before two assists. In other things, it’s very common term, and even measure it, right. It’s sports and whatnot. Like you get an assist. But in software, it’s assumed. But like I said, it’s really I’ve really loved that term, I’m going to start using that now. I love talking to people get new terms, suddenly want to go back to my teens and then be like, did you have a podcast and talk to someone this weekend? You know, because it’s sort of suddenly I’m using some new terms I didn’t use the format teams are like, “okay, you read that blog post”. Okay, so those are definitely not measuring yet what not to measure. Excellent point. Anything else that you would recommend for managers to start measuring and/or things that they, you know, the top three things that they should do to either start measuring and or do to try to improve the quality of their code.

Eric Elliott
If you don’t have a non-predictive burndown switch from the predictive burndown chart to the non-predictive burndown chart tomorrow, that’s gonna change your life. Excellent.

Christian McCarrick
You hear that? Tomorrow, everyone, tomorrow. You’re going to go back to your teams and be like, “Did you just listen to Christians podcast?”.

Eric Elliott
Yeah, because the those predictive ones are giving you unrealistic expectations. And that happens to be the number one complaint that developers have about like the biggest problems you’re facing at work—unrealistic expectations. So you’re seeing this unrealistic expectation, you’re passing that on to your development team, and then they’re feeling the pressure of those unrealistic expectations. And that’s problematic, that’s going to slow down your team because it’s going to make them unhappy. Oh, so speaking of happiness, developer happiness is a really big important thing to keep track of and to try to improve on. Think of your net promoter score. But for your developers, right, so yep, the developers give you, you know, net manager score or whatever.

Christian McCarrick
Yeah, well, that’s, that’s great. Yeah, there’s a couple of tools I’ve used to for that. Some companies use Culture Amp. I think it’s something I’ve used a tool called 15Five in the past and sometimes it’s just how you feeling on a one to five if it’s a maybe it’s a happy face, you know, smiley face, that’s a trend and, and those are definitely good things I think is right. Yes. You talk about also in your article, it’s one of your sections when you do talk about developer happiness, right. So you just mentioned unrealistic expectations being one of the top drivers of unhappiness, anything else and then the and then after that the kind of the the inverse, what are the things that do make them happy?

Eric Elliott
Yeah, so unrealistic expectations, time pressure, being stuck on a hard problem, they they’re not sure how to tackle. All the pressure from that kind of dissipates if you help them feel empowered to spend time on quality and spend time on learning and spend time on teaching each other and mentoring each other and asking each other questions. If they feel like they have permission to ask for help when they need it, then they don’t get stuck on those problems because somebody else can, you know, another set of eyeballs sometimes comes along, and they solved the problem in two minutes. So all those things can kind of disappear. And you know, when developers get stuck, a manager comes along and says, “Hey, how you doing on this?” Right? What we don’t realize as managers is that anytime we go and talk to our subordinates, it makes them nervous. Right? They’re like, “Oh, what did I do wrong?” Right. So unless it’s in a regular one on one kind of session and setting, right, but there are other things that you need to know about developer happiness that are really, really actionable and really valuable to them. So one of those things is that happy developers are better at finding and fixing bugs than unhappy developers right there. And they perform faster at their jobs like, significantly faster at their jobs like by up to 20%. Just when they’re in a good mood. Yep.

Christian McCarrick
Yeah. Yeah, that makes sense.

Eric Elliott
Right? Right. And what we have to remember, as managers is that when we pop in and say, Hey, how’s it going? They’re thinking, “Oh, am I going too slow?” Sure.

Christian McCarrick
I’m just trying to help but it seems like you are “helping” in air quotes, right? Because you just want an update? Or you’re nudging me. Yeah. And that goes down to the, you know, do you have this? Is it a psychologically safe team you’re on? And all those things make it much better, where people are more like “Actually, no, I’ve been stumped on this problem”. “Oh, great. Let’s dive in”. You know, let’s let’s look at what’s going on.

Eric Elliott
Yeah, you really need to approach cautiously and from a place of safety, where the developers feel safe to give honest feedback. And, and that’s not always easy to do as managers. And one of the best ways to do that is to do regular monthly one on ones so that they are accustomed to you like caring about what they’re doing, even if they’re not being slow, right? Sure, no, absolutely make the normal that you talk to them on a regular basis and check in with them on a regular basis. And it’s not about hounding them on like when you’re going to have this done. And when you set that expectation, then they feel more safe and comfortable when you ask them questions.

Christian McCarrick
Since we’re on this, like, what can we do now tomorrow thing? What would you recommend a manager to come in and, you know, start doing on their team immediately.

Eric Elliott
If you don’t mind? Let’s circle back to some other things that should be measured, and that’ll help inform this. So one thing that you should measure is how many open pull requests are there. If you’re not doing code review with pull requests, then that’s another thing that you can start doing tomorrow because it will deliver serious benefits. The most important being that your team learns from each other as they’re reading each other’s code. And they’re learning new tricks. And they’re learning the best ways to do things. They’re learning the normal process for working with your code. And that helps make your entire code base more consistent, more self consistent, and that makes it easier to learn and easier to code against. And a lot less confusing and confusing code creates more bugs.

Christian McCarrick
I can attest to that.

Eric Elliott
So right, getting everybody on the same page is super important. And the best way to do that, in my opinion, is code review. So start doing that. And then as soon as you do start tracking how many pull requests are waiting for review right now, and make sure that that Q is moving sideways or downwards and not growing upwards over time. soon as you get a growing backlog of those pull requests, that’s going to be really problematic. It’s going to cause integration issues, and rework. So you want those things to be cleared within a day or so. Not to take a week or two weeks or you know, after I’ve been on teams where an open pull request took a month, two months, three months to clear, which is just ridiculous. At that point, you might as well scrap it and start over. Right. So track the number of currently open pull requests. Another thing to look out for is too many open issues. So if your number of open issues is growing instead of shrinking or moving sideways, then you have a problem. Same kind of reason except the rework is now you or your project manager, whoever’s in charge of triage issues, has more rework to do, because every time you prioritize the tickets and figure out which ones the team should be working on next, that’s rework. All right, and the more open tickets you have, the more rework you have to get through. So you have to figure out that this is work about work. It’s not work that’s contributing benefits to the users,

Christian McCarrick
and it takes its opportunity cost at the same time.

Eric Elliott
Yeah, and having too many of those things open means that it’s harder to find the high priority ones to work on next. Right. So yeah, opportunity costs gets really factored in there. Because if you miss the biggest opportunities, because you’ve got too many opportunities to choose from, then you’re in trouble, right? So watch your number of open tickets, watch your number of open pull requests, and really stay on top of that. And make sure that if the team needs a little nudging to like, Hey, you know, once in a while chime in, during like, check ins or whatever, I have my team check in daily for slack asynchronously say, here’s what I’m working on today, blah, blah, blah, I’m blocked by such and such whatever, right? You can chime in during those those check ins and say, “hey, we’ve got a lot of open pull requests. If you have time to do an extra one today, that would be great”, right? And developers will respond well to that because they’re annoyed by too many open pull requests so they feel the pain of waiting for their pull request to be approved. So they’re like,Yeah, let’s do this.

Christian McCarrick
Well, that’s it. I think that’s the other point to teamwork. Because if you have a good team, if they’re bonding, if you had, share, go Share deliverables, then you’re going to want to help out someone else who’s not waiting, like you said, right? Not only for you getting that pain, but it’s karma. And you know, helping someone else will help everyone.

Eric Elliott
Yeah, the other kind of metric that you want to look at is like, and like I mentioned before, you want to look at your bug density. But you should also look at the number of open bug tickets. Because if those start to pile up, then you’ve got real problems because bugs reproduce critical bugs, it’s going to interrupt the developers, you have to stop what they’re working on, go fix this critical bug. And then interrupted task takes twice as long and contains twice as many errors, right? Which means that if you interrupt a developer to go fix a bug, you probably just caused another bug. Yep, right, or two or three, which is really scary, right? They can start to reproduce fast if you get too many bugs in your code base, and then too many of them go critical, right? So be very careful about The number of currently outstanding bugs. Another problem that bugs cause is they mask what’s really going on in the code. And that can cause developers to make mistakes, because they have a misunderstanding of what’s actually happening in the code, and then introduce more bugs. So bugs reproduce. So it’s important to keep track of how many open bugs you have, and fix them. Yeah. Don’t let that number grow. Make sure that number is shrinking or moving sideways, a maintainable level. I don’t mean like, lots of bugs and they’re moving sideways. I mean, like… be attainable level is and not interrupting our customers work, right? It’s okay to not fix a bug that’s only affecting one guy who’s not even a paying user. Right? There’s priorities. When we talk about bugs, which ones should be fixed first, well, the ones that are blocking the most amount of value in your application, fix those first, right? And there are… It’s okay, there’s sometimes there’s a bug that’s that you don’t have to fix, right? and that’s should just not be high priority, if only one person has ever complained about it, and it’s like really hard to reproduce, and you’ve got a million users. So you know, like, that’s a very small number of your users who are actually being blocked by that bug. So don’t worry, absolutely.

Christian McCarrick
Each one of these, we could go deep dive in, go to town, I already think part of my, my role as the host of this is actually, it’s somewhat like keeping myself in check, because I love to go on tangents and go down the holes with people. And just like how I do Google searches, sometimes, like my brain, just three hours later, I’ll have found all sorts of interesting things I’ve done, but part of the podcast too, is me trying to rein in myself, and then, you know, keep us all kind of on track, so that we can kind of get some digestible information out to people. But one last thing, and this is a whole episode in itself, so I don’t want to spend too much time on it, as we kind of, you know, come to the end, but you’ve mentioned a couple times test driven development. You know, there’s a lot of opinions on this either way. But for you, maybe if you could just give just a high level, kind of what does that look like, in practical terms? What’s a walkthrough? And why do you recommend?

Eric Elliott
Okay, I’ll start with why TDD has been crucial in my experience, and then put applied TDD on a number of different teams. And I’ve seen teams that use a different process where we’re still making tests, but we’re adding the tests after. And universally the teams that actually practice TDD and test first, work better. And I’ve seen, like I said, I spent the first 10 years of my career watching lots of different companies do lots of different things. So I’ve seen a lot of these, a lot of these. And I’ve also looked at a lot of the studies on the topic and testing first can reduce bug density by 40 to 80%, which is phenomenal. I can only think of, you know, spec review, design review, code review. Those are the only other processes that even come close. close to touching the benefits of TDD by a huge margin. So TDD is a very important thing. One of the important reasons that you need to test first is because when you test first, you always see the test fail before you see it pass. Right? So you’re testing your test. So your tests are more reliable. Some other benefits are that you end up designing easier developer user experiences for the modules that you’re putting together. Because if you’re testing first, that means you’re thinking of, how is the developer going to call this function, rather than how am I going to implement this function? Right? And when you do it the other way around, you tend to think what’s the easiest way to implement this thing. And then that implementation detail can leak into the public API of that thing, and make it harder to use. Yeah, so developer experience tends to improve. When you write you write your tests first. I’m going to stop there. But TDD is also going to give us better code coverage and That leads into another really important process, which is continuous delivery, right? If you have poor code coverage, and you try to do continuous delivery, you’re going to end up in trouble because you’re going to ship bugs to production. And then some of those are going to be critical. And it’s going to interrupt your developers are going to make more bugs and you get another cycle, right? So continuous delivery, and your ability to have good code coverage to stop the continuous delivery pipeline when something goes wrong, is of crucial importance. And TDD helps with

Christian McCarrick
that. Like I said, I was hesitant to even bring it up because I knew, you know, you’re a huge advocate. And, you know, we could have another whole conversation about that maybe I’ll call you in a year since we’re going to go these yearly cycles of conversations and we can we can definitely do that once a year, just our things going great. There’s lots of things maybe if there’s any resource that you would recommend a manager looking to get into TDD that, you know, you think that they should look at That might be kind of the the seminal thing to kind of start with.

Eric Elliott
Yeah. So of course, there’s the classic was it Kent Beck wrote a really great book on the topic. That’s what got me started. But it was the practice of actually using it for years and figuring it out, that really helped. I actually kind of distilled a lot of that experience into a five hour one day training that we recorded, and we put it up on EricElliotJS.com and we’ve had customers from Spotify and Amazon and Disney Interactive and you know, companies like that, that say they really enjoyed the training and that added a lot of value to the organization’s we share this process because banks are really, really careful about quality and and they they really care about getting the best quality process some

Christian McCarrick
good ones, the ones you want to put your money in.

Eric Elliott
Yeah, so we’ve shared these we share these practices with banks and they radically transformed their organizations. Quality practice as well. Yeah. So you should take a look at those. That’s my best recommendation is, is do that, because there’s a lot of other resources out there that there’s some misinformation floating around. And there’s a lot of resources out there that don’t go into very much detail about, “okay, how do you test first?” Right? How is this even possible, right? And what kind of tests should you use? Some of them say, do lots of functional tests and end to end tests, and very few unit tests and other say do lots of unit tests and very few functional end to end tests. And you really need both to get good coverage, right? Because they’re testing different things. And unit tests give you a much, much better code coverage. And the reason for that is because they’re a lot faster, easier to implement and a lot less expensive. So developers write more of them, you know,

Christian McCarrick
exactly. And for that course, I’ll put it up on the show notes as well. Simple leadership.io as usual, any other kind of resources or books since we’ve spoken Eric, that may be something interesting you’ve read recently, you’re seeing that you want to recommend to my listeners,

Eric Elliott
you know, you asked me that last time, and I didn’t have only one. But maybe I’ll just remind the readers right. So we just talked about a lot of stuff that is really, really well documented in a novel, fictional book called “The Phoenix Project”. And if you haven’t read that, you probably should. There’s another really good leadership book that I like a lot. It’s called “Turn the Ship Around”. That was guy from the Navy wrote, and it’s a really good one.

Christian McCarrick
I recommend that again, for our listeners, I’ll put up on the show notes. Eric, one last time, what is the best way for people to reach out to you you do your website socials or all the above?

Eric Elliott
Well, you can follow me on social media and follow JS Cheerleader as well on on Twitter. And those are good resources. If you want to actually make contact. We have support forums on devanywhere.io and EricElliottJS.com which is the best ways to actually get a response because we get inundated with the social media stuff and will probably miss it. But if you reach out through the support forums on those sites, it’ll go into our little process. And we always hit those.

Christian McCarrick
And for everyone there, if you’ve enjoyed this conversation with Eric, please search for and listen to my previous conversation with him, where we discuss how culture can help your team scale. And I will also put a link to that on my show notes on simple leadership.io. Eric, awesome conversation. Thank you for taking an hour of your day. I completely appreciate it. And like I said, well, we’ll meet up again next year. That sounds great. It’s a real pleasure. Thank you for listening to this episode of the simper leadership podcast hosted by me Christian McCarrick. If you have enjoyed the show, please subscribe. And don’t forget to leave a review in iTunes. Full show notes and additional information can be found on simple leadership.io. If you knew 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 so Engineering leaders

Transcribed by https://otter.ai

Christian Mccarrick:
[0:03] Christian Patrick welcome to the show.

Patrick Pena:
[0:06] Thank you for having me, I really excited to be here.

Christian Mccarrick:
[0:08] The absolutely and as we were talking just before you’ve actually been listening to a podcast for a little while to is that correct.

Patrick Pena:
[0:15] I haven’t I’ve been really enjoying.

Christian Mccarrick:
[0:17] Awesome I have to repeat the what is a long time listener first-time caller joke read have to put it in there.

Patrick Pena:
[0:21] Absolutely.

Christian Mccarrick:
[0:24] ISO and where are you actually calling from today Patrick.

Patrick Pena:
[0:28] So I’m calling in from New York City I work at a startup here New York in healthcare and.

Christian Mccarrick:
[0:36] Excellent I should have connected with you I was in New York about 2 weeks ago so next time I’m back in the area I will give you a I’ll send you a stock or something the movie connect.

Patrick Pena:
[0:45] Yeah I would be great I would love it.

Christian Mccarrick:
[0:47] All right so awesome Patrick as I do with all my guests if you could just go into a very high-level background of what you think the important pieces are of how you got to be where you are today.

Patrick Pena:
[0:57] Absolutely so like most people I started out as an engineer I remember having a lot of conversations with my family with my wife around like we are goals,
most of those tended to end up with me saying I’m just going to be a more senior engineer that’s what I want to do,
but in my previous role I was at hospital system in Philadelphia and my manager introduced me to this training at the hospital gave two people that were trying to make their way up in the organization,
and it was around the training and really the goal with change agent training was to,
teach you how to be a facilitator how to help groups problem solved and how they like to help people get a consensus and make change happen in an organization,
and that was my first test first teased,
set of skills that I had really focused on previously. Kind of open my eyes to this craft that I wanted to develop,
I use that not going to help me towards my next step of being a lead engineer and then,
add a new training opportunities come around for lean process Improvement training being trained to be What’s called the lean leader.

[2:12] And that help me grow in focus in terms of and see things in terms of,
value in the value that something was generating and if it wasn’t generating value then we considered it wasteful.

[2:27] Janet help me with like problem solving solving helping others problem solve,
really that I towards value and trying to set a foundation for a management style for myself and then from there,
I had transitioned into a manager role.

[2:45] Was building and growing a team was really excited about it was also in this kind of like new round that wasn’t familiar for me and ended up being kind of stressful.
Can I have a friend at the organization and she let me know that she was going to be hosting a pilot for a mindfulness and stress reduction program that she wanted to start at our organization.
Little did I know that led into me learning about the growth mindset positive psychology and kind of learning more about the way our brains were.
And that really helped me change and adjust how I saw and out with myself but also with how I met Road in coach maionchi.

Christian Mccarrick:
[3:30] Sharon will get into I think I’m number of those aspects kind of later in the show as we dive deeper into it can each of the different points of those I think I remember if you also did you start a company at some point is that true.

Patrick Pena:
[3:42] I did yeah so I graduating college I’ve been working part-time and I decided I wanted to just.
I started a company right out of college I was doing web development application development Consulting I had a few studies science really love to work,
really love owning my own work but I didn’t love the other parts of running a business so I can love dealing with finances I didn’t love dealing with sales or worrying about where my next paycheck was going to come from.
And I didn’t really have an opportunity to be part of the team.
And so when I made the transition to the health system in Philadelphia I was really looking for an opportunity to focus on Healthcare and to be someplace where I could be part of the team.

Christian Mccarrick:
[4:33] Yeah I think that’s it that’s an interesting point of our galaxies although as I often talked about in the show is you become higher kind of in the hierarchy of being a leader it does get lonely
I’ve also found two I had started a company myself out of college it’s when you going things alone especially that that’s really lonely.
Yeah I’ve known as share that for the troubles with talk to it does get hard.

Patrick Pena:
[4:57] Absolutely.

Christian Mccarrick:
[4:58] I ask this again to all of my guests but as you transition from the icy being an engineer
how you talked about the coming in your new manager coming to some of the lean manager items but what was what was the mistake that you made that you need to look back on pain and cringe,
Oriental Sunday that stands out that you you’ve definitely learned something.

Patrick Pena:
[5:22] I think when you start off you try to take for granted that you have additional contacts that other people might not and that different people interpret things differently,
and so I definitely started with like an approach it like I’m just going to treat everybody the same and I’m going to share you know the information that I think is important for them to know going into a project right now.
And it took me a bit and I stumbled through kind of learning to recognize that I had to interact with each person differently and that.
In a multiple people to look at the same situation and Come Away with very different reactions and very different points of a conversation that they would remember.
So try to building that scale sat around understanding individual and how to cut a deal and talk to that individual and like what they valued in what.
Call Basil the world.

Christian Mccarrick:
[6:18] Sure and how do you if there’s one thing that you could give advice to a software engineer that’s making the transition or brand new Suffern new manager that one piece of advice. That you would give him right now.

Patrick Pena:
[6:32] I’d say prepare for the change and how you deliver value so when you’re in ICU deliver value directly.
You write code you solve a problem you help others solve problems.
In a more concrete indirect manner like I can look at programs that I built and I had a productive week because I directly delivered something and I had full control of that.
When you start to make your way up I’m in your movie into more of a manager role,
the way that you deliver value is like how you enable your team and others to be productive,
I’m in to help them grow in their roles and it is a a shift and something that you have to adjust to that like your output is not lines of code anymore or a future and a product output is like.
The way that you enable others to do what you were doing previously and I think that’s a hard transition for people so my advice would be to try to mentally prepare,
to make that change and start to see not only the work you do directly but the value of providing by helping others be productive.

Christian Mccarrick:
[7:39] Sure that’s definitely great point and that comes up a lot too because sometimes it can be frustrating for people when they,
can’t see a little bit more of that tangible value that they’re providing instantaneously or at the end of a Sprint with dealing with people now in teams that feedback and value that you get is it right much longer scale-like.
Return Seattle no the other thing that that we talked about here you are you’re going to be giving a conference talk soon.
And your talk is about communication growth mindset in Psychology so first of all congratulations on speaking of me that’s always a there was a great achievement and nerve-wracking kind of all the same time.

Patrick Pena:
[8:22] Yes it is yes that I’m going to all those emotions out this month.

Christian Mccarrick:
[8:26] Awesome. You want one thing I have one book that that I recommend all of my,
leaders and managers who want to speak is that really actually good book called resonate by Nancy Duarte disagree,
Ted Talk that she does as well and the book resume is really good as another book that’s a companion called cytology but the resident one for me I find was just a really good book to read,
not only about giving presentations you know the conference or something but really also about howling how to help communicate,
storylines and
you and just if you’re going to talk in front of your team or you going to talk in front of an exec team or try to pitch an idea and there’s a lot of good information on that to 4
I just kind of her helping get ideas across so I’ll put that in the show note symbol to shut that I owe for a for anyone that’s going to be talking soon or just kind of in general wants to,
improve a little bit of both are there should have been there dialogue in their writing.

Patrick Pena:
[9:31] I will be picking up this weekend.

Christian Mccarrick:
[9:33] Text me so I know what conference will you be speaking at.

Patrick Pena:
[9:38] It’s a conference is called bifrost it’s in Toronto and it specifically in Engineering Management and leadership conference it’s a one-day conference
focusing on topics around people’s Journeys inside sin and tricks and tips in for people that are in or moving into leadership roles.

Christian Mccarrick:
[9:57] You know that’s that’s awesome and they want that you’re speaking are you speaking at a conference like that that’s also good but I think the other thing that is just really.
Really good to is that,
when I started this podcast not that long ago I think it was really maybe one or two conferences or meet up sort of around just to the fact of how do we improve engineering leadership like it was something.
She was separate and should be worked on right actually worked on and now,
there’s a conference you just mentioned there’s the calibrate conference there is the lead developer there’s a ton of them I know you know when I started my podcast is really just hang III started at the same time.
That I’m Jerry Lee also started if you’re in the San Francisco area this offer kind of engineering leadership meet up and.
What started I think the first meet up at 20 people and then earlier this year he had his first conference and there was something like six hundred people there was a wild you know success
but it was just awesome to to get the disc community of people are all realizing that hey you becoming a manager,
is not just something that happens and it requires work and investment and I certainly ways to improve it and then improving it will to your point will help you and your teams provide better value for your customers in here.

[11:19] I had to let some you know and are on the show from a gas if we’re lucky because we’re going to get a little bit of preview of The Talk topics that are going to be talking about so it’s a special preview you know a prequel to your conference here
let’s go to some of the topics I think the first one was communication so so foundational so critical,
but it’s usually an afterthought so tell me a little bit about communication why it’s important and do you know some of the things I might be talking about.

Patrick Pena:
[11:48] Sure so like I mentioned before you know what communication the part that’s hard for each of us as an individual to understand is that the words that were saying and the intent behind it,
isn’t always interpreted the same way by our audience right,
so they have their experiences and their background and the way that they use language to interpret the words that that we share and someone could say something in slack email,
or you know directly in person and you’re not quite sure did they mean it the positive way that they meet at the snarky way.

[12:25] You know I had a conversation recently with an engineer on my team and I asked them to start to consider communication.
I was just an important part of his craft the way that he would think about and looked at.
The more day-to-day activity refactoring code,
communication is just as important because it really impacts the general feeling that a teen might have,
I’m a really big proponent of the importance and value of teamwork and communication I believe it allows us to do our best to work and to deliver our best work and provide the most value to our organization and so communication is a key part of that,
we need to be able to communicate clearly and make sure that our intent is coming across properly onto our audience and part of that is understanding who our audience is and making sure that we are communicating in a way that they will understand.

Christian Mccarrick:
[13:24] So important that you mentioned something just a second ago and.
It’s locked and has most of us probably use slack on a on a day-to-day basis on a all the time I lost you were over at work is is pretty much,
almost fully distributed and slack is such an important part of it but you mention it’s really hard sometimes to understand the intent.
Behind slack messages it’s a short form does emojis I’m dealing with people across all different countries and and it’s very contextually
set aware and sent it as a sensitive about what is it what an emoji means you tell me a little bit you know how do you how do you help managers are or even teams to better improve their getting there in 10 to cross using a medium like Slack.

Patrick Pena:
[14:14] Sure so I start usually with asking them what did they mean by what they said.
To give me like the stock of Beast version of what they were trying to get across.
And Austin just by asking them what did they mean to say or what were they trying to say I get the version of what they did say that they probably should have put out there and so it’s just going to be back loop around.
The way that you phrase something or way that you said something left too much up to interpretation,
and I didn’t really understand what you meant and so probably other people might also not understand what you meant and I try to coach people towards being clearer in in what they say,
understanding that others might not interpret what they said the way that they meant it.
I think kind of making sure people think back to what the meeting is is important to help them think about how they communicate.

Christian Mccarrick:
[15:15] And
anything that you have is there any of you said any sort of codified formal expectations around what good are were unacceptable communication might look like with her in person on a team between people are over soccer email.

Patrick Pena:
[15:31] I tried it have that feedback be more one-on-one based on that person and how their interactions are going rather than Spotify anything specific I’m glad you asked that people try to do,
make sure that they’re coming from a place of teamwork and working together and B+ coming to a solution you know whether you’re talking to someone within your own department or in a different department.
You know we’re all trying to solve the problem and we all need to work together to be successful at that and I just ask people.
Communicate from that perspective that we are all trying to solve problems together and we need to be successful by doing that together.

Christian Mccarrick:
[16:14] Absolutely and I think communication which often gets overlooked is as much about the listening in the receiving as it is about the the talking into giving.
One of the important things I think is under one of the the guy that did Etsy and and which is another common thing used elsewhere is the presumption of good intent and if someone saying something to you.
Make the Assumption whether or not it’s true that the intent behind what they said was good and then and then have a response from that ass.

Patrick Pena:
[16:47] We have that as one of our company values.

Christian Mccarrick:
[16:51] Great and I was talking to my colleagues just about this today and she said not only is it good
to assume that good intent because they might it’s actually good even if they don’t because you come across in our conversation as you know as the one who’s taking The High Ground professional and you won’t escalate something,
I need to say.

Patrick Pena:
[17:09] Absolutely you know that that ties and I’m sorry.

Christian Mccarrick:
[17:14] No yeah go ahead Patrick.

Patrick Pena:
[17:15] I was going to say that ties into kind of another part of my talk around our brains work.
And and how I think that.

[17:25] Especially for engineers and how we come up through our careers you know our brains by default our wire to spot danger right are our primary goal is survival in our brains are wired for that by default.
And then you have so you have to default behavior that your brain has and you had on top of that,
the things that we tend to Value about good Engineers especially as you’re making your way up to your career around,
spotting problems looking for issues and code,
looking for like potential problems and work laws and stops and you know great job like you found a bug great job you like figure it out these edge cases,
you know a lot of your career is around spotting negativity,
and so you have this reinforcing behavior of progressing through your career by how well you can spot problems and it can like account for those potential problems with your default behavior of your brain,
edit needs to,
you know the stereotype in engineering of people being cynical of being negatives of mistrust and we have to work to break those patterns in those behaviors,
you know our brains are wired to the kind of cheek the least.

[18:47] Our brains are wired to take an approach to do the least amount of thinking so we formed these habits and these default responses that we take,
you can see this if you have a default reaction to when someone says something and you see someone else like roll their eyes all the time,
we have these habits that are our brains default.
And we have to work to reprogram that and change the way that we looked at our interactions you know if you take the approach of assuming best intentions.
Even for our own sanity it’s important to look at situations,
and break the habits that get us to negativity because getting that leaf in that stuff from just being more senior engineer especially moving towards people management.
You need to tell people make the progression from spotting problems to solving.

Christian Mccarrick:
[19:43] The excellent.

Patrick Pena:
[19:44] Yeah and it’s part of that is how we rewire our brains and how we look and respond to things by the Fall.
As an example in a one-on-one I might ask someone what’s what’s one thing we should be doing better as a team.
No it’s what’s one thing that we could improve.
I’ll try and I’m not always great at it but I’ll try week-to-week to find one positive thing that I can tell someone I noticed you know I really appreciate it someone’s throat Asana code review.
I really appreciated how someone spoke up in a meeting,
reinforce the positive behaviors that we want to see out of other people and help to build those Pathways so that when they’re in a new situation or they’re dealing with something they’re going to think about it from
the perspective of how do I make this better how do I improve the situation how do I assume that Dustin 10th W want them to do.

Christian Mccarrick:
[20:46] I’m going to point out something in the examples you just gave and this is important for for new managers you’re very specific,
in the feedback that you gave which is very important. Just you did a good job but but you know you pointed out a very specific example,
of you know why and I’ll even go a little further like that was good and then go into why that was good but I think if you if you do that to it becomes much more impactful for people and they’ll they’ll take it and be able to actually have actionable inside of the earnings.
It’s interesting we just add adult cereal we just had a new manager and SLT off site with we brought in some when we went through some
it’s some kind of leadership coaching and one of the things we all did was going to have to do a Myers-Briggs personality types right and it always shows up we have this default type but,
your to your point two in one of the things that we talked about at the sauce site was everyone has their default side jet type just like you mentioned,
are your brain might be wired a certain way to be lazy in some ways but it does not mean right doesn’t mean you can’t perform like another one of the types
and is that going from being an IC to a manager sometimes,
forces you to actually maybe you’ll go out of your normal comfort zone your default Pathways to do something that’s a little different,
but that’s not bad it just takes a little more work.

Patrick Pena:
[22:12] Right it’s a bird it’s it’s skill and it’s things that we can learn and develop over time and that’s the the next part of my talk around the growth mindset.
And I’m definitely someone who would characterize myself as being an introvert I don’t like speaking in front of groups of people generally very quiet very shy very in.
And I used to look at situations and think that’s just something I’m not good at that’s just a skill I don’t have.
Until I started learning about the way that our brains work and about the growth mindset versus being fixed and what I describe the four is that example of being fixed I am good at coding but I’m not I’m not good at.
Sitting in front of a.

[23:00] Then what I learned and and what I push myself with is to break myself out of that way of thinking I’m in understand that these are all skills that you can develop and grow over time.
And so every year for the last couple of years since I learned about this I set a goal for myself to help me grow outside of my comfort zone and to let me see that I can develop into work on a skill,
outside of what I think are my default skills so I’m back in 2017.
I signed up to be an instructor for a coding bootcamp and I spend six months teaching class and teaching people how to become edgeineers people that were coming from diverse backgrounds with varying levels of Education.
You know it was a way for me to force myself a couple times a week to get up in front of a group of 25 students,
explain technology to that and program meet you there,
and figure out what way is work better to get a point to come across and she get myself comfortable with speaking in front of a group on a regular basis.

[24:11] I remember when I started that I ended my first class and I turn to my teaching assistants and I said.
I could probably go an entire week without talking like I filled my quota I just don’t want to talk to anyone anymore for the rest of this week.
And by the end of that class it’s all great and I felt energized 6 months later.
2018 I set a goal for myself of doing a talk at a conference.
I didn’t quite make 2018 I’m speaking this year but it was the next step for me to push myself out of my comfort zones and actually be up and do a presentation like that in front of an audience on a topic that I’m passionate.
And then.

Christian Mccarrick:
[24:59] Announcement Aztec how to say that’s that and for people to write him and it’s it’s about setting a goal and like I said it happened in 18 but it happened this year that’s all that really matters right you’re making progress.

Patrick Pena:
[25:10] Righttime setting new bars and and stretching what I consider are my own limits and I set a goal for myself to do that every year.

Christian Mccarrick:
[25:19] Awesome and you know I do want to point out this is for for my listeners here this is Patrick’s first podcast,
so round of applause if you can’t hear right but you know again thank you for coming on the show which is which is not always easy I think you know I’ve had,
I got some podcast gas and,
they freaked out a little bit sometimes before the show that I never going to guess what I’m going to say I’m going to sound stupid I don’t like the sound of my own voice and you’re gone. You’re going to be okay.

Patrick Pena:
[25:50] It’s it’s interesting that you bring that up because that’s another part what do you think about how our brains work and we think about how we can change how we see experiences City energy,
when you’re nervous and the energy that you feel when you’re excited actually pretty close.
What is how you frame it for yourself and how you think about it so coming into this situation as an example and before my talk.
I will spend a couple days,
reminding myself that I’m excited to do this I’m excited to get up and share my lessons learned that you’re my background with others and I feel excited and positive about the situation I’m going in,
we’re a couple years ago I would have just been nervous and only seen it as nerves and let that self that negative self-talk get to me around,
it not going well the sound of my voice being bad me not sounding intelligent and I actively take the time now.
To reframe the situation before I go into it so that I see it as a positive.

Christian Mccarrick:
[26:58] Excellent that’s really good advice yeah that’s that’s I’ve heard that before too and it really makes a lot of sense and I think it’s it’s awesome that
to my listeners here to that that’s a really great way to try to practice that I refocused at you know take control the situation and use it to your data.
At what this growth mindset you how do you use that with members of your team ride you have any examples where you’ve seen this before you’ve been able to coach somebody to
you do something they didn’t think they could you innately do or I know what what kind of coaching Styles you use to help you.

Patrick Pena:
[27:32] I look for opportunities for them I find I try to find a small steps forward,
so depending on the person’s personality some people like myself might be a little less unsure of their abilities or their skills and I find,
these cam micro improvements and I’ll suggest that they take this stuff like.
Putting together a future plan where they haven’t done one before or asking them to speak in front of our team just our team but speak in front of our team on a topic that they either worked on or they done,
I’m going to try to tie back to something.
They’re already interested in the subject of but I definitely look for the small ways to kind of push people a little bit outside of their comfort zone,
maybe look at a situation a little bit differently than they would have previously.

[28:25] So if I see someone had a negative response to do something that was shared by and I’ll try to help them with that reframing,
and give them tips on like how to look at how they communicate how they think about how they’re communicating around this topic with.
Total views I might have someone to think of them as teaching opportunities you know not everyone is at the same level not everyone has the same,
Barber what they consider a quality code review you know everybody has their perspective of the situation or the task,
and so if you if you frame it from like this is an opportunity for me to teach someone else and you phrase how you talk around that.
Jordan 10 in your purpose is going to come across so much better then if you try to just dictate something to someone.

Christian Mccarrick:
[29:18] No absolutely that’s that’s it fellows point and
I’m a firm huge bleeder about the havior in Psychology in and how it is so intricately involved with everything we do in every day and how important it is
to understand those underpinnings as a manager and leader of organizations that it is so important to my My Philosophy is a,
matured through engineering career path item in you you start off Technologies the only thing.
And is not serve evolve that it becomes almost the last thing for me not that I don’t love it on Packard hard and but it’s
but it’s the people in the Dynamics of the people in the right people in the right spots and Heather acting together,
enables us to Ben be much more effective,
I producing really really good software and technology which as you pointed out earlier is really the reason we’re doing that is ultimately we’re providing value,
two other people in the world and how do we produce the most value the most effective.

Patrick Pena:
[30:20] Absolutely yeah it’s it’s that the people side of it and the Team Dynamics side of it that definitely are much more engaging for me at this point in my career then if you would ask me even 5 years ago.

Christian Mccarrick:
[30:35] And they also are probably some of the most complex things that keep managers including myself up at night and they are
I like to describe them to new injury managers just think of people and teams has just really complex systems see how do you how do you do system up in position and interfaces trading contracts
but it’s it’s not easy and dealing with people,
is not binary so it’s more analog and there is because it’s not allowed and there’s there’s the permutations are just infinitely greater.
One of the things I was reading one of your your blog post I wrote and you had a quote on there that’s too. It said I to find a high-performing engineering team is one does not need me,
Define that a little bit what do you mean by that and when how does that a philosophy that you live.

Patrick Pena:
[31:27] Short so I think.
Too many items back to that team Dynamic and interpersonal way of communicating and interacting.
Tamia and ideal high-performing team is one that’s perfectly child that’s making good decisions and is not dependent on me.
Operate independently they function as a very strong team that communicate very well and they just make good decisions and keep seeking value and delivering value.
For me that me that would be a situation where like I don’t need to do anything because I’ve already given them,
the tools and techniques to use and and a way of working that works where I can go and be on vacation and not worry about it.

Christian Mccarrick:
[32:19] Exactly and how do you know that involves a how would you recommend other managers to help to support a nurturing environment where that starts to happen.

Patrick Pena:
[32:31] I think it starts with your one-on-ones and that more frequent feedback that you’re giving to your
can you Mandy individuals on your team in around giving context right helping them understand your thought process and how you came to a specific conclusion and helping people understand that sometimes you have to be okay with ambiguity,
you’re not always going to have all the pieces of information you would need to make the best decision but,
you make the best decision you can with the information that you have available to you.
And so I will work with them as an individual I will work with them as a team around how do they make decisions how do they see the world out of the think about the problems are tackling and what value are they trying to provide and how are they measuring.

Christian Mccarrick:
[33:22] And I think it’s super important part of that is a manager though is also than supporting the decisions that they do.

Patrick Pena:
[33:28] Yeah yeah it’s it’s um you’re supporting the decisions that are made by the team and.
When you support their decisions and you own it with them right like if I Empower my team to make a decision on something I’m going to back them up,
and talk to other people about why we won with that decision and how was the best decision we can make at the time,
and show them that I support them in that decision and I trust that right like I trust my team to make good decisions,
and I have to demonstrate that trust to them.

Christian Mccarrick:
[34:12] That’s really great great point that you mention before you were instructor at the boot camp at Rutgers,
you would you recommend doing some of that for other managers you think it helped you in your like being a better manager but it being a better leader.

Patrick Pena:
[34:27] Absolutely did it forces you to find different ways,
communicating the same thing so that it sticks with your audience because your audience is going to be buried,
you know you’re your audience isn’t already a group of Engineers your audience is a group of people that want to get into and become engineers and so you have to learn how to phrase things and explain things.
Over and over and in different ways so that people get it and it sticks.
And it just helps you understand how to do that better with your own team and that you have to tailor the way that you communicate to the audience,
araneus isn’t always going to be your engineer’s you’re dealing with people in the business you’re dealing with product managers or do you have to tailor how you communicate,
to those around you and having to explain and cheap someone how to be a programmer and engineer,
is it fun and relatable way to do that is to build a skill set.

Christian Mccarrick:
[35:29] Yeah and I think it’s a win-win especially if you can,
game that you know advancement and Improvement on your own side but also if you’re going to volunteer your time for something like a code bootcamp you know you’re also can help,
baby other people may be members of underrepresented groups that didn’t go to a traditional University or get a CS degree that you can also help them get into,
you’ll be the you know software engineering Fields as well and it and I certainly recommend a lot of my listeners out there to know if you have the ability,
do you can one-up you or your skills and at the same time you can help in other people get into our industry that could greatly benefit from doing so.

Patrick Pena:
[36:13] How people change their lives.

Christian Mccarrick:
[36:17] Yeah absolutely Patrick any any resources that you would recommend for you no new managers or anything good that you’ve kind of read or watch recently.

Patrick Pena:
[36:27] There are a million interesting books out there I definitely would recommend all of the lead developer conference videos I haven’t been able to attend the conference yet but I definitely,
will spend the time to go through all the videos that end up online I found that super valuable.

Christian Mccarrick:
[36:47] There’s one coming up in New York for you soon in April.

Patrick Pena:
[36:48] Yes yes I’m going to think I have a scheduling contact but I’m going to try to go to that one.

Christian Mccarrick:
[36:55] Anything else that you might recommend.

Patrick Pena:
[36:59] I think just focus on the parts of your crafts that are not engineering specific.
Look for books or content around communication and effective communication now there’s a great book that I recommend to a lot of people called crucial conversations.
And it’s around giving feedback and how to how to communicate around topics that aren’t necessarily easy with others and I would say anything in that Realm,
around,
communication Styles in communicating effectively and how your brain works in the growth mindset there’s lots of content out there it’s yours for the choosing and I think.
The biggest part of that for me when I talk to people is consider that part of your craft especially as you move up into higher and higher leadership roles that side of the crap is more and more important.

Christian Mccarrick:
[37:59] Absolutely couldn’t agree more No Patrick if anyone wanted to reach out to you to invite you to speak another conference or just to talk about any of the topics we have discussed today what’s the best rate the best way for people to contact.

Patrick Pena:
[38:12] I’m on Twitter my Twitter handle is Patrick J Pena Patrick J and then Pena after my last name I’m also on LinkedIn you can find me on medium,
Britain a little bit for myself and a little bit for The Country Network.

Christian Mccarrick:
[38:29] Awesome both Patrick appreciate it it’s getting later in the day on a Friday in New York so I really appreciate the the time to have this conversation today really.

Patrick Pena:
[38:39] It was my pleasure thank you so much for having me.

Christian Mccarrick:
[38:42] Thank you bye.