Season 2 Announcement + REPLAY: Farhan Thawar, VP of Engineering at Shopify, on Culture, Leadership and Leveraging A.I. to Ship Better Software

[00:00:00] Welcome back to the Convergence Podcast. As our team's putting on the final touches of the Season 2 premiere with Mike Gayherd, Mike's taken experimentation on A.I. coding assistance to the next level, we wanted to air a replay of an episode with Farhan Thawar, the VP of Engineering at Shopify. Shopify are power users of A.I. coding assistance. They even had really early access to GitHub's co-pilot before it was done.

[00:00:30] It was generally available to us in the market. And I think there are a lot of very interesting nuggets in the episode about Shopify's culture and leadership. And we specifically wanted to give y'all a refresher on Farhan's insights about how Shopify uses A.I. coding assistance to help them ship better software faster. Incidentally, this was an earlier episode in the Convergence journey that many of you may not have listened to yet.

[00:00:58] And I think it really sets a great stage for next week's episode with Mike Gayherd on A.I. assisted product development. I hope you enjoy the episode with Farhan and we will see you next week on our Season 2 premiere. Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand.

[00:01:54] This is what teams are made of. Hey, folks. Welcome to the show. On this episode, we get to speak with Farhan Thawar, the VP of Engineering at Shopify. Farhan joined Shopify by way of acquisition of the company Helpful, where he was one of the co-founders. Before that, he worked on leadership roles at companies like Microsoft and Trilogy. And I have personally had the pleasure of working with him at both Extreme Labs and Pivotal Labs, where he served as the vice president of engineering.

[00:02:24] I've gotten to learn a ton from Farhan over the years. And I've especially been inspired by how, as a leader, he's able to drive a culture of high-performing technical teams, where the team is also really engaged and it's super fun to work at. And it's easier to do on smaller teams, but I've seen Farhan do it in the hundreds, if not thousands of people.

[00:02:46] On the episode, we get to talk about Shopify and how it's run like a giant experiment, where experimentation and R&D isn't just limited to the product and engineering teams, and how they're utilizing generative AI, both for their customers, as well as for their internal teams on things like Copilot as a pair programmer. Now, if you know Farhan, you know he's been a huge proponent of pair programming historically.

[00:03:11] So it's been really awesome to hear the evolution of the use of this tool in a hybrid work environment, and how some of the correlations that they see between high performers and likelihood to pair leads to better results. We also get to more broadly speak about the cultural elements and some of the systems and frameworks they use to ship better products, keep their code bases simple, and how the leadership at Shopify stay really connected to the work and stay technically sharp.

[00:03:41] I've also always known Farhan to be just a recruiting powerhouse. And we get to talk about how he collaborates with his peers on the people in HR team by being helpful, and some of the things they do to attract and interview what he refers to as candidates. Subscribe to the podcast to get future episodes as soon as they're published. If you find this helpful, give the podcast a five-star rating on your podcast app, or hit that like button on YouTube.

[00:04:11] I had a ton of fun recording the show, and I learned a lot. I hope you learned something too, and I hope you enjoy the show. Give us just a little bit of a background here. I know you went to Waterloo, and then you did a number of cool roles. We got to work together on some of them before you ended up at Shopify, so talk to me about that. Sure, yeah. So I kind of had like my careers kind of split into like I would say different decades, right?

[00:04:39] Like the first decade was really – I went to Waterloo and did computer science and a minor in electrical. But it was really focused on like writing lots and lots of code. And I had a lot of fun doing that. And what I realized in that first decade was when projects didn't go well, it wasn't always the code. It was like requirements or like talking to the customer. Like it was things around the code.

[00:05:02] And so I ended up playing like dual roles there where I tried to like either organize the team to make sure we were talking to customers and getting feedback and making sure that customers own the problem and we own the solution. And then also realized that my leverage will get better when I started like doing like spending time outside of the code, like recruiting or helping people get unblocked. So I moved into engineering management. So I spent like I would say the next decade doing a lot of engineering management.

[00:05:29] And then lastly, in the last five years or so at Shopify, I kind of married the two. Like got much, much deeper in this last five years than I have been in the last decade for sure. But at the same time trying to still have that same amount of leverage by running a large engineering team. So kind of marrying the two things by still going all the way down and going deep. But at the same time trying to be as broad as possible and spend my time on the things that I'm good at, like recruiting and other areas outside of just like the code. Cool.

[00:05:57] I mean, let's jump on recruiting because I know when we worked together, you were just a recruiting powerhouse. And it was stuff like working with the HR teams and figuring out what kind of systems, but also some like small tactical things, right? You put the logo of the company in the back of the T-shirt so you know like the next batch of interns are going to be seeing it in lecture. Sure. So you're a much bigger org than when we worked together. How involved are you in recruiting now? And like how much can you delegate? How does that look?

[00:06:24] Yeah. So I'm pretty, I mean, very, very involved. I mean, I know when we kind of changed models, right? When I first got to Shopify, I remember meeting with the recruiting team because I am, you know, somebody who likes to get involved in recruiting. And I remember meeting with that team and they're like, oh, you don't like, we don't need your help that much. Like we actually have like this own machine that's kind of running. And I was like, it's not really how I like to do recruiting. Like I like to be chatting with people out in the industry all the time. I make connections from people right out of school and interns all the way up to like senior people.

[00:06:54] And I like to play it as like a very long game, right? Like meaning you might meet somebody like one day and then three years later, they might reach out to you and you've, you know, stayed in contact with them about the problems that they're working on. And then it turns out that the overlap of what they're doing and what you need has come to fruition only then. And so from a recruiting perspective, I spend a lot of time talking to candidates. I like to inspect the process as well.

[00:07:20] And so when I meet candidates and then they apply, I actually will have, make, have a back channel. Like I'll say, hey, well, how was it? Like, how long did it take? How was this interview? Did you find it useful? What about this part all the way through to the offer? And it's a good way for me to kind of spot check our process. I'm always trying to like do that feedback loop. The other thing I would say is I'm a big fan of like try before you buy, if you can do it. Meaning like, can you have like, has somebody been interned?

[00:07:46] It's like a job interview for them and us because they could realize that it's not for them. Same with like contracting or same with people onboarding. I try to make sure that the first three months of anyone starting is really a way for us to both see if this is a fit. From a company perspective and what we expect. And, and if it's not, let's, you know, call it early. If it is working, let's double down and make sure that we're focusing on the strengths of the, of the person and what their, what their new role is.

[00:08:14] And so, you know, we have this idea also where we like to be pretty hands-on. Meaning like we say in these words, sometimes explicitly like, Hey, we don't think like micromanaging is a bad thing. Like we want to make sure that everyone's pairing and involved in all the decisions. And that could be different for someone coming in from the outside. Right. Everyone's going to be involved. You might comment on your PR. Like that's normal. And that's because we want the best people working together with the rest of the best people.

[00:08:43] It's not like hire smart people and let them do what they want. It's like hire smart people and pair with them. That's literally what we try to do every day. And so a lot of things come out from that. I love how you're incorporating things like design thinking and looking at the candidate experience. You're applying a feedback loop. You're doing like lean validation in other words. You use all the jargon words altogether, right? We would never use these words, by the way. I know. This is just how we look at the principles in another world, but you're bringing it into recruiting as well.

[00:09:13] And it's not just for the product folks, it's for the entire org. So was that like... Yeah, the whole org, the whole org is like that. The whole org is like an R&D experiment, meaning bring smart people together and interrogate how we build everything, including how we build the company. And so what's the advice for like a CTO, VP of engineering, getting into a role? They see this, of course, because they've built products this way.

[00:09:40] And then they bump up against like head of HR who says, no, that's not how we do things here. And what's your advice there? Any battles you've had to fight at Shopify or before to kind of change that mindset? Yeah, sure. So I spent a lot of time just being helpful. Like if you remember, my last company was called Helpful. And what I try to do with folks is try to just be useful to them.

[00:10:03] So for example, if let's say I wanted to make a change in the recruiting process and the recruiting process was pretty standardized for a long time. And then what I would do is I would try to offer help and say, hey, I realize that this part of the process is how we do things. But let me help you. Let me share with you like data that might show that. Let me show you some data that shows maybe we should do an experiment in this area. Or let me show you some data that shows that, hey, in this experiment we did, we removed a part of the process.

[00:10:33] Or we actually added a step in the process. And what did that do to the candidate experience? Or let me help you by sharing data what other companies are doing. Or let me go and interview other companies or interview at other companies and tell you about their experience so they can learn. Like the whole point of it is to teach myself, number one. But then teach others and just share. And what I've realized over time is by being helpful, people with a growth mindset want to learn and want to realize that they can get better at things.

[00:11:02] And might take that information and say, actually, I know we've had this process well, but you're bringing up a good point. Maybe we should experiment or maybe we should try this or maybe we should try that. And we also have this line here on process specifically that says, and it's a good short circuit. We say a process can only be added if it makes something possible that was not possible before. Or if it makes something 10 times easier. Right?

[00:11:31] And that is a real good framing because if something's being added, we're like, well, what is this enabling? Or is this making something faster? Otherwise, we don't add it. Right? And there's also a famous Elon Musk quote that says, process is not a substitute for thinking. Right? So I'll give you an example, actually. I was talking to a very senior candidate who I talked to in 2022. Went through our entire recruiting process. Got an offer and then decided to go somewhere else.

[00:12:01] Okay? Now, they just reached out to me. Right? It's 2024. What does our process say? Well, our process says, like, interview everybody. Now, we already interviewed this person. Right? They're quite senior. Now, maybe I want to check something about the last two years of experience. Maybe my process has changed. I want to check on cultural alignment or value alignment. That's totally fair. But outside of that, does it make sense to put them through the same, like, six technical interviews? Like, probably not.

[00:12:28] And so that's an example of where you might just look at the process and say, oh, the process says do this. But using your brain, you would look at that and say, actually, let's check values alignment. Maybe let's check something about the last two years of what they've done. And then I would just go straight to offer. Right? Unless those were different. Now, we also do something here where every person must be, like, sponsored by an executive.

[00:12:55] So, you know, I'd be putting my stamp on it, my reputation on the line to make sure that this would, you know, this – I would follow through that this person actually is a fit for Shopify. And maybe I'd learn something from that if it didn't go well. But it's an example of where you might want to go outside the process. And to clarify, every person must be sponsored by an executive. This is when you break process where someone's co-signing that? No, no, no. That's just how we do all recruiting. No, all recruiting. So anyone coming in at any role?

[00:13:24] That's part of our regular – that's part of our regular recruiting is that everyone's got to be sponsored by somebody. Because we really want to make sure that the people coming in here have, like, a yes. Like, yes, I want this person here versus – because here's what can happen, right? You can have a process where, like, there's no no's and so then the person just gets hired because that's the process. And that's not – you don't want to have somebody because there's a bunch of not no's. You want to have a person because there's, like, a yes. Actually, a yes might actually be followed by a no from someone else.

[00:13:54] And that's, like, a spiky person that you might also want in your company. So interesting. And going back to the process cannot be a replacement for thinking, you know, I had some, like, dumb luck when I was in engineering school. And you probably had this saying where you're forced to do non-engineering electives. And I hated writing, which is, like, kind of ironic because I spend so much time trying to learn writing now.

[00:14:19] And so I would go find, like, the multiple choice type of examination courses and only pigeonhole myself because I knew I could do well at those. And I'm optimizing for grades, not for learning, unfortunately. But anyway, one of the things I got to learn was critical thinking because that, again, ironically, critical thinking was a multiple choice course, which I don't know if it should be or not. And I've heard that at Shopify – you mentioned thinking here.

[00:14:43] I've heard that Toby also, like, really focuses on this, like, science of thinking or this, like, thinking about thinking. And he's had thinking clubs and stuff. You and I have talked about mental models before. So how do you do that as a culture? How do you do that as a big organization where you focus on the skill of thinking? Yeah, it's a very – so Shopify is a very cerebral organization. We have a book bar which has, like, systems thinking is one of its books. We interrogate mental models a lot.

[00:15:13] We think about things, like I mentioned, like, you know, process shortcuts to say, hey, don't have a process if it's not going to enable something new or make something 10 times faster. We have a writing culture. So when someone asks a question, if we can't point to a link or a doc or some write-up, we have a hard time reasoning about it because we don't know if somebody has actually spent the time to actually interrogate their thinking process there.

[00:15:37] Now, there's a downside to this where you could overthink and overwrite. And now, you know, you write a document and everyone's got to read it. Like, are you just wasting everyone's time? So you have to be careful on, like, what you're actually trying to accomplish.

[00:15:53] But culturally, we do a lot of the thinking in – I would say inside the company, like, in public inside the company, whereby, you know, if someone's asking me a question about how should we think about payments infrastructure or how we think about resiliency, like, we will – someone will have likely thought about it and written something down. And we might codify it somewhere, either in our wiki or we have something called the codex.

[00:16:18] And that allows us to then share the fully formed version of the principle to everyone else. So that's a shortcut for them to use in the future. But it is much more a writing cerebral company than I've ever been at. And sometimes feedback you might get from something might even say something like, you know, how did you come to this conclusion? Right?

[00:16:43] In which case, having somebody walk through the thinking and you say, oh, I see an assumption you made here, but I've got context over here that you might not have that might change how you think about it. Let me tell you about it. You might say, oh, knowing this information, my conclusion might change now. So let me take that new information.

[00:17:00] So we try to, like, you know, face – like, come face-to-face with reality quite often because that might actually change your thinking and then change the conclusion of where you end up. And I know I'm speaking, like, in the abstract, but it's not that abstract. It's like, here's a project. Here's the data we've seen. We know the customer likely knows way more about the problem than we do. But at the same time, we likely know more about the solution than they do.

[00:17:26] So let's come together, spend time, and figure out, like, what is – do we understand the problem better? And then can they understand how our solution might help them solve that problem? But you want to make sure you are doing both sides of that. And we do think – we do a lot of thinking here. But I will say one thing before people, you know, if they're listening to this podcast, say something like, wow, you know, there's lots of thinking and a lot of doing.

[00:17:51] We have this other principle, which is maybe counterintuitive to what I said, which is something around action creates information. And so actually doing things – so, yeah, of course, thinking and there's docs. But, like, actually doing something, like building a prototype, trying something multiple ways will produce information that you can then refine your thinking on. So one big thing happens here is somebody will say, I'm not sure which way to go, A, B, or C. I'm like, cool, go all three ways.

[00:18:21] Try all of them. And then let's look at – if it's a coding example, build a prototype with all three different libraries, look at the coding and the runtime characteristics, and then decide. Versus researching and talking and writing a Google Doc, that's probably not something that is like how Shopify works.

[00:18:43] Fostering an engaged product organization and aligning them with the principles around lean, human-centered design, and agile will more than likely lead to successful business outcomes for your organization. But getting started or getting unblocked can be hard. This podcast is brought to you by the player coaches over at Integral.

[00:19:03] They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile. Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:19:23] During this session, the Integral team will facilitate a problem-solving exercise that gives you clarity and confidence to solve a product design or engineering problem. That's integral.io slash convergence. Now, back to the show. We've heard time is money a lot, but I think time is especially money in commerce, maybe.

[00:19:49] And so there's this culture around performance that you need to have as well that I'm sure is a lot more critical than maybe some of the other roles. And so how does that kind of business problem of performance get translated into decisions on this side, like core decisions around architecture or even kind of higher level decisions?

[00:20:13] Yeah, I mean, the way we think about it again is it's like we're building the infrastructure, right, for commerce on the Internet. And so when you're building infrastructure, you know, and there are other modes where we're building an experiment or building a feature. But when we're building infrastructure, it's done when we build it correctly, not done because of a time frame. Right. So we do move the company on a cadence of weeks.

[00:20:38] We do still look at weeks and, you know, what happened this week and let's demo and let's interrogate if we're going in the right direction. But it's also like a path finding mission for us. We're trying to find the right path. So you may spend, let's say, 12 weeks trying different things, then delete everything because now you know where to go and then build the direct line because you've explored the territory. Versus just trying to incrementally build on top of what you built last week.

[00:21:06] So it's a little bit different in the approach it. And you're right. Performance is everything. But that doesn't mean that if we have been traveling the terrain and looking for the right path that we shouldn't start over. Because a lot of times, you know, you know this from coding or building a house, like starting from scratch is faster. And so especially because now you know what to build and now you have all the learning to move forward with.

[00:21:33] There's a cool anecdote where Toby and, you know, I think his first CTO, they would pair program in building parts of Shopify. And what they would do is they would say, we must build this component in less than one hour. And if we cannot, we delete all the code and try again. Because what we have built is actually not the simplest elegant solution to this because we have gone down the wrong path.

[00:22:00] So let's and sometimes what happened is they would so they would leave the tests, but they would write the code again. And sometimes they would go over by one minute and they would delete the whole code and start over and write it again. And that a lot of that code is still alive today in Shopify. So it's the right thing sometimes is like it takes longer. But now is infrastructure. You can build everything else on top of and is longer lasting. And so paradoxically, kind of like pair programming. It is faster.

[00:22:26] It just feels like slower to some people who are used to the collateral or the code that they've written as being the artifact instead of the learning. Because the learning is compounding. Exactly. And guess what? You know, it's funny. Also, paradoxically, engineers love writing things over. Like, you know, if you told everybody, hey, you're going to be able to write this system from scratch, knowing everything you know. They actually love that kind of project. But it sounds it sounds weird when you propose it because they have to delete the code. It's a sunk cost.

[00:22:55] It's like delete everything. No, no, I worked so hard on that. You're like, well, what you worked on really hard is learning. And now you can take that learning and build something better. So I've had this kind of notion that I haven't fully formulated. And maybe we could try and do it together where, you know, let me do extreme programming. The analogy is we turn everything to 11, like Spinal Tap, right? And turning this to 11 is saying, hey, what if like I told you that your code would self-destruct in 18 months?

[00:23:24] So I think I can't fully I haven't fully formulated, but I think we'd write code differently as engineers. If we were just told like, hey, 18 months from now, this is going to like self-destruct. So write it optimized for 18 months or six months, whatever. And I'm curious to know, like what that what reaction that gets for you. Yeah, that's something it's interesting. I think I mean, what I said before was kind of the opposite is the code ended up lasting forever.

[00:23:49] But I do think that there is something about the learning lasting and the code not lasting. So maybe I'll take it in a different direction. I think that you want to have less code overall. Right. And so one of the things that I tweeted out was I think we were there was a ranking of largest Ruby code bases in the world and Shopify was not at the top. And some people messaged me like, I can't blow. You're not like, aren't you going to try to be number one, whatever? I'm like, I never want to be on this list again. Like I would.

[00:24:18] And I wrote a post internally called largest code Ruby code base. What about smallest Ruby code base? Like that's what we're actually going for. And we we want to make sure that we have the right code, not like, you know, and we know this code is liability. One of my favorite tweets about pair programming, right, is the the one that says, well, if you have two developers, one machine, won't they write half as much code? And then the answer is, oh, no, no, no. They're going to write even less than that.

[00:24:45] Because the goal is like the elegant, simple solution is not a lot of code. And the limiter is not hands on keyboard. That's not the throughput limiter. It's actually that the thinking is the limiter and having two people spar and come to the right solution is going to be net faster, less buggy, more information sharing, happier. Like developers, you know, come from this pairing idea.

[00:25:09] So your idea is interesting, like if the code self-destructive, but I actually think that there's learning and then there is the right elegant path. Because what's happening in your case is you've now found the right path and then you want to destroy it. And I don't think that's the goal either. I think you want to do a path finding exercise. And as long as it is not the right path, yes, destroy, start over, destroy, start over, destroy, start over. But then when you find it, that thing will last. And you likely don't have to revisit it.

[00:25:38] And so I think that you do want to destroy everything but the last one. Mm-hmm. Makes perfect sense. And a lot of them you've said kind of like the correct solution or the right one. And so a lot of measurement has to come into play, I'm sure, because it's like you did, not just working in engineering, but on the team side, on the business side, product side. What's the approach to measurement? How do people get a gauge of like, hey, am I pointing the ship towards the right direction? What's the North Star kind of thing? Yeah.

[00:26:08] Well, I think, you know, measurement, like, you know, Goodhart's Law is like any good measure once that becomes a measure fails to be a good measure, right? Basically because people over-optimize for it. So I think measurement is tricky in that it can become, you can optimize for the thing that you do not want. And so I think you have to be very careful on measurement. That doesn't mean you shouldn't look at things and try to measure. It just means that if it becomes a goal, right? So here's a good example. Let's talk about lines of code.

[00:26:37] If I said, actually, smallest Ruby code base is our measurement this year, like people would go crazy and just start deleting things, maybe things we actually need, or they would write code that is much harder to reason about because it's more, because it's compressed. And that may be not what we want either. So it's a little bit of, there's a little bit of art and science in the answer. You want to measure things because on aggregate, maybe there's something interesting there.

[00:27:04] But you probably don't want to goal people on, hey, we're going to measure you based on like how few lines of code you write. Because of course the answer there is zero, although that could be a good goal for something if the code already exists. You could use an open source library. But you want to, it is a little bit of art and science. And I think this is true in maybe more domains than people realize. But it is, you know, it doesn't mean you shouldn't inspect. Like I still tell people when they ask me, what is your number one way to gauge like engineering productivity?

[00:27:34] One of my favorite ways still to this day, you'll remember this from the extreme days, is weekly demos. I love weekly demos as a way to gauge progress because it forces everyone to be focused on a little bit of like movement, right? Action creates information. Action. You can and should like in a future week say, oh, you know, we had all this progress, but we now found the path. So we started over, we deleted everything. And now we're going to move much more quickly on this new path. That's open to you.

[00:28:03] But forcing you to kind of have contact with reality, which is what a demo does and then get feedback and be heckled and be in coopetition with your peers on what they are learning and what they are building. I think it's super powerful as a productivity. I don't know if it's really a measurement, but I guess you could say a productivity measurement. It's weekly demos. The forcing function one way or another for sure. Yeah. And so while we're, you mentioned pair programming a few times.

[00:28:32] And so I want to talk about kind of team structure, right? Like we were fairly like pairing all the time. Most code is written on pairing stations. If we have to stray from that, it's side by side programming is what we did back then. So you still get a lot of the benefits, even if you're adding a little bit of risks without completely taking the foundation out. Now it's a hybrid world. You probably got teams on multiple time zones. How does pairing work? That might have been new.

[00:28:59] There was already a lot of engineers that were chipping away at Shopify when you joined. So how's pair programming viewed? Yeah. So I'm still a huge believer in pair programming and being at Extreme and then Pivotal, even my own company, we paired nine to six every day. And what we do at Shopify is different. We still pair, but we no longer, like I no longer believe that that's the only way to get value from pairing.

[00:29:25] So for example, we do have lots of folks in the same time zone. Some teams pair like multiple days a week. Some folks will just pair a few hours a week. But we do see high correlation between pairing and those who are successful at Shopify. In particular, we have this leadership question, which asks people on the team, is my manager technical enough for this job? Like it's a way to gauge technicality because we are quite a technical company.

[00:29:54] We want to make sure everyone has the technical foundations to do a great job here. And again, high correlation between those who pair and those who get a good score on that question because it's likely tautological. Meaning if you are pairing with your team, they're likely to give you a good score on that. But also if you are pairing with your team, you're likely to be in the details and in the technology. And so like you would imagine pair programming, you get correlation only, not causation, right?

[00:30:23] Like do good engineers pair or does pairing make you a good engineer? I actually don't care what the answer is because I think pairing is net positive. So if you pair and it makes you better, great. If you pair because you are good, great. Either answer is fine for me. But we do have a pairing culture here and it has been growing at Shopify, but it is not the nine to six.

[00:30:46] You know, I mean, we've all seen also like very strict in where any code not written pairing gets deleted. Like there's all kinds of, let's say, dogma, but also, you know, even like even very constrained environments, right? I mean, that wouldn't want you to not pair. We're not like that. Fair enough. And I mean, you can kind of look at the plus plus on that is using Copilot, right?

[00:31:15] Which you could argue is like a pair, even if your pair is sick or whatever. 100% using Copilot. And then is this pairing mindset? I know you're huge adopters of Copilot. Did that pairing mindset, if you had to guess, make it easier to adopt Copilot? Yeah, for sure. I mean, I think if you watch all the videos from like GitHub Universe, you'll see that they use the pairing analogy quite readily because it's like a pair programmer.

[00:31:43] I would say for me, you know, what it does is for leaders who used to code a lot, it helps you get unrusty quick because you might be in a language you're not as familiar with as your primary language. And Copilot can really help you not get stuck and not feel like you have to start from zero. So I think it's good for that. But it does, like what you mentioned, it does give you this feeling of not being alone. Like I'm not alone making this, writing this program. I actually have somebody who's helping me.

[00:32:12] And that I think has a little bit of the pairing nuance. One thing we tried, which I couldn't really get working, and I think they just deprecated it, but maybe it'll come back, was for accessibility. They had like a voice copilot. So you could almost like hear it and talk to it. And then you're like really like impairing because you're not like you're not even typing to the chat. You're actually like talking out loud.

[00:32:36] So I hope that there's more innovation in that area because I think then you can really like have a pair program where it's talking to you. I feel like that's a matter of time. I tried doing the same thing of trying to turn accessibility mode on. And the accessibility features I think are going to come a long way with Gen.ai and what you're talking about. Something to try is I know you like experimenting that works for me is I've been trying to learn how to code again, especially in this new realm of coding.

[00:33:04] It's been like over 10 years since I shipped production code. And a few ways. One, I get up at 5 a.m. on certain days, and one of my engineers is also trying to do 5 a.m. club instead of like scrolling Instagram late at night. Let's try to do something productive in the morning. And we say, hey, I'm going to show you some stuff that's important to our business, and you're going to show me how to like write Gen.ai code to see if we can go change how we do finance or marketing or whatever. Right. So some days he's not available. And what I will do is I'll record myself on Zoom.

[00:33:34] And there's this like accountability aspect that comes into play where I'm less likely to go down rabbit holes or get distracted and other things just knowing a future person may be watching this recording. And so that is why I'm not alone because of this hypothetical person in the future. I forget where this which company this came from. That's one thing to, you know, maybe try out. We can compare notes later.

[00:33:56] But while we're talking about this, like what we're doing here, what I'm doing with the 5 a.m. thing is I'm trying to like keep my skills sharp to be ready to lead in a new paradigm. And a lot of the things you said, whether it's recruiting, other reviewing, like pull requests and other things like that, you're staying sharp as a leader. And that's not necessarily the case across the enterprise. Right.

[00:34:21] So what is like advice you have for your peers or people that report into you about staying sharp that way? Yes. I actually like that your accountability club idea, like the 5 a.m. club. So one of the things I try to do here is scheduling like pairing hours. And so what will happen is my admin will basically like just ping a different direct report every week and say, hey, Furhan's going to pair for an hour with someone on your team.

[00:34:46] Pick somebody and then she will schedule an hour with that person and then I will just pair with them on whatever they're working on. Sometimes it's a tech design. Sometimes it's, you know, I paired with somebody. They were building developer tools. Like it was a BS code plug-in. Like these are kind of really just a way for me to get to know a person, but also to like be in like an editor when we're talking and ask questions. And what I find is even if I don't know the language, like I was pairing with somebody, they're doing Lua.

[00:35:13] I've never done Lua, but it's interesting for both people because it's interesting for them to hear how I'm thinking about what they're working on. And it's interesting for me to watch them go through the developer workflow and see the entire end to end of trying to build something. And, you know, sometimes you get something built in an hour. Sometimes you don't get that far. But I think that's one way. Another way is because we want a technical leadership team. I do a lot of interviews with folks and we do coding in the interview, even all the way up to the VP level.

[00:35:41] And we encourage them to use Copilot, by the way, because it's part of today's world. It's kind of like saying, don't use Google, don't use Copilot. We're like, well, Google, you can use whatever you want because you can have the whole thing available to you. And I do a lot of those coding interviews with them. So they can see, one, it lets me code, but it also shows them that everyone is technical at the company.

[00:36:05] And ensures that if they are somebody who has left technicality for, you know, getting into management because they are kind of running away from code, that might work well in some companies, but just doesn't work well here. And so we want to make sure that people feel comfortable in the tools, in coding at Shopify. And speaking of some kind of hypothetical company, I think, well, I'm curious, do you think it drives discipline?

[00:36:33] Because like all those folks know, hey, Farhan could drop in to pair with me anytime. So I'm going to relatively keep my house in order. So I'm not doing a bunch of cleanup and stuff retroactively because there's a guest coming or? I think maybe yes and no. I think that, yeah, culturally, if the leaders are more technical and ask detailed questions and do technical reviews, like that gives the team and the company like leeway to say, you know what?

[00:36:58] I need to prioritize this against features because I know that, you know, the Steve Jobs, the inside of the MacBook must also be beautiful. Right? So I think that is nice. But I also just think that it shows them that depending on which career path they want to go down, whether it's individual contributor, because you can go all the way now at Shopify or management, that technology is something that we are in love with. We are technologists and we are, you know, in love with, you know, software.

[00:37:28] So if that is not your ethos, then maybe Shopify is not the right place for you. But if it is, you can figure out so many ways to have impact here via your love of R&D and software. For sure. Hey, something that I think you tweeted lives rent-free in my head and I want you to talk more about, which is complexifiers versus simplifiers. And I'm always wondering, like, am I being a complexifier or simplifier? And I start to see this in other people too.

[00:37:57] But I've made so many assumptions from your little tweet to how it's going. So give me a little bit more about how that came about, how you use it. Yeah. It's funny you picked that up because actually I don't think you got that much pickup on Twitter, but it's actually how I've been thinking about a lot of things over the last six months. So usually when you're, like, going through either, like, performance management season or interviewing people, you're typically looking for a set of capabilities.

[00:38:24] And a lot of times it's, like, technicality and leadership and problem solving. But rarely have I seen folks use this as an axis, like, complex versus simple. Sometimes it shows up in, like, the solution somebody might produce and you might say, okay, that's overly complicated. But it's very rare that you would use it as an axis to, like, actually, like, I don't know, use a crude word, like, sort people.

[00:38:49] Like, this person's smart, but that person's smart, but they're a simplifier. And it turns out, like, you know, there's this cool line from DHH, right, the Ruby on Rails guy, where he said, complexity is a bridge, but simple is the destination. And so basically, you can use complexity to get from A to B, but you may not stay. You cannot stay on the complexity bridge. You must get to the simple.

[00:39:17] And so I've been starting to use that lens a lot more when I'm talking to people about, like, the problems that we are solving. And if there are five subsystems, I'll notice people look at the subsystem and say, okay, we have data in place A and we need to get to place F. Do we need each of these B, C, D, E to get to F? Or can we just make something that goes from A to F? And is it, are there reasons for all of the complexity?

[00:39:43] And so by simplifying, by deleting code, by deleting systems, by subtraction, which, by the way, is really hard to use, can we make our lives easier? And so I've really been using this, like, way, like, this mental model in my head around people who are simplifiers, because it's such a powerful way to think about who you want to surround yourself with.

[00:40:05] And then, you know, there's a line that Toby's chief of staff, one of his, sorry, his distinguished engineer, technical assistant says, Duncan, he says something like, what are we doing to make this more complicated than it needs to be? Same idea. We asked that question in a tech review. Like, what's so, like, can this just be simpler? What's, or what's the simplest thing that could work here?

[00:40:29] And a lot of times the simple thing is the thing that ends up being the infrastructure you can build on top of, because everybody understands it. It doesn't have a lot of indirection. It's very performance, usually. Like, all those things come because it's simple. And so it sounds funny, but, like, engineers and, like, lots of, there's lots of smart people in the world. But it is smart when you try to, like, use the, like, the easiest thing. But a lot of times you want the simplest solution that can work.

[00:41:01] I hope I'm not butchering who it is. I think it's DaVinci that said simplicity is the ultimate sophistication. And we can add that to the list of DHH and Toby and everyone else. All right. Yes, exactly. I like that. We talked about Copilot. Talk to me about generative AI. What are Shopify's customers seeing? What are you using it for your team? What are you excited about there? Yeah.

[00:41:27] I mean, I think no one is, like, not using Gen AI now, right, with the launch of ChatGPT and these tools. I think there's a few different ways to think about it. One is, what are all the things that we're building for our merchants, right? We want to make sure that we can save them time and they can, you know, spend all their time building great products and building their community. And so right away, we had something called, like, product descriptions, which is making it easier for them to generate these descriptions that are SEO friendly and vibrant for buyers.

[00:41:55] We have a tool, Inbox, which is a way for our merchants to offer this to their buyers. So a buyer comes to the storefront and asks questions like, where's my order? Can I exchange this for red? Is there a discount? And an LLM could reply quickly. And depending on your workflow, you might want to read it first or you might want to have it auto reply as a merchant. But again, it makes that workflow much easier. Toby put out a cool video about Sidekick.

[00:42:23] Sidekick is kind of like your co-founder and you can have it help you, like, run your business. So again, like, you're not alone, right? And Sidekick is really, like, your person to help you kind of manage your business and do admin operations in Shopify via chat. So there's lots of these examples. And then for employees, right? GitHub Copilot.

[00:42:44] We're testing other tools from other companies as well to see, can we remove oil from people's work, right? We use AI summaries a lot in the company where you might have a lot of text. You might want to just summarize it or you might want to generate ideas. So there's all sorts of places that we're trying to take advantage of this. And I think it's still very, very early days. Like, there's a lot of toil that's being reduced, but there's a lot more to come. For sure.

[00:43:16] And last question for you. And this is less about work necessarily, but I know you've got, like, high standards for products for your own teams, but also for the stuff that you buy. What's something that for your family or at work, like, the physical or metaphorical unboxing was just like, you're like, yeah, these folks get it? Interesting. Interesting. So, I mean, I bought something that I think is getting there, but not yet there yet.

[00:44:14] I bought a Miko chessboard. And I bought a Miko chessboard. So, I think the reason I say it's interesting is because it's putting together all of the things. Like, I love playing chess, but now it's got an AI engine. and it's like playing against somebody because it's a 3D chessboard that automatically moves. It's not like I'm looking at the screen and seeing where somebody moves and moving it. It's actually moving for you. So that's kind of cool. My second answer is the MetaQuest 3. We do a process called six-week reviews

[00:44:43] where every six weeks we sit down and go through every project in the company. Like the exec team takes us three whole days every six weeks. And every other time we do it in VR. And so I'm excited to see how much farther that can go. I'm surprised I don't hear more companies doing this. Like a lot of people do this and like Zoom but I don't hear that many companies using it for VR and we'll do six hours a day in VR while we go through the product reviews and it is quite good.

[00:45:13] And so we do it IRL every six weeks, every 12 weeks and then off 12 weeks we do it in VR. So I want to shout out to the team building MetaHorizons. I want to make sure it continues to get better but it is early days for that too. And so I'd love to have you back on. Maybe the next one we'll do in VR and we'll figure out how to record that. Yeah, we should. So speaking of... Yeah, you can really see how it's different. So you have ports now as well instead of offices. Yep.

[00:45:42] Right, and like we can get set in our own ways and comfortable with never coming in but we know that there's benefit in coming in. What's like a self-accountability or way to hold your team accountable to not forget to come in? Yeah, so I mean, I tell people that we are like 90% remote or like 95% remote. Like I never want to say we're 100% remote because IRL still matters. Like building that, we have something called the trust battery. And if you meet every so often you can recharge the trust battery.

[00:46:12] And then if you're at home, it kind of goes slowly, fades because you haven't been with that person IRL in a while. And so we have times the whole company gets together. We have times when you might get together with your team. We have something called bursts when you might want to schedule something. It's a project kickoff or you want to solve an important hard problem. And then we also have the ports, which is just if I live near a port, I can go in whenever I want. And so there's all these opportunities to have IRL time. I think people need to remember that.

[00:46:42] I don't know if there's a accountability thing that we do, but it's really about making sure that it's available to you and using it because it's there. And so for me, I tend to go in between one and three days a week for IRL time with folks. Thanks for listening to the replay of that episode with Farhan Thaur, the VP of Engineering at Shopify. Stay tuned for next week when we get to hear from Mike Gayherd,

[00:47:11] Also, like Farhan, a Pivotal Labs pivot previously. Mike has spent countless hours experimenting in what I believe a fairly structured way, quite deeply with AI coding assistants. I loved the really thoughtful opinions he's formed on how to best use the AI assistants to get the most out of your product team's talent and capability. Until then.

[00:47:42] Thank you for joining me on the Convergence podcast today. Subscribe to the Convergence podcast on Apple Podcasts, Spotify, YouTube, or wherever you get your content. If you're listening and found this helpful, please give us a five-star review. And if you're watching on YouTube, hit that like button and tell me what you think about what you heard today. Thank you.