In 2017, I wrote this post (Getting Your Presentation Submission Accepted For DevOps Enterprise Summit In 2017) with some tips on getting your DevOps Enterprise Summit presentation proposal accepted. In that video, there is a link to a fantastic one-hour video that I did with fellow programming committee member Damon Edwards (co-founder of Rundeck), and Margo Cronin, whose submission we had accepted in 2016 when she was Head of Technology Architecture at Zurich Insurance (and now at AWS!).

In this post, I write about the goals of the DevOps Enterprise Summit, how important the CFP (call for presentations) process is, some statistics about submissions, the top reasons submissions are declined, and other advice on how to write winning submissions. 

I also want to thank the three programming committee members who spent 45 minutes with me, discussing all these topics: Jeff Gallimore (CTIO, co-founder, Excella), Dominica DeGrandis (Principal Flow Advisor, Tasktop), Jon Smart (Partner, Enterprise Agility, Deloitte). I think this is another incredible testament of what a great programming committee we have, so willing to invest time in helping the community.

At nearly 4,000 words, this is a long post, but I wanted to give you as much advice as I could from evaluating over 2,000 submissions over the last eight years of running this conference.

You can watch this video full of fantastic advice that we recorded here: https://youtu.be/E-kX-0XcJf4 

Our Programming Goals and Resulting Conference Structure

As you likely already know, the DevOps Enterprise Summit is a conference for technology leaders in large, complex organizations implementing DevOps principles and practices. The event programming emphasizes both evolving technical and architectural practices, and the methods needed to lead widespread change in large organizations. Our goal is to give leaders what they need to create better value sooner, safer, and happier.

We recognize that leaders come in all forms—they don’t always have fancy titles, occupy the highest positions in the org chart, or have the most people reporting to them. 

It’s the job of the programming committee to create conference programming to best achieve those goals. Internally, among our goals is creating a conference series that is even better than those before it—which is no small challenge, as we thought our most recent conferences were our best conferences yet!

As before, the foundation of the DevOps Enterprise Summits are experience reports—as leaders and adult learners, we tend to learn best by studying how other people in similar situations have solved similar problems. For those of you not familiar with experience reports, they typically include the following:

• My organization and the industry we compete in.
• My role and where I fit in the organization.
• The business problem that we needed to solve.
• Where we started and why.
• What we did, including tools and techniques.
• The outcomes that resulted.
• The challenges that still remain.

We are looking for experience reports in the following areas (i.e., conference tracks):

• Standard Experience Report: This is the most general category of experience report, assumed to be presented by a technology leader. If there is a more specific category below, please use that one.
• Experience Report (Repeat): We often invite speakers from previous years to present on the continuation of their journey. If you’d like to present a continuation story, choose this track. Please see below on how we’ve reduced the number of these talk slots and why.
• Spanning Business/Technology Divide: These are experience reports which are co-presented by technology leaders and their business counterparts. We believe these are the most important type of experience reports for the community, because we are looking for as much evidence as we can that technology transformations create genuine business value.
• Overcoming Older Ways of Working: These are experience reports showing how technology transformations can co-exist with other parts of the organization, which have often been obstacles (e.g., information security, compliance, project management, legal, etc.).
• Next Generation Ops and Infrastructure: This track has the loosest requirements around experience reports, because we are looking for talks that describe or demonstrate how Ops and Infrastructure teams create value (and stay relevant). These talks are often about SRE culture; creating and maintaining internal platforms, often to elevate developer productivity; and so forth. You can find a whole blog post about our goals around this track here: https://itrevolution.com/call-presentations-next-generation-ops-infrastructure-practices/.
• Liberating Data and DataOps: Although this is a new CFP track this year, we chose many talks on this topic in 2019. This track focuses on experience reports that solve the immense problems of getting data from where it resides (often in data warehouses, systems of record, etc.) to where it needs to go (in the hands of business users and development teams to use in their daily work). 
• Dynamic, Learning Organizations, Transformational Leadership, and Psychological Safety: This is another new CFP track this year, but again, there were many talks on this topic in previous years. We are looking for experience reports around the dramatic changes needed in leadership and culture. We would like to see talks submitted by technology leaders around how they’ve created a learning dynamic and psychological safety, overcoming top-down, command-and-control cultures.

In combination, these tracks make up 73% of the presentations at the 2020 DevOps Enterprise Summits—and most of these talks come from our CFP (call for proposals)!

Let me repeat that again, just in case you didn’t get that—experience reports are almost three-quarters of all the talks at the conference, and most of these talks come from the CFP. So, if you want to speak at DevOps Enterprise Summit, submit your idea!

Statistics Around the CFP: The Acceptance Odds are Better Than Ever

At DevOps Enterprise Summit Vegas 2019, we had 65 talks, distributed into these tracks:

• Experience Reports: New—12
• Experience Reports: Repeat—6
• Spanning Business/Tech Divide—9
• Next Gen Ops—8
• Overcoming Old Ways of Working—7
• Dynamic, Learning Organizations—5 (none came from CFP)
• Leadership Lessons and Transformational Leadership—3 (none came from CFP)

In 2019, we received 270 submissions for DevOps Enterprise Summit Vegas. This statistic blew my mind. So here’s the math: if every submission requires 10 minutes to evaluate, then evaluating every submission would require 2,700 minutes, or 45 hours. (And if all nine programming committee members evaluated each submission, that would require 16 person-days of effort.)

This isn’t meant to deter you from submitting—after all, about 15% of submissions were accepted to speak! (As a mental benchmark, this is 2x higher than students applying to MIT.)

And the odds of acceptance are higher than ever. We reduced the number of repeat experience reports by 50%, which makes more room for new experience reports. Conceptually, we plan on having repeat speakers present every other year, so that they have larger updates to share, have a different co-presenter, etc.

Of course, in 2019 we split up the submission evaluation across the entire programming committee, and it was very important that every submission got at least one review. And 80% of the submissions received two reviewers or more.

Every review process is imperfect, but I’m extremely satisfied with the review process we’ve created. However, this brings up the next point and an offer: I am happy to discuss any specific submission, and give you feedback on why your talk was not accepted. (It might not happen right away, but Jess will make sure that you eventually get a response. Especially if you’ve submitted multiple years without getting accepted, please take me up on this—just email Jessica Meyer and me at jessicam@itrevolution.com and genek@itrevolution.com.) 

We Are Looking for Experience Reports from All Industry Verticals, and at All Stages of the Journey

As Jon Smart says in the video, “When in doubt, submit.”

One of the great uses of experience reports is to negate objections—in other words, when people talk about doing DevOps, they’ll often hear, “There’s no way that that will work here, because we’re not a [insert industry vertical here: bank, telco, intelligence agency, retailer, so on].”

The best way to negate these arguments is to show experience reports of other organizations in the industry vertical they’re in. Over the last seven years of the conference, we have collected over 400 experience reports from nearly every industry vertical, many of them heavily regulated, such as financial services, government agencies, healthcare, etc.

As fellow programming committee member Jason Cox, Director of Platforms and Systems Reliability at Disney, once said, “I’m always bringing these experience reports to my leadership, showing them that the most unexpected organizations are doing DevOps.”

There are still some industry verticals that I am personally looking for more experience reports from: specifically military services, energy, healthcare providers, higher education… (Looking at the US Standard Industry Code manual, I’m amazed how many of these we’ve already covered!)

And by the way, when I look at submissions, one of the first things I look for is the brand recognition of the submitter’s organization, and whether that brand generates over $1 billion in annual revenue. I will often enthusiastically support a submission from a firm that everyone recognizes, and one that will likely generate a reaction of, “Wow, I can’t believe ____ is doing DevOps!” 

But what if you’re not that far along in your DevOps journey? I’ll echo what Jon Smart advised, “When in doubt, submit.” We are looking for experience reports from all stages of the DevOps journey, whether it’s early, in-progress, or if you think you’re done, well, tell us why you think so! (Har har.)

To state this as explicitly as possible: if you’re at a famous, large company, you have a huge advantage over other submitters from more obscure, small firms. 

(One counter example is Maks Kiamos Shah, Domain Head Chemical Development & Product Life Cycle Management, Syngenta (2019). I had never heard of Syngenta, but when I learned that they were one of the largest life sciences firms, with a mission of helping feed the world’s population, with nearly $15 billion in annual revenue and 30K employees, I knew it was a presentation that we needed to accept. So, if your brand isn’t well known, make sure to explain what your firm does: https://www.youtube.com/watch?v=6FA63iwyk-8.)

Top Reasons Submissions Are Declined

After reviewing the declined submissions, here are the top reasons that submissions are declined, along with some recommendations:

“Too Vendor-y”

Personally speaking, some of the most satisfying comments that people have told me about the conference is, “I love this conference because I’m never being sold to or been pitched something from the stage.” As someone who loves going to conferences, I can attest to how frustrating it can be to be pitched constantly from the stage—and this is something that we’ve strived to minimize throughout the history of the conference.

Many of the programming committee are from software vendors, and it is not an exaggeration that some of our best friends are from software vendors—personally, I spent thirteen years at a software vendor (Tripwire, 1997–2010).

As stated from one of the guidelines in our CFP: “We seek open and transferable knowledge. Attendees must be able to use the bulk of the presentation’s lessons without buying or using a particular tool or service.”

But many submissions we receive are too product-specific, or speak too narrowly about a product category or product. In general, if you need a specific product to get the outcomes you’re espousing, your submission is likely to be rejected.

As Jon Smart said in the video, “Often these submissions read like a sales pitch because it probably is a cut and paste of a sales pitch. It’s easy to come across them and see something for what it is quite quickly.”

In other words, no one likes a presentation that is just a sales pitch for a specific methodology or product.

Consultant/Vendor Submitting Without a Client/Customer

In almost all cases, consultants and software vendors should submit with their clients. Over the years, we’ve had some intriguing submissions come in from consultants, and for the most promising ones, I’ve emailed the submitter, asking to re-submit with their client. Many were not able to do so, and we had to reject the submission. (In two separate and memorable cases, a vendor submitted a joint proposal with a client, but I later discovered that they did so without the client’s consent, and that client did not have the authority to speak for their organization!)

Few submissions of this type manage to get over the finish line—the most common reason is that the vendor was unable to get someone from their client pool to submit with them. However, we have accepted many of these talks over the year. Some have been excellent, while others got feedback that the consultant did too much of the talking.

Here are some fantastic examples of great talks that fit this category:

• Ingenico ePayments and Accenture (2016) on transforming their core payment process platform into microservices: presented by Vincent van Kooten, Domain Manager Front Office, Ingenico ePayments, and Gebrian uit de Bulten, DevOps lead Gallia (Netherlands, France, Belgium, Luxembourg), Ingenico/Accenture. https://youtu.be/8Al9nHt82wU
• Fiat Chrysler Automobiles and DXC (2018): presented by John Ediger, Principal, DevOps Transformation, DXC Technology, and Christopher Gallivan, Co-Leader of DevOps Transformation, Fiat Chrysler Automobiles. https://www.youtube.com/watch?v=uyVModa-7s4
• Jeffery Payne, CEO, Coveros, Inc., and Dan Gahafer, Program Manager [former], DISA forge.mil Program (2016): this was a fantastic talk about how they worked together to create a continuous delivery pipeline supporting a top-secret application for the DISA forge.mil organization. One of the unique challenges was that the teams were never able to see the production environment! Fantastic! https://youtu.be/6l7zeU1Le0M 

Exception: Technology Leaders at Software Vendors

If you’re a technology leader at a software vendor, and you have a technology transformation story to share, by all means, submit! After all, you are a member of the technology leadership community! Over the years, we’ve accepted many talks like this:

• A great example of a talk we accepted that came through the CFP was Anne-Marie Fred, Senior Software Engineering Manager from IBM (2016): “Adapting the Squad Model at IBM: DevOps and the IBM Marketplace.” All of her experiences will surely resonate with anyone who has had to figure out how to organize their developers, operations people, and designers. https://youtu.be/Arzypra73hU
• Another great talk was from Jennifer Perret, Group Program Manager, Skype Infrastructure, and Sam Guckenheimer, Product Owner, Azure DevOps, Microsoft (2017): “Moving Skype To DevOps In The Cloud”: this was a fantastic talk about all the work required to migrate all the infrastructure that powers Skype to the cloud, which runs on Java and Postgres. https://www.youtube.com/watch?v=TyKv7LOevZ8

Submitter Is not Senior Enough, or Sphere of Influence/Control Too Small

This requires some explanation, because this reason may seem contradictory to what I wrote in the beginning of this blog post: “We recognize that leaders come in all forms—they don’t always have fancy titles, occupy the highest positions in the org chart, or have the most number of people reporting to them.”

In the past, the typical titles of presenters have included managers, directors, project and program managers, VPs, and CIOs. Of course, we’ve also accepted submissions with other titles, such as architects, chief architects, technical fellows and distinguished engineers, showing that leaders don’t necessarily have to have “manager” in their title. 

Personally, when I look at a submission, as I wrote above, I first look at the organization the submitter is from. The second thing I look at is the seniority of the person. In my experience, I’ve found that the scale of the transformation and impact that it has is proportional to the level of influence or authority they have. And that often correlates with the title of the person. 

As Jeff Gallimore stated in the video, “In general, the more senior the person, the larger their sphere of influence, or control that person has in the organization. And generally, as the scope of the transformation grows, the more difficult transformation becomes and the challenges they face. Experience reports that talk about these challenges are the sweet spot for the conference.”

I’ve found that when senior leaders are on stage sharing their experiences, the implication is that they’ve gained a level of buy-in across a large part of the organization—which is what this community aspires to achieve to enable the changes we want.

(By the way, an example of a great talk from someone who didn’t have a huge team reporting to them was David Ashman, formerly Chief Architect of Blackboard: https://www.youtube.com/watch?v=SSmixnMpsI4.)

Okay, so what can you do if you have a title that doesn’t obviously signal that you have a large sphere of control? Well, you can explicitly explain it in your submission—something like, “I influence the processes that support the business lines that generate 50% of the revenue of our $4 billion company.” 

Absent this type of explanation, when we run into submissions like this, I’ll often personally respond, asking the submitter if they could co-present with their boss or someone who has more line responsibility.

(And remember, if you have a great story to share, consider teaming up with one of the leaders that you worked with—this isn’t required, but again, it helps convey to us that your submission tells a story about technology leadership.)

Submitter’s Organization Not Large Enough

During the video, one of the things that came up was how surprised we all have been by the number of submissions from startups, businesses with fewer than ten employees. We have rarely accepted one of these submissions, because we don’t think their experiences translate enough to large, complex organizations.

Recall that DevOps Enterprise Summit is intended to be for technology leaders in large, complex organizations, likely with hundreds, thousands, or even tens of thousands of software engineers and with billions of dollars in annual revenue. What’s astonishing is the universality of the problems faced in these organizations, such as entrenched and conservative middle management, low trust and bureaucratic cultures, large amounts of outsourcing, powerful legal and compliance offices, and so forth.

So if your submission is describing a startup experience, you are likely at a significant disadvantage—but if you’ve still faced challenges that you think are relevant to the DevOps Enterprise community, describe them explicitly, and we’ll definitely consider it.

One great example of a presentation we accepted was Neil Crawford, Head of Technology, Findmypast, on “True North and Technical Debt” (2019): https://www.youtube.com/watch?v=R7ZCVlPX-jo. Despite having only 150 employees, it was a great presentation about investments in developer productivity, which is as relevant for smaller organizations as it is for the tech giants (i.e., the FAANGs: Facebook, Amazon, Apple, Netflix, Google, etc.)

Other Advice To Get Your Submission Accepted

There was lots of other great advice from Jeff Gallimore, Dominica DeGrandis, and Jon Smart on how to get your submission accepted:

• Be concrete about your outcomes. Either describe metrics or include testimonials about how people have valued your work. Short of having business stakeholders co-present with you, the best way to convey their appreciation is by quoting them.
• Ask a programming committee member for help. If they love your story, they will help champion your submission. And if it generates a lot of excitement within the programming committee, we’ll often move to “immediately accept.” In many cases, certain stories bypassed the entire CFP process, and we invited them to speak.
• Pick a specific problem that you set out to solve. Problems that we all face are fantastic, because they’re likely universal problems that span industry verticals, independent of company size, age of company, etc.
  A submission that describes how you set out to tackle one big problem and goes into detail about how you overcame it is far more likely to be accepted than one that describes lots of problems, but is vague on what you did and what the outcomes were.

From Jeff Gallimore: “Talk about impact. Talk about why the problem was a big problem, and how it negatively impacted people. Talk about what you did, and how it improved things for people. Talk about the business impact you made, and how it moved the needle for the organization.”

Well said!

• Share what you learned, and what the audience will learn: if it’s something that resonates with us, and we think it is relevant to the DevOps Enterprise community, we will lobby for it!

Demographics and Underrepresented Communities

Speaking of demographics, I’m particularly pleased that we’ve had so many women speakers at DevOps Enterprise Summit. In 2014, we had 43% women speakers, and over the years, we’ve done our best to preserve such a high representation of both women speakers and attendees, which more closely matches the actual demographics of most technology organizations. During most years, over a third of talks have included a female presenter.

I’ll again quote Margo Cronin: “My advice is to encourage women in technology to submit, because you have a story to tell. It’s not about tools and skills; it’s about leadership.” 

Having women presenters is important to us, and we know that there are many out there leading transformations in their organizations. We strongly encourage women to submit their stories to the CFP either as a solo presenter or as a co-presenter. If you know of someone on your team or in your network who fits the criteria outlined above, please encourage her to submit a presentation.

As Margo Cronin said in the 2017 video, “I encourage everyone who has a DevOps story to share to submit!” I absolutely echo her encouragement, and for anyone submitting, here is the lens that the programming committee views submissions, so you can better shape your own winning submission!

Last Advice: Submissions That Are Almost Always Rejected

• “Why DevOps Is Important,” “Why DevOps Is Needed In The Modern Digital Economy,” “Why Culture Is Important For DevOps”: These are “why” talks that try to convince people that DevOps is important. However, rest assured that DevOps Enterprise Summit is a conference where everyone is already convinced DevOps is important. We’re all at the conference to learn from people who are pioneering the practices that are helping them transform their organization. (Yes, Simon Sinek advises us to always talk about “Why Before How.” But trust me, if your submission focuses on “why” for a problem that we already know is urgent and important, your submission is almost guaranteed to be rejected.)
• “Capability XYZ Is Important, And That’s What Our Product Does”: These are the thinly-veiled product pitches. Please see the sections on vendors above..
• “Doing Something Important with Our Product ABC”: This is a bit more nuanced—this type of presentation talks about an important problem (e.g., automated testing, continuous integration), but is being submitted by a vendor. In this case, I’d recommend the talk get re-submitted by one of your clients, and drop the name of the product being used from the title. (Again, please see the sections on vendors above.)

Quick Hits on DevOps Enterprise Summit

And finally, here are a few quick facts about the conference to help you understand the conference audience.

• Last year, more than 3,500 people attended DevOps Enterprise Summit.
• More than two-thirds of our attendees were managers, leaders, directors, architects, and executives.
• Our attendees represented over 500 organizations from around the world who are struggling with the same challenges as you.
• We talk about the big, audacious problems that large organizations are working on.
• We’ve hosted presentations from more than 500 speakers
• We’ve evaluated more than 2,000 speaker submissions since 2014.

We hope you will join us to share your transformation stories and the impact you are creating!

- About The Authors

Gene Kim

Gene Kim has been studying high-performing technology organizations since 1999. He was the founder and CTO of Tripwire, Inc., an enterprise security software company, where he served for 13 years. His books have sold over 1 million copies—he is the WSJ bestselling author of Wiring the Winning Organization, The Unicorn Project, and co-author of The Phoenix Project, The DevOps Handbook, and the Shingo Publication Award-winning Accelerate. Since 2014, he has been the organizer of DevOps Enterprise Summit (now Enterprise Technology Leadership Summit), studying the technology transformations of large, complex organizations.

Follow Gene on Social Media

• 
•