I’m now six months into Shopify.
So far it’s going basically on schedule: as I was told, “Your first couple months you’re going to have zero idea what’s going on. Then around month three you’ll come up for air and think, ok, I got this; and then you’ll try to start doing stuff. Then you’ll really struggle, because you won’t be in that happy new float-around-and-learn-people’s-names mode, you’ll be in oh-shit-can-I-really-do-this mode. It’s actually a little scary. But then around month five or six, you start to actually figure some things out for real. And then it starts to feel fun.”
So far it’s gone pretty much exactly to plan. But it’s starting to get fun. So this week I’m sharing six things I’ve learned in my first six months; some of them about working for a big company in general, and some about Shopify specifically. I hope they’re helpful.
- Job number one
In my first week at Shopify, I had a bunch of meet-and-greet conversations with people around the org and one of them really stuck with me. It was a conversation with a GM for somewhere else in the company, and I asked him, hey, what advice do you have for me in my first year? Here’s what he told me:
“In your first 6 months here, here is your number one job. Familiarize yourself with the dozen senior people at Shopify who have the final call on really important decisions, from Tobi and Harley on down. You need to familiarize yourself with their operating philosophy around business and around how Shopify works. Go consume every written memo and every podcast episode (we have a great internal podcast called Context) they’ve ever done, get inside their heads, learn their perspectives and their preferences, and learn what gets them to say Yes to things.
“Here’s why this is your most important job. In your first six months, you’re gonna be useless anyways. You’re going to be drowning in new information and context and it’ll take you a few months to learn how to swim. But then once you do, you need to become effective. And in order to be effective, you need to know how to get those people to say Yes to things, and how they would think through a decision down to a detailed level. If you can do that, then you can get basically anything you want done. If you can’t do that, then you’re never going to get anything done. Therefore, this is your most important job right now.”
I remember thinking at the time, wow, that sounds like really important advice, I should listen. And I did put in some effort; not nearly enough, in retrospect, but more than zero. Now, six months in, I’m not nearly at a point where I would consider myself “effective” yet – I still have a long way to go in that department. But that advice is paying huge dividends already; not only with my own initiatives but actually more so with helping other groups with theirs.
When you’re in a company full of smart people, like Shopify, it can often be quite tricky to resolve disagreements and impasses with, say, product decisions – because the conflicting opinions all have a lot of merit. So I’ve found it very helpful to be able to bring to the table: “Here is how I think ____ would look at this problem, from their perspective and their philosophy. It’s a pretty different POV from how we’ve been talking about it so far, so hopefully that added perspective helps us get unstuck, since they’re ultimately the person who has to say Yes here.”
Moreover, it’s not like we only care about their opinions because they are decision-makers; this isn’t really advice about relationship-building. It’s advice about how to think better. Great leaders are right, a lot. They know things. So having their operating philosophy available on-demand, or even a rough approximation of it, can be really useful in moving the ball forward and getting teams aligned around the best possible decision.
- Conway’s Law
Conway’s Law, if you don’t know it, is usually summed up in the famous phrase: “You ship your org chart.” The original wording from Melvin Conway goes: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication system.” (Eric S. Raymond helpfully elaborated: “If you have four groups working on a compiler, you’ll get a 4-pass compiler.”)
I’ve known about this concept for a while, I’ve probably repeated it to try and sound smart in conversations, but I never really understood it until joining a large organization.
Think about any complex product you like – it could be your phone, your car, a public transit system; whatever. That product is composed of many different parts, and sub parts, all the way down to tiny little atomic units that feel like indivisible “chunks” of product. Conway’s law is an observation about the contours of those chunks of product.
Each individual chunk of product was probably built and shipped by one specific team, who worked together closely and understood each other well. Within that team (think of Amazon’s famous “two pizza teams”), everyone knows each other, and communication flows easily. So the final product that gets shipped by that team will feel like a unified, cohesive, harmonious chunk. You won’t be able to tell that one employee worked on one half and another employee on the other half; it feels like one piece.
But the boundary between that product and an adjacent product – let’s say, between a car door versus the car handle – will be between two internal teams that don’t communicate as easily with one another. Those communication barriers, even when they’re small, shape the contours of the final product that gets shipped. If two teams work side-by-side and speak daily, then the contours between their adjacent products might feel small. But if they rarely speak, or have different product or design principles, or are “far apart” for whatever reason, then the boundaries between the products will feel disjointed and bolted together.
In an ideal world, everybody would communicate perfectly with everyone. But that’s just not practically possible. In a large organization, there are necessarily going to be teams you don’t talk to as much. So your organizational design, which imposes a kind of topographic map for communication, matters a lot: it’ll shape what products get built, and how, before the product even starts getting brainstormed.
That’s one half of “you ship your org chart”: boundaries between chunks of product mirror communication boundaries inside the org. But there’s a second part, too: not all product teams are able to advocate equally. There are power differences between groups. So the final structure of a product won’t just reflect the boundaries of the teams; it’ll reflect the relative influence those teams in getting their products shipped. Power is, in of itself, a form of communication: in large systems, the meaning of a communication is the behaviour that results. If the system said it happened, then it happened. That system behaviour manifests in the form of the product as it’s made: teams ship what they’re empowered to ship, but their output often finds itself looking a lot like the same hierarchy that went in.
- Partnerships
One particularly inspiring project I’ve been working on over the last month is our newly announced partnership with Operation HOPE to help start 1,000,000 new Black-owned businesses over the next decade. It’s a really great project to help get off the ground, and now the hard work is starting to get it to real success over the long term.
Working on this project was the first time I’ve ever really interacted with an outside organization from inside Shopify. And it gave me some insight into something I was told a long time ago: “if you’re a startup, try not to waste your time talking to big companies unless you’re doing it deliberately. They have an absolutely endless capacity to consume your time with meetings.” I’m not sure I really understood why at the time.
But it’s clear to me now how this happens. And not because our current partnership is going badly by any means – we’re still in the early stages of getting a lasting framework in place that will help the partnership succeed over ten years, but we’re making progress and I’m feeling optimistic with how things are going. But even so, I can see firsthand how complexities and potential liabilities, once you introduce them into an environment like the inside of a company, can rapidly metastasize and create more of themselves.
The art of getting these partnerships right is really solution architecture: making sure from the very beginning that someone who understands every piece involved can get them lined up right, and interacting the right way, from the very outset of the project. If you don’t get that person immediately, what happens is that people who don’t understand every piece (like me, currently, I’m afraid) start “solutioneering” to make forward progress quickly.
This creates more problems, which often kicks things back to the partner company to straighten out: what are your requirements again? How do you need that workflow to go? And since they won’t understand your architecture problem you’re dealing with internally, they’ll just give you straightforward answers about what they want – without really understanding the degrees of freedom available to fix the problem.
Unless you really fix things quickly, the interface between your two companies (and the mechanics on both sides) just compound with problems on both sides, and never get really fixed – just patched over and over. All the while, this creates meeting after meeting as new groups get pulled in, but never really solving the real problem, which was an initially misunderstood problem or misapplied architecture. (Fortunately, this isn’t happening yet – as far as I can tell – with our project with Operation HOPE so far! But I’ve felt some degree of painful self-awareness as, in an effort to be helpful and move the ball forward, some of my “help” may just be creating net more meetings for everybody. It’s something I’m trying to keep in mind, anyway.)
- Canada & the impact of being in a secondary market
Five years ago when I was starting at Social Capital, I remember an ongoing debate over what tech company would grow into the next $100 billion market cap firm, and retroactively define what that “era” of tech was all about in hindsight. So obviously Uber and Airbnb came up a lot (“this era of tech is about the networking of assets”), Snap (“This era of tech is about images and video taking over as the new default internet format”), we obviously hoped for Slack (“This era of tech is about the future of knowledge work”).
No one really mentioned payments or commerce. PayPal or Stripe never came up in those discussions, that I can recall. And certainly no one ever mentioned Shopify. (Except one person. He’s doing really well now.)
Until recently, no one really knew about Shopify. We were just quietly up there in Canada, helping merchants make websites, as far as anyone in Silicon Valley could tell. Not a lot of Tech Twitter, not a lot of hype. Until one day, everyone knew who we were, everyone suddenly figured out that we’re an entrepreneurship company, not a website company, and “Shopify for X” became a Demo Day trope.
There have been several profound consequences of Shopify being a Canadian company, tucked out of the way in Ottawa (and then Montreal, Toronto, Waterloo…) and not in the Silicon Valley limelight. The most important consequences have to do with people.
The first impact is on employee retention. Shopify never competed in the never-ending war for Silicon Valley product and engineering talent, where average employee tenure at some companies is under two years (!) and employees work for a portfolio of high-growth companies over their best years, not just commit to one. Instead, the common complaint about Shopify up here in Canada is that all the good tech talent comes to work here, and then never leaves. There’s a virtuous feedback cycle at work: since Shopify can count on you staying for longer than your average tech company can, they can invest more into you when you start. Reciprocally, having everyone get more up-front investment and more context and tenure means that you can make a lot tactical choices in how you work that people really like, and makes them stick around.
The second impact is on what employees do when they’re here, especially product people. In Silicon Valley, if you are a product person, you are probably friends with lots of other product people at other companies and especially with other founders. You are going to feel pressure to live up to, and impress, your peer set. And the ultimate peer set you’re being judged against are successful founders. They are the top of the food chain.
This peer pressure is a mixed blessing. It’s good in the sense that it promotes more people to start startups. People see founders with status, and ego, and success, and want that too. But it’s bad in that it creates a lot of ego, and big egos aren’t what you want on a team that’s going to stick around for the long run. Shopify doesn’t really have that problem; not because we’re somehow more virtuous or ego-free or anything, but just because the peer set up here in Canada is different. Again, it’s a mixed blessing. We don’t have as many startups or as many wild crazy bets. But it’s great for Shopify, because not only do people stick around, they stick around as team players. That’s valuable.
- The surface area of software is enormous
This is a quick learning but it’s a powerful one: there is so much software. I know this seems like a silly lesson, and that this is something I’ve already had plenty of exposure to. Software markets are huge, we chronically underestimate how big they are, et cetera. But it’s one thing to see all these SaaS businesses and productivity tools as isolated businesses or in market maps; it’s quite another to see all of them inside your Okta portal and realize, oh wow, we use all of these. A lot.
I forget who said this – someone smart on Twitter – but your mental idea of the software business changes when you realize that the primary customer of software is becoming other software. Shopify runs a pretty tight ship, and even we use so many different tools and work products if you look across different teams and job functions. And that’s just the SaaS products – it all sits on top of an immense body of open source code, of which Shopify is a proud contributor. And we’re just one company. Anyway, it’s all so big, and it’s getting bigger at a rate many people who should know better still don’t appreciate.
- Compressed Learning
The last lesson I’ll share here it that Shopify takes learning very seriously. Learning isn’t just something that happens at its own pace: some environments for learning work better than others, because they let you practice certain transferrable skill over and over and over again. I’ll leave you with a quote from Tobi (lightly edited) in a podcast interview with Patrick O’Shaughnessy earlier this year:
“I’m a card-carrying member of the “video games are actually good” club. I’ve learned so many things in my life through video games. The only reason I learned programming is because I wanted to make changes to the video games I was playing. And obviously not all games are created equal; I tend to point out a few I think are extremely valuable. Factorio is one of those. It’s the one game that anyone at Shopify can expense. Because it’s just bound to be good for Shopify if people play Factorio for a little while. We’re building supply chains for our customers; logistics networks; and Factorio makes a game out of that kind of thinking. And you know what, it’s actually not surprising, cause that kind of thinking is super fun.
It’s fun to say, hey here’s a factory, and that factory needs inputs, and those inputs come out of the ground, and they needs to be producing at the rate it needs to be consumed. I invariably find that this is a very exciting world. I find that video games are getting a little bit more mature; I mean, sure, I enjoy a good game of Call of Duty every once in a while, but we understand why those our popular; building a supply chain is a little less obvious. But then you play this particular game, and it’ll suck you in. And your brain will have pathways that will light up in many, many more situations than you can imagine.
The tl;dr of why I think video games are good is because of transfer learning. There’s a good book called The Talent Code that talks about this. There was a famous story about people analyzing why Brazilians became so much better at soccer than anyone else. And there were many reasons – it’s a system that’s reinforced by all these things – but people hadn’t found the key reinforcing mechanism that made this true.
It turns out, in Brazil there was a culture of playing a pickup game, a version of soccer that was played in a much smaller space and with fewer players. And the players did all the things you need to be good at soccer, but they did them significantly more often, because there was more ball contact per person. Just because that’s a different game than soccer doesn’t mean people won’t learn soccer skills. They had way more ball contact than someone who went through the British system, by the time they entered the Premier league, for instance.
What are other situations where you can – in a compressed way – practice these skills that you need in the business world? I make strategic decisions, for my job at the company. For most of these strategic decisions, I hope I do well, but I only find out a couple years later. The way I’m doing them is I try to get as much context as I can, and resolve this big multi-stakeholder situation, plus technical abilities, plus future timelines, plus the way the internet will go… How often do I do this in a year? A couple times, maybe once a month? I don’t think so. Major opportunities to bet the company and allocate resources don’t come around that often.
But if I sit down for an evening of poker, I make these decisions every hand. And then you look at a game like Starcraft, which I think is very good, or Factorio, and in a very compressed, fun environment, follow a certain activity over and over and over again which otherwise comes around only rarely. And doing that will change your mind, and your brain, and help you be prepared for situations you could never predict.”
I won’t elaborate into this too much more, so as not to reveal anything I shouldn’t, but applying these principles that Tobi walks through here lead pretty directly to some shockingly effective practices.
So those are the six lessons. I hope they’re helpful. If they were, head over here.
Like this post? Get it in your inbox every week with Two Truths and a Take, my weekly newsletter enjoyed by 20,000 people each week.