On DevOps, enterprises and writing books with Emily Freeman

We’ve interviewed Emily Freeman for our 0800-DEVOPS newsletter.

If you’re interested in receiving interviews with thought leaders and a digest of exciting
ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS
newsletter!

###

Now and then you come across some people with great ideas and genuine interest and willingness to help others. Emily is one of these people. Being Senior Cloud Advocate at Microsoft, she talks a lot with developers, listens, and takes their ideas and concerns back home where they actively shape Azure to best suit developers’ needs.

One thing I like about her approach to DevOps is the “people-first” philosophy. DevOps is all about collaboration, maximizing value for end-users and removing bottlenecks. As Emily says, “We humans have reached a point in our evolution at which technology is evolving faster than our brains”. In effect, we are the bottleneck.

It sounds a bit dystopian, but it doesn’t have to be. Her book DevOps For Dummies was released recently, and much of it deals with these sociotechnical challenges. Twitter is raving about the book, and you should definitely check it out. I have, and it’s great!

Chatting with Emily was super interesting… Emily, thank you!

Ivan: I know that this whole book experience was an emotional rollercoaster for you. How far away was writing a book from your comfort zone? Did you regret along the way that you even started writing? Did you have any crisis and what kept you going?

Emily: The book was definitely an emotional rollercoaster, you’ve got that right! I think everyone knows that writing a book is going to be hard. But go ahead and 10x whatever effort you think it would take to get it done. It is by far the hardest achievement I’ve set out to accomplish. I finished it (barely) like a marathoner at the end of a long race. I was empty.
What surprised me most is just what an emotional journey it actually is. Because you have to face a lot of internal demons through the process. Am I good enough? Should someone else be writing this? Are people I admire going to laugh at how bad this is?
There were moments I definitely wanted to quit. But Chad Fowler, before I even started writing told me, “Finish. Because if you don’t, none of the work will count.” I kept thinking about that because it’s absolutely true.

Ivan: DevOps is hot topic today and it seems like everybody has something to say on this subject. Were you at any time concerned that somebody would come up with similar or “better” book before you?

Emily: DevOps is definitely one of those topics that gets opinions going, but isn’t all of tech like that? I feel like we’re one of the most opinionated industries. Unless accountants sit around conferences and argue about the best way to do someone’s taxes…
I wasn’t so much worried about someone else writing a better book than me, but that the authors I most respect — Nicole Forsgren and Gene Kim especially — would be disappointed in DevOps for Dummies. Mary Thengvall actually got me through this one when she gave me a pep talk. “You’re writing A book on DevOps, not THE book on DevOps”, she affirmed. That somehow took the pressure of nailing the topic for everyone. Instead, I focused on writing the book I would have liked to read on DevOps. And I think I stayed true to that.

Ivan: I’m reading a lot lately about successful people dealing at some point in their career with Imposter syndrome. What are your experiences and did it help you do better or throw you back?

Emily: I’m riddled with imposter syndrome, for the record. I’ve never made it through a week without doubting myself in some way. There’s a quote by William Hazlitt I love, “No really great man ever thought himself so.” I think that’s true. If you’re self-reflective, you’re often quick to go right to the things you’re not so great at and skip over all the things at which you excel.
It’s a constant struggle and I don’t have a shortcut for getting through it. My only suggestion is to invest in others. If you expect kindness, be kind. If you expect trust, earn it. If you expect forgiveness, give grace.
I’ve built a network of incredible humans who genuinely care about me (and for whom I would bend over backward). I’d truly be lost without the advice and patience of my friends. The amount of pep talks I needed to get through this book broke records. Surround yourself with people who give a shit about you beyond your accomplishments. We all stumble. Who sits with you when you’ve failed? Those are your friends.

Ivan: According to DORA State of DevOps 2018, 48% of companies are classified as high performing as a result of DevOps culture (roughly the same number in 2019). This is good news, but in a way it’s also terrifying: if I feel that my organization has space for improvement, does that mean that at least 48% of other organizations are already better performing than mine? Am I too late? What are your experiences with enterprise organizations? How serious is average enterprise organization about introducing DevOps culture and how far has it come?

Emily: No, no one is too late to DevOps or beyond help. One of the reasons I wrote DevOps for Dummies is because I think a lot of thought leaders live so close to the bleeding edge that they forget a massive proportion of companies who can’t leap to adopt every new idea or tool. I designed the book to be approachable and helpful, no matter where companies are on their DevOps journey.
It’s true that more organizations have been classified as high-performing in the latest DORA report. I think this is great news! It showcases that the principles and practices of DevOps actually do make a difference in a team’s ability to deliver better software, faster. It also means that more engineers are already trained in the foundational knowledge that will take your business to the next level. So get to poaching!

Ivan: Every organization has its own way of introducing DevOps culture. But looking specifically at enterprise level organizations, are there any patterns that you see about first steps those organizations take and low-hanging fruits they typically focus on?

Emily: I think enterprises have the hardest path to DevOps adoption. There is so much that slows an enterprise down. I think one of the first pitfalls is trying to change too quickly. My suggestion is always to focus on the people part first. Executive buy-in is important. Often, the institutional culture has communication practices that discourage autonomy and experimentation. Without that explicit permission, it’s going to be a slow climb. But if executives communicate that they recognize the expertise of engineering teams and allow them to make small changes as appropriate for their particular focus, they’ll have established the foundation necessary to continue that journey.

Ivan: Your approach to DevOps is very people-oriented which is a bit unusual for an engineer. How come you’re not obsessed with shiny new tools? (I’m having doubts that you’re a real engineer.. 🙂
BTW. I like how you point out in the book that we “humans have reached a point in our evolution at which technology is evolving faster than our brains”. This observation supports well your people-first approach.

Emily: I strongly believe humans have reached a point where our tools are evolving faster than our brains. And ultimately the greatest challenges in tech aren’t technical; they’re human. I think the reason I’m doggedly people-focused is because I’m not native to tech. I had a decade-long career in the humanities and have an undergraduate degree focused on centuries of complex geopolitics.
I’m intimately familiar with countless examples of humans repeating the same patterns and facing the same consequences. When I joined tech, I saw a relatively immature industry filled with geniuses, some of whom are more comfortable communicating with machines than humans. And that’s not a bad thing. We ALL come to the table with strengths and weaknesses. My greatest hope is inspire engineers to embody kindness and respect in their work. Those two values are the cultural glue that enable engineers to trust each other and those in other areas of the business. When you extend that culture to how you think about and treat your customers, well, you’re golden.

Ivan: More and more, people are starting to perceive Microsoft as ubercool company with progressive products and healthy corporate culture. How much has internal awareness and implementation of DevOps principles contributed to this external perception of Microsoft? Do we need to “blame” you for this transformation? 🙂

Emily: Microsoft’s culture is moving in a positive direction. The company avoided adapting to the changing (and OSS loving) market until that stasis threatened its survival. Like any organization, Microsoft has a lot of room for growth. It’s a massive organization with decades of institutional memory and that takes a lot of time to unwind. That said, I think they’re moving in the right direction and targeted hires (including some advocates) helped with that.

Ivan: Among other things, you are Developer Advocate and working in Developer relations. You and Nicole Forsgren had a great talk on O’Reilly Velocity Conference explaining what DevRel really means. DevRel comes natural in product oriented companies, but not all companies are like that. How does DevRel look like in a professional services company that has no specific off-the-shelf products but offers consulting and implementation services? What are your experiences? Are DevRel efforts in such cases focused more on internal developers?

Emily: Developer relations fascinates me. As soon as I heard about it as a career option, I was ecstatic. It allows me to blend my writing with tech and I’m forever grateful for it. I’m curious how it evolves over the next decade. I do not believe that the current role is sustainable. I think too many people view advocacy as an excuse to get famous (nerd famous as my friend likes to say) or fly around the world on someone else’s dime. Despite the spotlight, advocacy is not self-focused. It’s community oriented. And it requires someone with deep empathy for the daily struggles of engineers. Yes, I get up on stage. And yes, I have a lot of twitter followers. Does that make me anyway more valuable or worthy than someone who commits code everyday? NOPE. It does not. I should be a reflection of the community to my company, and an educator of my company’s products to my communities. I’m honestly afraid we’re building a cult of celebrity in tech and I think it’s dangerous to worship anyone.
I think advocacy is one of the best ways to get an incredibly broad view of a company. You gain exposure to engineering, marketing, sales, product, executive decisions, and on and on. Some advocates are deeply technical and will likely return to engineering positions. Others will move into product management or product marketing. Some will thrive in management.
But at some point we’re going to need to discuss just how many conferences there are (and if that’s the best way to serve the community), the sheer cost and environmental responsibility of flying around the world, and the sustainability of such a demanding and varied role. Maybe that’s my next book…

Ivan: If you had to roll the dice and bet on technology concept that will fill Twitter feeds during next year or two, what would that be?

Emily: I think it’s well known that I have a love-hate relationship with Twitter. I think we have more connection than ever before and yet little to no community. If I had to guess which technical topic people will be raging about over the next two years, it’ll be some combination of serverless, AI/ML, and real-world implementations of blockchain. I’ve teased blockchain, but I do think there are interesting applications, it’s just a question of abstracting something that basically requires a PhD in mathematics to something approachable by everyone. (I do kinda hope we also see some conversation around moving from microservices to monolithic architecture. That would make me chuckle.)

Ivan: Can you share with us what are you reading these days and who are the people you follow that make you think differently and do better?

Emily: I don’t read nearly as much as I should. (It’s actually one of my least favorite things about me.) But I’m obsessed with Never Split the Difference by Chris Voss. I love anything by Robert Greene. People who love history as much as I do will as well. I more or less worship Brené Brown and her work on shame and vulnerability. I’m about to start reading The Chimp Paradox by Steve Peters and Leaders Eat Last by Simon Sinek.

###

If you’re interested in receiving interviews with
thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox,
subscribe to our 0800-DEVOPS newsletter!

You will receive in your inbox interviews with thought leaders and a digest of
interesting ideas from the world of DevOps, technical practices and increased productivity!
We will never spam you, just share things we discuss internally in our CROZ DevOps Community of Practice. Join us!