Center Stage

There’s an unspoken belief in tech that the stage is reserved for only the most knowledgable, most talented, and most well-known developers of the industry. 

That is bullshit

When I gave my first talk, I was six months into my first developer gig, I didn’t have a computer science (CS) degree, and I wasn’t a particularly good engineer. In other words, I was still learning. And guess what? I’m still still learning.

But I knew one thing. It’s not how many people you know, but how many people know you. I knew I would go further in my career if I could get in front of more eyeballs. And that key advantage was worth the risk of falling flat on my face on stage. 

I mean, what did I have to lose? Turns out, nothing. 

It’s not how many people you know, but how many people know you.

My first talk didn’t go particularly well. I had traveled to Kyiv, Ukraine — yes, I traveled across the world to give my first talk — and my 30 minute talk turned into a 16 minute rushed panic about developers and operations folks hating each other. 

I didn’t land the jokes. I had a full-on anxiety attack when I couldn’t get the second monitor to connect just before the talk and had to run back to the speaker room to beg one of the English speakers for help. A veteran calmly walked me through my panic, set me up for success and stayed to cheer me on. (Thank you, kind human.)

And guess what? 

It wasn’t the best talk anyone had ever seen. Not by a long shot. But it wasn’t the worst talk anyone had ever seen either. Most folks got up, left the room, and immediately forgot me. A few stayed to say it was a clever idea. 

Every speaker has given a first talk and the vast majority are incredibly kind. 

It was in Kyiv that I learned the first fundamental truth of public speaking: The audience wants to see you succeed. Did you just scoff at me? I’m serious! 

Think abut the last time you sat in the audience of a talk at a conference. Or watched a video of a talk on YouTube. Did you want the speaker to fail? Of course not. That would be a waste of everyone’s time. 

The audience wants to see you succeed. 

The folks in the audience is there for a reason. You already got their attention. They’re genuinely interested in the topic, and they want to learn — from you. Lean into that. Trust the audience. 

The people in front of you aren’t a peanut gallery of commenters waiting to judge you at every “um” or “so” or verbal stumble. They’re eager participants — friends even — who signed up to join you on your journey. They believe in you. You should believe in you, too. 

Finding inspiration.

The idea for Humpty Dumpty: A Story of DevOps Gone Wrong was born out of my own frustration with my colleagues and the company at which I worked. 

I was a brand new backend engineer, fresh out of a seven-month code school focused on Ruby, and was learning Java on the job. But even with such little experience, I knew developing software didn’t need to be so damn difficult. 

You see, Java was the easy part. (I really do love the language.) It was the people, specifically the operations engineers, who were D-I-F-F-I-C-U-L-T. 

I wrote a feature that swapped out the hero images in a carousel on the front page of the website for one of our largest customers. The feature grabbed an image randomly from a collection hosted in our content delivery network (CDN). It was a rather straightforward feature, passed quality assurance (QA) and was released. 

Only it would intermittently fail. (Inconsistent software — every developer’s worst nightmare.) I double-checked the code, peaked at the logs in the development environment, and nothing seemed off. So I went to look at the production logs. 

Only I didn’t have access. 

So I walked over to one of the operations engineer’s desk and asked how to get the logs. I was met with a condescending, “Why do you need them?” 

I explained. “That sounds like a code issue.” 

I asked again if I could have the permissions necessary to view the production logs just to see if anything looked off. We went back and forth and back and forth. In truth, developers at the company weren’t given permission to view production logs. The production environment, it seemed, was the domain of the system administrators. 

Cool, cool. 

I was still breastfeeding at the time and had a closet I would retreat to throughout the day to pump. I sat down with my laptop and angry-typed the abstract for the talk. 

Humpty Dumpty sat on a wall,

Humpty Dumpty had a great fall. 

All the king’s horses and all the king’s men

Couldn’t put Humpty together again.


All the king’s horses and all the king’s men — I couldn’t think of a better analog for the incessant fighting between developers and operations folks in traditional engineering teams. 

Yes, I wrote the start of my first talk hooked up to a breast pump. You can do anything, ladies! 

Investing in yourself.

Signing up to speak was a bit of a risk. And I footed the bill for the travel myself. I had the privilege of being able to afford the flight and I negotiated with the conference to have them pay the hotel fees. I thought of it as an investment in my own career. And it eventually paid off, big time. 

My career before tech was writing. I ghost wrote for various people too busy to manage their own blogs and contributions. One of my clients ran a highly profitable business training professionals adhere to modern etiquette standards.  

Although her business was niche, my client wasn’t particularly brilliant, or talented, she wasn’t incredibly engaging, but she had built a reputation that landed her national speaking opportunities on stages and TV shows. 

I was frustrated in my own career and so I thought about it for a long time. Why did she get these opportunities and I didn’t? I was just as smart, just as capable. 

What I discovered was, in short, she put herself out there. 

She wrote (or hired me to write) articles on a regular basis. She wrote a book proposal and shopped it around until a publisher showed interest. She acted as her own publicist, pitching reporters on stories and interviews. 

It wasn’t that she was so unique as to be noticed. It was that she continually claimed space for herself. Reputation builds reputation. The more people think you’re talented, the more people think you’re talented. 

Standing up on stage doesn’t mean you’re the best. It doesn’t mean you’re the smartest, or the most capable, or even an expert. 

It means you signed up. You put in the work. You claimed you time in the spotlight. And that, perhaps even more than your day-to-day work, will get you noticed. 

Emily Freeman

Emily Freeman is a bestselling author of two books, DevOps for Dummies and 97 Things Every Cloud Engineer Should Know, and a prolific speaker, traveling across the globe to educate executives and engineers on the best approaches to AI, DevOps, and cloud engineering.

Emily has been studying, leading, and shaping the developer journey for the last 15 years. She has led developer relations and product marketing at AWS, Microsoft, and cutting-edge startups. Emily is based in Denver, Colorado.