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!
Top comments (2)
As someone who's worked at companies with great tech blogs and wrote on them a few times, here's my take: getting developers to write on the company blog is really hard without some sort of "carrot" or incentive.
Here's why: this kind of writing is pretty thankless to most many engineers. It's a lot of work and they have to write it in a more moderated fashion -it needs to sound more professional than a personal blog and it needs to make the company not look bad, so nothing too controversial. And it will also be in front of a lot of people.
Is there a reward for this? Are blog posts parts of performance evaluation? Do they help get promoted? If the answer is yes, and this is clearly communicated, managers will suggest this as growth areas for experienced engineers and those developers will come volunteering. If it's not then you're left with the enthusiastic developers who write one or two articles. Those who are good writers quickly realize they can just blog on their own, with less moderation, instead of using the company blog. And those who find it difficult and realize there's no reward - implicit or explicit - might not spend the effort on this.
At Uber, writing posts is something that's explicitly recognized in performance evaluations and promotion cases. This helps ensure people know it's not "invisible work" and a lot more people step up. Managers also encourage people to grow in this direction, knowing they are helping people in the right direction and it's something the company explicitly values.
So I would ask the CTO what incentive they are giving to developers to write and make sure it goes beyond a "thank you". And don't forget that C-level executives, who are invested in the company due to their position already have a large incentive to write: developers won't have the same.
Of course, none of the above helps if there's no infrastructure and professional help in place, to make it easy to write, for those who want to. It sounds you've done a remarkable job getting things off the ground all by yourself - well done! But you'll probably need organizational support to make this sustainable, over the one-woman-show. Wishing you best of luck!
Thanks a lot for your input (it made me head over to Uber's blog to read more :))) )! I agree with everything you said about organizational support and it's actually familiar to me since this happens in my case as well.
Without the CTO upping the ante in this regard, I wouldn't have been able to do what I did. He was the one who wrote the first tech pieces, who initiated a writing call to action at the beginning of the year and who helps programmers spot a lot of writing opportunities. And yes, writing is rewarded across performance reviews and in free days (matters for promotions as well).
"Those who are good writers quickly realize they can just blog on their own, with less moderation, instead of using the company blog." -> since we're not a big company, it hasn't been the case for us (yet). People are encouraged to write using their own voice, blog on their own platforms as well, and there haven't yet been cases of blatant differences from the 'brand voice'. But I'm assuming this is way harder to control in a big company so I'll bear it in mind for the future.
The best thing for me, at the end of the day, is that (regardless of the number of articles I manage to facilitate), I can see the snowball effect: someone writes for the first time, some others see that and then they write for the first time. And so on :))