On recognizing what the job actually needed, and building that, too.

When something genuinely excites me, it shows immediately. I get a hundred ideas at once, I’m in full “let’s do this” mode, and nobody can stop me. Twice in my career, that energy has dropped me into the exact same situation: no map, no precedent, just a brutally steep learning curve to climb from scratch. That pattern is a way of working I’m genuinely proud of, which is why this is a very personal post. What follows is just one example of how it played out, not the whole story.

The brief

It always starts the same way: “We need documentation.” Great, I think, glad you noticed. But: for what purpose? For whom? Is there more behind this than it sounds like? There usually is.

The onboarding I designed myself

Then comes the part nobody hands you a map for: meeting people, building understanding, watching, learning, asking questions, figuring out who does what, how processes work, where the real challenges sit. In one job, I got all of it at once, no half-measures:

  • documenting APIs (Application Programming Interfaces), a technology I had never touched before
  • testing those same APIs myself, making actual REST calls
  • the technical product behind all of it: the backend of an online shop
  • the actual product: the shop’s frontend
  • the people building all of it: software engineers, UX designers, frontend designers, product managers

That’s not an onboarding handed to you. It’s one you build yourself, deciding where to start, what to learn first, and where you can add value fastest. It’s also the phase I miss the most once the pioneering is done. The way you might miss a kid who grew up too fast.

It’s never just documentation

Once you take a closer look at the whole thing, there’s a lot to do, because it was never “just” about documentation. It’s the entire experience of using the software or the technical product: how it’s perceived, how usable it is, how it’s presented, how clear, complete, and current the information is, how well users are supported, how clear the communication is. There’s a name for that: Developer Experience. And there I was, one single technical writer, facing all of that. Nobody had scoped this job before me, so I was drawing the boundaries as I went, while colleagues on the side were already quietly wondering how to keep me busy once the docs were actually written.

Building the thing that didn’t exist yet

The more I learned about the technology, the APIs, how the developers actually worked, what product management was planning, and where sales wanted to take things, the clearer one thing became: we needed to own Developer Experience end to end, not just write docs about it, and that meant building a platform. Not just for our own engineers, but for external partners too. And as the technical product scaled further, for HR as well: the portal’s blog and our posts on Twitter (now X), showing how and what we actually worked on, turned out to help attract new engineers. That platform became a developer portal. Nobody had a headcount for “platform that doesn’t exist yet,” so pioneering meant building the case for it, too. It became mine to build.

Becoming the product owner nobody hired

Alongside the deep dive into “all things API,” the developer portal turned into my product. Everything it needed, I had to learn on the job through:

  • countless conversations with developers
  • close, ongoing exchange with the CTO
  • alignment with product management
  • competitive analysis and research

I’d picked up the nickname “swiss army knife” by then, but building a developer portal single-handedly is not actually a superpower. I needed engineering resources and design/UX support. I had to learn how to prioritize, how to write user stories, and how to set up processes and actually get them running. And then keep adjusting all of it as things changed around me. That’s how a technical writer becomes a product owner: not by title, but because someone had to fill the gap, and I wanted to take on that challenge.

Cross-discipline, out of necessity

That’s how I ended up in constant exchange with UX designers, frontend designers, frontend engineers, a scrum master, another product owner, and HR. I learned how each of them worked, what they paid attention to, where our disciplines overlapped, where we could support each other, and where we could build something new together. None of this was written into anyone’s job description. I found the connections that had not been mapped yet.

From there, UI writing developed almost out of nowhere, and looking back, this was the logical next step from working on the APIs. I already knew exactly what those APIs exposed, which capabilities they represented, and what that meant in the frontend. Paired with a UX colleague who knew exactly what online shop owners needed and where they got stuck (or shouldn’t!), we became a genuine two-person team.

Then localization, because the pattern doesn’t stop

Once a software product goes international, someone has to pioneer that too, and I got to be the one who did. Once you’re already deep in UI writing and API work, localization is the logical next link in the chain. I happen to hold a degree in technical translation, so this wasn’t a stretch, it was a fit. Gathering requirements, feeding them into development, finding the right tooling, setting up internal processes, finding translators, and setting up translation workflows: that felt like a third job on top of the other two. That was also the point where I finally needed help.

What “we need a technical writer” actually built

Looking back at the whole arc of pioneering, spread over roughly five years: “we need a technical writer” turned into a new product, two new disciplines built from scratch, and a small interdisciplinary team. By the end, I wasn’t a solo technical writer anymore. The team was me, one colleague combining localization manager and technical writer in a single role, two UX designers, a working student running the portal’s blog, a scrum master supporting the process, and engineering resources consistently allocated to the portal. What had been one person facing an open-ended list of challenges became an ensemble that could actually play the full composition. That portal documents more than twenty APIs across two technical platforms.

The undefined space that makes pioneering work

Here’s the part that makes this more than a lucky one-off: this happened to me twice. Both times, the opening line was “we’re looking for a technical writer” or some version of “we need someone for this, we’re just not sure what to call it.” Both times, nobody knew yet how the role would actually work, only that something was missing. And both times, that was exactly the kind of situation I love to work in: an undefined space, no fence around it yet, and the kind of learning curve that only pioneering work gives you.