Shopify on Building & Scaling Engineering Teams in Fast Growth Remote Culture with Farhan Thawar, Shopify

We had a town hall that was already distributed every Thursday at 4 o'. Clock. Those kinds of things don't actually have to change. We already had a culture where everybody jumps into a live stream channel. We watch the town hall, we collaborate, we talk about it, and that allows us to really continue those traditions that were working in the old model and the new model.

I need some traction. You need some traction. Let's get some traction.

Hey, what's up, innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host, Lloyd Lobo. We're a community of over 100,000 people just like yourself, on a mission to help you get the methods, the money, and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more, this episode is brought to you by Boast AI. Each year, the US and Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging Boast AI software to maximize cashback. Check out B oast AI. This episode is also brought to you by Launch Academy, an international tech hub that provides mentorship, resources, network and the environment for entrepreneurs to launch, fund and grow their startups. Since 2012, Launch Academy has incubated over 6,000 entrepreneurs, of which 300 have grown their startups past Seed and Series A and have collectively raised over $1.2 billion in funding. To learn more about Launch Academy's programs, check out launchacademy.ca the man, the myth, the legend.

Farhan. I was gonna say, Lloyd, you're the man, the myth, the legend. I'm just like the sidekick.

I'm super, super stoked today because one of the hardest thing to do is build a massive engineering team and build it for scale. I couldn't find a better speaker for this topic than Farhan. Farhan runs engineering. He's a VP of engineering at Shopify, where he has built distributed teams and transitioned to a full remote culture. He's hiring 2,000 engineers at Shopify and you already manage 500 engineers going to a thousand?

Yeah, so somebody pointed out, they're like, oh, 2,000 engineers. That's one per working hour. So. So we're hiring one engineer per working hour of the year.

That is insanity. And they're all going to be distributed remote.

The whole company moved. So when Covid hit, like in many places, we went remote in March, and then in May, we decided to go fully remote. So happy to talk about that. And so that means everybody being hired is from all over and will not come into an office.

That's crazy. And then prior to joining Shopify, Farhan was co founder CTO at Helpful, which was acquired by Shopify. And I remember Farhan because previous company, I was at Speakeasy, we worked out of Bessemer's office. Helpful was funded by Bessemer, so I'd see Farhan stop by every once in a while. Also, interestingly, we probably grew up on the same street there in Markham. Yeah, you said Kennedy and High Glen is where I spent my late teen years.

Yeah, that's pretty close to me. I was like Brimley and Steeles.

Yeah, yeah, very close. And then before Helpful, you were CTO and then led technical teams at Extreme Achievers, Microsoft and Trilogy. And like today, you're investing in a lot of companies. I think you've done like, what, a hundred angel investments?

Not 100. Maybe like 30 or 40. I gotta count.

You're one of the most unsung sort of active angel investors. You're not very public about it. And just overall, great, brilliant minds in tech and engineering. Welcome to Traction.

Thanks for having me. And when I do, these people always ask, like, why do you do these talks and why do you connect with folks? And there's this line I heard recently which is. Explains it, which is that when. When one teaches to learn.

Yeah.

So I find that by the questions and the engagement, I always end up learning something about the way somebody else is thinking about a problem. And by asking for my advice, I have to go like, why did we do that? Or why would that work today? Or why would it not work today? And so I end up learning things, too.

Definitely. I'm going to use. I'm going to steal that. I'm going to rebrand that phrase by T. By when 1. When one teaches to learn.

Yeah. I didn't make it up, but I.

Read it somewhere, and it's been my hack, too. I hate reading books. I don't know. I can't bring myself to read books. But what I did was I run these two webinars a week for Traction, and Traction's become this massive nonprofit community. And I interview smart people like yourself, and I soak that knowledge in, and it's great. And we implemented in our business but awesome. Foreign. Before we dive into engineering and whatnot, give us a bit about your background. What led you to Shopify and how did it lead to where you are today?

Yeah, sure. So I've always been into tech since I was a kid and I was lucky that actually my uncle, my dad's uncle actually came to my house one day and dropped off like a modem and told my dad I would know what to do with it. And so I got into tech pretty early and I was always focused on being around smart people and learning. And so that led me in my career to like these very weird extremes. Like I joined like a small company. Like even when I did co op, I worked. My first co op was at Craft, Craft dinner, like craft. And I worked in the, you know, IT department writing software and then I went to a very small five person startup, right? So from Craft, which is a giant company to a five person startup as a co op and that the same thing happened to me in my full time career. I worked at some medium sized companies. I worked at small, like I started my own company. So I started zero people. I worked at Microsoft, which is a huge company. And the reason I oscillated between those, it wasn't like a plan. It's always that I've said to myself, I want to work with smart people and hard problems and sometimes it leads you to working at a, you know, larger company and sometimes it leads you to going to a smaller company. And I never really had that like a framework that said, oh, go, go here. Learn something at a big company and then apply it in a small company. I never thought of a career path as being a stagnant or very planned out thing. I always thought about it as, hey, where are the smart people and hard problems. And it was pretty clear when Shopify approached us. We were doing helpful for three years. They were a customer and it was a pretty cool journey. I'm happy to talk about the helpful journey, but it was pretty clear that if we attached ourselves to Shopify that it would be something that we would learn from and work on very hard problems with them versus just trying to be a vendor.

One question though before we dive in. How much was it of you? Going into engineering was just brown parents like my mom. I wanted to be a chef and my mom said, you're either going to be an engineer or a doctor. I'm not paying for chef school.

Yeah. So no, it's funny you say that because my parents, my dad worked for like Revenue Canada, like the IRS equivalent in Canada for 37 years and my mom worked at TD bank so they were very like immigrant, you know, first generation immigrants to Canada and focused on like the kids as going into very stable things. So my dad wanted me go to accounting and auditing. I actually won the accounting award in high school and I did first year accounting at Waterloo actually as in addition to doing computer science I took my electives in accounting and it wasn't till, and don't forget I'm older than you. When I was going to school there was no Internet. Like there was an Internet but there was no web browsing. It wasn't like a field. It was actually hard for me to get a job in co op and it was like it wasn't easy. My aunt actually hired me at Craft so it wasn't like it was like a no brainer and I just went to the co op program and so it wasn't luckily until the end of university like I graduated 98 where there was a field but the whole and nothing against my parents but they really, they actively fought me on doing computers. They said there's no field, there's no jobs, there's no money. So they actively fought me and I luckily just ignored them and said, you know what, I'm just going to spend time doing this because I enjoy it and if there's a job or not, it doesn't matter.

Every decade or generation it changes.

It was pretty clear when I graduated that everyone was like, whoa, how did you guess? Like this. I'm like, I didn't guess. I just did this thing because it was interesting. And a lot of people I know I had my best friend at the time was doing like science and was doing like chemistry and the parents were really mad that he had done that instead of computer science by the end. But nobody knew.

Exactly. And then give us a bit about your helpful journey and the exit by Shopify. It's a great story and everyone should hear about it.

Sure. Yeah. So helpful. I would say it started off actually quite different than most companies. A lot of people start a company because they have a problem they have in mind and then they gather a bunch of people who are interested in that problem. Or you grab a coworker and you're like, hey, we saw this problem with this customer, let's go and start a company around it. We started completely differently. So Daniel DeBeau, my co founder and I, we knew each other for a decade. He started a company called Ripple. He actually tried to hire me at Ripple and then he did not Actually, to his, to his credit, he didn't hire me at Ripple. I was at Extreme Labs instead. But he was my customer as we got to know each other as a like a customer, customer relationship. And he decided that after his exit to Salesforce, after the he was done doing what he wanted to do there, he was going to start another company. And so he didn't have, we didn't have one problem. He had a list of 10 problems that he thought were interesting problems. And I said to him, shouldn't we have one problem? He goes, don't worry. Let's build a team that can go after a bunch of different problems that I see as happening over the next few years. And so here's how much of a psychic Daniel is. So the, the first problem we had was we thought about in any fast growing company, it. It's really hard to know who knows what and who knows who inside the company. Meaning how do you forge those connections and how do you understand as people are showing up at the office what they know and how they can, how you can help them and how they can help you. And in many companies I know Facebook and Twitter has this, they have a thing called like the Name game, like a name game program which helps you figure out somebody shows you somebody's face and it asks you who they are or asks you whose favorite soccer team is Manchester United. Like a way to get to know employees. And so we built this AI powered employee directory and it was a way for people to mine Slack email for skills and knowledge that pivoted actually into what we turned into a Snapchat for work, which is basically this idea that you want to be able to communicate remotely. So turn into a remote engagement platform, right? And this is 2016, 2017 before the pandemic, which allowed you to use imagery and audio and video to connect. And so what was interesting about that was every communication tool has always gone from one genre into corporate world. So email started in academia, went into corporate irc, started in the open source and developer communities and turned into Slack. And so Skype, right, was consumer, turned into Zoom. And so there's all these things that eventually end up in the corporation. So I still believe today that some sort of Snapchat like experience will come to the enterprise. Just hasn't happened yet. And then the last thing we built was a live interactive podcasting platform which is very similar to Clubhouse. And so we built it in 2018. We didn't have a Covid market fit like with these. We see the explosion of audio and Audio tools now because everybody's at home. But it allowed us to understand the dynamics around live audio experiences versus podcasts, this ability to interact, ask questions, more like a radio show. And we also had our celebrities on our platform. We had Ben Stiller, we had Greta Van Susteren from Fox News. We had Jake Tapper. But we weren't able to catch the fire that clubhouse caught. And what was interesting about that journey was we built these three tools over three years. Shopify was a customer. And over time, late 2018, it was pretty clear that there was alignment between the tech and the team to join the Shopify rocket ship.

What a great journey it's been for you, right? When going from helpful into this rocket ship. And when you joined Shopify, it was a fairly like, work from office culture, right?

Oh, yeah, it was more than work from office. We had what we called centers of gravity. And so the Shopify centers of gravity were specific offices where certain products. And we talked about this, you know, prior to the call, like, certain pods were located. So if you think about a group of people who are focused on building a product, you have product data, UX engineering. Those people come together to work on a product. And then, of course, there's commercialization. Right. Sales go to market, product marketing. There's all kinds of things that go together. The centers of gravity for different product lines in Shopify were based on offices. Right? So we have a big Waterloo office. Toronto, Ottawa, Montreal. We announced a thousand people. Do you remember this? We announced a thousand people in Vancouver. We have offices in Sweden. Right. In Europe, like in Asia. So we have these. We had these specific centers of gravity where people would come to. Actually, I was brought in to run, like, Shopify, the site lead for Shopify Toronto run Shopify, Toronto Engineering. That was literally the pitch to have me come in. And so we've definitely made a 180 on, like, Office centricity towards the future, which we believe is in Rome.

Covid hit at some point last year. You guys were hopping on this early. You went full remote. And what is introduce us to the concept of moving engineering remote and what that looks like at Shopify. And how do you, like, keep the culture going while having thousands of people remote?

Yeah. So I think there's a bunch of different things, and I don't think we have it all figured out, but I'll say there's a few amazing things about Shopify that like, really showed their, you know, showed their how. How they show their face in 2020. So one was that Shopify is A very pragmatic company, right? Like we're run by a very pragmatic CEO. And that culture permeates itself all the way down through the organization. So when you get information. So first part of the information was we have. Everybody had to go remote in March because of the pandemic. So we all go remote. And what became clear was that it was going to be uncertain as to when we were going to go back to the office. That was the first data point. And it's still unclear. Right? I don't think anybody in the webinar can tell me right now. Offices are really going to open up in every company and depends on which countries they're in, which office and vaccination rates and all kinds of things and how comfortable people feel. So that's. That was the first thing. It's uncertain. And then two was that there has always been a trend. It was slower at first and Covid accelerated a bunch of these thinkings was that remote work was growing as a thing in the world. So over time I started to see more remote postings. I started getting reached out to more often for remote VP engineering positions. Remote work was a trend that was gaining some steam. It was still pretty early, but it was something that was growing over time. So that's the second thing that was happening. And what we realized was we can one be at the mercy of when we think these things are going to open up or we can choose certainty over uncertainty by one attaching ourselves to the trend we already see happening in the world, which is office. Like the reduction of office centricity, the ability to hire the best people wherever they live. And this amazing. The amazing new tools that are coming to remote work to just claim that we're going to go remote forever. And that caused a bunch of things to happen in our company. One, if you used to like work on an ironing board or have a really crappy in the corner setup for your laptop and camera, we just encourage people to say we're going permanent. We were talking about this. Get high speed Internet, get Ethernet, get a good camera, get a good mic, get a good home setup because we're going to be here for a while. That was the first thing we wanted people to really understand that. And then the second thing we said was today is the worst type of remote, right? It's not remote. This is pandemic mode. You can't go outside, you can't go to lunch with your friends, you can't travel to other places. Like this is not really remote today. It's pandemic. And so when we move to remote, there's going to be an acceleration of how we think about it. The tools, the techniques, and the ways in which to create that, those relationships. And so what that means for us is ensuring that we lean in to all the things we want to learn about how remote works and building what we believe will be the best version of remote. So it'll be likely something like 90% remote, 10% in person, getting together. It won't be around an office, but we're still going to probably get together. And your specific question, how do you help new hires get connected, feel connected? What tools are you using? We have to learn all that. So what does it mean to what were you getting in the office? You're getting serendipity by running into people, you're getting socialization, you're getting more intricate trust signals. So we have to replicate all that in the remote world. And so I'm excited to see what tools we adopt, what tools we build, those cadences we build as we roll this out.

How do you fuse different cultures across the globe into your company culture?

Yeah. So I think that there's a few things to think about here. One is that we never really think about Shopify as having a Shopify culture, like, one culture. Even though there was a joke that the Toronto office was better addressed than the Ottawa office because it just had different people in it. And what we did find was each, like product. Each team had their own culture. And that culture was around how they think about the way they communicate, how they. When, you know, where. When they had their rituals for making sure that they were socializing, how they thought about deadlines and how they approached them, how they thought about product planning. Like, each team had their own anyway. And so I see that as an extension of what's going to happen as Shopify continues to grow outside of North America. Right. Like, we have big goals to grow in Europe, apac, and also North America. But I don't think that those cultures have to match. Like, I did an internal talk. I do internal talks. You're doing this webinar. I do this kind of. This thing internally. I did one with our team in Sweden the other day. And it's quite different how the culture of that team operates and how they think about things. But exactly why I think we want to take the best things from each culture and use that to learn about how you might want to run your team differently. But I don't think that we need to have a Shopify culture. That is permeated across the world.

Definitely. And there's this hiring today has turned into gatekeeping. Right. Over the years. If you look at it. And if you just gatekeep for the kind of people that fit your culture, you'll never grow. And openness is probably the most indispensable lever for growth. And so it's about culture. Ad versus culture fit, I think is what everyone needs to adopt.

Let's go. I'll jump on that one. Because don't forget, what's interesting about Shopify is we have over a million merchants and those merchants are extremely diverse. Right. All kinds of backgrounds, locations, products, stories that got them to get into entrepreneurship. So in order for us to build the best products for our merchants, we have to be as diverse as they are. And so you don't want to have a monoculture in that type of environment where you're not building for a specific segment like we're trying to build for entrepreneurs. And as an entrepreneur yourself, the story is so different. Everybody's story is so different. So in order to have the best product for those folks, you have to have a team that is as reflective as they are.

What makes distributed teams more successful, in your opinion?

Yeah, so I think that there's differences between co located teams and distributed teams. I think that there are things you can lean on to think about as advantages and the things you have to worry about that could be disadvantages if you don't think about them explicitly. So for example, in distributed teams, I find that the ability to work asynchronously can be really powerful because you have to by design, write things down more, get, get more of those things that can be figured out from a team that's distributed like have to have. They have to actually be agreed upon in a way that is not, that is actually explicit versus implicit. So if you and I are in a meeting that's synchronous and we agree on something, the team might not know about it. We might not be actually agreeing on the same thing because we're just humans and we're talking the decision, like I said, it might not actually stick as much as we think it will, versus if we were distributed in async, we'd have to write it down, we'd have to agree upon it overwriting, which means we can comment back and forth, it's easier to share. There's likely a place where this can get disseminated to the team, which lets it stick more. As people get onboarded, they can read that decision as well. So I think there's a bunch of things that distributed teams lend themselves to that make it easier. Now the things that are harder are like brainstorming and we're used to like jumping in front of a whiteboard. Trust build, serendipity is harder. And so I think you have to manufacture some of that. So some examples are we have a tool at Shopify called Corridor, which is basically if you're not doing anything at the moment, you can jump into the corridor and it'll automatically match you up and show you people who are also in the corridor. So it's a way to like and it's a video chat, a way to meet with people that you might not normally run into. We have a bunch of Async video tools we use. Right. We have some internal tools. We also are testing out some others like Loom and Descript and things like that to test out what does it mean to send short asynchronous videos that are imperfect. That's the other thing we're focusing on, which is when you're in person, if I say the wrong thing, that's what happens. And so why can't I say the wrong thing on a video? I don't have to edit everything and have it be picture perfect every time. And so I think that's another thing we're working through. And I think there's going to be more, more of a cadence around how you communicate as a company. We had a town hall that was already distributed every Thursday at 4 o'. Clock. Those kinds of things don't actually have to change. We already had a culture where everybody jumps into a live stream channel. We watch the town hall, we collaborate, we talk about it. And that allows us to really continue those traditions that we're working in. The old model and the new model.

If you're starting a team today as a non technical, I'm going to throw it in there because you're an engineer, so you are a non technical founder. How would you build your engineering team who would be the first few people to bring on board to get you to product market fit? You recently were there at helpful. What did you do day one?

Yeah. So it's funny because I think our story is quite different than what other companies would do. Usually in a company you've already decided on the product or the problem you want to go after and so you can spend your efforts trying to understand how to reduce the risk around that problem. In our case, because we had so many ideas, what we did actually was we wanted to time Box two or three months where all we did was talk about these different ideas. And so what that meant was we were going to make sure that we were understanding how much time do we want to spend on validating this idea? Sometimes that was a week, sometimes it was an hour. We wanted to spend time figuring out, are there ways to reduce the risk of this idea by either prototyping or learning about somebody who tried this before and why did that fail? What's different now? We wanted to make sure that we understood the types of resources that would be required to reduce the risk of that problem. We want to understand specifically our team, why are we best suited to go after this problem? Why is now the right time to work on this problem? Is the solution that we think we could build gonna be 10 times better than what exists in the industry? Is there a technical technological advancement that's happening? And so a lot of these are actually focused on how we think about taking the problems and actually narrowing them down versus going after a specific problem. But I think that exercise was super interesting for us because it allowed us to then spend. We spent enough time on each of these that then we found what we thought was the most exciting problem to go after that was reducing the most pain for folks and then deploy folks. Now you mentioned you said, like, who would you hire? So I think the way to think about it is how should we think about reducing risk? That's always how I think about these things. And if the risk is in, and maybe I'll be controversial, if the risk is in go to market, I would hire somebody in go to market first because we think that's the risk. If the risk is in technology, can it be built or is the technology possible? I would hire somebody in engineering. If we think the risk is in, are we working? Is the problem actually one in which we think we understand the scope of it and we're close enough to the customer, then I would hire a product person. If we think the risk is in how the solution works, I would hire a UX person. So it actually depends on what the risk is for me to decide who to bring onto the team first.

And as founders, you're always de risking a couple, maybe one thing at a time, maybe two. Right? Like us at Boast, we were focused on get customers and keep customers with by any means possible. We've raised money and it's like, okay, now let's de risk the tech. What do you, what do you derisk at any given time is key.

But I think that's why it's why people have to make sure that there's no formula. Right? Like you can't just say, oh, I heard. I watched Lloyd's Traction video with Jeff Lawson and Jeff Lawson to De Risk Twilio did the following things. But if you're not doing anything that's close to like building like an API first company, then you have to be careful of not of taking the wrong lesson. Same with me. If I say, if I tell you, oh yeah, the first person I would hire is a go to market person. That depends on the problem I'm going after and my own skill set. So people have to make sure that they're taking the information and not blindly applying it. I think there's that Elon Musk quote. Never mistake a process for thinking.

Yeah, like he's basically like reason from first principles, not an analogy. Just because it works for some people, it won't work for you. And my perfect example of that is my Covid story. I got hit by Covid. I'm like, this feels like common cold and seven days later I'm in the hospital on oxygen. And my parents who are in their 70s, they're fine.

Reason from first principles, you never know.

It may not work for you, you never know. Exactly. But let's say you need to build an engineering team and you got this problem space defined. At what point do you bring on like a head of engineering? This person asks here. My engineering team is nearing 20 developers in a QA. I've been resisting adding this layer, but it's getting to a point where I'm unable to keep up with everyone and give them quality time. And I think he answered his own question.

Well, again, I would say it depends. So I had a. I was chatting with many years ago, I was at a first round capital like CTO conference, whatever. And I was talking to Chris Fry, he was a VP Engineering at Twitter and we were talking about growing our companies and I was at extreme at the time and he said, he told me this amazing story about how he had. He hired so many people, so many engineers at Twitter without hiring any managers that he had 80 direct reports. 8, 0. And I was listening to this story and I was like, that sounds. So I started smiling and he's like, why are you smiling? I'm like, I have 120 direct reports. And so the same. We both went through a similar journey where we were trying to build systems in a way that allowed the teams to not get blocked by having to go up a layer in the stack which requires managers if you think about what managers do and managers can be super important. It depends on like your company, right? This is not a knock on managers, just depends on what kind of company you're in. So if you're in our company extreme, we were building, we were an agency, we were building mobile apps for many clients. Those mobile app teams were two, four, we were doing pair programming. So two, four or six people. Those two, four or six people didn't necessarily, outside of the technology domain have any, have to have any interaction with any other teams. They were all their own, like separate cells, right? In the big organism. They didn't require collaboration. So having a manager there didn't really make sense because we didn't really see the need for those folks to have to have a layered, where they had to have to get unblocked or across company issues, alignment or from a Gantt chart, like any ordering dependency. Like that didn't happen and so we didn't need managers. And then at Shopify, for example, we have a ratio where we want to have around 10 engineers to one manager because there's much more across collaboration, right. We're famously monolithic in our code base and monolithic in our infrastructure, in our organization, such that coordination is required and actually encouraged. And so I think that there's depends on which company you're in. So showing me you're saying you have 20 engineers, that doesn't actually tell me whether you need managers or not. I would actually sit down and be like, what is a manager going to help you do? And if you think that the manager will help unblock you from the things you want to focus on and be really good at unblocking the engineers, I would go for it. If you don't think that's the case. Like he said something interesting in the, in your question, which you said, I can't spend enough time with each person and, or know what everybody's doing. Like, that may not be the goal, right? The goal may not be to know what everybody's doing or to spend quality time with everybody. Maybe the goal is for you to focus on what you're really good at as the, as the founder and for them to be autonomous in their groups and for you to trust what they're doing. Or maybe not. Maybe you do want to have a trust but verify step. So you want to make sure that every Friday you're getting demos to see if things are according to your technical vision, being built correctly. Or maybe you do have to be involved because they're more junior. So I think it Depends on the answer is always it depends. But I've seen and there's a famous Warren Buffett tweet which people have, sorry, it wasn't Warren Buffett tweet, Warren Buffett line that has been tweeted out that people say is maybe not true, but I thought it was interesting which said that Warren Buffett sets compensation for his 250 CEOs himself. And so in theory has 250 direct reports. And so I thought that was interesting as a, as another example of potentially somebody who is trying to be very flat in their organization and have those interactions with those people directly.

Definitely. If you hire super smart people and you know they tell you what to do and you're out of their way, then the interaction is very different than you're hiring. Not everyone is, hey, hire me and get out of my way and I'll tell you what to do. There's a lot of people who want, need direction.

Right.

And we'll dive into that. Hiring junior people growing from within. I have this fundamental belief that the job of a leader is to build, inspire and motivate a team to deliver. And deliver is the lagging indicator in that equation. And if you're invested and help your people grow, you will grow. And I, for me personally, I can't physically be invested in so many people's growth where I can't do so many one on ones. And it just gets overwhelming for me. And so if I can't do justice to people, then I gotta have a fork in the road and have another manager there.

Yeah, but I'll say, but I'll tell you this, Lloyd, when I go back to those. So I told you I had 120 direct, direct reports. When I go back and talk to those folks, like years and years later, they will tell you that was one of the most formidable times in their career. Even though I was 1, 1 20th of the people who like was able, I was able to spend time with them. And it's because we spent, we set the system up in a way to allow them to. I'll take the Dan Pink example, like mastery, autonomy and purpose. They were able to get mastery because they were working in very small teams and they're pair programming, working on very exciting mobile applications. So our clients were Facebook, Twitter, Uber, Slack, Instagram, like NFL, NBA, like these are the biggest mobile apps in the world. 2 It was autonomous by definition because I couldn't manage them, micromanage them because there's so many people.

Yeah.

And then purpose. They were building things that were being used by millions and millions of people. And so I thought of myself as, as like something to be reduced. Right? Like I'm only gonna, I'm only gonna give you bad information or bad context. I was only. My goal was like, I'm here to unblock you. If you are blocked, I can unblock you, but otherwise, like, you don't need me. And so we set up systems to allow those teams to be completely autonomous. We had weekly demos where people would heckle each other. We had a once a week, I called it a. I forgot the name of the meeting. Now once a week meeting on a Thursday where everybody would. Everybody would anchor meeting where all the anchors of the project, one person from every meeting, I would ask them the same questions every week just to pull information out of them. How's your project going? When's the next milestone? Who's the product owner? How's your code quality? Do you need team changes? And that would allow me to pull out the things that I thought were predictors of whether a project was going well or not. And because we were, you mentioned delivery is a lagging indicator. We were delivering every week. So you can really only go off track once a week.

Exactly one week, sprints. So this is interesting here. I like what I'm hearing here is give them the mission, the vision, the values, the metrics, and then get out of the way. Be an input, not an approver. Shay asks here, what about setting goals and targets and personal growth? How do you take care of that without managers? Or do you think engineers don't care about those things? I think everyone cares about those things. It's how do you set the context? What are your thoughts there?

Yeah, so I think there's a bunch of different ways to think about it. I can contrast the extreme way and the shopify way. I think that there is a lot of value in setting up longer term themes for your life in general. So for example, a theme could be, oh, I want to spend time mentoring people. Because that's not something that ends. The problem I have with like goals is that if you have a goal of, hey, I want to be a manager or I want to be a director of engineering or you know, VP engineering, I think those goals are like the wrong goals because you, you might do the wrong thing to try to get them. And I've seen this a lot where people like quit one job to get a promotion entitled at another job. Because that's the goal. Right. They want to be able to show. You talked about this. Your parents sometimes to show your parents or sometimes you want to. You just intrinsically want to show your friends or that you want to get there. And I think that's the wrong thing. I think the right thing is like a theme. I want to help people, I want to learn, I want to work on hard problems. Maybe I want to be best in my field. Like those things, they don't end. And so I think that I worry about having those types of goals now. Don't forget these engineers, if you go back to the Dan Pink analogy, mastery, autonomy, and purpose, they were getting that. They were getting mastery on a new domain, working with smart people. They were autonomous. They were working towards a larger purpose. So that was happening. Same thing's happening at Shopify. Right? Right. We are very. There's very sharp people there. We work in a way to help bring more entrepreneurship to the world. Our engineering team is world class. We work on the fundamental technologies that we like, the ones that we adopt. We are core contributors to all of them. Right. React, React. Native Ruby Rails. There's lots of opportunity to learn there, work around smart people, work on hard problems. What I would say is it's useful to have goals in support of some larger theme. So I don't think a good goal is I want to be promoted, but I do think a good goal is how do I increase the impact I have on my team? How do I help bring others up alongside me? How do I ensure our merchants are getting value from what we build, Whether it's they're saving time or they're able to grow their business. Like all those things are good themes that can have goals attached to them. To say, okay, I'm working on this thing. Merchants spend 5,000 hours in this one area. Can we reduce it to 3,000 hours? That's a good goal. But it's in support of a theme which is let's help our merchants save time. So I think that it's now, a manager can help you with that and mentors can help you with that. And that's why, like I said, at Shopify, we do have 10 engineers to one manager. But I'm just saying, don't just read about a ratio in a book or from this talk and then say, Furhan said 10 to 1. Don't do that. Figure out what makes sense. It might be 3 to 1 in your company, it might be 100 to 1.

But that's a theme that's picking up especially in a lot of Silicon Valley companies. I talked to Jeff Lawson a couple of weeks ago. I've talked to Nab Opendoors head of product and I see more and more that the ratio there is. You got a product team of 10 with a head of product, with a product manager, with a UX person, a director of engineering and then seven engineers. I see that as a recurring theme. We say don't reason by analogy. That's what everyone seems to be doing is like 7 devs and then as soon as they hit that 10 mark, they try to fork a team. We're doing the same at boast. Any sort of caution pieces there? Yeah, sure, that's a good plan. But watch out for these things.

Yeah. So sure you people do. You have to start somewhere and I think it's not a bad idea to like have these trip wires in place to have a look at your team structure when they hit these numbers. But I would. Here's one example. There's a difference between a pioneering team. Have you, have you seen that framework like pioneer, settler, town planner?

No, I haven't. But let's, let's dive into it. It sounds interesting.

Yeah. So it's this idea that there are inherently different kinds of people. There are pioneers who are really good at like the 0 to 1, like figuring stuff out. They tend to be hacky and they get excited by like new ideas and applying like a new API to a different idea. And a lot of it is covered in that book range by David Epstein, which is like people who have deep interests in lots of different areas. And then there's these settlers who are really good at taking that idea like the one to end and then more like productionizing it, turning into something more people can use, helping it scale up, ensuring that it has the right support and has all the things around what you would consider to be a product. And then there's the town planners who are really good at like eking out that next level of efficiency. Taking something from 80, like the. You can think of the. The pioneer is like 0 to 1. You can think of the settler as like 1 to 80, basically the 80, 20 rule, getting it to 80%. And then you can think of the 20. The last 20% is like the town planner. And I think in each type of team and the members that are in those teams, you could change the ratio of managers to ICs. You can think of the town planner team as having many more engineers per manager because you're really in a like an efficiency maximization. And so maybe more than 10, maybe the settler teams are 101 to 10. And then potentially those innovation teams might Be much smaller. They might be like three engineers to a product person. Because you're really like trying shit, but you're not really productionizing anything. And so that's just one framework that you could use to help you think about how many people could a manager support. I don't think it's cut and dry. Also people are different. Some people need more management, some managers can handle more people. So I think there's no hard and fast rule. But of course we are a big company. I have 2,000 engineers. We have to apply some rubric. Even though there's all kinds of different teams. But we let the teams then say, oh, by the way, that team, we're going to structure it this way. That other team, we're going to structure it that way. And I have people I've seen on my own teams. I have some people who have three reports and I have some people who have 18. So it depends on where you are in the cycle and the people involved.

I love this concept.

Pioneers, settlers and town planners. Pioneers are the innovators and the town planners are the people who can like that 80, 20. They take the last 20 and the settlers are the ones that get you to 80. Like for myself, for example, I think of myself mostly as a settler. I'm pretty good at taking the like Daniel was the pioneer. So I can take the thing that he thinks like what's the 25 year roadmap for communications in the workplace? And, and I can get there 1% a week. And so I can. That's how I work. And then the last 20% is probably someone who's really focused on the efficiency.

You know what, I consider myself that pioneer at Boast. I've always done new things and now we're bringing on a CTO by the end of the month and I'm just focused on one new product. Right.

I think there are people are people can span. But I think people like if you take a pioneer and you put them in a town planner role, yeah, you're hated and you won't be good at it. So same with me, right? I'm pretty good at working with pioneers. But if you put me in a role that's, hey, I need you to really, you know, build like 10 new products in this area. I'm not your person. But if you want me to productionize or take to market or work with, I consider myself reasonable. I want to work with unreasonable product founders. I'm good at that. But so I think that there's another, like another layer of personality to think through there. No, I love it.

How you framed it. And in the concept of go to market and sales, there's this similar concept. It's called the Renaissance salesperson. Oftentimes it's the founder who interface with everyone trying to sell the first 10, 20 deals get to product market fit. And if you try to hire sales and like we all look at it as sales, just find a salesperson. It's not right. You gotta find the fit. If you find the salesperson in a pre product market fit company, someone who's used to closing deals on a rapid pace, they're gonna hate it, they're gonna quit, they're not gonna make commission because they don't wanna figure it out. So I think that pioneer settler and town planners concept applies across. I love it. I love it. I'm going to edit this video myself by the way, so to rewatch it. But do you continue using pair programming with your Dev team of 500? Do you have any tools or software specific for this?

Yeah. So I'm a huge fan of pair programming. I think it is the single most underutilized engineering technique in the world. It reminds me of the underhanded free throw in the NBA where it's proven to be more accurate and easier to execute, yet few people do it because it looks dumb. It's very similar to pair programming. I think the way to phrase it for this person is like, are there tools? Yeah, there's great tools. I saw a few come out last week, I think from I saw it on Hacker News, I think something called Co Screen and others. We use one called Tuple T U P L E dot app. We use that one exclusively at Shopify and it is a great way to pair program. I know some people use it for not just programming but other tasks as well. And we have a cool innovation inside Shopify. There's a Slack group called Pairing Sidekicks. And if you join the group, you will automatically once a week get scheduled to pair program with somebody for an hour. And it is awesome because it allows me to meet different people in the organization and pair with them for an hour every single week. And so I encourage people to do that. We have people who pair eight hours a day using Tuple. We have people who pair like one or two hours a week, whatever you want to use. But it is quite good in high fidelity and it's a very small team. I think of four or five people who build that tool.

That's awesome. And Carolyn asked a similar question on the whiteboarding side. Any recommendations for whiteboarding tools. I hear Mural is really good. M U R A l. Yeah, Mural.

So I heard Mural. I heard Miro M I R o Mirror, lucidchart. We use, we've been experimenting one called Excalidraw. So there's a bunch of, there's a bunch of tools here. What we try to do at Shopify is pick one and then make it the standard. And so we're, like I said, we're experimenting with a bunch of these right now.

Yeah, I think if you use Mural M U R A L, I'll try to get you guys a discount. M U R A L CO because they have the same lead investor as us.

Oh, nice. Yeah. And so I think the, the other thing I was going to say on those tools is also the last one is we use also Google Jamboard because that's built into like the G in G suite. And so I know some people have an iPad set up with Google Jamboard and they draw on the iPad and they like just shoot it over to the, to a hangout, for example.

You're adding thousands of people. I can't even comprehend how you add like 10, let alone freaking thousand. So what are some examples of bottlenecks in an organization that sort of can be a poison pill to hyper growth? Right. There are like some little things that happen along the way that could just F your culture and slowing things down. And you're now spending time dealing with this, trying to run through sink and sand.

Sure.

What have you seen? What are some examples that you should just like nip in the bud?

So this one's pretty easy. Like it's always process. Right. So overly putting processes in and very rarely taking processes out. So a good example, even in this case, like you just mentioned, what's a good drawing tool? If you have a company that's growing as fast as ours, or any company that's growing fast, you'll have a proliferation of tools. And so what we try to do is, at least what I try to do is if I'm introducing a new tool, I remove a tool. So for instance, if we say we're going to go with Mural instead of Mural, for example, I will deprecate one to bring the other one in so that we all are still on the same tool chain. And there's a great article on HBR called, I think it's from 1967 or 1968 called how do you motivate employees? People can look it up. It's a great article that is still relevant today. And you'll see that it basically puts things on axes of satisfying and dissatisfying. And the number one dissatisfier, which is why people quit your company, is for process, admin and process. And for example, you talked about digital, like how do you move to remote world? We noticed that there are some things that were just process time sucks that weren't adding any value. So for example, we just did this one at Shopify in the past when you used to ask, you go into. We have workday. So you go to work day and you request the vacation, the automatic flow for workdays. It sends it message to your manager. And then your manager opens up and says, carol wants to take Friday off. You're like, sure. Like, like it doesn't. Like, as long as Carol's professional and it's got a backup and not people are not relying on her course she can take the day off. And so we just came up with a automated process where if somebody asks for vacation that's less than five days, it's automatically approved. So I just get an email that says, carol's taking Friday off. I'm like, cool, so now you're saving her time from waiting for can I book my trip? Or whatever. It's saving me time. And it's just an automatic process. And there's so many of these around the company, right? There's probably one around expense reports, time off, product manager, all kinds of things that can block teams. And especially in this async world, the more you can automate these, I think these are the number one killers for companies. And especially as you get more. This is what happens in most companies. Let's say you. Let's say you have somebody comes to work one day and is wearing like really short shorts, for example, and you're like, okay, this person probably shouldn't wear that. Maybe people are uncomfortable. It's too short. Who knows? Whatever the reason, if you're. If you have an office, because we don't have an office anymore, but let's say you do. There's kind of two ways you can approach it. One is you can write a dress code policy. Like, you can have a policy that's like a dress code and you can tell people, hey, shorts must be this length and all this kind of crap. And because one person didn't agree that, you didn't think that one person did what they should do, or you can just talk to that person. And so I think people land on the first one a lot where they like write up a policy or Imagine one person submits like a $6,000 phone bill one time and you're like, cell phone bill. And you're like, what the f? You can just talk to that person. You don't have to put a policy in. So I think that what happens is most people put a policy in because they think that putting in a system every time is a better way to handle the thing versus just talking to the person and say, why do you have a $6,000 cell phone bill? And they tell you why they were in Mauritius and they had to do a customer call. And whatever you're gonna say, cool. Just in the future, get a phone card or get a SIM card or whatever. Like, you don't have to have a policy. So I think that's the misnomer that happens in most companies. And I would say process is what kills most companies.

Speaking of that, James asks here, say you're a new leader or you just come into leadership or startup or scaling company. What are three processes that must exist in scaling an engineering organization? Your top three.

This is a good one. Top three. One, you have to have a single priority queue of work. Whether you use JIRA or a spreadsheet or notepad or pivotal track or whatever it is, you must have literally a queue that is top to bottom and one to N. Not high, medium, low. Because that's not granular enough work. And why I like that is because when the crazy, unreasonable pioneer like you, Lloyd, comes up to the dev team and says, we got to do this, someone can look at the list and say, okay, Lloyd, where does it fit? Because you said these things yesterday and now we have this new thing and you can go and go, oh, yeah. Because as pioneers, you don't always think about all the things you already said. You're like, onto the next idea. And so you can be like, oh, yeah, you're right, this isn't number one. It's like number four. So I would encourage everyone to work from a priority queue. And then you train folks to like, make sure you work from the queue. And engineers can pull things off the top. Like, you can work together. It's not like it's not an assembly line, but you have a conversation about the queue. That's number one. Number two, I would say, is release at least weekly to at least even internal, but hopefully even external because you can get feedback and you make sure your deployment process works. And production, like going pushing to production is low ceremony. So I would say for sure, push to production at least once a week. And that allows you and hopefully many more times than that, but at least once a week so that you don't have like at least a week, more than a week of inventory. And there's many ways to do this. You can even release the code behind a beta flag, but at least it's the code is in production. So I would do that as number two. Number three, this one's probably controversial, but I would say pair programming, but I don't maybe let's take it even a step back from pair programming. I would say work intensely at least 40 hours a week. And pair programming is an easy way to get that. But I think that in today's like world and even before this hustle culture, hustle porn culture of Everybody's working till 1am I think Gary Vee says, what are you doing from 7pm to 1am I'm like, okay, like you don't have. Not everybody has to like work like that. But if you work super intensely for 40 hours a week and by that like full beast Mode for those 40 hours, I think you'll be in the top 1% of like effort versus most companies. Because a lot of companies you get stuck in like meeting or you're stuck in a rut, whatever. I think if you can just be like time box your time and say, I'm going to work from nine to six, five days a week and take an hour for lunch. I actually think you'd get way more done than if you just said, I used to work at Microsoft and I was working like nine to nine, but we were playing foosball and shooting the shit. Like that wasn't working. Versus when I got to extreme and I started thinking about, I got three kids at home, I'm like, I'm going to work beast mode 9 to 6 most of the time. I didn't have to work at night or on the weekend. I was just able to get as much. And I do the same thing now. I try to work as hard as I can for 40 hours a week.

And that time boxing is key because me having this near death Covid experience, I realized one thing. You got to give attention. You got to stop and smell the roses. Because you know what? Work's not everything. And it's really important that you treat with love and respect your family because you want them to be the collateral damage for your business ventures and whatnot.

Yeah, There's a great YouTube. There's a great YouTube video by Alan Watts called Music and Life. It's two minutes long. I encourage everybody to watch it.

Definitely. I want to take some questions around hiring and team building. There's a lot of questions coming in. Go a couple minutes over, but in rapid fire, how do you, what are some hacks? You've learned to hire engineers and you also have a great intern program. So tell us about that. Like how do you build this team?

Yeah. So again, I have a controversial answer, which is I try to not rely on interviews and instead do job trials. And so I did. I hired lots and lots of people with the explicit assumption and explicit notion that, hey, we're going to understand how each other works over the first 90 days. And if you think we're a fit and we think we are a fit, like, we'll keep working, but if we don't think you're a fit, we'll give you feedback. And if you don't like think we're a fit either give us feedback. And then there's a no harm, no foul like rollout in the first 90 days. And so that's not how we do it at Shopify, but that's how we did it at extreme. And it was very, very easy way to have a conversation with somebody and really test the work versus the interview. Now at Shopify, for example, we look for something completely different. Is like we look for a big range. We want to make sure people bring a diverse set of deep skills and so we test for that. So for example, we have this interview called the Life Story where we try to figure out not what somebody did, but why they did all the things in their life. And we believe that's a predictor for performance at Shopify because they've got a deep curiosity in a bunch of different areas versus looking for particular keywords on a resume. So I think that's one way to think about hiring, which is figure out what you're looking for and job trials, even starting people off as a contractor, hiring interns, like you mentioned interns, I'm a big fan of interns because one, they're from a different generation, they have a different way of thinking, they grew up differently, two, they bring a lot of energy and three, they're here to learn and really prove themselves. And so I found them, they can be an additive to any team. When I started my own company, we had four engineers and four interns and.

They paired how do we bring the same energy? So like this, Norman asked this question, what advice do you have for a fast growing startup in terms of bringing lots of engineers into a well established core? Or it could be vice versa. Right. You have this sort of team of settlers here and they're like, I gotta jam it with some innovation. So you give these guys who are moving like 100 miles an hour, how do you like fuse these two to level set the energy?

Yeah, two different ways. One is I will go back to pair programming. Like the best way to get people to understand each other's points of views is to have them work together on the same computer. That's a really good way to learn about how somebody else thinks. Whether you're a settler, pioneer or town planner. I think that's a very, can be very instructive. I think two is you can also have these different teams, right. You can have like slow twitch and fast twitch teams. They can be fast twitch teams that try experiments, try things out and then when they work they can be, you can pair with the settler team and then hand them over. That's exactly how extreme ended up getting started. We were building like the first versions of a lot of these mobile apps and then we would pair with our counterpart companies. So then have them take it over. So there are lots of different ways to like think about that. But I do believe what you said Lloyd, which is that you want to have all kinds of personalities and all types of people in your organization in order for it to thrive at those different levels.

Definitely. And there's a few things here. Now you've gone full remote. You guys have like the, the epitome or the pinnacle of hyper growth here. Not only you said going to go from this office centered culture to full remote, but you're hiring thousands of people. How do you ensure that people are not hiding and they're engaged? You talked about pair programming, but how do you ensure some of the other things you've done to ensure people are super engaged?

Yeah. So I think that we do rely upon like our small trifecta team models to help us with that. So Even though we're 2,000 engineers, it breaks down all the way down through the organization where you've got product UX and engineers on different teams. And we do have some purpose built tools that help people understand what everybody else is working on in the company. How those, how that your project actually cascades up into a mission for the company and so you can see what each team is working on. And I think that really helps people feel like they're connected to the mission. So I think. And so from that perspective, the question you asked specifically is like, how can people hide? Unfortunately in like any company even. Actually I saw this happening at startups Unless you've got a real culture around giving like big problems to small teams, it's always going to be the case that somebody can hide. And so I would encourage people to give big problems to small teams, give them the autonomy to figure it out and then trust. But verify weekly. I said ship every week, have demos, have a culture where you can talk to anybody in the company. Have a culture that shares the wins and the losses and the learnings. That's the way I would try to counter that.

What are some useful metrics to keep top of mind? What is, what are metrics for you that are top of mind here and when you were at Helpful with a small engineering team?

Yeah, so I'm a big fan of weekly demos. Like I'm a huge fan of weekly demos. And the cool thing about a weekly demo is it can show you a lot. So for example, if a team comes out and shows you a mobile app and they did 15 screens and they're testing a bunch of things, you can be like, wow, team got like a lot done. And if the next team comes by and in comparison to that team doesn't have as much velocity because not as many things are changing, maybe there's a reason, right. They're like, oh, we have to refactor this, we have to upgrade from this to this. We were doing cross platform work. Like whatever it is, you can at least get a feel for what's going on. I think that it's hard to know from metrics because there isn't like a sales style team number that you can look at for engineers, but you can look at the volatility of velocity. Meaning is the team able to get a significant amount of work done every single week? That's one way to think about it. And if it changes every week, there might be a problem. So if there's a lot of throughput one week and then low throughput another week, the volatility is changing. That might be something for you to look into further.

What disengages people? Right. How do you. What are some two or three things you've seen that sort of cause engineers, developers to get disengaged and like destroys relationships?

Yeah. A good framework is to reverse the Dan Ping framework. So mastery if you're not learning anything, autonomy, if they don't have autonomy over a problem area and then purpose. And if they don't, if they don't have a larger purpose that they're contributing towards. If you reverse each one of those, I would say, or even any one of those, you Will cause disengagement in your engineering team.

Awesome. And communication is one big part of that. What are some signs of bad communication.

You'Ve seen oh so really long. So any kind of long piece of writing can, can have this problem where you hide the details or you're not clear on what you're trying to get across. And so we actually have a group, I mentioned that we have a slack group. Slack groups. Inside of Shopify we have a group called Help Writing. Like literally if you drop a document in there, they will help you reword and edit and copy edit the document to make sure that it gets the message across. So whenever I've got like a big email to send to the whole company, I will always use that channel. So people should really invest in getting very good at speaking and writing because communication is only going to become more important as the world goes more remote. It also helps you in non remote. So it's like a, it's a win, win everywhere. But being able to speak clearly, write clearly and get your ideas across is only going to get more important.

Jeff Lawson a couple of weeks ago, a few weeks ago recommended this book called Made to Stick. So Jeff Lawson's a phenomenal speaker who started as a developer. If you've seen him speak, he's spoken thrice at Traction. He always outranks every other speaker and he does these keynotes. And so I asked him and he's made to stick and doing a lot of standup meetings. Putting it in practice here on the interview process because you said you like bringing on people to do projects versus going through an interview process. But what does that process look like for you to identify the right engineer? Say it's a senior person or maybe a mid level person. Do you do take home assignments? Do you do whiteboarding? What is your process getting end to end?

Yeah. And the process I've seen work changes company to company because every company, for example, if you are doing like hardcore computer science, like you might need to do algorithms and whiteboard problems. Right? Because that's the type of work you're doing for us. Like I mentioned, we want to be as close to our diverse merchant base as possible. And so we rely on the life story as one of our filters which helps us figure out if people have people approach their career in a way that is curious and as interesting as potentially our merchants have. Like that's a connection. We do have a technical screen and problem solving part of our assessment where we try to understand the whys behind how people did things. If they went back in time. Would they do make the same decision, a different decision? You want to make sure there's introspection happening there. What do you do when you're faced with a particular type of problem? Give us examples of problems you solved. So I think there's a bunch of some experiential and some introspection that we look for that helps us determine whether someone will be as curious into our types of problems as they have been in their previous problems.

Awesome. And I'm going to take it away with close it out with one last question here. You're a great mentor. You're angel invest. And just whenever we talk, I get this sort of like servant leadership vibe from you. Enable success. Become successful by enabling the success of others. Any insights on mentorship? Like any personal story you want to share where you had a personally a great mentor that inspired you and what was that like?

Yeah, I think we said this at the beginning, right? When two. When one teaches, two learn. And so I think that for me it's all about learning. I will put my. There's another line that somebody I read somewhere that said you can learn something from anyone, meaning no matter who you're with, you can learn something from them. And so I think that I've always approached things, I've always been maniacal about being in front of learning. Like I want to learn things. And so whenever I'm with somebody, I try to figure out what is it that I'm going to learn from them. This person. I've been super lucky. I've had lots of great mentors. I've had lots of people who have given me straight talk right on. Like what I'm doing, what I'm doing wrong. I always appreciate that. And actually maybe I'll give people this tip. You have to find out what motivates you. So some people take screenshots when you get like congratulations and some people send you good job. If that's motivating for you, great. For me, that doesn't motivate me. What motivates me is when people give me feedback. Right. So when someone says, hey, what you wrote there or said there was wrong or it didn't resonate with me or. Or someone sent me this. My boss sent me this email you wrote is terrible. I couldn't understand what you were trying to get across. I couldn't write like I screen capture those because it reminds me that I can always get better. And I think that people have to figure out what motivates them and then make sure that's in front of them.

Stress is the precondition for growth, my friend.

Hey, I like that line.

Thanks so much for joining us. Hopefully we get to hang out in person either in the Bay Area or in Toronto sometime soon, before the summer is out. Have a wonderful rest of the week and thanks everyone for joining us.

Thanks everybody.

I need some traction.

Thank you for listening and we hope you enjoyed this week's episode of the Tracktion podcast. If you enjoyed the show, please leave us a five star review and you can find more information and all the resources mentioned in today's episode at. Boast AI that's B o a S T AI blog.