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