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?
Saturday, December 24, 2011
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!
Subscribe to:
Posts (Atom)