DevOps Patterns for Private Equity: Technology organization strategies for high performing software investments

By Dave Mangot

As many of the top Private Equity investors know, software companies can be a great investment. Whether as a platform with add-ons, or as a profitable company that needs help to "nail it and scale it", there are many opportunities for great returns. But that doesn't make it easy. With compressed time schedules, closely watched bud

• Language: English
• Publisher: Mangoteque
• Release date: Sep 12, 2023
• ISBN: 9798988840114

Dave Mangot

Dave Mangot helps private equity portfolio companies get good at delivering software. He is a leading consultant, author, and speaker as the founder and CEO at Mangoteque. A DevOps veteran, Dave has successfully led digital, SRE, and DevOps transformations at companies such as Salesforce, SolarWinds, and Cable & Wireless. He has a proven track record of working with companies to quickly mature their existing culture to improve the speed, frequency, and resilience of their software service delivery.

Book preview

Preface

Make the hard things easy, so you can work on harder things.

I was leading the DevOps transformation at Salesforce (and writing this book has shown me how formative that was) at about the time that the first real DevOps book, The Phoenix Project, was released. One of the authors, Gene Kim, used to give talks at conferences to recruit people to the cause. I’d heard his speech a number of times, but one of the most special times to me was when, as a result of the work I’d done, he gave that talk to the entire Technology & Product organization at Salesforce.

At the end of his presentation, Gene would always talk about being on a mission to improve the lives of thousands of IT professionals around the world. His words have always stuck with me.

My career has spanned more than a dozen companies, and I’ve always tried to improve things for both the company and my co-workers. When the DevOps movement began in earnest, I was drawn to its emphasis on both technical excellence and humanism. When I decided to go into business for myself, I discovered that, instead of just being able to improve the lives of people at the company where I worked, I now had the opportunity to help folks enjoy work more, make more meaningful contributions to the business, and do some of the best work of their lives, all the while having less stress, more time with their families and friends, and greater satisfaction.

By emphasizing both technical excellence and empowering humans as the creative, smart, and wonderful people that they are, I’m able to improve the lives of thousands of IT professionals too! When engineers are happier at work, they produce better business outcomes like customer satisfaction. When they produce better business outcomes, leadership is able to deliver on their promises. When leadership is able to deliver on their promises, investors are happier. It’s one of those unique situations where the outcomes are win–win–win.

Which leads to the purpose of this book — to help you create systems in portfolio companies that lead to win–win–win situations.

This is not a how-to technology book. This is a book that ties technology organization choices to business objectives. One of the things I have always appreciated, that is core to the DevOps movement, is the fact that it has always emphasized tying engineering outcomes to business outcomes. The first way of DevOps from The Phoenix Project, which emphasizes systems thinking, starts with the business and ends with the customer. There is a deep recognition that, while many of us enjoy nerding out on the engineering aspects, there are very real business drivers at stake.

One of my favorite DevOps stories is from 2008, when a network administrator for the city of San Francisco was actually jailed for refusing to provide the administrative passwords for his network gear.¹ He hadn’t wanted anyone to ruin his beautiful, perfect creation. However, engineers are not paid by their organizations to make beautiful creations. He didn’t understand that the technology organization exists to solve real customer’s problems and to help their business succeed.

It’s my hope that this book will help you to shine a light on the connection between engineering perspectives and business outcomes. By the time you finish, you should have an understanding of how to better recognize the different engineering situations you see, whether during due diligence, during a board meeting, after purchase or acquisition, or just when facing an especially unfamiliar situation. After recognition, you should understand how that particular situation fits into the overall goal of getting good at delivering software, which makes businesses twice as likely to meet or exceed their organizational performance goals.²

The things that I’ve written about in this book are what I see when I work with companies, regardless of their level of maturity. The things we examine are from the perspective with which I look at them. They are the things that are holding the organization back from achieving its objectives. I hope that in the pages ahead you’ll learn to see these patterns for yourself and be able to understand what’s required to change the system.

Why Patterns?

I’ve held a belief for many years that wisdom is just pattern recognition writ large. When we’re younger, we’ve seen something maybe a few times. It’s not as easy to recognize any one thing as something we’ve seen before. There may be subtle differences or the context may be different.

One thing humans are naturally good at is pattern recognition. When you’ve seen something only a few times, it might be hard to recognize. When you’ve seen that thing dozens, hundreds, or thousands of times, it becomes much easier to recognize. I believe that as we get older and collect more life experience, we don’t know more than someone who may have learned something in school or in a book, but we get better at recognizing things that we’ve seen before, what the expected outcomes will be, and how much control we have over a situation.

In this book we’ll discuss patterns that I’ve seen often in portfolio companies. Organizations saying they’re agile because a few engineers went to Scrum Master training, that prioritize work by what’s in front of their noses, that are afraid to change their infrastructure because they might lose customer data. But just as we talk about patterns and anti-patterns in engineering, there are patterns that can help us escape from the obstacles that hold us back. These DevOps patterns help us to break through these impediments and move up to the next level. These patterns are the solutions.

Why Private Equity?

One of the things I like most about the private equity folks is that they’re what I would call serious. They have an investment thesis, clear objectives, and time constraints in which to achieve their milestones. The types of firms that I enjoy working with are driven, analytical, not afraid to make change (even big change), not afraid of the cutting edge, and they make decisions in the service of their objectives. They invest heavily at the start of the holding period and improve the operation of the business in areas like finance, business development, and technology, which helps the company to grow over the next few years. Then they exit at a higher level than when acquired. Some portcos are reacquired after a number of years by the same firm because they’re ready to move to a higher level once again.

An investor once told me that I get a call when a company’s growth has outpaced its maturity. Applying DevOps principles allows these companies to match their maturity to their growth. I constantly encourage the engineering teams I work with to make the hard things easy so they can work on harder things. By doing so, they start moving from slow ticketing systems and halting delivery to work that enables growth and flow. They take the step up to the next level. Achieving operational excellence in the technology organization (just like in sales or finance) is a great match for DevOps, which teaches how to achieve high-performing teams.

Ask any of my close friends what motivates me to do something. It’s not because it’s there, or because someone said I can’t do it, but because it’s hard. I love working on hard problems. When my kids were young they discovered that I go to work and solve puzzles all day long and they would ask me why. I think of it as one of life’s greatest joys.

Organization problems, technology problems, implementation problems. Those are the things that get me out of bed in the morning. Have you bought a few companies and combined them together and found that the developers say the operations folks are lazy and dumb, and the operations folks complain that the developers don’t understand what they’re asking for? Perfect, that’s my cup of tea. I love to work in organizations that are multiples of Dunbar’s number (the theoretical number of personal connections any one human can realistically maintain) in size, where communication is strained, and things are constantly delivered late. Thankfully, because of the profile of companies that private equity companies tend to buy, and what they do with them, portfolio companies have these kinds of problems in spades!

Like Barbarians at the Gate?

Are there bad private equity firms out there that treat people poorly and predominantly make investments that harm society and the planet? Sure. There are approximately 10,000 private equity firms in the United States alone. It’s simply not possible that every single one will be ethical. Stories abound in the press about this private equity firm that did awful things to healthcare, or that one that preys on the real estate market. I hope those companies fail, and I’m particularly choosy about my partnerships.

I choose to partner with firms that want to level up their portfolio companies to get better returns, not just look for the laziest way to make money. That work sounds boring anyway. I like hard problems.

Who Is This Book For?

This book is both a business book and a technology book. Therefore, it’s best suited for people who work at the intersection of business and technology. They can be:

Operating partners with backgrounds in software engineering

Operating advisors like former CTOs

Portfolio company CTOs

It’s also helpful to have read The Phoenix Project.

Does this mean the book won’t be useful for others? Of course not. The goal of the book is to demonstrate the connection between technology organization choices and business outcomes. However, the folks listed above are well incentivized to make that connection happen.

Who Am I?

Like a lot of people I’ve worked with, I became fascinated at a young age with what computers could do. I was getting paid to write code by the time I got to college. I graduated with a degree in Cognitive Science, which is basically computer science and cognitive neuropsychology mixed together (I was studying machine learning decades ago). I try to bring elements of my psychology background to my work.³

I moved to the Bay Area during the first dotcom boom and had no idea such a thing was happening. When employers found out that I was pretty good with computers, jobs weren’t hard to come by. Over the years I bounced around to different jobs until I led a globally distributed team running the content delivery network (CDN) for Cable & Wireless. Big scale and tons of hard problems, transforming the way a complex system was managed. I was hooked. I took some other jobs, but by 2009 I knew that production web operations was what I wanted to spend my time doing.

Along the way I’d picked up a lot of skills with security, coding, management, and infrastructure, and I became an architect in Infrastructure Engineering at Salesforce right about the time that the DevOps movement was taking off in earnest. I became heavily involved in that community while still designing and implementing a lot of the foundations of what runs Salesforce today.

In some respects, I feel lucky that I went to an enterprise software company like Salesforce instead of a Facebook or a Google. My clients are run like enterprise software companies! It’s very familiar, just at a smaller scale.

In my last operational role I ran the global Site Reliability Engineering (SRE) organization for the SolarWinds cloud companies. This is where I got my first experience working with private equity.

I’ve never been afraid to break new ground, and I can move fluidly between different groups like development, operations, and executives. When I began consulting I realized that I didn’t enjoy working with startups, which don’t understand my message, or very large enterprises. My message resonates well with middle market companies that have hard problems and are interested in building a solid business through sustainable growth.

My job is not to solve my clients’ problems. My job is to help my customers solve their own problems. I can’t know as much about their business as they do, but I know how to get them to approach the problem in the right way. If you’re interested in the approach, and not simple solutions, then this book will be good for you.

There are so many people to thank who have helped to get me to where I am today. If you and I have crossed paths during my career, you have almost certainly taught me something that I should thank you for. I’d particularly like to thank Nii Ahene, Bruno Connelly, my clients who have taught me so much, Joel Dolisy, Vadim Friedberg, Joe Kim, Gene Kim, John Willis and the early DevOps leaders, James Leppek, Andy Meaden, Jim Pennypacker, Steve Pereira, Barzel Segal, John Stauffer, Paul Zuber and the crew at Thoma Bravo, the Learning From Incidents (LFI) community, the Flow Collective, Chad Upton, my coach Rochelle Moulton, my technical sparring partner and all around amazing person Peter C. Norton, my incredible family, Peggy, Micah, Alex, and Lidya, who’ve heard me comment endlessly on this book, and anyone else I may have unwittingly forgotten.

I hope this book enables you to see things