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 com…

Im now six months into Shopify.
So far its going basically on schedule: as I was told, Your first couple months youre going to have zero idea whats going on. Then around month three youll come up for air and think, ok, I got this; and then youll try to start doing stuff. Then youll really struggle, because you wont be in that happy new float-around-and-learn-peoples-names mode, youll be in oh-shit-can-I-really-do-this mode. Its 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 its gone pretty much exactly to plan. But its starting to get fun. So this week Im sharing six things Ive learned in my first six months; some of them about working for a big company in general, and some about Shopify specifically. I hope theyre helpful. 

1. 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? Heres 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) theyve ever done, get inside their heads, learn their perspectives and their preferences, and learn what gets them to say Yes to things. 
Heres why this is your most important job. In your first six months, youre gonna be useless anyways. Youre going to be drowning in new information and context and itll 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 cant do that, then youre 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, Im 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 youre 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 Ive 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. Its a pretty different POV from how weve been talking about it so far, so hopefully that added perspective helps us get unstuck, since theyre ultimately the person who has to say Yes here.  Moreover, its not like we only care about their opinions because they are decision-makers; 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. 

1. Conways Law

Conways Law, if you dont know it, is usually summed up in the famous phrase: You ship your org chart. The original wording from Melvin Conway elaborates: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organizations communication system. (Eric S. Raymond helpfully elaborated: If you have four groups working on a compiler, youll get a 4-pass compiler.)
Ive known about this concept for a while, Ive 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. Conways 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 Amazons 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 wont 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 – lets say, between a car door versus the car handle – will be between two internal teams that dont communicate as easily with one another. Those communication barriers, even when theyre 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. 
Thats one half of you ship your org chart: boundaries between chunks of product mirror communication boundaries inside the org. But theres 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 wont just reflect the boundaries of the teams; itll 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 its made: teams ship what theyre empowered to ship, but their output often finds itself looking a lot like the same hierarchy that went in. 

1. Partnerships

One particularly inspiring project Ive 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. Its 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 Ive 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 youre a startup, try not to waste your time talking to big companies unless youre doing it deliberately. They have an absolutely endless capacity to consume your time with meetings. Im not sure I really understood why at the time. 
But its clear to me now how this happens. And not because our current partnership is going badly by any means – were still in the early stages of getting a lasting framework in place that will help the partnership succeed over ten years, but were making progress and Im 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 dont get that person immediately, what happens is that people who dont understand every piece (like me, currently, Im 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 wont understand your architecture problem youre dealing with internally, theyll 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 isnt happening yet – as far as I can tell – with our project with Operation HOPE so far! But Ive 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. Its something Im trying to keep in mind, anyway.) 

1. 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. Hes 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 were 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. Theres 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 theyre 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 youre being judged against are successful founders. They are the top of the food chain. 
This peer pressure is a mixed blessing. Its 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 its bad in that it creates a lot of ego, and big egos arent what you want on a team thats going to stick around for the long run. Shopify doesnt really have that problem; not because were somehow more virtuous or ego-free or anything, but just because the peer set up here in Canada is different. Again, its a mixed blessing. We dont have as many startups or as many wild crazy bets. But its great for Shopify, because not only do people stick around, they stick around as team players. Thats valuable. 

1. The surface area of software is enormous

This is a quick learning but its a powerful one: there is so much software. I know this seems like a silly lesson, and that this is something Ive already had plenty of exposure to. Software markets are huge, we chronically underestimate how big they are, et cetera. But its one thing to see all these SaaS businesses and productivity tools as isolated businesses or in market maps; its 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 thats 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 were just one company. Anyway, its all so big, and its getting bigger at a rate many people who should know better still dont appreciate.

1. Compressed Learning

The last lesson Ill share here it that Shopify takes learning very seriously. Learning isnt 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. Ill leave you with a quote from Tobi (lightly edited) in a podcast interview with Patrick OShaughnessy earlier this year: 
Im a card-carrying member of the video games are actually good club. Ive 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. Its the one game that anyone at Shopify can expense. Because its just bound to be good for Shopify if people play Factorio for a little while. Were building supply chains for our customers; logistics networks; and Factorio makes a game out of that kind of thinking. And you know what, its actually not surprising, cause that kind of thinking is super fun.
Its fun to say, hey heres 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 itll 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. Theres 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 – its a system thats reinforced by all these things – but people hadnt 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 thats a different game than soccer doesnt mean people wont 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 Im 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 dont think so. Major opportunities to bet the company and allocate resources dont 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 wont elaborate into this too much more, so as not to reveal anything I shouldnt, 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.