This book comes from two of my greatest failures, one personal and the other professional.

The first came in fall of 2013, as I was being unceremoniously cut by a sporting apparel company after a disastrous stint as a project manager. It was a miserable trip out to my car, with rivulets of rain streaming off my jacket onto my soggy box of belongings. I felt like I’d been hit on the back of the head with a 2x4. What happened?

Just a year earlier, working at a great company in the same market just down the street, I had managed a team of developers and had enjoyed some great wins in adopting Agile. I had expected this assignment to be the next rung on the ladder and build on this success; after all, I had so much more to work with at this new company. I had a bigger team, which meant more firepower. And the team looked like the perfect group to build on; they were bright, experienced developers with very deep-level expertise in modern web development. My new manager understood Agile and backed my vision 100%. I felt confident, fully expecting a glorious victory; instead, ignominiously, I was having to start over.

The fact remained that though I had been successful with Agile at one company, the same recipe and approach had not gained any traction at another. I remember gripping the wheel in frustration as I drove home that evening, thinking; Dave, you missed your off-ramp.

The off-ramp I had missed wasn’t made of concrete. Looking back, I had missed opportunities to really drive a better vision for the team that would have been less risky, incorporated quality as a first-class citizen and built incrementally on success. I had engaged with the testing community and even – halfheartedly – tried to inject some quality initiatives within our team. But the two teams still remained very separate; QA was always lagging by a significant margin behind development, our manual testing took days to complete and leaked like a colander. We had missed several very embarrassing issues that required all-out efforts to mitigate, costing me points in rep that I now realized I couldn’t afford to lose. Our poor reliability and lengthening technical debt hurt team morale and was nakedly exposed to the end user community.

Worse, we were dropping stones into a pool with our releases. Operations was also siloed from development. We had no idea what features were working as expected and were often the last to know when key services went down. Our releases were joined at the hip with an older web site that was in even worse shape. We had the capability to roll out multiple times a day, but as we were chained to this old manually tested system, we were forced into a torpid multi-month release timetable. Our weekend releases became crucibles of forced overtime with bad catered food, terrible cat picture slideshows, and short tempers as we had to choose between forcing a humiliating rollback or trying to patch things together in place.

As personally painful as the experience had been for me, one experience stood out that started some wheels turning. I inherited on the team an IT/infrastructure liaison whose main assignment was to write Chef recipes so infrastructure could be rolled out alongside code releases. This was the first experience I had had with Chef and automated infrastructure – and it was a real eye-opener. I remember watching templated environments get rolled out with a single command and being absolutely floored by the repeatability and reliability of that one pocket of our release lifecycle.

This same infrastructure person pulled me aside once and told me – “Dave, sometimes you have to go slow to go fast.” In the mad chaos of day-to-day project management, I brushed that aside. Now, thinking back, I realized that I had missed something.

Years went by; I found a great job that was incredibly challenging technically, writing a shop floor application as part of a small three-man team supporting a manufacturing process of large-screen touch sensitive monitors. The days of big battalions and 20-person teams were behind me; here I worked as part of a very tight, close-knit group. Everyone contributed to design and implementation, and we proudly watched our little code baby grow in strength and capability.

But even on this tiny team, the same problems with coordinating releases remained. Most of our releases failed, as the big batches of code that we checked in every few days or so failed to integrate. As a result, several critical demonstrations to our customers abended, and we were forced to scramble to patch together a working fallback. In the end the project succeeded, but only with a lot of unnecessary friction and waste.

Then, I moved into Microsoft as a senior consultant and began working with customers throughout the western United States on their development challenges. However, I never forgot my earlier experiences and kept thinking about better ways of making software releases safer and more predictable. Increasingly, I could see that the problems I had faced trying to scale Agile in the real world was not an anomaly.

Then, in December of 2017, just as I was beginning to think about what this book would look like, my second great life failure happened. My new doctor required an in-person checkup, so I made a routine visit, had some blood drawn, and left. Two days later I got a call – I needed to come in, as soon as possible. My blood sugar level was through the roof, as was my bad cholesterol levels and blood pressure. In short, I had Type 2 diabetes and would need to change my diet, exercise, and be on medication, for the rest of my life.

I was hit with waves of guilt. Type 2 diabetes is a lifestyle disease; the hectic and stress-filled pace I had set in my life – and the food and drink I used as fuel in coping with it – had finally caught up with me.

This was a different and very personal crisis, but I felt the same reaction – what happened? I thought I was healthy; I had tons of energy, a great gig without too much stress, and a wonderful family life. But as my colleague Aaron Bjork has pointed out – “Just because you’re not sick, doesn’t mean you’re healthy.” I had ignored several critical warning signs with my health and now was saddled with a life limiting condition to manage – the physiological equivalent to a disabling car crash.

Looking back, I’m grateful for my failures most of all. I’ve learned so much from them. My professional failure as a project manager got me thinking about better ways of writing software and coordinating releases, which led directly to discovering DevOps and a brilliant and selfless community of professionals with a powerful mission. Failing at managing my health made me reset the pace of my life and the way I was using and abusing food and drink. I’m calmer now, more empathetic, less focused on “getting stuff done” – more concerned with safety and a sustainable pace.

Giving away the ending of our novel here – but our hero Ben ends the story with a talk about humility, patience, and trust. I’ve had a great opportunity to share time with some great leaders in our community; they were across the spectrum in terms of their personality types, their favorite choices with technology, and the resources at their command. But those three qualities kept appearing in our conversations, a common thread.

There is no single roadmap to success in DevOps. But, if you get only one thing from this book, remember this – if you make it about learning, and demonstrate humility, patience and trust in your personal behavior, you won’t be far off from success.

We live in a time of instant, or at least near-instant gratification with information at out fingertips within 200 milliseconds or less. After reading a book such as this one, or any book for that matter, the reader often assumes that the tightly woven narrative that is portrayed has always been such. It couldn’t be further from the truth. A book, as with a career, or anything worthwhile doing is the culmination of many months, and even years of concentrated effort, often by multiple parties. This book was such. Dave and I worked countless hours while managing relationships, families and our day jobs to follow a goal that we thought worthwhile of sacrificing the better part of a year to.

My career, just as with this book, was the product of daily effort multiplied by time. It didn’t appear overnight, there were no fireworks, nor did I even realize I had a career until years down the road.

As I suspect how many of the readers careers began did, mine began in the trenches of IT. Helpdesk Tier 1 to be exact. It was my first salaried position right out of college, and I couldn’t have been happier. “I made it!” I thought to myself. I couldn’t believe they were going to pay me $35,000 no matter how many hours I worked! Let’s just say it didn’t take long until I began to strive for more.

From helpdesk I began to teach myself programming and worked my way into more of a Junior Sysadmin-type role at the same company. After learning a couple of programming languages and seeing the power it had to transform my career, I was hooked. From there, I continued to work my way up to my first traditional Systems Administrator position. In my career path, and my limited understanding of the field, Senior Systems Administrator was the culmination and ceiling for my career path. After a couple of more years I’d landed at just that, a Senior Systems Administrator role. “This is it, I made it.” Once again, I thought. But the truth was it didn’t really feel any different from my first position working on the Helpdesk. Instead solving one-off problems with people and their desktops, I’d simply migrated to solving one-off problems with servers. My workflow was still entirely push-based. Work came to me, and typically at the worst time possible. I was a technical firefighter for all tense and purposes.

Enter my “there’s got to be a better way” moment. Sick and tired of legacy systems, legacy thinking, and legacy people I pulled up my stakes and set my sight on new career horizons. I spent months of looking for and researching my next career move.

Luckily, not too long into my research I stumbled my way into a DevOps role in Los Angeles. I’d barely heard of the term DevOps, what did it mean? Was it the beta-max of development methodologies, or was there some staying power to this new concept? I wasn’t sure, but I sure as hell wasn’t about to complain. The money was good enough that I figured I could make myself excited about it for the foreseeable future.

My second stroke of luck was being able to work under a brilliant DevOps engineer. The company was small, so it was just us two. I had landed basically what seemed a paid mentorship. A mentorship is something not easy to find anywhere these days, much less getting paid for it. I learned the ins and outs of configuration management tools, proactive monitoring suites, as well as deploying infrastructure as code. This was everything my career had been missing up to this point, a way for me to proactively design my way around future potential problems. Problems that all legacy systems were plagued by. Problems like, snow-flake systems, or rather systems that needed special hands on maintenance due to drifts in configuration practices across the environment. Other problems like only finding out systems were down only because customers called, or simply trying to keep up with all of the systems we owned seemed to be a thing of the past.

It seemed too good to be true; there had to be a catch. And there was a catch. It required a shift in mindset, specifically the mindset of an engineer or an architect to properly implement and build such systems. The cowboy coder and the typical grump legacy systems administrator mindset was 100% incompatible with this new methodology. I fell into those camps. I hacked my way through every cookbook, recipe, task, you name it. I did so with, not surprisingly, limited success.

I wish I could say I read a couple of books and BAM! I saw the DevOps light, and everything was happily ever after. That couldn’t have been further from the truth. It took me the better part of my DevOps career to shift my perspective. Only through diligently reading, educating myself, and working with greater engineers on a daily basis was I able to reshape the way I thought about IT, DevOps, and Software engineering as a whole.

My education and understanding of DevOps is now quite simple. Ask me a few years ago if you came to me looking for a definition of DevOps and what it is I do I would have told you to “google it.” Not because I’m a jerk, well maybe, but rather because the concept was so elusive to me. It means something different to each person you ask. So, I’ll give you my definition of DevOps.

Firstly, and foremost, DevOps is a mindset. It’s not some new-fangled tool made by some trendy software company of which everyone sports their t-shirt. It’s a way in which you approach a problem. The tools are, well just that, tools. Pick whichever ones suit you and your organization best. The mindset, however, is the real asset. DevOps, when applied correctly, will help you and your organization architecturally plan around problems before they happen. DevOps, its accompanying methodologies, and tools should help you architect infrastructure that is iterable, scalable, and version-able. No different than software development methodologies such as Agile. Agile for infrastructure if you will.

Secondly, DevOps should empower you and your organization to take on any project no matter how large through the process of breaking large tasks into smaller tasks, delegation, automation, and lastly by using the multiplier of time. Any successful company, no matter the sector, will tell you that this above all is how you build empires.

Thirdly, and perhaps the most important concept DevOps has to offer, is the idea of closing or integrating feedback loops within a tech department, or even across an organization. For far too long departments have been siloed, forced into throwing work over the fence to another, each operating in independence. Even within the tech department processes and technologies are siloed in a way that didn’t offer an easy way to see the whole picture. DevOps offers a way of integrating all the various systems and closing the feedback loop for rapid learning, iterating, and re-integration of knew knowledge to systems and processes. DevOps is an organic approach to systems design that has been missing in the tech landscape until now.

My hopes and wishes for the reader are that they understand that DevOps is not only a set of tools and practices, but rather a mindset. A mindset that informs each and every decision for their work and the direction of the organization as a whole. However, in reality, we are dealing with concepts larger than DevOps itself. On a more global scale, whether it be creating a family, growing a garden, or writing a book, each can be achieved by using the same fundamental principles. The principle that through small, incremental, yet measurable changes applied daily can create long and lasting change.

My other greatest wish for the reader is that this book, although loaded with information, quells their fears of mobilizes them to take action on what seems an Everest of tech debt. We all have stared down this mountain and wondered “How can I ever hope to achieve half of what is being asked of me?” Not enough resources, not enough time, lack of knowledge, etc. The excuses are endless. However, they are not unique to any one individual or organization. There is no DevOps “Never-Never Land” where everything works as it should, no practice ages, nor has any consequences upon its failure. Not even the “big guys” you hear about from your favorite Tech blogger operate in a sandbox. They each got to where they were by adopting a certain set of tools and practices, as well as a mindset that worked for them and their organization. They took these resources and simply started. Each and every day chipping away at the mountain. It’s the only way anyone could ever hope to achieve what is being asked of them and their department.

This same pain point exists today , and it’s killing us. We find motivated, bright people at every level of the organization and from all walks of life – IT, QA, development, InfoSec. These early adopters catch fire and love the concepts of DevOps from the first day; but as they only can change part of the organization, the underlying issues of end to end delivery remains unchanged. After returning from a great conference, or reading inspiring books like The Goal , Continuous Delivery , or The Phoenix Project , a common reaction seems to be – oddly – depression.

It’s what we like to call a “now what?” moment. Unlike the heroes in these stories, we aren’t blessed with a magical, all-wise advisor who can lead us in the right direction; we may also not have a small army of bright, capable direct reports that can follow our lead as we try to turn things around.

It’s almost cruel. We’re being shown a shiny, beautiful car – but we’re not allowed to take it for a spin. In conferences and in meetings with customers, we constantly hear from people that love the principles underlying DevOps, but then are slapped in the face with the ugly reality – my place just doesn’t work like that. I don’t have the kind of authority we’d need to pivot like this.

So, what to do?

In Portland, a few years ago, Dave was asked by a good friend to speak at a conference about this shiny new object called DevOps. The auditorium was full, and the audience was engaged and interested in the topic; the time flew by as we went back and forth about different ways of building out an effective, pragmatic roadmap. But one programmer toward the back put up a stumper, asking, “This is all terrific, but on my team I’m just one guy in a group of ten. And we’re all heads-down programmers. What can we do to play around with this?”

Dismissively, Dave said, “Well, that’s just it. If you don’t have executive buy in and a mandate to completely rework the company top to bottom – forget it! If you can’t change the company – and at your level you might not be able to – then change your company. Find your way to an outfit that lives and breathes this, and don’t settle for less.”

On the way home, Dave felt uneasy, like he’d failed a test. The answer seemed to pat, too glib – and it bothered him for weeks. Was that really the end of the story? Did the people in that audience – fellow application developers for the most part – go home discouraged, thinking, “Well, that was super interesting, but ultimately irrelevant. It’s not like I personally can benefit from this – it’s all strategery stuff for the bigwigs.”

Was the answer really wrong? Most of the successful transformations we’ve seen have been led by visionary leaders who set the pace and could drive change, top to bottom. And there’s no question that having a large amount of authority, resources, and a time-capped existential crisis helps tilt things in our favor when it comes to creating change in large enterprises.

So, for the rest of us – let’s say we don’t have those cards to play. Are we stuck? Is DevOps only possible from the top down? And does it only work for the handful of unicorns out there with the web in their DNA – flexible, nimble companies with rivers of money and oodles of innovative, creative people?

This book is our answer to those questions. Now we’re convinced – because we’ve seen it – that it is totally within our grasp to create change. Each of us has the ability to contribute toward a shift in thinking so that a true large-scale DevOps effort can be successful. And the payoff is immense. We’re not talking about productivity or efficiency here; we’re talking about leaving work with less fear and exhaustion, with more time for the ones we love, and a deep glow from a job well done. Who doesn’t want that?

Let’s say you’re part of a great team of very capable people – but the way you are working, the environment, is a limiting factor. Changing it seems like too big a task; overwhelming, like climbing a mountain. Where do I start? Am I going to get fired when something goes wrong with this? What about the other areas of the company I need but have zero control over?

We’re going to answer these questions by telling a story of a team that’s exactly where we suspect your team might be – one that’s not at a complete failure state, that actually has some wins under its belt with Agile, but has some significant obstacles in its path. We’ll walk along with this team as they begin their journey and, over the course of a year, emerge victorious in their struggle – despite some serious potholes and setbacks as the team finds their way onward and upward. The story ends – if you can forgive the spoiler – with the entire organization beginning to make some visible traction in the right direction. As Winston Churchill put it, “not the beginning of the end but rather the end of the beginning.”

We’re assuming you know what DevOps is and have read some of the concepts written about by the Mount Rushmore of thought leaders in that arena – which to us includes Gene Kim , Jez Humble , Martin Fowler , and Gary Gruver . We’re assuming you have some background in Agile and have even made some strides in applying those principles in your team; now, you are at a plateau stage and are thinking about ramp up your organization’s maturity level when it comes to end-to-end delivery.

One caution we feel we have to make right at the beginning. A common ask is for a specific roadmap, a one-size-fits-all recipe that can be followed, along with the “best-in-class” software that will guarantee a bulls-eye in “doing DevOps.” That’s not in this book; only a circus huckster – or a software vendor! – would try to sell a magic silver bullet. In the world of code, this is called “ cargo cult programming ” or “implementation thinking.” Mindlessly trying to cut and paste what Google does, or Amazon, is the one guaranteed way to fail miserably in your journey; culture can’t be grafted.

So, we’ll tell a story in this book, but please don’t misunderstand us and think that this is YOUR story. The destination the team is reaching for in this book is likely the same one you’re thinking of, but how you and your organization will get there will need to be very different from what the team does in this book. Despite what some consultants and software vendors try to pitch in their marketing, you cannot buy DevOps. A single battle-tested, foolproof recipe for success simply does not exist.

But that’s not saying that you won’t come away without learning something new. The main problem we hope to overcome is what we’ve called “Baskin Robbins’ syndrome,” where we’re paralyzed by an abundance of possibilities. There’s so much to do. And we’re so far behind. Where do I start? Stay too long in that state, and there’s a very strong and understandable tendency to lapse into apathy, or play it safe and conservative – putting together a large, strategic-level Big Plan stretching across multiple years.

In fact, both reactions are mistakes. Let’s say you feel like you’re on the outside looking in. Well, no worries, you’re not as far behind as you think. It may be true that most companies are attempting some form of DevOps on a trial basis, but how many are really doing it at scale and across the entire company? The number is likely lower than we think – perhaps much less than 10%. Even the “unicorns” we point to with envy had to start somewhere; most as recently as a decade ago were stuck with the same crumbling, error-prone infrastructure and leaky, nightmare-inducing releases that we might be struggling with.

And on the Big Plan, stretching across many years, well – a word of caution. Many executives in desperation or envy have chosen that type of a 90-degree pivot. Some have even kept their jobs! But uniformly – and this is even for the companies where it’s worked – we’re told that these huge campaigns are high risk, wasteful and very traumatic. Given a do-over, without exception, we’re told that they would have gone about things differently – more of a gradual leveling up, a slowly progressing experiment.

So, instead of trying to come up with the perfect plan, this book will show a team that applies Agile and Lean thinking in solving their own delivery issues. They will make some serious mistakes that will cost them – but they will be moving forward, and learning as they go. Imperfectly, they’ll begin with what hurts the most – make small investments that help that pain point – then refactor and keep moving up the mountain, one step at a time.

There’s a third mistake we’d love for you to avoid – and that’s apathy. We commonly think that we have less power than we actually do. But there’s a ripple effect from implementing the right behaviors that has immense power over time. Damon Edwards is fond of saying “you can’t change culture, but you can change behavior, and over time behavior becomes culture.” We live in an increasingly API-centric world – one where we consume services that have bindings, a known engagement protocol and predictable responses in its communications. Our teams – even if we only are responsible for a few people, or part of a small team – can be thought of as being an API-based service. We can change our behavior, and the way those bindings work – our requirements to consume our services – so that quality is built in early, and our services are easier to maintain and support. Fascinatingly, once our behaviors change, we often find our partners adjusting in their behavior as well, creating a snowball effect. Whoa. We have more power than we think!

This book is not a fairy tale. It’s based on real stories, from real people working everywhere from small consulting teams to software vendors and large-scale enterprises to pubsec agencies. Each of them has been able to change their organization, often without a strong mandate from top-level executives, starting first with refactoring the way they work as a team. None of their stories are complete, and there’s been some bruises along the way that they shared with us as a valuable lesson for others. We’re hoping, once you finish reading this, that you’ll feel both excited about the potential for DevOps with your company, empowered to make small, incremental changes to your team’s behavior and practices – and most of all, confident that your next steps with DevOps are well thought out and will be successful.

Now, let’s talk a little about bias. You’ll notice some of the authors of this book come from Microsoft . Most of us are fairly new, arriving after the Steve Ballmer era when the company began adopting Open Source aggressively. But there’s a residue of mistrust stemming back to the early 2000s that leaves most of the leading DevOps books and speakers to leave Microsoft out or mention them as an afterthought.

This attitude was well deserved back in the mid 2000s when Microsoft’s attitude toward Open Source and even release management could best be described as adversarial or primitive; it simply doesn’t hold true anymore. Most organizations out there now view their CI/CD solutions and tools as modular and expect Microsoft to compete on merit, not as an all-or-nothing “stack.” Every year, tools become more inclusive and can be integrated with minimal effort, at least on a CLI level if not natively as tasks in a release path. Viewing Microsoft as a DevOps backwater is not only dated, but this bias ignores the reality of mixed platforms in most organizations today.

Linux and Open Source tools have shown astonishing reliability and an ability to innovate and disrupt that has been very good for the IT community. They’re clearly here to stay, and the disruptive and powerful ideas embedded in that community have bled into every successful enterprise we admire today; Google, Amazon, Netflix, and yes – Microsoft. To survive, Microsoft was forced to look in the mirror and recognize that what used to work no longer held true. It needed to embrace Linux, Apple and Android mobile development, and the OS community and the decentralized way development is handled on these platforms.

We wish that more of the DevOps materials we see out there would adjust their point of view to reflect current reality and not that of the mid 2000s: DevOps is a concept that is not limited to a single company, software tool, programming language, or platform.

We’ve done our very best to counter any tendency toward bias based on our corporate allegiance and keep true to the open source and community-driven roots of DevOps. You’re not going to see us advocating any particular software tool for builds, source control, monitoring, or config management. In fact, most of the solutions we recommend in this book will cost you nothing; they aren’t software tools but improvements in process, helping you maximize your investments in tools you already own.

If this book saves you some work, prevents an embarrassing production failure, or improves your working life in some way, we feel like we have reached our goal – regardless of what flag your ship is flying!

Microsoft, Facebook, Amazon, Google, Netflix – all have succeeded in different ways of driving more business value with DevOps. As part of the research for this book, we reached out to all of these companies. The astonishing thing was the openness and direct, frank way thought leaders from these organizations spoke. Consistently, there was a great deal of pride in how their companies met the needs of customers and could innovate at scale.

The flavor of all these conversations was friendly and very open. Without exception, all seemed to have the same basic desire we have; a strong desire to share information and honest lessons learned, motivated by a spirit of community and helping others avoid the bumps and bruises they suffered in figuring out what worked best. We’re deeply grateful to be surrounded by such bright and giving people with such unselfish motives in the DevOps and Agile community.

There simply wasn’t enough room to print every book and article found in our research; for a more comprehensive list, please check out the “Achieving DevOps: The Back Story” post on Dave’s blog, driftboatdave.com: https://driftboatdave.com/2019/02/16/achieving-devops-the-back-story/

Go forth and conquer! We are in your corner, all the way.

At the end of this book, you’ll find a collection of case studies and interviews. One of the most surprising things we found during the course of writing this book was that most of the prescriptive “list” books out there are making a fundamental mistake. There are many possible roads to success, as the experts we met demonstrated. Getting insight into their experiences and perspectives drove home the point that there is no such thing as a “best practice”– only a better practice than yesterdays.

Here’s some highlights:

“I’m always looking for that right kind of leadership protection, a willingness to experiment, and a group that wants to learn and try something different. That’s your beachhead!”

“The saying we live by goes – ‘You can’t cheat shipping.’ If you deliver working software to your users at the end of every iteration, you’ll learn what it takes to do that and which pieces you’ll need to automate.”

“A lot of managers don’t realize what a fundamental difference it makes – how we react when there’s an outage or a failure. Sometimes you’d swear that the poor coder is a puppy and it’s everyone’s job to rub his nose in it when there’s a screwup.”

“It’s all too easy to get bogged down when it comes to automation. DevOps isn’t art, it’s just hard work. Focus that hard work on the things that really matter. Guard your time and that of the people around you.”

“The tool is not the problem, ever. It’s always culture and energy.”

“Often times CTO/CIO’s catch fire and announce that they’re going to reorganize with cross functional teams. Don’t do that! Think about your DevOps or SRE transition in the same way that you’d release software.”

“DevOps is an emergent characteristic. It’s not something you buy, not something you do. It’s something that emerges from a team when you are doing all the right things behind the scenes, and these practices all work together and support each other.”

“There was no magical fairy dust for us. It required progressive change, some very conscious hard engineering changes, and walking the walk.”

“We’ve tried tiger teams, where we pull in one rep from every department – for us that wasn’t a winner. Instead we try to focus on one very specific goal as an experiment.”

“We’re still way behind the times when it comes to having true empathy with our end users. It’s surprising how entrenched that mindset of monitoring being an afterthought or a bolt-on can be.”

“Defining how people should interact and how they optimize their work and collaborate, to me that’s the real potential offered with DevOps. It’s not tech. Tech is cool, glossy, beautiful, but what’s way more important is showing leaks in the process.”

“I refuse to get entangled in arguments about the pros and cons of various tools. This is really a closed problem: there is always a solution, you just need to find it.”

“People don’t want to do testing, it’s not glamorous. For us, there was no alternative but to roll up our sleeves and do it. It’s been the key factor in everything we’ve accomplished, the velocity we’ve been able to reach.”

“One of the biggest failure points I see is that people often don’t make their work visible enough. If you don’t know what people are working on across the team, that creates a natural siloization which reduces ability to collaborate.”

“The number one point that I want to bring out is waste. Executives get this instinctively. Here’s the waste, and if you eliminate this, look as the payoff – that gets you the buy in you needed.”

We also were blessed with an extraordinary group of interviewees and contributors. This included the following:

Anne Steiner from CPrime, Tyler Hardison from Redhawk Network Security, Michael Stahnke and Nigel Kersten from Puppet, John Weers from Micron, Jon Cwiak from Humana, Sam Guckenheimer, Brian Blackman, Aaron Bjork, and Brian Blackman from Microsoft, JD Trask from Raygun, The IT Skeptic (Rob England) from faraway New Zealand, Michael Kwan from InTimeTec, and Ryan Comingdeer from Five Talent Software, Betsy Beyer, Stephen Thorne and Seth Vargo from Google, and Sam Eaton from Yelp.