Transcript
Stanier: The one thing I want you to take away from this talk is a great model that you can use to improve your communication at work, especially if you're in a hybrid or remote working environment. What we're going to do is get stuck straight into some backstory, going back to 2020. We all know what happened in that year. We had the global pandemic, which was really difficult. Then we all had to take part in the biggest remote working experiment that the world has ever seen, and not many of us were prepared for it. We had to deal with bad working setup, no space in our homes, distractions of home and family life all at the same time. It came as a shock. What also was challenging is that for those of us who had very highly collaborative, impersonal synchronous interactions as part of our day to day, those disappeared completely. We were as technologists used to the tools that you use for distributed communication. We use GitHub, we use Slack, and so on. You can only imagine how hard it must have been for other industries who aren't even used to using tools like that to do their job.
This is a screen grab of the first ever UK government meeting that happened remotely back in March in 2020. Thirty five people in a Zoom meeting is gnarly in the first place. You can only imagine how difficult it would be to take a chaired physical meeting taking place in a properly designed chamber, and then bringing it all online with people who aren't used to using the technology as well. For even people who could use the technology like myself, we found ourselves not always making the right choice about how to get help when we needed it. Sometimes we find ourselves remotely talking into the complete void if we needed something because we were stuck. We found ourselves with so many tools and so many choices, but it was difficult to make the right decision. We had to deal with email, and chats, and video calls, code and pull requests, recorded video, and live video. What was it that we should be using and at what given time? Who was setting any norms and standards for us to communicate with each other so that it will be effective? No one really did.
We Need a Model
What we really need, as we're still in this world today is a model. We need a model that's really going to help us be effective in how we communicate with each other. It needs to be easy to understand, and easy to choose the right way to communicate. This basically is a talk about communication. It's a talk about communication at a technology conference, which is strange. If you were to be really pessimistic, and I'm not saying you should be really pessimistic, you could even say like a talk about communication could be a bit boring. I'm going to try and convince you that it isn't. I'm going to firstly start off by showing you that communication is a bedrock of absolutely everything that you do at work because it goes through everything. Good communication improves your programming, because your program becomes easier to understand. If you're in management or leadership, good communication is key. For anybody building consensus around decisions, building rapport and trust with your teammates, is all to do with communication. Writing great designs, building great architecture, giving feedback, all of this is the bedrock of communication. To improve it is worth it. It's a great skill that really multiplies through whatever you do.
Normalizing the Playing Field
Before we talk about this model that's going to really supercharge your communication, we're going to do one thing. We need to set the right conditions, in our workplaces, in our teams, and in our brains, in the mindset that we're taking to this so that we normalize the playing field for everybody. We normalize the playing field by treating everyone as remote, even if they aren't remote to us. Because whether we like it or not, the world is always going to be some kind of remote now. It seems like the workplace trend is that we're always going to have a hybrid model, at least. If we think about it, we always had a hybrid model because we always worked with people in different offices. We work with partners and clients who weren't in our building. There's always been a hybrid nature, a digital communication nature to what we've done anyway. If we treat everybody as remote from now on, we're going to normalize both the practicalities and also the cultural side of our communication. Because it means that if we treat everybody as remote, everyone communicates via channels that everyone else has access to. It means that everyone joins meetings with their own camera and with their own microphone so that the experience is normalized no matter where you are. It means that there's no dependence on any physical artifacts in order to get our jobs done. It's fine if you've got a diagram on the whiteboard, but not everyone is near that whiteboard, so we should use digital tools so we can treat everybody as remote. Culturally, it means that there should be no bias for where someone's located having any effect on the work they do, or how they can progress in the company, because we treat everyone as remote. It's the leveling factor.
Thinking of this principle, and going back to our cabinet meeting, they actually have done a pretty good job here, most people have their own camera and microphone. There's one square up here that doesn't, and that's the cabinet room. I don't know who's in there, because their name isn't on their grid square. I can't see them well enough because of how many participants that are on this call. I can't read their body language. I can't read their faces. Really, that cabinet room is not adhering by the principal, and those four people should be on that call separately. Treating everyone as remote is super important.
Synchronousness
Getting onto this communication model that I want you to take away. It's one model, but there's three aspects to it. Those aspects are synchronousness, permanence, and humanity. I'm going to take you through each of those in turn. What we're going to start with is this concept of synchronousness. If you're a programmer, you've probably encountered synchronous and asynchronous before, because synchronous execution of code happens one after the other, and asynchronous is something that returns after some amount of time, after some wait. The same is true for communication. What we're going to do is categorize it in this way, is that synchronous communication exists or occurs at the same time, or location, or format. For example, if I'm having a face to face chat with you, we're having it at the same time, we have to be having it at the same location because we have to stand next to each other to hear each other. The format is the same because we're talking and listening. Asynchronous communication does not have to exist or occur at the same time, location, or format. An email could be replied to two days later with a video call. A written document could then generate some documentation further down the line in a completely asynchronous manner. It isn't a binary choice. It's actually a continuum between these two things. It's a spectrum.
This is where we introduce our model. Our first type of model is going to be between synchronous and asynchronous communication. What we're going to do is between these two points is plot the different types of communication that we might come across in our workplace. Starting off on the left-hand side, a video call or a face to face communication, yes, it's synchronous. We know about that. We have to be there at the same time, same place, same format. Then moving along, we have things like chat, so Slack, Microsoft Teams, and so on. We know that even though it is fairly synchronous, there is an expectation that if we're both online, and we're chatting, that our messages will become pretty synchronously to each other, but there may be some delay. We can carry on moving and have things like recorded video. You might think, that's a permanent artifact. Then let's think about how these things are used at work. Often a recorded video in the workplace is used as a backup of a synchronous interaction. There'll be a meeting, and maybe somebody can't make it, so you create a video and someone will watch shortly after, and then they'll get back involved with that communication.
Then we have email, which is starting to get a bit more permanent. Now the expectation of email is different, isn't it? If I send you an email, and you don't reply for a couple of days, I'm probably not going to be too upset about that. That's the expectation of email. That's just how it works. Then we have written documents. We could be collaborating together to design something, come up with an idea. We could have a spreadsheet where we're computing some costs of something. That document, we can work fairly asynchronously, we don't have to be doing things at the same time in a collaborative way. Then the most asynchronous is a wiki or a README, because if you think about the time between something being written and something being consumed, it could be a decade. If the project is still relevant, and it still builds this particular code base, then the documentation will still be fine in 10 years' time. It's very asynchronous.
Thinking about this model, we can come up with our first key point, which is that the format that you choose carries an expectation. Your choice of how to communicate, implicitly tells the person receiving it how they should get back in touch with you. My example of talking into the void in Slack could be a massive team channel. I could be just saying, can somebody or anybody help me? If I really needed help immediately, then I probably would have been better off finding somebody that I know was online, and just having a video call with him in order to get help at that very moment. As well as choosing the right part of the spectrum to use when you're communicating, you can also combine different parts of the spectrum together to fix some bugs that usually happen.
Thinking about meetings, I'm sure you've all tried to prepare for a meeting before. You thought, we're well ahead of time, I'm going to write up all my notes. Put them in a document. Send them around to everyone the day before, therefore, everyone can asynchronously read. Then we can meet together and talk about everything while being on the same page. Then the meeting happens, and no one has read the document. It's a pretty common problem. What we can do is combine synchronous and asynchronous communication together. This is a really cool example called silent meetings. If you've got lots of people who need to discuss something by reading something beforehand, then why not dedicate a portion of the synchronous meeting to read an asynchronous document, because then you can all take 15 to 20 minutes. Get onto the same page. Then spend the rest of the time having a really fruitful discussion. There's a link there, which goes into the silent meeting manifesto in more detail.
Thinking about our model, we have to think about groups and we have to think about decisions. Synchronous means strong consistency, because if we're all meeting together at the same time, format, and location, then we are completely consistent in our viewpoint. We have synced together. Asynchronous is where we have to think about eventual consistency. This is like programming distributed systems, distributed storage. If we're using asynchronous communication and broadcasting it out, we might not even guarantee that everyone is going to read it. We have to choose a medium where we're ok with that being the case. If everyone has to know something, a synchronous communication is essential. If it's ok, if everyone catches up with time or doesn't need to know, asynchronous is completely cool. If we're trying to move ideas forward, then we can expand even further here, because a closed group has high synchronousness and high speed. If you're working on a project with a small team, you know that you have autonomy to move forward and make decisions and make really rapid progress. However, when you're thinking about broadcasting to a large group, there is low synchronousness and low speed, because 750 people or 1000 people to have input into a decision can sometimes just take too long.
Just recapping our first aspects of our model, between synchronous and asynchronous communication, we can plot all of these different communications on this. Then we can use this model to think about what we need to pick to set the right expectations for what we need in terms of responses, in terms of speed of movement, and in terms of how many people need to hear or see the communication that we're doing.
Permanence
The next aspect that we're going to be thinking about is permanence. Permanence is something that's quite interesting when it comes to communication, because there's never before been so many ways in which we can capture the work that we're doing so that we can share it later. When we talk about permanence, we talk about two sides of a coin. We talk about permanent being the state or quality of remaining unchanged indefinitely. That can be, not just in terms of the documents sticking around forever, it also means, how relevant is that document? Is it always going to be relevant? How accurate is it? Is it always accurate? Is it always useful? We have to think about these things. Impermanent communication lasts for a limited period of time, and not only the artifact lasts for a limited period of time, the relevance, the accuracy, and the usefulness also decays.
The really interesting thing about thinking about synchronous and asynchronous, and also permanence and impermanence is that we can plot them on the same model. We go back to where we were, but we also add impermanence over synchronousness, and we add permanence over asynchronousness. Because asynchronous communication requires permanent means to deliver a message, and synchronous communication is an impermanent exchange in the moment. What does this mean? We can use this model to think about why we found it such a struggle to adapt to remote working, because we spent most of our time on the left-hand side of this model, when we were working together in person. Because by the nature of being near people, by it being fun to talk to people, and nice to bump into people, we would have impermanent synchronous communications. The problem is, is that they leave no trace. When we all shifted to remote, and we wanted to find out information, we couldn't ask people in the same way that we could just know someone next to us, or there will be that thing on the wall that we drew a while ago that we could look up. We'd lost all of the artifacts that we typically had in order to organize ourselves together. We spent too much time pre-pandemic on this side of the scale, and we spent too little time pre-pandemic on this side. This is where we have to change and we have to think about how we make things better for people when we treat them when it was remote.
The key point here is to think of the future. Are you making the future better, as you're going about your communication day to day? Are you leaving a breadcrumb trail for other people to find? One of the things that we've done at Shopify to make sure that our developer documents are absolutely world class is that they're not an afterthought. We think of the future as a first class citizen. The developer documents this year have been a headline part of the roadmap, where everyone from the exec downwards knows that this is a critical project that we do. As a result, this means that you dedicate the resources towards it. As a result, you also make these developer documents that really are beautiful, really well written. They're fantastic, both for internal and external parties working with our platform. Making documentation front and center is a way to make it get done.
Another thing that Shopify does, which is fantastic when it comes to permanence, is a system called Vault. All of our internal documentation from our processes, our projects, our archive of people, their jobs, what they do, is all contained within this internal system called Vault, which is searchable. Anybody regardless of where you are around the world working for us, has access to the Vault. The company is open and transparent. You can find out anything that you need to know about anything at your convenience. Everyone uses the Vault because it is embedded within the company culture. We know that the process of getting things done involves documentation along the way. It involves broadcasting and blogging your project updates. It involves up to date documentation for your team. As a result of that collective effort from everybody in a distributed manner around the world, creates this wonderful leveling centralized platform to see what's going on.
Outside of Shopify, there's also other great examples that you can use. There's architecture decision records, which are a great tool. If you've ever worked with a code base and wondered, why is it this way? Why has this particular design been used? Why is this particular inheritance pattern in place, it doesn't make any sense to me as an outsider? Having a folder inside your code base where you can have these architecture decision records, allow you to raise pull requests that check in milestones and say, we are going on this direction with our code for this reason. That means that in the future, people can look back through your decision records, and understand why the code base is the way it is. If you go to that URL up there, you'll be able to see some great examples of these design records that you can take away and use yourself.
Something else that is a great permanent artifact that you should think about as part of your projects are design documents. I'm aware that agile as a concept says that you should just move in small chunks and iterate, but there is building for the long term as a very future focused, important thing that you should be doing. Design docs are a really great way to make sure that you embed some process in what you're building, so that you can get the right amount of design, the right amount of critique improvement before you embark on big journeys with your code. This blog post has a great template that shows you all the questions, headings, and subheadings that you should think about. I really recommend embedding design documents before any non-trivial feature that you build in your code base. Because in the future, people can then find the design documents, and like the architecture decision records, understand why something is a certain way because of a snapshot in time. That's impermanence to permanence. It plots the same way as synchronous to asynchronous. We had spent way too much time on the left-hand side of this diagram pre-pandemic, and we need to be pushing to the right as much as we can, in order to make things better for remote working, hybrid working around the world.
Humanity
The last spectrum that we're going to talk about is humanity. You might think, why is it being called humanity? That's a little bit strange, isn't it? It's an homage to a game, which I think is fantastic, called Dark Souls. Dark Souls is you play this Undead Knight, who is in this strange purgatory world called Lordran. There are these bonfires where you save your progress. These warming fires are the only connection that you have back to humans and humanity and the outside world from your purgatory. The longer that you spend away from the bonfires, the longer that you get damaged by all the other enemies. You begin to become a hollow shell of your former self. Actually, in the game, they call it going hollow. This is the way we think of remote working because too much time away from humans, no connections to the outside world does make you a shade of your former self.
We can plot on exactly the same scale from synchronous to asynchronous, what it means to be human in the Dark Souls concept, and hollow. If we spend more time on the left-hand side, then we get more chances to interact in a real way with human beings, which is really beneficial for us and our souls. If we spend too much time on the asynchronous side in the world of documentation, and READMEs, then we're not interacting with humans, and we can just find ourselves just feeling like we're missing something. The question and the key point here is that in your communication from day to day, are you restoring your humanity or are you going hollow? There's an interesting dilemma here, which is that, as an engineer myself, I'm thinking about trying to be the most efficient. I want to write things instead of say things. I want to broadcast, communicate my ideas, so I get more input. All of those asynchronous means of communication, fundamentally, don't connect me to humans in the same way that a tight close group of synchronous interaction has. You have to keep riding this line between the two.
There are some ways that you can embed humanity into your remote communications. Firstly, make it a part of everyone's day job that they are socializing as well. This can be really simple things from having Slack community channels, where people can share what they've been up to. They can post what they did over the weekend, talk about their pets, cooking. Unite people by the habits and the interests that they have outside of work, and just make it a normal part of work to be socializing, because that's what we did in the office anyway. This is a picture that I took, which I shared in one of our social channels, about a great rainbow that I saw the other week. It was really nice.
Something that doesn't involve time and money that we do with Shopify is something called bursts. We are a fully remote company now. We don't have people in offices. That's great for all the reasons that we know remote is great, and it really suits me. We have to try and get together when we can, if people want to, of course, and there is budget and company time for people to book trips together as teams, as divisions, as departments, as even just people who live in a similar location, we go and do something fun. We go on a field trip together, go on a hike, go and investigate a farm nearby. Go and do something cool. Don't just get together to sit in an office and work, get together as humans and do something that really connects you. Because then it really restores that connection that you have with people so that when you come away, and you're working remotely again, you just trust people more. You build more rapport, and you generally understand the human beings that you're working with, rather than the video grids that you have on the screen.
What we have to do is shift to the left of that diagram on purpose. We have to sometimes fight on wanting to be efficient, and instead, have a messy chat with people instead. Because it just makes us feel better as human beings. There are so many ways that you can work together in a social way as well. One of the tools that we use is called Tuple. It's a piece of software that is really great for doing pair programming. We encourage people all the time to pair. I know that sometimes it feels like it's more efficient to do your work independently to just tackle your programming problems on your own. Actually, pairing together on a ticket is not only good for problem solving, as we already know, but it's just really nice to connect to another human being to solve a problem together and to also have a chat at the same time, because this is what keeps us human amongst this whole process. It keeps us connected to the outside world and feeling warm about being in touch with humanity.
Summary
Those are the three spectrums that we've talked about. We've gone through what happened before and after 2020, and how we've had to adapt, and how it's been really challenging. Then we've had some motivation about why communication is really important for you to have an impact at work, especially in a hybrid and remote environment. Then we looked at this spectrum where we plotted things along the same line the same way, and just saw the interplay between synchronous, asynchronous, impermanent, permanent, and also human and hollow. How we have to be really conscious in the choices that we make, in how we talk to each other, how we communicate, how we build consensus, because we're always going up and down that model in many different ways. We have to be thinking about us and our audience and the effect that it has on us all the time.
Questions and Answers
Goldberg: How do you handle discovery of documentation, especially in this world of Google Docs, Confluence, GitHub READMEs, if you have multiple streams, just the freshness, accuracy, versioning, and discoverability. What do you do?
Stanier: I don't think anything's a solved problem. One of the things that I mentioned is this internal Vault system, and someone had a question about what's the difference between it and Confluence. By having this Vault documentation, that's the place where things are expected to be up to date. In terms of what you put in it, it's up to the team. If a team prefers to have something in GitHub pages to do their documentation, they can link off to it. If they want to use Google Docs, they can link off. The central point of discoverability is always this Vault system that we have. You open it up, you do Ctrl+K. You search for whatever you want. It's expected that if you're looking after a team, or if you're looking after some software or some architecture, there should be a page on it that people can find and then route off to where they need to find out the information.
Goldberg: It's like a central index in that sense.
Stanier: Yes, pretty much. It's nothing new in a sense. Back in the '90s, we had company intranets and things like that. The concept is the same. That is the central place where we want permanent documentation to be.
Goldberg: I get that, especially if you have multiple streams, if you have at least one place where you agree that things should be authoritative, then that already provides.
Stanier: Absolutely. I think, for example, the way that we track projects is that there are custom built things that fit how we do stuff. It links to the question as to what was the difference between Vault and Confluence. The framework for doing projects at Shopify is that you go to the Vault part that says projects, and then a project is proposed. There's a review process. Then when a project is happening, updates are blogged to that page in Vault. What's nice is that every project has a Vault page, every project has a blog of updates and documents. It's customized because we use it, the central core of how we do. There are some tweaks to how we do our work.
Goldberg: I think that that's probably the strongest part of this is that if you all agree to use it, then it's going to be good. If you don't, then the tool has lost its power.
Shifting gears a little bit about the humanity aspects of things, you mentioned, bursts. Who organizes the different burst activities at Shopify?
Stanier: There are two categories, there's ones that the "company" organizes. For example, there's some really cool stuff that's been arranged for what's happening this week and next week in Canada for hundreds of people in different tracks. Those are organized centrally by the operations team. In terms of smaller get togethers, it's the thing where the engineering manager can do it for their team or a director can do it for their division, or someone who's part of a committee can do it on behalf of the committee. The one thing that's a negative side to doing it yourself is that organizing trips for people is really time consuming and challenging. Literally, I was thinking about, where could our team meet up in early next year? Then started to dig into, it's going to be a lot of work to think about where to go, and the accommodation, and that kind of thing. There is central operation support for this, but some of it's currently still in the staff, and that can be challenging, and we don't have a good answer for that right now. The centralized ones are all arranged for us, so that's nice.
Goldberg: At least you don't have to organize all of them yourself. I agree, it's a big lift to get that stuff done, especially if you have other job requirements.
There's a lot of questions about documentation. Obviously, it was the focal of the talk. Going back to this idea of a permanent spectrum, you charted permanence and impermanence in line with synchronous versus asynchronous. I had this thought as well that things like chat are synchronous, but they're also permanent, in that you can search Slack. Sometimes that's an expedient way to get the information you need. I actually recently heard that Datadog has a 30 or 60 day expiry policy on Slack, so people don't do this, and instead write documentation. I'm curious what your take is on things like Slack for sources of truth.
Stanier: Our Slack does have a retention limit, which does mean that old stuff will disappear, so that does force you with a habit. I've seen the other side of the coin, actually, with my previous company, our Slack didn't have a retention policy for most of the time that I was there. What that actually ended up doing was, people would then over-rely on Slack to find stuff. Is that, yes, that design document was posted five weeks ago by Alice. I will search for Alice, and then it contains a link. Then you can't find anything. I think chat can be permanent, but I think the context of chat is always maybe a bit more informal. You're not presenting information for discovery, really. You're presenting information to communicate primarily. Whereas if you force people to use permanent documentation, the audience changes. I think the way that you write it changes and the discoverability, so it's about more. If you're a Slack ninja, and you can find everything, then good for you. Personally, I find it really hard to find things in the history of Slack. I find it hard to keep up with channels day to day, to be honest. Having it somewhere that's permanent that I can find it, is just a way that habits happen, I think.
Goldberg: I think going all the way the opposite, you mentioned that this year, in particular, Shopify has really invested in your public documentation. I think importantly, you mentioned that you can use it internally as well. Can you say a little bit more about the value of public docs as internal docs as well, and how you make that investment and make it work?
Stanier: The things that come to mind as you're asking that question, like public accountability for things is a really fantastic way of raising the bar for quality. This can come through anything like open source projects as part of your work, because you're developing in the open, it forces you to think about communication to the outside world a lot more. Having public docs like that is great, because you know the bar has to be really high because it's for the company. Third party developers who are also building their businesses off of a platform rely on them for their income as well. It sets the stage for doing things in a really good way. The dev docs themselves, I can only go into so much detail, but we have some core principles when it comes to developing things on our platform. Which is that any internal APIs that we are building should theoretically with the right authentication be potentially available to the public as well, and it's just a matter of permissions.
Goldberg: Yes, I love that concept because it's like, always externalize.
Stanier: Yes, exactly. Because it just forces you to build things the right way. Then when you're building something, and you're like, this is an internal API. I'm just going to do some weird authentication hack to get access to a thing. Then you've got something that can't be turned public. We have those little boundaries with our system, we always develop as if it were external facing.
Goldberg: You espouse the virtues of pair programming. Taking the time to build your APIs as though eventually they would be externalized, writing your documentation as though eventually you will be using them internally. Also, taking the time to do pair programming, which at the outset I have my own opinions about this, but I know some people think is wasteful, or half the capacity? How do you maintain this culture of putting time aside to do things in a way that maybe feels a little slower at first, but hopefully pays off? Do you get pushback on that, or is this really baked into the culture?
Stanier: It is really baked into the culture. Giving people access to the Tuple tool, and doing a pair programming session is part of our onboarding as well. As you onboard as the new engineer into Shopify, as well as orienting yourself, going through the facilitated onboarding, there's days set aside where you pair with somebody on a problem and fix some bugs. You spend some time thinking about some problems together. That's right from the start, that pairing is seen as "normal," a normal way for teams to be doing things rather than an exception. I think personally, I was fairly skeptical about so much pair programming myself coming in. As someone like, I'm a director level, but it's still really nice from time to time to understand what people are doing. I can program, so being able to say, "That looks really interesting, how about we pair on it?" I get so much context, and so does anybody who is pair programming on something gets so much context. For example, if you're a principal engineer, or very high up on the IC track, taking 30% of your time every week and dedicating it towards mentorship of others, where maybe you can just be available to pair program with someone, that's just such an amazing, useful, helpful thing to be doing. I think the more positive experiences that people have with pairing, it just builds. It's like a muscle, it gets strong. You'll be like, why wouldn't I pair program on this thing, because that's just such an easy way of getting things done.
Goldberg: I love that, especially as a mentor, if you are putting aside 30% of your time for mentorship, you could be having just a conversation, or you could be pairing. I think there's a lot more going on in a pairing session. As you mentioned, that slides more toward the humane side of things, and so on.
Do you have any tips on how to improve the social and humanity aspect of the team, particularly when they're in different time zones when something synchronous can be harder to do?
Stanier: Yes, it's the age old question. I think we're trying our best to balance teams so that they at least have three to four hours overlap every day. It is very challenging if you have someone in California and then someone in Eastern Europe, because they just don't have any overlap at all. Making sure that teams have overlap in the first place is necessary. Making sure that there is time in the week to socialize properly. One fun thing that Shopify did that was cool, was called Shopify party. You can Google it. We had one of our AR engineers build a 3D world where you can do your meetings, but you can be a 3D avatar in this cool little island, and there's loads of mini-games. You can have a chat about your project, but you can also race cars at the same time. That sounds really silly, but it actually worked pretty well. Just having an hour, or an hour and a half at the end of the week, where there is the overlap, and you just hang out and just play some games in this thing, and you chat about work. Especially if you're running a team, like making sure that, yes, there is cohesion that's built through achieving things together, but there has to be cohesion by setting aside time to just hang out as well. Just making it inclusive and fun.
See more presentations with transcripts
