Lately, Google's been announcing decisions it's made to focus efforts on key products. I've made similar decisions to focus the efforts of my team, and thought it would be interesting to talk about why and how I did this.
There are a few constant challenges in staffing tech writers:
My team had fallen into this trap when I stepped up to management. Google has a myriad of interesting projects going on at any given time. As a company, it's known for its bottom-up management style. This is great for being empowered to get things done quickly and with a minimum of politics. However, it's historically been difficult to get a straight answer about what projects are most important.
The writers on my team are extremely talented. They do great work on the projects we work on, and their project teams love working with them. However, previously, our portfolio consisted of a smattering of random projects that, taken as a whole, didn't make much sense. More importantly, we weren't solving many strategic business problems for Google. Because of that, we had a tendency to be overlooked when it came time for things like resources, recognition, and headcount allocations.
The first thing I did to resolve this was to step back and make some deliberate decisions about what business problem we were trying to solve. In our case, that was "Support our developers." Then I made choices about what kinds of projects would do the most to help our developers. In some cases these choices led to our working on the documentation for key products. In other cases we had to think bigger; providing frameworks that let others contribute to the documentation with our guidance, or providing solutions for sticky problems that impacted multiple documentation sets at a time.
Since there wasn't really any clear external prioritization guidance, I had to come up with my own criteria. To do that, I made some high-level decisions about what factors might indicate that a project is important. The criteria I decided to use to evaluate project requests is as follows:
How many users does the product have?
Vetting project requests is a good first step. The next step is to be proactive about seeking out strategic projects to work on. I do this by making sure I'm involved in key meetings; especially those where new projects are reviewed and discussed. This gives me information about what new projects are coming down the pike, in time to plan resources needed to staff them. At the same time, it gives me the opportunity to meet the project stakeholders and raise awareness of the value of documentation and the work that my team does.
These days, developer product teams at Google are much more aware of the value of good documentation. The other day, in a product review meeting, a product manager said "We can have all the great APIs we want, but without good documentation, we have nothing." (By the way, he's right. :-) ) People think of us when they're planning new projects, and get us involved early.
Focusing our portfolio was not an instant process, to be sure, but it was worth it. It drastically increased the impact my team's work has on our developers. Once Google understood the role that tech writers play in supporting our developers, our group gained the status, recognition, and respect that our work merits.
There are a few constant challenges in staffing tech writers:
- Product teams often don’t think of tech writers until the last minute.
- It takes time to get to know a developer product well enough to document it, so it’s not usually possible to immediately refocus someone on a different project when requested to do so. Therefore, staffing takes time.
- The closer teams get to releasing a product without documentation, the more frantic they get, and correspondingly, the louder they get.
My team had fallen into this trap when I stepped up to management. Google has a myriad of interesting projects going on at any given time. As a company, it's known for its bottom-up management style. This is great for being empowered to get things done quickly and with a minimum of politics. However, it's historically been difficult to get a straight answer about what projects are most important.
The writers on my team are extremely talented. They do great work on the projects we work on, and their project teams love working with them. However, previously, our portfolio consisted of a smattering of random projects that, taken as a whole, didn't make much sense. More importantly, we weren't solving many strategic business problems for Google. Because of that, we had a tendency to be overlooked when it came time for things like resources, recognition, and headcount allocations.
The first thing I did to resolve this was to step back and make some deliberate decisions about what business problem we were trying to solve. In our case, that was "Support our developers." Then I made choices about what kinds of projects would do the most to help our developers. In some cases these choices led to our working on the documentation for key products. In other cases we had to think bigger; providing frameworks that let others contribute to the documentation with our guidance, or providing solutions for sticky problems that impacted multiple documentation sets at a time.
Since there wasn't really any clear external prioritization guidance, I had to come up with my own criteria. To do that, I made some high-level decisions about what factors might indicate that a project is important. The criteria I decided to use to evaluate project requests is as follows:
How many users does the product have?
- If there is existing documentation, is it one of the X most-read doc sets at the organization based on Analytics data?
- If the product is an API, how many requests are (or are projected to be) made to the API itself?
- What’s the (projected) rate of adoption for the product?
- Is the project in the company high-level goals?
- Did it get a company or industry award?
- How many engineers are on the project?
- How many support people are on the project?
- If the product is an API, does it enable developers to create applications that work with a strategic company product?
- Is the project focused on a high-level community goal that the company supports?
- How much money is the project projected to bring in this year?
- Will revenue increase or decrease over time?
Vetting project requests is a good first step. The next step is to be proactive about seeking out strategic projects to work on. I do this by making sure I'm involved in key meetings; especially those where new projects are reviewed and discussed. This gives me information about what new projects are coming down the pike, in time to plan resources needed to staff them. At the same time, it gives me the opportunity to meet the project stakeholders and raise awareness of the value of documentation and the work that my team does.
These days, developer product teams at Google are much more aware of the value of good documentation. The other day, in a product review meeting, a product manager said "We can have all the great APIs we want, but without good documentation, we have nothing." (By the way, he's right. :-) ) People think of us when they're planning new projects, and get us involved early.
Focusing our portfolio was not an instant process, to be sure, but it was worth it. It drastically increased the impact my team's work has on our developers. Once Google understood the role that tech writers play in supporting our developers, our group gained the status, recognition, and respect that our work merits.
Nice post.
ReplyDeleteIn my former life:-), I faced a similar roadblock, and 'borrowed' a piece of business functionality from the engineering team who had been designing a way to measure 'priority, complexity, and risk' for our customer's projects.
Late in the requirements phase, early in design, I would work with the PM to try and get a handle on the priority, complexity, and risk of a project.
* The higher the combined total of these three factors, the earlier a writer needed to be involved.
* The higher the priority, no matter the risk or the complexity, the more I knew we needed a skilled writer to be involved.
* The higher the complexity, the more I knew we would get squished at the end (as it meant developers would be scrambled trying to figure it out themselves, let alone try and document a moving target).
I like that framework, Meggin. It's an excellent point that you need to think about complexity v. writing resources. I'll keep that in mind for the future.
ReplyDelete