Yeah, so let me talk about the problem which was frustrating for me in particular because essentially I joined this organization, <company name>, where we were a series A startup where growth is really important. So I was the head of growth and I had to lead our engineering team to build products for product-led growth. And it was really frustrating for me because I had to essentially onboard myself. There was a very big issue with the documentation. So our CEO in particular, obsessed with note-taking, we're building a note-taking app for developers. As you can imagine, he targeted himself for that use case. And then he produced an overwhelming amount of information that was by and large not particularly useful. When you're onboarding a new role, it's really important that you get the right information that enables you to do the work. The point of documentation isn't to produce text for the purpose of having text lying around. So I talked with our most recent hires in a series of one-on-ones to essentially clarify what we believed and what we saw the problem as. Then I set up a series of meetings to get buy-in from, well, to understand my CEO's point of view and be empathetic to where this process came from and what he figured were the requirements of it. So once we spec'd out these requirements with the new onboardings and the CEO, then I was able to go and talk to my laterals, get buy-in from all the relevant stakeholders because our entire company essentially was subscribed to the same documentation process. So once I got the buy-ins and I was able to spec out the problem, then essentially I began working on formulating those solutions, a series of one-on-ones with key people who were involved with writing the documentation or the CEO, again, in a series of meetings in terms of as we iterated on the solution, what he felt like was missing to get his acceptance of the solution. Then I called a meeting with all my laterals and the CEO as well in order to present this new solution and essentially get everyone on board. Everyone essentially was happy with it, so then we were able to take that solution and distribute it to my reports and then other people actually to their reports as well. And then the result seemed to be pretty resounding success. So essentially I added a little bit of work at the beginning where people were consolidating important information into this front-facing summary documentation page instead of just whatever random files were lying around. We put all the most important information into one document and that took a little bit of front-loaded engineering time sometimes. But we had two new hires, two new engineering hires, and actually that was pretty useful immediately for them. They would ask me like, oh where is this and where is this? And I was able to point them to these docs and they were able to unblock themselves by and large for the most part, which took a lot of time out of my hands. And they were able to write their first diff in the first two or three days actually. And then this process not only was accessible for the entire organization but we were able to take it further and essentially iterate on this process where all these people would come to me and they'd be like, hey I noticed that these people kept asking me about this process or this process. So I was able to point out, I was able to develop, I was able to add to our process this idea of creating backlinks and prioritizing adding backlinks to any relevant information so that people would be able to self-service and unblock themselves to find the relevant adjacent articles.
