A Senior Technical Writer role has opened at Cyber City, DLF Phase 2, in Gurugram. It's full-time and on-site, and the documentation this person owns gets read by real users trying to solve a real problem, not by an internal reviewer checking a box. The role sits within the broader technical writing function, working closely with several product teams rather than being tied to a single codebase.
Background and Experience Expected
A bachelor's degree is the baseline for this seat, most often in English, technical communication, or computer science, though the company will look at a related field if the writing samples are strong enough. What actually carries weight in the hiring process is a portfolio: documentation you've written that's still live somewhere, ideally covering something technical enough that a reader would need real explanation to follow it. Ninety months of hands-on technical writing experience is expected, with a track record of taking a genuinely complicated technical concept and making it usable for someone who didn't build the thing themselves. Someone coming from a related field, developer relations or QA, say, with strong writing samples but a less conventional title, would still be worth a serious look.
Skills This Role Draws On
- Technical writing itself, at a level well past basic grammar and formatting, the kind where structure and sequencing carry as much weight as the sentences themselves.
- Comfort with documentation tooling, whether that's a Markdown-based workflow, a dedicated help-authoring tool, or a static site generator tied into a version control system.
- Clear communication with engineers and product teams, since most of the raw material for a good guide comes from a conversation, not a spec document that already says everything plainly.
- Attention to detail sharp enough to catch the difference between what a feature is supposed to do and what it actually does once it ships.
These skills lean on each other more than a bullet list suggests. A writer who's precise on the page but weak at pulling information out of a reluctant engineer will still produce thin documentation, no matter how clean the prose is.
Familiarity with API documentation tools built around OpenAPI or Swagger is a real plus given how much technical writing work now touches developer-facing content. Experience with a style guide, Microsoft's or Google's developer documentation style being the two most common references, also speeds up onboarding, and any comfort with basic diagramming or screen-capture tools rounds things out well. None of these extras replace strong core writing ability, but they do shorten how long it takes a new hire to become genuinely productive on the team.
What the Work Looks Like Day to Day
- Build user guides and technical documentation from the ground up for products that don't yet have any, and keep the existing library from going stale.
- Sit with engineers directly to pull out the details that never quite make it into a ticket or spec- the edge case someone mentions in passing that turns out to matter.
- Revise published content as the underlying product changes, so a guide never quietly drifts out of sync with what a user actually sees on screen.
A specific example from recent memory: a spike in support tickets traced back to a setup guide that still referenced a configuration screen the product team had redesigned two releases earlier. Nobody had flagged the doc as stale because nothing about it looked obviously wrong; it just described a screen that no longer existed. Catching that kind of quiet drift before it turns into a wave of support tickets is a core part of this role. Some weeks lean heavily toward writing brand-new material for an upcoming launch, and others go almost entirely into maintenance and cleanup work instead.
How Senior Writers Grow Here
A senior writer who's built real credibility with engineering, meaning teams start looping them in on a feature before it ships rather than after, tends to move toward owning documentation strategy more broadly rather than just individual guides. That shift usually tracks with how much trust a writer has earned across teams, more than with time served in the seat. Someone who's spent most of their career maintaining existing docs, without much experience standing up documentation for something brand new, may need to build that muscle before taking on a broader strategic role.
Compensation and Benefits
- A monthly salary of ₹73,000.
- Health insurance.
- Paid time off.
- Performance-linked bonuses tied to output quality and consistency, not just volume of documents shipped.
- On-site cafeteria access and cab or commute support, both standard for employers in this part of Gurugram.
For a senior technical writing role specifically, this salary falls within a reasonable range for Gurugram, and the cafeteria and commute support offset a meaningful portion of the daily cost of working out of a hub like Cyber City.
Working Out of Cyber City
The office is in Cyber City, DLF Phase 2, one of Gurugram's busiest commercial hubs, and this role is on-site only, with no remote or hybrid arrangement. This opening was posted through Naukri Mitra. Cyber City's density of large employers means the commute support offered here matters in practice, given how heavy traffic into and around DLF Phase 2 gets during peak hours. The documentation team itself works closely with product and engineering, sitting near enough to those teams that a quick clarifying question doesn't require scheduling a meeting. The on-site cafeteria also means lunch doesn't turn into a lost hour spent navigating Cyber City's crowded food court.
How to Apply
Send a resume along with links to two or three writing samples, ideally something technical enough to show how you handle real complexity rather than a simple how-to piece. If any of your samples were written for an internal audience and can't be shared publicly, a brief written description of the project can serve as a substitute. Shortlisted candidates should expect a practical exercise involving a short piece of raw technical information that needs to be turned into something a user could actually follow. Strong samples matter more here than a perfectly polished resume, so don't hold back on sharing the messier drafts if they show real problem-solving.
