Here is the counterintuitive part of pitching InformationWeek: the person with the most to say about enterprise technology, the vendor who builds it, is often the least welcome voice in the publication. Not because editors dislike vendors, but because readers do not trust them by default. A CIO reading InformationWeek wants to hear from people who have made the same decisions they face, and to learn what happened next. A vendor who can write like that gets in. A vendor who writes like a vendor does not.
That shapes everything about how to get featured in InformationWeek. The publication, now part of Informa TechTarget, has served IT leaders for decades. Its coverage centers on the business of running technology: strategy, budgets, talent, governance, risk and the hard trade-offs that come with adopting new tools. If your pitch helps an IT leader make one of those decisions better, you have a shot. If it describes your product, you do not.
Write for the CIO who reads it
Picture the reader. A CIO at a 3,000-person company who has an AI governance policy due to the board next month, a vacancy for a security lead she has not filled in four months, a budget review where finance wants a 10 percent cut, and a cloud bill that grew faster than anyone predicted. She reads InformationWeek on her phone between meetings. She does not need another explanation of what large language models are. She needs to know how a peer handled the board conversation about AI risk, what other IT leaders cut first when budgets shrink, and how to tell whether the cloud bill is a design problem or a pricing problem.
Every pitch should start from a reader like that. Ask yourself which decision your idea helps with, and whether a CIO would forward it to a direct report with the note “read this before our meeting.” If the answer is no, the idea is not ready.
This also tells you what tone to use. IT leaders are skeptical, busy and well informed. They respond to plain language, specific numbers and admissions of what went wrong. They tune out superlatives, buzzwords and anything that sounds like it came from a campaign brief.
Which format fits your expertise?
InformationWeek publishes staff-reported news and features alongside commentary and analysis from practitioners and industry voices. There are three realistic ways in, and choosing the right one saves time.
The first is as a source for a staff story. Reporters and editors write features on IT leadership topics and need people to interview. If you or your executive has led a major transformation, built an unusual team structure or handled a public crisis, you can be a valuable source. The pitch is short: who you are, what you did, what you learned, and one surprising detail that shows you have a real story.
The second is as a commentary author. Practitioners and executives can write pieces that share a point of view grounded in experience. These are the most competitive and the most demanding. Editors look for a clear argument, original insight, and no promotion. Guidelines and submission routes change, so check the site’s current contributor information before writing anything.
The third is as a data provider. If your company has research on IT spending, staffing, adoption or incidents, that data can anchor news coverage. Muck Rack’s State of Journalism 2026 found that 40 percent of journalists value original data or research in a pitch. For an IT leadership publication, a credible survey of IT decision-makers or anonymized operational data across many organizations can be the most direct path to coverage.
Whichever route you choose, the source needs a title and a track record that an IT leader would respect. A head of IT infrastructure who has run three data center migrations is a stronger source on cloud repatriation than a chief marketing officer, however senior. If your company does not have that person, borrow one: a customer, an advisor or a former CIO on your board who will speak in their own name.
Pick one format per pitch. Editors do not want an email that offers a byline, an interview and a dataset all at once. That reads as a request to do your thinking for you.
The Boardroom Translation Test
Before you send any idea to InformationWeek, run it through a test we call the Boardroom Translation Test. It has three questions, and an idea should pass all three.
The first question: could a CIO explain this idea to the board in two sentences? Board members do not care about container orchestration or vector databases. They care about risk, cost, speed and competitive position. If your idea cannot be translated into those terms, it belongs in a more technical publication.
The second question: does the idea include a cost of being wrong? IT leaders make decisions under uncertainty. Ideas that name the risk, such as “if you get this wrong, here is what it costs and how you will find out,” are more useful than ideas that only describe the upside. A commentary piece on AI governance that explains what happened when a company skipped a step will be more valuable than one that lists best practices.
The third question: is there a peer in the story? IT leaders learn from other IT leaders. An idea backed by your own experience running IT, or by named peers who agreed to share what they did, passes. An idea backed only by your product’s capabilities does not.
To see how the test changes a pitch, take a common vendor idea: “AI observability tools are essential for modern IT teams.” It fails all three questions. Now rework it. “We cut our own AI inference costs by a third after we found that 40 percent of model calls came from three internal tools nobody was monitoring. Here is how we found them and what we told our board.” That version can be explained to a board, includes the cost of being wrong and has a peer in the story. Use your real figures, but notice how the shape changes. It is the same expertise, framed for the reader.
Most vendor ideas fail the third question. The fix is to find the operator experience inside your company. Many vendor executives were CIOs, CISOs or IT directors before they joined the vendor. Write from that experience. Others work closely with customers who would share their stories on the record. Bring those customers in as sources rather than writing about them yourself.
Submitting commentary that gets accepted
If you choose the commentary route, the pitch should include a working headline, a two-sentence summary of the argument, three to five sentences describing the main points, a note on the author’s relevant experience, and a sentence confirming the piece is original and not published elsewhere. Keep the pitch itself under 300 words. Some editors will want to see a full draft. Others prefer to approve the idea first. Follow whatever the current guidelines say.
When you write the piece, start with the reader’s problem, not the author’s company. The first paragraph should describe a situation the reader recognizes. The body should share what the author learned, with specific examples and numbers where possible. The ending should give the reader something they can do differently next week.
Strip out anything that sounds like marketing. That includes product names, references to “our platform,” customer counts and phrases like “industry-leading.” An editor will remove them anyway, and their presence in a draft signals that the author does not understand the publication.
Write like a peer, not an expert lecturing an audience. Use “I” and “we” where the author did the work, and name the size and type of organization so readers can judge whether the lesson fits theirs. “When we rolled out our first AI coding assistant, we underestimated how much code review would slow down” lands better with IT leaders than “Organizations must carefully assess the impact of AI coding tools on development workflows.” The first sentence sounds like someone who did the work. The second sounds like a white paper.
Expect edits. Editors at publications for senior audiences will tighten arguments, cut sections and change headlines. Accept that gracefully. An author who argues over every change is an author an editor will not work with again.
Following up without burning the relationship
Editors at InformationWeek receive more pitches than they can answer. If you do not hear back in a week, send one short follow-up that adds something new, such as a fresh data point or a timely connection to recent news. If you still hear nothing, move on. Pitch a different idea a month or two later rather than pressing the first one.
When a piece runs, share it with your network and send the editor a brief thank-you note. Do not ask for a link change, a headline change or a quick follow-up piece. Let the first piece establish your reliability.
Over time, the goal of learning how to get featured in InformationWeek is to become someone the editor thinks of when a topic in your area comes up. That happens when you deliver what you promised, on time, without making the editor’s job harder. It also happens when you share things that help the editor even when they do not lead to a byline for you: a heads-up on a trend you are seeing, a source who might be useful, a correction to a common misunderstanding.
If you remember one thing about how to get featured in InformationWeek, make it the reader in the opening section: a CIO with a board meeting next month and no time to waste. Every idea you send should earn a minute of her attention. The vendors who do best in InformationWeek treat it as a long relationship with a sharp, skeptical audience. They write sparingly, they write from experience, and they leave the product out. That is harder than sending a press release. It is also the only approach that works with readers who make technology decisions for a living.