FAANG and the others™

This was precisely what happened to us six months ago. We should have written a blog post. 

1. Taking pride in what your engineering team does. Most likely, you're not sending rockets to mars. You know what? Many companies aren't either, but they're good at storytelling. I wrote about it in one of my last blog posts.
2. Give engineers recognition for their great work. It's a way to keep them engaged with your organization and deliver great stuff. Creating purpose — through intrinsic motivators — is critical for this. Daniel Pink talks about it in his book "Drive: The surprising truth about what matters to us."  
3. Improve employer-branding awareness. That is more of a long-game type of thing. As Gergely Orosz mentions, it takes at least 6-24 months to start seeing results. Often, much more. However, when it works, it's an invaluable resource to impress candidates with what you built in your hiring pipeline.

What can an engineering manager do about it?

1. Leading by example. I'm active on social media, sharing my views on management, DevOps, Cloud, and technology. In Adevinta, I write a weekly letter to my team called "Bricks of Love," too. I m
2. Giving work-time. If you don't clarify that people can do these things during work and follow up on them, your teams won't get anything out the door.
3. Setting deadlines and leveraging personal goals. As Parkinson's Law says: "work expands to fill the time available for its completion." It's everywhere, and people are (too?) comfortable with it. Leveraging yearly goals from people and pushing them through — acceptable, agreed — deadlines works best.
4. Offer peer-reviews. You can be a peer reviewer of your team's posts to help them become more confident. I also like to suggest different reviewers within the organization. On the one hand, it gives a diverse point-of-view to the writer. On the other, it generates serendipity and agency for these reviewers, making them more known across the company. Your team may need to learn about a Staff+ engineer that knows a lot about distributed systems. It's the ideal moment to connect with them.
5. Help with distribution channels. The person writing an article may need to familiarize themselves with the communities and key places to share their article once published. At the same time, it's more powerful when someone, not the author, shares it. So you can re-tweet it and share it in your social networks, Discord, and Slack groups. I'm sure your team members will thank you for that.
6. Help with storytelling. Most of the great blog posts I've read are not telling anything novel. But they talk about it from an insider perspective and create relatedness with their topic. Maybe your team thinks they're sweeping the floor. Your job is to make them aware they're sending rockets to the moon. I like the Pixar framework to tell a story:

Writing and distributing Hackernews material

1. Pick a topic you learned from experience in the last 6-12 months. Your audience will prefer a first-hand, recent experience rather than a theoretical exercise. This technique helps deal with procrastination when publishing. It's easier to repackage an incident review or an internal presentation into a public blog post rather than create something from scratch.
2. Create a story. How does your story connect to the users of your company (e.g., buyers, sellers, riders, apartment renters)? Leverage that and start with WHY. Once you get hooked on the audience on why something is a problem, the write-up of the solution becomes way better. You must sell your content!
3. Pick at least two peer reviewers. Our mental model of the World is always limited. Selecting peers to suggest changes or additions or to focus on the main thread is helpful. I recommend selecting peers with different skills. For instance, a domain expert in the topic you're writing and someone that is less familiar but has excellent writing skills.
4. Do editorial work. Get someone to do an editorial review of your work. It can be yourself or someone from the communications department in your company. Cut all the unnecessary parts. Then, cut again. You may re-write some sentences or an entire paragraph. I recommend using Grammarly, the Hemingway app, or  LanguageTool as a writer assistant to make your job easier. Some experienced bloggers, such as Gergely Orosz, hire a full-time editor to help them review the books and posts.
5. Get a catchy title. Think about how you react to how different authors create titles for their articles. Playing with words usually has a nice effect. I called "Avoiding the SCHIP sinking," one of my latest internal memos about the product we maintain (SCHIP), and played with the word "ship," using the verb sink as a metaphor for how to avoid the team to fail. There are other commonly used patterns, such as the "X considered harmful", after Dijkstra's famous paper.
6. Distribute it wisely. As a software engineer's job doesn't end when merging to main or deploying to production, your job as an author doesn't end when the article is published on the Internet. If you want recognition — for yourself or your team — you need to distribute it to a broader audience. How do you find the right audience? It depends on the content. It may be one of the Software architecture channels in your organization's Slack, a local community such as "Barcelona Engineering," or niche ones such as "CNCF" Slack. As for social networks, it's helpful to use Twitter and LinkedIn to talk about it or re-share your company's account in case you publish in the corporate blog. Finally, you can submit it to Hackernews.

It's not all about carrots and sticks