About a question I couldn’t answer, until I remembered I’d already lived it.

A colleague and I were wondering a while ago whether technical writing should work closely with management, or more specifically, with the CTO. I didn’t have a strong answer, and we moved on. Then we passed by the topic again recently, and I just couldn’t get it out of my head. As so often happens when I go for a walk, it hit me like a bolt of lightning: I’ve worked exactly that way already!

The most normal thing in the world

Why couldn’t I remember? Maybe because it felt so natural and intuitive and just right that it wasn’t anything special. Looking back and comparing it to other reporting lines, it definitely was special! We didn’t even have an org chart. Reporting to the CTO was simply lived reality.

In that company, the CTO oversaw all engineering staff, as well as the roles that directly supported them, such as scrum masters and technical writers. He had regular routines with his lead engineers, worked closely with the product owners of the engineering teams, communicated regularly with recruiting, and maintained good relationships with sales and marketing as well as with external partners. For employees, these flat hierarchies are absolute paradise; I can imagine that it was a huge challenge for him.

What really stuck with me and impressed me was the closeness he sought with his tech teams. Not at all in a micromanagement kind of way, but out of genuine interest and involvement, to build understanding, provide guidance, spark new ideas, and make decisions together that he could stand behind and that wouldn’t get in the way later on.

That closeness, that exchange, that give-and-take also existed between him and me in my role as a technical writer. (Oh my goodness, anyone reading this might think I’m buttering people up and writing a glowing tribute here. But I’m telling you: that’s exactly how it was! And yes, he read this before I published it.)

What the closeness looked like

In practice, it looked like this:

  • He involved me early. “Let’s involve Birgit at this point” was a typical move in engineering rounds.
  • He asked for my perspective and then actually used it. We sat for hours in his office discussing his vision, sharpening next steps, and putting things into action.
  • He bounced ideas off me. He walked into my office to share an idea he’d had on his bike ride to work.
  • He pushed me to grow. He made me create an account on X (Twitter at the time), and he literally got on my nerves until I learned the basics of Ruby on Rails (he was a fan) — and I actually did it!

What the closeness made possible

The closeness didn’t stay between the two of us. Because he took my role seriously, everyone around him did, too. For the tech organization, that meant a technical writer who was part of the work in every direction, and a translator between the disciplines:

  • Engineering: I was a trusted partner for making the API experience great, finding good wording for APIs and within APIs.
  • UX: We combined the user perspective with the engine room by writing UI texts together.
  • Product owners and scrum masters: Documentation work was planned into the sprints, including time to sit down with developers and understand a feature before documenting it.
  • Recruiting: I translated what works well in tech, and what we do there, into a language they understand. Some of them even wanted a crash course on GitHub.
  • The outside world: I wrote blog posts about what we did in tech and showed our culture, pairing up with HR and the CTO.

A sounding board

The closeness also ran the other way. Working with so many disciplines gave me a kind of 360° perspective, and he valued that. I became a sounding board for him: what do I read between the lines, and how do things fit together across the disciplines? I was one voice among many. The people he stayed in close contact with, from engineering to product to recruiting, each added their piece to his bigger picture, and I was glad to be one of them.

Worth trying

So, should technical writing report to the CTO? For me, it felt right, and it worked. What made the difference wasn’t a line on paper, but the position: close enough to the CTO to be asked early, heard, and backed.

If you lead a tech organization, think about what that closeness gives you. Someone who understands your product from the API down to the UI text. Someone who knows what the teams are working on and where they struggle. Someone who can tell your engineering story to the developers outside. And someone who sits at your table instead of at the end of a ticket queue.

You don’t need to redraw an org chart for that. Start by giving technical writing a seat in the engineering rounds. Ask for its perspective before the decision, not after. And make time for a regular exchange, because that closeness is what made everything else possible.

I only realized later how rare that was. It felt like the most normal thing in the world. It wasn’t.