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!