“Everyone needs to sign this off.” “Nobody uses that feature.” “All the teams are blocked.” I hear sentences like these every week, and I say them too. They sound like facts. They are almost never facts. In Technology Strategy Patterns, Eben Hewitt makes a case that surprised me: the most important skill in strategy work might be knowing what you’re talking about, in the literal sense. The Domain of Discourse Hewitt borrows an idea from predicate logic called the domain of discourse. It’s the set of things a statement is about. “Everything is in New York City” sounds absurd, but if your domain contains only the Empire State Building, the statement is true. ...

I finished Software Engineering at Google this week. Eighty-eight sections in, the part that stayed with me wasn’t the chapter on build systems or the one on testing. It was the afterword, five pages from the end, where Asim Husain writes one sentence that I have not been able to get out of my head. “The passage of time and the importance of change cannot be ignored.” That’s the whole book, compressed. Everything else in it is a mechanism. That line is the reason the mechanisms exist. ...

The first question on every incident bridge is always the same. What changed? It’s the right question. It just isn’t the answer, and the gap between those two things has cost me more hours than I care to count. I’ve been working through the argument pattern in Eben Hewitt’s Technology Strategy Patterns, and the part that stuck isn’t the section on decks or rhetoric. It’s a small Latin phrase he uses to describe the reasoning we all fall into at 2am. ...

I have been spending a lot of my working hours lately on compliance automation, vulnerability backlogs, and the dashboards that try to hold all of it together. Somewhere in the middle of that, reading Eben Hewitt’s Technology Strategy Patterns, I hit a line that made me stop and audit my own work. Many shops are just collections of tools. That stung, because it was almost true of mine. I had a scanner here, a dashboard there, a repo of policies, a pipeline running nightly. Plenty of moving parts. What I was not sure I had was a reason for any of them to exist other than the fact that each one solved the problem sitting in front of me at the time. ...

A rule Winters describes in the Software Engineering at Google material keeps coming back to me: developers must never have a choice about which version of a component they depend on. On its face it sounds restrictive. Remove choice from engineers and you are removing agency, right? But the more I run systems, the more I think he is pointing at something deeper. Removing the choice is not a restriction. It is the thing that lets the organization scale. ...

The analysis the business already did in their heads I have spent a lot of time lately inside compliance automation and infrastructure work, where the pressure is less about flashy features and more about supplier power, substitution risk, and industry rivalry. Reading Eben Hewitt’s Technology Strategy Patterns, the chapter on industry context landed harder than I expected, because it frames something I keep missing. Every businessperson knows Porter’s Five Forces. But most of them hold it in their heads like a mental model they update as they skim headlines, never written down. Hewitt makes the point that this is exactly the job the technologist is missing out on. The folks who do this analysis informally have not seen the business through the lens of technology. That is the gap we get to fill. ...

I keep coming back to a line from Software Engineering at Google that sounds wrong until you sit with it: faster is safer. The health of a product and the speed of development are not in opposition. Products that release more often, in small batches, have better quality outcomes. They adapt faster to bugs found in the wild and to unexpected market shifts. That runs against instinct. Most of us assume that moving fast means cutting corners, and that safety comes from slowing down and being careful. Google’s experience says the opposite. The risk lives in the size of the change and the time between releases, not in the frequency of them. ...

Reading through the Large-Scale Changes chapter in Software Engineering at Google, one line kept pulling me back: the analogy of pets versus cattle. A handcrafted change is a pet. You spend days on it, you know it intimately, and you feel a small sting when a reviewer rejects it. A change churned out by automation is cattle. It’s nameless, it’s faceless, and losing a few of them on any given day costs nothing, as long as the herd moves forward. ...

I have been deep in compliance work this week, and it got me thinking about a chapter from Eben Hewitt’s Technology Strategy Patterns. The chapter covers three things that look boring on paper but quietly determine whether your strategy lands: the RACI, the company life cycle, and the value chain. The RACI is the one I keep coming back to, because it is the cheapest way to kill confusion on any project. ...