I've been lurking around here for more than a year, right after I joined a product development company from Romania. I was the first content writer in their team (ever!) and my role was to craft content for the company's outlets but also to help my dev colleagues write their own stuff on the blog.

"help my dev colleagues write" - sounded great on paper. Except I barely knew how a programmer's brain works, what they respond to, and how much I could stretch things until I got them to write.

Bear in mind, I am doing this among people who enjoy to learn continuously and challenge themselves - so much so, that this is what the company culture is centered around. And still, even in this environment, I needed to hack my way towards earning their trust in what I did, why on Earth I was there, and how I could help them.

That's when I started reading Dev.to.

And noticed how a lot of y'all were discussing about writing, its importance in your careers, getting your stuff out there and whatnot.

So here I am, making my own DEV account, sharing my journey to helping devs put their stuff on the www .

1. The Learning Phase: People, Keyword Research and a New Tool

Why would a dev bother writing on the blog? They have their projects and zillion tasks to worry for, the last thing they need is a marketing fella nag them about blog articles.

This was me last year. Since then, I learned to see these thoughts as a challenge and not a deterrent. So I took 3 paths (all at the same time):

• I started asking people about their projects, their tech struggles, and what's next for them (these talks usually happened at lunch breaks and such). Of course I failed to really understand the technical terms most of the time, but I tried to listen, absorb and sometimes suggest (in subtle ways or not) that they try to write about whatever was going on in their dev lives. Guess who soon became a dreaded sight in the office? :)
• I started drafting mind maps with keyword research for the first tech piece I was about to publish. I used the keywords to craft strategic title variations that would serve as inspiration for a bunch of other pieces on the topic. This helped me start scratching the surface and really get acquainted with the tech lingo, the trends, and the communities in the industry.
• I had a meeting with my Marketing Manager, Managing Director and CTO, and presented my research for a SEO Tool that will help us better manage our content. Great, now I could make sure everyone's articles will be well taken care of.

Note: I was able to do all these because the CEO, CTO, and Marketing Manager are advocates of 'going the extra mile', are great writers in their own good, and this doesn't go unnoticed. People easily feel you actually practice what you preach, so there were a few devs who were already writing on a regular basis, emulating what they'd seen in the upper management.

2. New Pieces, New Flair

I slowly started writing my first articles on the blog, shared them on our Slack channel, got reacts for them...in short, people were seeing this was serious.

3. Asking for Help

I obviously needed help for most of what I published. It did not come easily.

I nagged developers for feedback on software development articles.
I nagged CEO to explain the business side of it all.
I nagged everyone to give me insights about internal initiatives.
I was nagged to deliver stuff.

Bottom line: this dynamic drives results.

4. Show, Don't Tell

At the end of 2018, there were 8 tech articles published (as opposed to 1 in 2017). The momentum had to be carried forward, so by the time my colleagues were back from vacation, I pulled some guidelines on writing best practices and used them in a presentation about all the *why*s and *how*s of writing content.

Thoughts about long-life career assets were shared and evil schemes were used (data, graphs, fun visuals, GIFs).

Snippet:

5. Act Immediately + Follow-up

Whenever someone is willing to give writing a try, I have a quick chat with them about the topic and I let them know I'm always available for suggestions, optimization, and any kind of edit.

Then I follow up, depending on the case - if I sense determination, I do it after one week; if there's hesitation, I may come back in one month or whenever it feels right.

The crucial move is to find that balance between pushing the person and letting them know you're always there for support.

6. Put the Effort in

What I also do is I don't spare any effort when my help is needed.

Is there proofreading to be done? I do it as soon as possible, by myself, to get things done ASAP.

Are there more radical changes to be done (logical structure, flow, transitions)? I book one hour - maybe two - in a meeting room and invite my colleague to an intense side-by-side editing session. I don't replace their text with my content; I rather trade a solution, offer alternatives, and guide the person towards finding their own optimal words.

7. ...then Make Some Noise

I didn't shy away from singing the praises for those who did write. This is the kind of stuff I post right after an article is published:

Let people feel appreciated for stepping up their game? Hell yeah!

After All...

It's different strokes for different folks.

Some people only need inner triggers to write and you might just need to stir those motivations up.
Some others need constant support and follow-up.
Some write when they feel like ranting or proving a client that what they say is right.
And then there's also the 'impostor syndrome' issue: a looot of people just don't consider they have something to say. Even though they spend one or two months' worth of sweat to find a unique implementation, it doesn't occur to them a bunch of other devs might be googling for that particular solution.

My point with this article is to emphasize how much you can achieve if you find a way to be there and provide encouragement or constructive feedback for someone you know has relevant stuff to say.

Have you ever helped fellow developers write? What was the outcome? I'd be thrilled to hear about more journeys and steal good practices from y'all. And if you need more advice...do ask away, it's free!