Jan 2, 2019 · 44m · a16z
a16z Podcast | Feedback Loops -- Company Culture, Change, and DevOps
0:00 / 0:00
▶ Watch on YouTube →
gold bands on the timeline = statements, start to end. Hover to read, click to jump. CC turns on captions
In this episode of the a16z podcast, host Sonal Chokshi interviews 'Accelerate' co-authors Dr. Nicole Forsgren and Jez Humble to discuss how empirical research, DevOps principles, decoupled architectures, and generative cultures drive high tech performance and sustainable business value.
How this conversation actually went
Every chapter scored 0–10 on four independent dynamics. Hover any point for the reasoning behind the score. The host holds 29% of the talking time here. How this is scored →
The host as informed peer 5.4 Guest teaching 3.6 Guest disagreement 2.1 The host pushing back 2.8
speaking balance: gold is the host, purple is the guest (3 minute bins)
Sharpest disagreement ▶ 6:05 Rejection of the software blueprint metaphor
Jez Humble bluntly rejects Sonal's quote from Leslie Lamport, stating 'I hate that metaphor' and immediately dismantling the comparison between software engineering and physical construction.
Hardest push from the host ▶ 32:22 Defending executive metrics against capability model rhetoricSonal explicitly refuses Nicole's dismissal of maturity frameworks, pushing back to argue that non-technical executives require clear benchmarks to evaluate organizational progress.
Biggest teaching moment ▶ 6:05 Gaudi's Sagrada Familia architectural lessonJez reframes Sonal's house-building metaphor by explaining how Antoni Gaudi built upside-down string models to prototype hyperbolic curves, demonstrating that novel designs require empirical testing rather than rigid blueprints.
The host holds their own ▶ 28:19 Applying Coase's theory of the firm to continuous deliverySonal connects architectural decoupling directly to Ronald Coase's 1937 paper on transaction costs, prompting Jez to admire how she reduced his entire body of work to a single economic principle.
the scores for every segment, with the reasoning behind each
| Chapter | Topic | The host as informed peer | Guest teaching | Guest disagreement | The host pushing back | Why |
|---|---|---|---|---|---|---|
| Origins of DevOps and Evolution Beyond Agile | 3 | 4 | 1 | 2 | Sonal sets up the conversation by asking basic taxonomical and historical questions about DevOps. Dr. Nicole Forsgren and Jez Humble detail the origins from Agile and explain the industry joke about Day 1 vs Day 2. | |
| Debunking Software Metaphors and Managing Technical Debt | 5 | 6 | 6 | 5 | Sonal brings up Leslie Lamport's blueprint metaphor comparing software to house building, which Jez Humble forcefully rejects. Sonal then pushes back by asking if DevOps advocates are creating a developer-centric cult while ignoring technical debt. | |
| Dispelling the Speed vs. Stability Trade-off | 6 | 3 | 2 | 3 | Jez and Nicole explain how high-performing software teams avoid trading speed for stability, using Toyota's lean manufacturing as an analogy. Sonal highlights her fondness for hardware analogies and probes the validity of survey-based methodology. | |
| Measuring Delivery Performance: Speed and Stability Metrics | 4 | 4 | 1 | 1 | The guests outline the core delivery metrics (lead time, release frequency, MTTR, change fail rate). Sonal engages by drawing parallels to manufacturing throughput concepts. | |
| IT Matters: Technology as a Competitive Differentiator | 6 | 5 | 3 | 4 | When Nicole states delivery performance drives business outcomes, Sonal provocatively calls the finding obvious. Nicole counters with historic HBR research arguing IT does not matter, while Sonal notes her personal experience editing author James Besson. | |
| Organizational Profiles and Mindset for Transformation | 5 | 3 | 1 | 2 | Sonal asks if there is an ideal organizational profile for DevOps adoption. The guests explain organizational mindsets, and Sonal synthesizes their point using a metaphor of a 35-year-old checking health markers. | |
| Flaws of Traditional Productivity Metrics in Software | 5 | 4 | 2 | 2 | Jez delivers a passionate critique of traditional software metrics like lines of code and story point velocity. Sonal contributes by noting how lines of code incentivize bloated software like Charles Dickens novels. | |
| Maximizing Outcomes and Rapid Feedback Loops | 6 | 2 | 1 | 2 | Nicole and Jez explain focusing on outcomes over outputs and building tight feedback loops. Sonal reinforces this point by quoting Jeff Bezos on defining true innovation. | |
| Architectural Decoupling, Conway's Law, and Legacy Systems | 8 | 2 | 2 | 3 | Sonal demonstrates strong knowledge by linking microservices and DevOps to Ronald Coase's 1937 economic theory on transaction costs. Jez humorously concedes that Sonal summarized his entire body of work in one sentence. | |
| Capability Models vs. Flawed Maturity Models | 5 | 5 | 4 | 6 | Nicole dismisses organizational maturity models as flawed and arbitrary. Sonal directly pushes back, arguing that non-technical executives need concrete maturity frameworks to evaluate progress. | |
| Modern Tooling, Small Batches, and Machine Learning Feedback | 6 | 3 | 1 | 2 | Jez reasserts core engineering principles over temporary tooling crazes. Sonal directs the conversation to machine learning, asking how probabilistic systems alter feedback loops. | |
| Westrom Organizational Culture Typology and Psychological Safety | 6 | 2 | 1 | 1 | Jez details Ron Westrom's typology of organizational cultures and Google's psychological safety research. Sonal humorously jokes about applying the typology to dating before neatly summarizing the generative model. |
Statements from this episode (27)
Jez Humble: DevOps emerged to solve scale challenges pioneered by Amazon and Google
“And I think from a historical point of view, the best way to think about DevOps, it's a bunch of people who had to solve this problem of how do we build large distributed systems that were secure and scalable and be able to change them really rapidly and evolv…”
Humble: Agile hits a brick wall in large, complex organizations
“If you're working in a large, complex organization, Agile's going to hit a brick wall, because unlike the things we were building in the sixties, product development means that things are changing and evolving all the time.”
Forsgren: Agile methodology does not scale without IT operations support
“Agile doesn't scale, and sometimes I'll say this and people shoot laser beams out of their eyes, but when we think about it, Agile was meant for development. Just like Jez said, it speeds up development, but then you have to hand it over and especially infrast…”
Forsgren: The DevOps movement was originally named Agile System Administration
“So DevOps was sort of born out of this movement, and it was originally called Agile System Administration.”
Humble: Phased software development fails when user needs are unpredictable
“When we're building products and services where particularly We don't know what customers actually want and what users actually want. It doesn't make sense to do that, because you'll build something that no one wants. You can't predict.”
Forsgren: Only one-third of well-designed Microsoft features deliver customer value
“Even companies like Microsoft, where they are very good at understanding what their customer base looks like. They have a very mature product line. Ronnie Kahavi has done studies there, and only about one third of the well-designed features deliver value.”
Humble: High-performing tech teams do not trade speed for stability
“High-performing companies don't make those trade-offs. They're not going fast and breaking things. They're going fast and making more stable, more high-quality And this is one of the key results in the book, in our research, is this fact that high performers d…”
Humble: Toyota won by making higher quality cars faster
“Okay, so I've got, so Toyota didn't win by making shitty cars faster. They won by making higher quality cars faster and having shorter time to market.”
Humble: Software Teams Should Focus on Recovery Rather Than Preventing Failure
“We accept that failure is inevitable because we're building complex systems. So, not how do we prevent failure, but when failure inevitably occurs, how quickly can we detect and fix it?”
Forsgren: Fast, stable software delivery drives commercial profitability and market share
“Developing and delivering software with speed and stability drives things like profitability, productivity, market share.”
Humble: Amazon wins because competitors cannot copy its continuous production experiments
“They're running hundreds of experiments in production at any one time to improve the product, and that's not something that anyone else can copy. That's why Amazon keeps winning.”
Forsgren: High and low DevOps performance occurs across all company sizes
“I see high performers among Large companies. I see high performers in small companies. I see low performers in small companies. I see low performers in highly regulated companies. I see low performers in not regulated companies.”
Humble: US tech firms should fear competitive threat from Tencent and Alibaba
“I think U.S. Companies should be scared because the moment Tencent and Alibaba are already moving into other developing markets and they're going to be incredibly competitive because it's just built into their DNA.”
Humble: Lines of code cannot measure developer productivity
“But lines of code have all these drawbacks. We can't use them as a measure of productivity.”
Humble: Never use Agile story points as a productivity measure
“You should never use story points as a productivity measure.”
Humble: Measure software performance by lead time, frequency, MTTR, and fail rate
“So this is why we like two things in particular. One thing, that it's a global measure, and secondly, that it's not just one thing, it mixes two things together, which might normally be intention. And so this is why we went for Our measure of performance. So m…”
Humble: Mission-Driven Companies Outperform Those Focused Solely on Profit
“In fact, as we know from research, companies that don't have a mission other than making money do less well than the ones that do.”
Humble: High Software Performers Outperform Low Performers by 2x
“But I think, again, what the data shows is that Companies that do well on the performance measures we talked about outperform their low performing peers by a factor of two.”
Humble: DevOps Is the Technological Basis for Lean Startup Methodology
“So to sum up, the way you can frame this is DevOps is that technological capability that underpins your ability to practice lean startup and all these very rapid iterative processes.”
Humble: Team autonomy without dependencies is a top predictor of IT performance
“That is one of the biggest predictors in our cohort of IT performance is the ability of teams to get stuff done on their own without dependencies on other teams, whether that's testing, or whether it's deploying, or whether it's planning.”
Humble: Microservices and Kubernetes do not guarantee high IT performance
“Implementing those technologies does not give you those outcomes we talked about. We actually looked at people doing mainframe stuff. You can achieve these results with mainframes. Equally, you can use the, you know, Kubernetes and, you know, Docker and micros…”
Forsgren: Maturity models are an inappropriate framework for tech transformation
“Maturity models, they're really popular in industry right now, but I really can't stress enough that they're not really an appropriate way to think about a technology transformation.”
Humble: Software engineering first principles do not change every few years
“And the first principles, I mean, they will change over the course of centuries. I mean, we've got modern management versus kind of scientific management, but they don't change over the course of like a couple of years. The principles are still the same. Techn…”
Humble: Reasoning about cause and effect requires working in small batches
“So the same thing is true of organizational change in process and product development as well, by the way, which is working in small batches so that you can actually reason about cause and effects. You know, I changed this thing. It had this effect. Again, tha…”
Humble: Research proves culture predictively drives tech and business performance
“And in fact, we measure it in our work, and we can show that culture has a predictive effect on organizational outcomes and on technology capabilities.”
Humble: Psychological safety during failures is required for innovation
“If people don't feel that when things go wrong, they're going to be supported, they're not going to take risks. And then you're not going to get any novelty because novelty by definition involves taking risks.”
Forsgren: Five leadership traits predict successful technology transformations
“We find that there are five characteristics that end up being predictive of driving change and really Amplifying all of the other capabilities that we found, and these five characteristics are vision, intellectual stimulation, inspirational communication, supp…”