Home on Birgit Bader

Who’s mentoring whom, anyway?

Thu, 20 Aug 2026 00:00:00 +0000

Why mentoring is not a one-way street.

This is about a great young talent, who started as an intern, continued as a working student, and became my mentor along the way.

Fresh out of her bachelor’s degree in IT and with a master’s program ahead of her, she wanted to use the time in between to get a taste of technical writing. Fair enough. Little did she know. Or I, for that matter.

What rebuilding my website taught me

Sun, 16 Aug 2026 00:00:00 +0000

There hasn’t been a new blog post here since June. I did have a lot to write about, but I was busy getting this website up and running — again. What started as a fairly small personal project turned into a surprisingly good exercise in many of the things that I’m surrounded with in my professional life: making decisions that scale, dealing with limitations, working with tools that don’t fit into the game, changing direction, migrating content, working with AI, relying on documentation and, eventually, bringing something live before it feels completely finished.

Helping knowledge move

Sat, 20 Jun 2026 00:00:00 +0000

Usually, I do write a blog post first and then I bring a teaser on LinkedIn afterwards. This time, things happened the other way around (or the story goes in circles). After sharing some thoughts recently, I kept coming back to a question I’ve been asked (and have asked myself) many times over the years: What is it that you actually want to achieve in your work?

At first glance, this is a question that seems quite simple. My focus areas have changed quite a bit over the years depending on my roles, and so have the environments I worked in. I’ve been involved in technical communication, product ownership, localization, terminology work, knowledge management, documentation, and more recently AI. One might think, all those things don’t necessarily look closely related. But there is a pattern.

Finally talking about API docs

Sat, 30 May 2026 00:00:00 +0000

Friends, how much longer were you supposed to wait until I finally post something about API docs?! Waiting is over. Here we go. I’ve actually procrastinated on this topic for quite a while, because I had too much to say, that I genuinely didn’t know where to begin. So let’s start with the basics first.

APIs are everywhere

We interact with APIs constantly, even if we’re not developers ourselves. Your weather app? API. Paying with PayPal? API. Spotify, Google Maps, “Login with Google”? APIs everywhere. At the core, an API is just a way for systems to communicate with each other. One application sends a request, another responds with data. A simple idea with a huge impact.

Magic moments happen between roles

Sun, 03 May 2026 00:00:00 +0000

Do you know those moments at work when something suddenly clicks? When a thought becomes clear, a connection becomes visible, or an idea sparks? These moments happen surprisingly often when technical writers come into play.

The unknown role

In my career, I have often been “the one with the unknown role.” Not because of bad intent, but simply because many people had never worked with a technical writer before.
And honestly? I like that. I like this sense of new territory, those slightly puzzled looks in the beginning, that unspoken question: What does she actually do?
For me, that’s a positive challenge. Because that’s exactly when I get the chance to show what this role is really about. That it’s not just about writing, but about understanding, connecting, and thinking things through together.

The space between how we work and how we document

Sat, 18 Apr 2026 00:00:00 +0000

Exploring the gap between business and technical documentation cultures.

Because so much of the real work doesn’t happen in systems or tools, but in the gaps between roles, where assumptions collide and understanding is never quite complete. Lately, one of those gaps has been bothering me. It shows up in something that sounds simple, but isn’t: documentation. How do we bridge the gap between technical and business documentation?

On one side, we have developers.
They increasingly embrace docs as code: documentation that is versioned, reviewed, and lives close to the code. It evolves with the system and brings a certain clarity and discipline. On the other side, we have everyone else: product managers, designers, business stakeholders. Their knowledge lives everywhere: meeting notes, whiteboards, chat threads, and design or analysis tools. Not because they don’t care, but because their work is fluid, conversational, and fragmented. And, maybe most importantly: time-constrained.

Clarity over perfection

Mon, 30 Mar 2026 00:00:00 +0000

Why technical writing is less about precision, and more about making the right decisions (even in the age of AI).

I make fast decisions. Not careless ones. Just clear ones. I walk into a store, try something on, and within seconds I know: yes or no.
Take it or leave it. Done. My mom? She’ll browse, compare, try things on, reconsider, circle back, and go home with nothing. Sleep on it. Regret it. I don’t have that gene. My default setting is: Do I want it? Do I feel it? What’s the worst that can happen? And if it’s not a clear yes, it’s a no. Always.

The strange case of the „technical writer“

Mon, 23 Mar 2026 00:00:00 +0000

Or: why „technical writer“ is the most misleading job title in tech.

There’s a small professional paradox I live with. I’m trained in linguistics, which means I tend to take words very seriously. Which makes it slightly awkward that my own job title doesn’t quite mean what it says.

Lately, there’s been more conversation about how the role of technical writers is evolving. And yet, the name itself hasn’t really caught up.

Documentation is product thinking

Sun, 08 Mar 2026 00:00:00 +0000

Why good documentation starts with product decisions, not last-minute writing.

Let’s clear up a common misconception in software development: documentation is not something that happens after the product is finished. Not after the sprint. Not before release. And definitely not when someone says, “Hey, can someone quickly document this?” Good documentation doesn’t appear at the end of the process. It grows out of product thinking.

Good documentation starts with product thinking

The best documentation rarely begins with a blank page. It begins with things like:

Datenschutzerklärung / Privacy Policy

Mon, 01 Jan 0001 00:00:00 +0000

Allgemeiner Hinweis

Der Schutz Ihrer persönlichen Daten ist mir wichtig. Personenbezogene Daten werden auf dieser Website nur im technisch notwendigen Umfang verarbeitet.

General information

Protecting your personal data is important to me. Personal data on this website is processed only to the extent technically necessary.

Hosting und Server-Logfiles

Diese Website wird als statische Website bei GitHub Pages gehostet, einem Dienst der GitHub, Inc., 88 Colin P. Kelly Jr. Street, San Francisco, CA 94107, USA.

Impressum / Imprint

Mon, 01 Jan 0001 00:00:00 +0000

Diese Website wird von Deutschland aus betrieben. Die folgenden Informationen werden gemäß deutschem Recht (§ 5 DDG) bereitgestellt.

This website is operated from Germany. The following information is provided in accordance with German law (§ 5 DDG).

Angaben gemäß § 5 DDG

Birgit Bader
Walddörferstraße 305
22047 Hamburg
Germany

Information according to § 5 DDG (Germany)

Birgit Bader
Walddörferstraße 305
22047 Hamburg
Germany

Kontakt

E-Mail: diplomatintech@web.de

LinkedIn: Birgit Bader (opens in a new tab)

Skills and strengths

Mon, 01 Jan 0001 00:00:00 +0000

I work in the space between different roles, responsibility levels, organizational units, and perspectives, turning friction into patterns, and patterns into solutions that scale.

What I do

Sit with a team long enough to find where the friction actually is, not where people say it is.
Ask the questions nobody thought to ask, until the room lands on the same understanding.
Translate between engineering, product, and business until everyone’s using the same words for the same thing.
Facilitate workshops that turn “kind of clear” into something everyone actually agrees on.
Spot the pattern across scattered conversations and turn it into a standard that scales.
Lead by doing — people follow the work, not a title.
Write and structure documentation and architectural guidelines that hold up as a product grows.
Mentor technical writers and young talent as well as build communities around documentation and knowledge management.

How I work

I ask a lot of questions, not because I don’t get it, but because I want everyone to land on the same page.
I translate between ways of working. I don’t force one on everyone.
I like pioneering: the role nobody’s had before is often where I do my best work.
I’ve learned as much from people I was supposed to be teaching.
The questions I keep coming back to when a team scales fast: Where is growth creating friction? What feels harder than it did a year ago?

More of this, in writing

For the roles and timeline, see my CV.

Talks and publications

Mon, 01 Jan 0001 00:00:00 +0000

A selection of where I’ve spoken and what I’ve published in the context of technical communication, API design, and developer experience.

Talks

betterCode() ArchDoc — “If it’s not documented, it doesn’t exist. – 5 Hacks, wie relevante Infos im SDLC überleben.” May 20, 2026
JavaLand — “Das hätten wir dokumentieren sollen… Entwicklungsprozesse optimieren durch Zugang zu Fachwisssen.” April 1, 2025
betterCode() API - “Warum API Guidelines eine coole Sache sind.” March 30, 2023

Publications

Why AI hallucinates – and what technical writing can do about it, OTTO Tech Blog. April 8, 2026
Why using API guidelines is a good idea, OTTO Tech Blog. July 28, 2023
Why it makes sense to introduce a design system, epages Developer Blog. September 26, 2019
In three steps to a great help article, epages Developer Blog. February 21, 2019
Why the heck would we need a software localization tool?, epages Developer Blog. May 15, 2018
A day in the life of a UX team, epages Developer Blog. April 27, 2018
Five compelling reasons why you should care about terminology, epages Developer Blog. September 12, 2017
API writing: just copy and paste?, epages Developer Blog. July 1, 2017
What it’s like to be an agile technical writer, epages Developer Blog. November 30, 2016
How to find out what your target group needs, epages Developer Blog. August 23, 2016
Why UX and technical writing make a dream team, epages Developer Blog. June 16, 2016
RESTful API documentation at ePages, epages Developer Blog. May 28, 2015