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.
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.
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
Redis Pub/Sub vs. Apache Kafka
Terraform vs. CloudFormation: Which Is Better for You?
Your take on a trend:
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:
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.