Contributors have always been a vital component to The New Stack. Since the site’s inception in 2014, we have had an open door policy for those who wanted to share their own views in a contributed post about what is happening in their corner of the tech community — be they a Fortune 500 company or a single hacker feverishly working on the weekends.

People like TNS because it analyzes and explains technology, with a voice that is positive, forward-thinking and cuts through the nonsense. We don’t talk down to the reader; we know our readers are intelligent.

Contributed stories are, at heart, an exercise in mutual exploitation. We want stories that offer our readers a little something for their time. Busy people, they are. They’re CTOs, project managers, developers, administrators and other technically-inclined IT pros who do not appreciate having their time frittered away on artfully-disguised marketing copy.

To clarify, we are NOT interested in generic “unbiased” thought-leadership posts, crafted by your marketing department. There are other outlets for those pieces. We expect you to biased about your own work — why wouldn’t you be? — as long as what you write is accurate as well.

Story Ideas

We get it. Sometimes it’s hard to come up with story ideas beyond product announcements and promotions. But IT people tend not to read these articles – they want insights from other technologists. This is first and foremost our goal at The New Stack: to help readers do their jobs and make smart decisions. Finding where that aligns with your expertise will help position you to readers as a trusted resource.

Here’s a checklist to help you identify with fresh ideas and on-staff expertise that will resonate with The New Stack readers.

• Talk with your developer relationship advocates and IT project leaders. The best way to find out what readers want to learn is to talk with your IT team, particularly developer advocates who hear firsthand from your users about their concerns and what they need from you to do their jobs well. IT project leaders are also another great resource – what problems are they solving that would help readers? Even if it’s not directly related to your offering, posts such as these help readers identify your company as experts they can turn to. 
• If you are a TNS sponsor, bring your developer relationship advocates to the sponsor meetings with The New Stack. This allows them to be part of the process and assist in the brainstorming of new topics.
• Ask your social media feed. While social media is a great resource for promoting products, it’s also a great way to have conversations with your users about challenges that they may be facing with your product or just technology in general. Those conversations can be turned into articles about unusual ways to use your product or service, or it may reveal areas where your staff can provide expertise. Did a user have a problem that you think others might learn from and you helped solve it? Share that story. 
• Check with the Help Desk. Similarly, your help desk may notice patterns that could be addressed more broadly by an article.
• Identify Passion Projects. Many developers have passion projects and side projects, and some participate in open source projects as well. While these may not tie directly into your product, again, there’s benefit to showing you have on-staff experts in technology and puts your name out there as someone who’s participating broadly in the technology community.
• Provide a walk-through of one of your tools, but from an engineer’s perspective.
• Check out our monthly roundup of hot topics. Each month, we will send you a list of hot topics and issues that you can provide thought leadership on. Sometimes, we may even include another article that you can respond to and offer a different perspective on. Again, talking with your IT staff might help you identify on-staff expertise on topics that may seem unrelated, but will help position your company’s roster as thought leaders. 

Here are some more examples of great content that worked:

Your take on a story in the news, especially with an engineering or startup angle:
What We Can Learn from Twitter’s Outages
How Tech Leaders Are Managing Anxieties after SVB Failure

How you deal with a problem within your own company:
How We Manage Incident Response at Honeycomb
GitLab Data Loss Incident Prompts a Review of its Restore Processes

Why did you take this approach, and not that one, to deal with a technical problem:
Why We’re Sticking with Ruby on Rails at GitLab 

Comparing technologies:
Redis Pub/Sub vs. Apache Kafka 
Terraform vs. CloudFormation: Which Is Better for You?

Explain something:
How to Use Terraform’s ‘for_each’, with Examples
K8s Resource Management: An Autoscaling Cheat Sheet 

Your take on a trend:

A New Architecture for APIs 
Coding Sucks Anyway — Matt Welsh on the End of Programming

Why you chose a certain programming language:
Why Is Python so Popular? GitHub Knows What’s up
Rust vs. Go: Why They’re Better Together

Other Things to Keep in Mind

Please note that all contributed content we run must be original. We do not run posts that have already appeared somewhere else on the Internet. We also require a two-week window when we have exclusive rights to run that content. We ask this to ensure the material gets the highest visibility with our readers and with the search engines. After this time period, contributors are free to run the material elsewhere, such as on their own sites or on Medium.

A contributed piece doesn’t have to be 3,000 words of heavy teaching. It can be 500 words outlining a technical epiphany, a handy technique, or a small lesson learned of some sort. Code snippets are fine, as are visualizations, and stats and metrics are always appreciated.

Please note: ALL post images/illustrations/charts should be 1,800 pixels wide (the size of the page) or 350 pixels tall. This includes feature images.

We do accept tutorials with embedded code. Due to the limits of the WordPress platform, however, we have a set of rules for what we can and cannot support with embedded programming code:

• Code can not be colored, nor have any additional formatting.
• Only ASCII characters — not smart quotes.
• No HTML or any other code with an open or closed brackets.
• Code block space (i.e. tabs) is done on a best-effort basis: We can make no guarantees that code will remain in the structure provided This is especially true with tabbed code (We’re looking at you, Python).
• NO markdown.
• We encourage the use of third-party plug-ins where applicable, such as Asciinema, or dynamic gifs.

Please also note that we can only accept contributions from a company or individual once every three months. We encourage those who wish to submit more frequently to chat with our sales department to find the sponsorship that is right for them.

So if you have questions, or want to submit something, hit us up here.