 Hi there and thanks for joining. My name is Ash and I'm a technical program manager at Meta. I'm going to talk to you about the crucial skill of writing today. As a quick intro, I've been a TPM at Meta since 2017, working on a range of programs covering augmented reality, privacy, and now Metaverse products and infrastructure. As you may be able to tell from my accent, I'm originally from London and have bounced between the UK and the US over the years. I came to Meta after a career in the gaming industry. I started out as a software engineer on centralized platforms, transitioning to developer relations to help partners use those platforms, and then to more TPM-like roles to build and launch products and services throughout my career. But let's move on to the main topic. As a TPM, communication is a huge part of our job. We constantly need to explain a vision or idea, understand someone else's point, and aggregate information from various sources. Where you want to get buy-in from others, remove ambiguity, and help everyone keep executing in the same direction. Writing is probably the most scalable way to share a message. So this is the method you would likely use the most in your communication. We'll discuss some more why writing is important, cover some principles to keep in mind in your communication, and talk through a working process when writing with tips on doing it well. As a bonus, I think of the tips not only apply universally to writing emails, and documents, slides, blogs, and so on, but may apply to your communication overall. So let's start with why writing is important. Writing is thinking. I often write just for myself. It helps me organize my thoughts. There can be so much information to know and connect, but keeping it all live in my memory at the same time just doesn't work. So I'll write it down. It can start off rough with links to other docs and wiki pages, a list of people involved in their roles, notes I catch in meetings, and so on. But then it turns into a summary of that content. Initially, just a collection of random-looking bullet points as I brain-dump what I've been picking up. But then I can start to group and categorize them into something of a narrative that explains my view of what's going on. There will be points where something doesn't connect, or I realize I can't explain something. And that's my hint at what to go and investigate or ask about next. And having your thoughts down means you can now share and debate with others. The doc may or may not turn into something that I share with others, but if I'm starting to write it, it could be because I've not found a doc that looks like this. So it could be beneficial for getting everyone on the same page or just helping others round up on the topic after me when they join. Human success comes through stories. When we all bind to the same narrative, it's much easier to work towards a common goal. Being able to clearly tell a story means you understand the topic and getting things into a clear narrative should help you and others discover your options and come to a conclusion. You can scale through writing. It's obvious to say that you can write once and share many times. In the workplace, writing is crucial because it outlasts a meeting. And good writing can save you from having to have many meetings in the first place. If you're an expert on a subject, no doubt you'll be asked a lot to help and ramp other people up or give advice to others, but you can't meet everyone one-on-one and not everyone can attend some larger meeting like all the new people that might be joining after you. And you've got other things to do than keep on presenting the same thing over and over. So if I find myself talking about the same thing more than twice or expect that I will, I'll go and write it down instead. Then people can catch up in their own time. And then if and when you do meet, you can focus on misunderstandings or unanswered questions, which you may then wanna go back and update your doc to clarify for the next person. As a non-writing sidebar bonus, a clear agenda going into a meeting, a link to any notes included in that invite, a pre-read shared early enough that people can actually read it, a meeting notes that can stand on their own but not attend these to understand and not just some shorthand of topic names. They're all really helpful things that you should also be doing. Simple, concise, and accurate is really hard to do. And it's similar to the quality, speed, and cost triangle where you can only pick two. And you may have heard the line, I would have written a shorter letter but I didn't have the time. So really you may end up with the 80-20 rule where you end up spending mostly a writing time on the proofreading and editing to get the doc just right. This does take time, but the artifact you end up with is a tool that can save you time and energy going forwards. And realize that you will spend much more time thinking, writing, and editing than any one person will spend reading your piece. But by doing this, you save them a lot of time allowing them to quickly ramp up. And this compounds with the more readers there are. You may be able to repurpose this content in multiple ways too. For instance, getting that simple elevated pitch intro down can then go into future status updates, the front of their project Wiki or any leadership presentations. And that saves you time prepping those materials each time and can help you fend off having to repeatedly answer basic questions. So that's why we write, but now some things to keep in mind about our content. Know your audience. You need to be able to tell your story in a way that others can also understand where those people won't have the same context and experience as you. If you're writing a note for your team, acronyms may be fine. If you're writing a Wiki page for partner teams, then you at least need to link off those acronyms to a definition somewhere. Readers can then skip the parts they know or can quickly go and research the things they need to to catch up. If you're presenting a leadership review, you may need to either add some context on whatever the acronym stands for or avoid the term altogether and use some simpler language. So I'm thinking to myself, is engineering director X or product manager Y or lawyer Z going to understand that sentence? On that note, explain like I'm five can be a useful exercise. Try to use the most basic language you can. If you're relying on complex words, long sentences and so on, then you're going to lose some of your audience. And it's possible you don't understand the subject to whether or not yourself in order to explain it more simply. Personally, I like to try and write things the way that I would talk, not like I'm submitting some scientific paper. On another non-writing sidebar, when I'm conducting an interview, if the candidate is talking about a program they worked on in some domain I know little or nothing about, this is really what I'm looking for them to do. Help me understand what they were working on and what makes it worth talking about. So what outcome do you want? You're writing this doc for a reason. You want feedback on idea or do you need people to complete an action? It's an FYI on the decision that could impact someone else's plans. Make it clear what you want to happen. Spell it out, tag the relevant people if you can to ensure their attention and don't assume everyone is going to find it. Read it all the way through and then correctly interpret or guess what you wanted them to do. On the point of reading it all, keep it concise. Have you ever read a book and thought that could have been one page or for sure you've been to a meeting and thought that could have been an email? Just get to the point and share that first before you go diving into more details. That doesn't mean everything can or should be boiled down to just a few bullet points. You might truly need a few pages to give the necessary context but do try to focus on the important details you want people to walk away with and not the extra fluff which is really just a distraction. And finally add some structure to help the reader and let's look at a quick example. Here are a couple of screenshots from the start and end of a document version of this presentation. You don't need to zoom in to actually read the content. Just look at how it's laid out to get the point. Notice how I've used section headings to break up the content into logical concepts. And next within longer sections I've used a numbered list of my points. If we're reviewing this in a meeting or I've shared this in some context where the reader can't type in a comment right into the document then this helps someone who wants to ask about one of those points. What did you mean by point two, for example? Each tip also starts with a bold summary to easily scan and the point here is overall try to make your content easy to consume. Okay, so those are a few points on the content but how do we actually produce our content? And so these are some of the steps that I go through. The key thing at the start is to answer for yourself what you are writing this for. This is the outcome that you won based on the main points we're trying to get across. And I'll note this down so that I'm clear what this is what I'm aiming for. Next, I need to know my audience. If it's just going to your team you may be able to skip so many introductions and link off to terms for other documents. But if you're trying to educate people say a potential partner team or a customer think about what that means for someone new to this work. If we're just linking off to other docs to gain more context they may have to read three other sources or even get out of your first paragraph. So make it easy for people by adding enough context to understand your points and help guide them elsewhere if they want to find out more decent information. So that's what I've got a quick example. I'm a TPM and I'll be talking about roadmap and project plans often. So maybe I need to make a point about one of the projects on that roadmap. So MCT needs a new UI. It's certainly concise but it leaves things open to too many questions. What is MCT? What makes you think UI change is useful? So improve time to complete with a new MCT UI. And my call tool MCT is a standard way for internal teams to complete task X but user research shows it takes too long. If we believe a workflow change sorry, we believe a workflow change will reduce this by half. So it's obviously got some placeholders in there but two quick sentences adds enough detail for most readers without getting into ton of specifics and links off for more info if someone is interested. So we're balancing brevity with simplicity or understandability. Moving on. Layout a skeleton first. I don't write the perfect final draft from start to finish in one sitting. I normally start with a few scattered bullet points and I'll jump all over the place. I might list out the questions I think the audience would have as a way of laying out the content as answers. Eventually I'll feel good that I've got the major points out of my head and start to order them. And having got something of a structure down I'll start connecting the points and filling in the details as needed. Writing something that's short, accurate and simple to understand can be very difficult as I've said. So try to spot jargon, add supporting links, remove unnecessary detail. What is and is not necessary can depend on a situation but a simple razor to use is and whether this information is going to have an impact on the outcome you want. For instance, maybe you want to give some credits to several teams that worked on something and the challenges they tackled along the way. Perhaps this would be good to have at the end of a leadership review doc to keep everyone happy but it makes less sense to go into that detail in a customer wiki about this product. Other fluff to remove includes unnecessary words. Don't write hard to do, use difficult or the purpose of can speak to really small is tiny. A lot of can be many. And even better flows to examples, use actual numbers if it makes sense in that context. A final point to hammer on here is that I've separated the actual creative part of the work in previous step with the editing part here. You shouldn't do both at the same time. Editing uses the analytical part of your brain while writing uses the creative part of your brain. So you're just grinding your gears if you're trying to do both at once. All my time I get skimmerable and with the raw content in now I'll help the reader out by breaking it up like I said before. I'll add section headings around each concept, use numbered lists instead of boiler points and use both summaries to make things skimmerable. People can scan to get the idea and dive in where they need to. For slide presentations I'll include slide numbers too. So follow up much easier when the audience can ask on slide eight what did you mean by point two? Rather than can you go back a few slides and read something about targeting? I'll revisit the summary and I'll call it to action and I'll always have a summary at the start which is maybe the last thing that you write for example. I'll clearly call out the things that I want the reader to do because of this doc along with a deadline or what the end result of summary search was with some key metric or what the thing the team would learn by reading this is. But this particular presentation is educational content. So the summary was really the agenda but I can have a wrap up side of the end as a shareable recap. And that's it, I'm done with my writing. I may share with a small circle for initial feedback and revise it before going broader but the bulk of the work should be done. As a final thought, I'll call out that we are living and working in an asynchronous world. Any artifact that you can produce that others can consume and learn from without you having to be there to present it will help you scale up your message. But oftentimes the message needs repeating in order to drive it home but the product vision for instance or with some big change of plans you will need to keep reminding people why things are happening and why this is important even when deep into a project or program. Because of that, you probably want to have one doc. But in producing the first one you've put a time into the thinking already so you can supplement your writing with same message and other mediums at low cost. People like to consume information in different ways like reading, video with subtitles, audio in person and so on. Those things do not be difficult and expensive to produce. You have presentation software, you have a webcam and a mic or just use your phone. But that can all be for another lesson. Thanks and best of luck and now I'll leave you with a quick recap.