Well, folks, the time has come for me to move on. Today is my last day at Google.
After I eliminated my position, I got to thinking about what I want to do next. I thought about going back to tech writing, and there was plenty of opportunity to do so at Google, but it didn't draw me in, like it has in the past. I thought about managing a different type of team, but that didn't resonate with me either. In short, there was just nothing at Google that called my name.
I'm a firm believer in choosing work that you can be passionate about. We spend so much of our time at work. Our job should be something that gets us out of bed in the morning with anticipation for the day to come. Sure, not every day can be like that, but overall, we should be doing something we love.
I also believe that careers don't have to be linear. For some, the right choice is to work in one place for a long time, becoming a deep expert in what they do, and climbing the ladder over time. Others prefer to hop from startup to startup, engaging in the excitement of a new venture. Still others prefer to contract, sometimes working 80 hours a week on an exciting job, and other times taking long vacations. Many of us encounter a combination of those situations over the course of our career.
Finally, I see skills as abstract entities that can be applied to the same job title, or can be repurposed for new and different roles. I think that outlook will become increasingly necessary as personnel needs morph to accomodate an ever-more-quickly changing world.
So. What's next for me?
I'm going to start my own company, helping organizations implement collaborative developer documentation.
The industry's changing. We've seen it. I've talked about it a bit in this blog, but here it is: Developers no longer go to the manual first when they get stuck. They go to Google, and type in the problem or error code they're encountering. More often than not, this leads them to a forum, a blog, or some other "non-official" resource.
"Official" documentation is still important. Without an initial version of the docs that accompanies the API distribution, and explains how to set up the SDK, how to use the APIs, and gives some sample code, it would be impossible for developers to understand what the API is, and what it's meant to do. That documentation can never be written by the community, because writing it requires close collaboration with the developers who created the API.
However, there's a long tail of documentation that is best written by the community. For example: explanations of how to overcome obscure errors that occur only in certain environments, sample code that shows how to use the API for things it's very good at, but for which it wasn't intended to be used, and, sometimes, up to date translations of the official docs.
For one thing, this kind of information is best learned through trial and error by a large user base. Even if a tech writer did nothing but use the APIs, she would never encounter errors that occur with a different development environment, software version combination, or operating system. The community is working on a diverse set of environments, will encounter these errors, and can help each other overcome them.
Secondly, more people means more viewpoints, and more viewpoints can provide better documentation. The whole is greater than the sum of its parts. A community of collaborators provides creativity and strategic thinking that can only come from the meeting of more than one mind.
There are already many tools that enable collaborative documentation, such as Mindtouch, MediaWiki, and SharePoint, among others. However, these tools fall short of encouraging people to contribute their knowledge to the docs. There's no incentive for them to do so. I have some ideas for fixing that problem.
Another roadblock with collaborative docs is that the review process becomes a bottleneck. It is not sustainable to have a single person, or even a few people, review all contributions. I have some ideas for fixing that problem too.
So there you go: that's what excites me. That's what pulls me out of bed in the morning, eager to find out what the new day holds. And so, with a mixture of anticipation and sadness, I say goodbye to Google, and welcome the next chapter in my career.
Think through your career. Does its flow resonate with you? Are there threads that have resurfaced at various points in your career? What do you like best about what you're doing now? What haven't you done yet that you hope to do in your lifetime?
Friday, February 3, 2012
Friday, January 13, 2012
The future of technical communication
For most of the history of technical communication, docs have been a megaphone that enable one-way declarations from tech writers to product users. In many cases, tech writers still perceive docs in that way.
However, user behavior has diverged from this model. Since web search became good and readily available, product users no longer exclusively rely on the official docs. Now they listen to whatever the search engine deems to be the most reliable answer to their question. Sometimes, this comes from the official docs. More often than not, though, the most useful information comes from forums, blogs, YouTube, and more.
As tech writers, we're at a crossroads. We can either ignore the fact that the world has changed, or we can embrace it and realize that docs are now a multi-way conversation, of which tech writers only have a single voice. Our job is still to make the most of that voice, but it's also to facilitate the rest of the conversations and make them more accessible to users.
Two examples of sites that do a good job of this are:
Both sites seamlessly merge different, related content sources, including docs, forum answers, photos, and video.
Contributor profiles are a major focus of both sites, and the contributions of each user combine to create a site-wide reputation for that user. iFixit has a particularly good algorithm for establishing and showcasing contributors' reputations.
For both sites, the interface for contributing content is quite easy to use, with WYSIWYG authoring environments and brief but useful inline guidance. The Instructables site has excellent guidance on how to write good content (although it would be nice if this page were easier to find.)
What are other important considerations for collaborative sites? What are examples of your favorite sites?
However, user behavior has diverged from this model. Since web search became good and readily available, product users no longer exclusively rely on the official docs. Now they listen to whatever the search engine deems to be the most reliable answer to their question. Sometimes, this comes from the official docs. More often than not, though, the most useful information comes from forums, blogs, YouTube, and more.
As tech writers, we're at a crossroads. We can either ignore the fact that the world has changed, or we can embrace it and realize that docs are now a multi-way conversation, of which tech writers only have a single voice. Our job is still to make the most of that voice, but it's also to facilitate the rest of the conversations and make them more accessible to users.
Two examples of sites that do a good job of this are:
Both sites seamlessly merge different, related content sources, including docs, forum answers, photos, and video.
Contributor profiles are a major focus of both sites, and the contributions of each user combine to create a site-wide reputation for that user. iFixit has a particularly good algorithm for establishing and showcasing contributors' reputations.
For both sites, the interface for contributing content is quite easy to use, with WYSIWYG authoring environments and brief but useful inline guidance. The Instructables site has excellent guidance on how to write good content (although it would be nice if this page were easier to find.)
What are other important considerations for collaborative sites? What are examples of your favorite sites?
Saturday, December 24, 2011
The Potential of Forums
I've spent the last couple of weeks recovering from a tonsillectomy. Having your tonsils taken out when you're pushing 40 sounds (and is) insane. Surprisingly, though, there are a fair number of people who do it. When I stumbled across a forum of people my age undergoing the same surgery at the same time, I was happily surprised.
The official documentation that my hospital and doctor provided was helpful. It told me what kind of surgery I'd be having done, the expected prognosis and recovery time, and detailed the medications I could take. However, as with any documentation, it was missing a lot. What the official docs were missing, the forum provided. Forums are the perfect complement to documentation.
2 things that forums are great at
In general, forums are great for two things. First, they're a good medium for people in similar situations to share practical advice with one another. I'm thankful to the person who discovered that chewing Dentyne Ice gum helps with ear pain after surgery, and am very glad that person thought to share his discovery. That kind of information would never have been included in my doctor's documentation, but it's nonetheless very helpful.
Forums also provide emotional support. Just knowing that someone else is grappling with the same thing; whether that be going through a medical procedure, or trying to write code against the same libraries, is heartening. Your peers for whatever's at hand are uniquely able to appreciate your triumphs and empathize with the problems you're facing.
2 things that would make forums even better
Forums would be even better if the information that goes into them were easier to get out. They work well for people who are facing the same problem at the same time and can have a real-time conversation about it. But once that conversation is archived, it's harder for Joe Schmoe to come along a few weeks later and get all the learnings that the first people figured out together. The same learning process is often just repeated over and over with new people. Search should be improved for forums so that people can learn from past conversations, as well as current conversations. Even better would be the addition of artificial intelligence to forums, so that forum conversation about documented topics could automatically be added to the relevant documentation. That would bring the best worlds of documentation and forums together; a perfect marriage.
The second thing that would make forums better would be a way for participants to create a reputation based on their contributions, at their discretion. This reputation should be persistent across forums of similar nature; for example, a developer's Java reputation and her Android reputation should combine to show her skills as an Android app developer. Stack Overflow has a good algorithm for reputations; it would be great if we could extend that to other sites.
How do you use forums? What works about them, and how could they be better?
The official documentation that my hospital and doctor provided was helpful. It told me what kind of surgery I'd be having done, the expected prognosis and recovery time, and detailed the medications I could take. However, as with any documentation, it was missing a lot. What the official docs were missing, the forum provided. Forums are the perfect complement to documentation.
2 things that forums are great at
In general, forums are great for two things. First, they're a good medium for people in similar situations to share practical advice with one another. I'm thankful to the person who discovered that chewing Dentyne Ice gum helps with ear pain after surgery, and am very glad that person thought to share his discovery. That kind of information would never have been included in my doctor's documentation, but it's nonetheless very helpful.
Forums also provide emotional support. Just knowing that someone else is grappling with the same thing; whether that be going through a medical procedure, or trying to write code against the same libraries, is heartening. Your peers for whatever's at hand are uniquely able to appreciate your triumphs and empathize with the problems you're facing.
2 things that would make forums even better
Forums would be even better if the information that goes into them were easier to get out. They work well for people who are facing the same problem at the same time and can have a real-time conversation about it. But once that conversation is archived, it's harder for Joe Schmoe to come along a few weeks later and get all the learnings that the first people figured out together. The same learning process is often just repeated over and over with new people. Search should be improved for forums so that people can learn from past conversations, as well as current conversations. Even better would be the addition of artificial intelligence to forums, so that forum conversation about documented topics could automatically be added to the relevant documentation. That would bring the best worlds of documentation and forums together; a perfect marriage.
The second thing that would make forums better would be a way for participants to create a reputation based on their contributions, at their discretion. This reputation should be persistent across forums of similar nature; for example, a developer's Java reputation and her Android reputation should combine to show her skills as an Android app developer. Stack Overflow has a good algorithm for reputations; it would be great if we could extend that to other sites.
How do you use forums? What works about them, and how could they be better?
Friday, December 9, 2011
Why I eliminated my own position
A couple of months ago, I directly managed all of Google’s developer documentation tech writers. Through their efforts, I was responsible for the documentation for all of Google's developer products and APIs. It was a wild ride and a hell of a fun job.
As of today, I have intentionally eliminated my own position by successfully merging all of those writers into the Developer Relations teams for their product. Want to hear the story of how and why I did this?
A couple of years ago, I decided to try my hand at management. I liked the idea of helping people grow their careers, and I like thinking outside the box about how to match up my group's goals with the company's business objectives. Management seemed like a natural fit.
Shortly after I accepted the job, I started to perceive ways I could help the team have a bigger impact. I refocused my team’s efforts on a portfolio of high-priority projects, optimized team performance, led the team through a cultural shift, and built strategic relationships with other teams around Google.
After about a year, my efforts started paying off. We had become a measurably stronger group, with an unmatchable skillset and a very strategic portfolio. The relationships I had been working on came to fruition. My group formally moved from being part of a central documentation group at Google, to being organizationally aligned with Developer Relations.
That was a great first step. It made our mission clear, and it gave us a framework for success. It meant that we were directly interfacing with our developers, so our work was driven by our developer needs, as should be the case.
When we moved into Developer Relations, all of the writers reported to me as their people manager, and worked closely with the product leads for project guidance. Over the course of the next year, I perceived the writers becoming more and more entrenched in their project team. My role became less and less critical as time went on. It became apparent that it would be better for everyone: Google, our developers, Developer Relations, my writers, and myself, to roll the writers directly into their teams.
That's what we officially did a couple of weeks ago, and so far, it's going great! The writers are the first people to see new features, so they're the "canaries" as it were, and can help everyone else on the team figure out how new features and APIs work. The Developer Programs Engineers and Developer Advocates talk to our developers every day. When they identify things that are tripping up developers, they can pass that info back to the writers, so that the writers can make sure these things are clearly explained in the docs.
Companies vary wildly in how they define the reporting structure for their technical writing teams. Sometimes tech writers report up through product development, sometimes through sales, sometimes through customer relations. My team has found our greatest success so far reporting up through the Developer Relations teams for the products we document. With this alignment, we’re able to put ourselves in our developers’ shoes, write documentation that developers actually read, and advocate for product decisions that will be most beneficial to our developers.
How is your team structured? What works about that structure, and what doesn’t?
PS: You might ask - where does this leave me? I had a lot of fun over the last couple of years, and am looking forward to finding out what comes next!
As of today, I have intentionally eliminated my own position by successfully merging all of those writers into the Developer Relations teams for their product. Want to hear the story of how and why I did this?
A couple of years ago, I decided to try my hand at management. I liked the idea of helping people grow their careers, and I like thinking outside the box about how to match up my group's goals with the company's business objectives. Management seemed like a natural fit.
Shortly after I accepted the job, I started to perceive ways I could help the team have a bigger impact. I refocused my team’s efforts on a portfolio of high-priority projects, optimized team performance, led the team through a cultural shift, and built strategic relationships with other teams around Google.
After about a year, my efforts started paying off. We had become a measurably stronger group, with an unmatchable skillset and a very strategic portfolio. The relationships I had been working on came to fruition. My group formally moved from being part of a central documentation group at Google, to being organizationally aligned with Developer Relations.
That was a great first step. It made our mission clear, and it gave us a framework for success. It meant that we were directly interfacing with our developers, so our work was driven by our developer needs, as should be the case.
When we moved into Developer Relations, all of the writers reported to me as their people manager, and worked closely with the product leads for project guidance. Over the course of the next year, I perceived the writers becoming more and more entrenched in their project team. My role became less and less critical as time went on. It became apparent that it would be better for everyone: Google, our developers, Developer Relations, my writers, and myself, to roll the writers directly into their teams.
That's what we officially did a couple of weeks ago, and so far, it's going great! The writers are the first people to see new features, so they're the "canaries" as it were, and can help everyone else on the team figure out how new features and APIs work. The Developer Programs Engineers and Developer Advocates talk to our developers every day. When they identify things that are tripping up developers, they can pass that info back to the writers, so that the writers can make sure these things are clearly explained in the docs.
Companies vary wildly in how they define the reporting structure for their technical writing teams. Sometimes tech writers report up through product development, sometimes through sales, sometimes through customer relations. My team has found our greatest success so far reporting up through the Developer Relations teams for the products we document. With this alignment, we’re able to put ourselves in our developers’ shoes, write documentation that developers actually read, and advocate for product decisions that will be most beneficial to our developers.
How is your team structured? What works about that structure, and what doesn’t?
PS: You might ask - where does this leave me? I had a lot of fun over the last couple of years, and am looking forward to finding out what comes next!
Wednesday, November 23, 2011
Lavacon
A good conference should get you out of your day-to-day tactical problems, and get you focused on the big picture. It should put you cheek-to-cheek with people who are excited about being in the same space, and who are interested in exploring beyond the status quo. You should return to your day job with a renewed sense of energy, and a plethora of ideas that will inspire you to do better, achieve more, think bigger.
For tech writers, that conference is Lavacon. It's dedicated to content strategy, which, in my mind, means thinking outside the box about why and how we produce content. Social media, new content types (such as mobile) and an increasingly global environment mean that the communication approaches we've used in the past are no longer good enough. The role of a tech writer is changing; there's simply too much content to have only one role dedicated to writing all of the docs needed.
My favorite session was Scott Abel's "Help 2.0" presentation. His ideas about how to leverage the crowd to create and organize content were revolutionary. I think that crowd-sourcing has great potential for developer docs and have been thinking about how to do it ever since.
For tech writers, that conference is Lavacon. It's dedicated to content strategy, which, in my mind, means thinking outside the box about why and how we produce content. Social media, new content types (such as mobile) and an increasingly global environment mean that the communication approaches we've used in the past are no longer good enough. The role of a tech writer is changing; there's simply too much content to have only one role dedicated to writing all of the docs needed.
My favorite session was Scott Abel's "Help 2.0" presentation. His ideas about how to leverage the crowd to create and organize content were revolutionary. I think that crowd-sourcing has great potential for developer docs and have been thinking about how to do it ever since.
Friday, November 11, 2011
Telecommuting for tech writers: feasible or not?
Does it make sense to hire a tech writer who is not co-located with the team? The answer is: it depends. Here are questions to ask to help you decide.
- How many people does the tech writer need to interface with?
The more people involved with a project, the more valuable it is for the tech writer to be onsite so s/he can gain economy of scale by meeting with multiple people at once. - How formalized is the exchange of information in the company?
If a company has, and follows, fairly stable specifications and project plans, it's easier for the tech writer to work at a distance. If critical information tends to be communicated in hallway conversations and over lunch, it's better for the tech writer to be onsite so s/he can take part in these conversations. - How important is it that the "powers that be" at the company recognize the value of tech writing?As a general rule, face to face contact increases perceived value. If education about the value of tech writing is strategically important in the long term, it's better for the tech writer to be located onsite. If it's okay that tech writing be viewed as a commodity, then telecommuting is fine.
- How specialized are the requirements of the position?
As with any profession, the best tech writers are hard to find. The more specialized the skillset of the writer you are recruiting, the more you may have to gain by agreeing to let the tech writer telecommute.
Many of the most technical API writers are qualified to be software developers. They have consciously chosen to earn less income as tech writers in order to make gains in work/life balance, and telecommuting is one of the top benefits they are seeking. You can attract exceptional talent by allowing telecommuting.
Friday, October 28, 2011
Evaluating Tech Writer Performance
It's that time of the year again: performance review time. As I sit here making my way through the stack of reviews in front of me, I'm reflecting on the process.
I actually like perf reviews. I have a very strong team. Perf reviews give me the opportunity to reward the ones who really nailed it this year, and to give others the feedback they need to be one of the writers I'm rewarding at this time next year.
Also, perf reviews give me a chance to celebrate all the great work my team has done over the past year. Tech writers are invariably on the forefront of the most exciting new technology, and needless to say, there's a lot of fun stuff going on at Google.
Essentially when I'm evaluating tech writer performance, I look at three things:
How do you think tech writers should be evaluated? If you work with another role, what differences or similarities are there in how performance is evaluated for that role?
I actually like perf reviews. I have a very strong team. Perf reviews give me the opportunity to reward the ones who really nailed it this year, and to give others the feedback they need to be one of the writers I'm rewarding at this time next year.
Also, perf reviews give me a chance to celebrate all the great work my team has done over the past year. Tech writers are invariably on the forefront of the most exciting new technology, and needless to say, there's a lot of fun stuff going on at Google.
Essentially when I'm evaluating tech writer performance, I look at three things:
- What did the person write?
- How good was it?
- How hard was it to write?
What did the person write?
My team comprises about 25 writers, give or take. That's an extremely lean team when you consider everything we write: http://developer.android.com/, http://code.google.com/, http://developers.google.com/, http://www.chromium.org/, and more. In any given year, most of my writers write the equivalent of at least a couple of books. They stay busy!
How good was it?
I read what my team writes, and look for clarity, completeness, and quality. I also look at stats, such as Analytics data, bug queue metrics, and forum data, that objectively tell me how effective the docs were.
How hard was it to write?
This is the tricky one with tech writing. You often have to dig to find out what's behind a document. It might take a day or a month to write the same one-page developer guide; there's really no way of telling on the surface. It depends on what source information there is to start with, including specs, other docs, or sample code, how complete the API is, how well-designed the API is, and how helpful the related subject matter experts are. The only way to find this out is to keep in close communication with the writer, and to solicit feedback from the team the writer works with.
My team has several different levels of tech writers; some straight out of college, some with a long career history under their belt, and many in between. In general, the more senior the tech writer, the more self-sufficient they should be, and the better they should be able to find creative, strategic solutions and guide the work of others.
How do you think tech writers should be evaluated? If you work with another role, what differences or similarities are there in how performance is evaluated for that role?
Subscribe to:
Posts (Atom)