Arrested DevOps

No Topic, On Purpose

Matty and Marino Wijay went into this one without a plan, and the plan that emerged was the honest one: what the hell is actually going on in tech right now. Both have been around long enough to remember big shifts before (DevOps itself, the rise of Kubernetes and cloud native) but neither can remember change compounding this fast. Marino traces it to a specific hinge point: a predictable decade of innovation through the 2010s, then 2021 hits, zero interest rate money floods in, "you were limitless at that point," and a wave of startups and advocates get built on cheap capital. When rates rise, those ideas fizzle, the people promoting them lose their jobs, and the industry lurches toward the next hot thing. "Something called Loops was a huge thing two weeks ago, and now no one talks about it."

Three Layers Become Two

Marino draws on his data center days, back when a SAN install or rack expansion needed three distinct layers of expertise: contractors doing the physical racking and cabling, a team doing the finer cabling and bring-up, and a business layer figuring out what the infrastructure was actually for. "Those three layers, interestingly enough, have collapsed into two layers now." Physical labor gets automated away like it did in manufacturing, and what's left is a single human-plus-AI layer making the calls. The specialties that used to sit between those layers, especially networking, don't disappear so much as go invisible: "No one really talks about networking as much anymore, despite the fact that every single one of these models is running on hardware that's running on high-performance computing networking." The unsexy, boring infrastructure work is where the real money quietly lives now.

Every App Is the Same Paint Swatch

That collapse pushes everyone toward the same shortcut: "I need to just build, build, build with AI," and the result is that every AI-built product looks identical. Marino's line for it: open enough of these sites and "I'm looking at the same set of swatches," because the models are all referencing the same patterns. It's a preference problem as much as a technology one. Everyone wants the instant gratification of shipping a result, and nobody wants to be the one still doing the boring, careful thing while a competitor ships fast, so the shortcut becomes the default.

Tech as the World's Longest-Running Accounting Hack

Marino's most unfiltered riff of the episode: a lot of what looks like innovation is actually VCs hedging bets across five companies solving the same non-problem, and a tax and accounting structure that rewards hiring tech people and building software regardless of whether anyone needed it. "Tech has been the largest accounting hack ever." Data centers get sited for cheap water and power with real cost to the communities around them, models get bigger because bigger is fundable, and somewhere in the OpenAI-NVIDIA-Oracle circularity, "we're all in this endless cycle of tax evasion, tax accounting, tax hacks." His read isn't purely cynical, though: underneath the noise there's real opportunity in the unglamorous infrastructure work nobody wants to do, if you're willing to look past the hype for it.

You're Not Talking to the Whole Industry

Matty pushes back with a story from his PagerDuty days, arguing with a co-founder convinced that manual, dedicated bug-fix teams were extinct: "Alex, you talk to people who know what PagerDuty is in the first place and decided they wanna talk to you." A week at a manufacturing trade show reinforced the point for both of them: plenty of shops, tech and non-tech alike, are quietly not participating in any of this, "we still are building shit, and we do it the way we do." Whatever conclusion you're drawing about AI adoption from your own timeline and network is a sample of one bubble, not the industry.

Finding Signal in the Noise

Closing out, Marino's advice for keeping up: lean on the people who've kept their credibility instead of trading it for sponsorship money, because those are the ones who'll actually tell you when something's overhyped or underhyped. He points to Keith Townsend as an example of someone pragmatic who gets his hands dirty before rendering a verdict. Matty ties it back to a conversation he had with Emily Freeman after his own layoff: the useful answer usually sits between "I will not touch a single thing that uses AI" and "the only way you should communicate is through the agent."

If you want more on how to actually keep learning in the middle of all this, Matty points back to three earlier episodes: Learning to Learn, Learning Stuff, and Managing Your Mental Stack.

Download

Control Theory Had a Name for This All Along

Naga Sujitha Vummaneni and Sundeep Bobba co-authored CI/CD as a Control System, which takes Jez Humble and Dave Farley's Continuous Delivery, now pushing 20 years old, and reframes it through control theory. As Sujitha puts it: "The pipelines are activators, observability is the feedback signal, policy is the constraint, and deployment strategy is how you regulate the risk." Once you see a CI/CD pipeline that way, a lot of what look like tooling problems turn out to be system-behavior problems, and most pipelines today are open loop: "They measure everything and on nothing." Sujitha traces the pattern back to a moment from the Arrested DevOps episode with Hannah Foxwell and Robert Warner: enterprise clients insisting continuous delivery would never work at their company, until it was just how everyone shipped. The premise of the book is that this framing was always available, but AI agents moving at machine speed finally make it urgent.

Bonded Automation and the Four Questions

Sundeep's answer to "should the agent handle this?" isn't a yes/no: it's a bounded operating envelope. Low-risk, reversible actions like restarting an unhealthy service or quarantining a known-bad artifact are fair game for automation. Changing security policy, touching production data, or anything with real customer blast radius pushes the threshold for human involvement way up. His framework is four questions: "How confident are we in the signal? What is the blast radius? Is the action reversible? And who owns the risk if the decision is wrong?" Sujitha adds the control-theory language underneath it: signal quality is itself a gate, because an automated rollback that fires on a noisy metric is worse than no automation at all, "you get flapping." Bounded blast radius, rate limits, and cooldowns exist so the system doesn't correct itself into a new outage.

Writing "Always Run GitLeaks" in Your CLAUDE.md Doesn't Make It True

Matty pushes on the gap between guardrails you write down and guardrails that actually run. Telling an agent to always scan for secrets before committing is no different than the developer who says "you're right, I should have run that" after skipping a check themselves, "it's the same trust-but-verify thing we've been doing forever, except now it's exacerbated." The book's answer is to stop treating this as purely a tooling problem: platform controls enforce the non-negotiables, prompts tell the agent what good behavior looks like, and runtime feedback tells you whether the controls are actually producing the outcome you expected. Sundeep frames it as fundamentally organizational: "Who owns the control, who can change it, what evidence proves it ran, and what happens when it fails, and who is allowed to accept an exception."

The Approve Button You Click 200 Times a Day

Sujitha's closing point reframes what a bypassed control actually means. "The bypass is a signal, not a violation. When engineers route around a control, the control was misdesigned. It might be in the wrong place, or too slow, or solving a problem they don't even have." She names the familiar shapes: the emergency-change process used for 40 percent of changes, the security scan everyone has a documented exception for, the staging environment nobody deploys to because it's never in a usable state, the approve button clicked 200 times a day without being read. Each one means leadership believes there's a control while the dashboard shows green and nobody actually knows what's happening behind it, control theory's version of losing observability of your own control layer.

You Don't Need a Platform Team to Start

For smaller, scrappier teams, both guests argue the model still applies, maybe more cleanly. Sujitha notes that small teams often close feedback loops faster because the control boundary and the team boundary line up. Sundeep's advice: "Start with one service or one delivery path and make the loop visible. Know what signals tell us the system is healthy, what decisions we're making from those signals, and what actions we can safely automate." Observability is foundational to all of it, since without actionable feedback there's nothing to close the loop with. The through-line for organizations of any size: "It's whether you have a closed loop of feedback, decisions, constraints, and action, rather than a pile of automation."

Download

The Wall Nobody Talks About

Long before "DevOps" had a name, manufacturing plants had already split into two tribes: the automation and manufacturing engineers who built up their own scrappy plant-floor IT, and the corporate IT department issuing laptops and running the domain a few buildings over. They grew up independently, with different tools and different goals, until, inevitably, they collided. IT wanted plant data flowing to corporate; OT wanted to reach out for data too. Add different incentive structures on top, and, as Matty points out, it's the same "wall of confusion" that gave rise to DevOps in the first place, just wearing safety glasses instead of a hoodie.

"I Broke the Rules Just to Get It Going"

Doug's clearest example: a robot on the plant floor goes down because of a network issue, and the routers are owned by IT: a help desk routed through Bogotá with zero context on an explosives manufacturing line. The ticket crawls through triage while production sits at zero and the CEO starts calling. Doug's fix was to log into the router console himself and get it running again. "Everyone's like, 'Ooh, yeah, you're a hero.' Like, no, I'm not a hero. I broke the rules just to get it going." It's shadow IT, industrial-plant edition: the AWS-credit-card moment of manufacturing.

Converging, Whether Anyone Planned It or Not

What actually helped, in Doug's experience, wasn't process; it was knowing people. "It's always gonna be personal relationships," he says, and his pitch to leadership has been simple: IT needs someone who's had OT experience, and OT needs a rep who understands IT's constraints, because the requirements on both sides have already converged. Neither side can keep pretending plant data stays on the plant floor; predictive maintenance and machine learning mean data has to leave the building, sent out to third parties for analysis, whether or not the old "peace treaty" between IT and OT accounted for it. That same shift is dragging OT into IT's security concerns for the first time, too. Doug is blunt that OT folks "just don't have a good concept of the security requirements," a gap he's only closed by talking directly to security engineers in IT.

Manufacturing Already Solved This: In Manufacturing

Matty pulls in The Phoenix Project and its inspiration, The Goal, both built on the theory of constraints and value-stream mapping from actual manufacturing. The irony: software loves borrowing metaphors from manufacturing (Andon cords, the Toyota Production System) while the people doing real manufacturing haven't necessarily absorbed the lessons about visibility and bottlenecks that DevOps eventually learned from them. Doug agrees the CAMS/CALMS framework (culture, automation, measurement, learning or lean, sharing) maps cleanly onto OT/IT, especially the parts industrial teams already live: lean practices are baked into manufacturing, but the value an OT change delivers is far easier to point to (100 widgets became 110) than the value of infrastructure work that only shows up when it's absent.

Incentives Explain Almost Everything

The conversation lands on a favorite Matty theme: people work to the incentives you give them, not the ones you intended. A mandate for developers to write ten tests a sprint produces assert(true). A cash bonus for testers finding bugs and developers fixing them produces a black market in planted bugs. And "litigating severity" on an incident call is really about whoever's compensation is tied to P1 counts. Matty points to the STELLA Report as the same pattern in postmortems generally: after a well-handled incident, it's easy to reason "nothing bad happened, so you shouldn't have shut it down," the same Y2K cognitive dissonance in miniature. Doug's closing advice for anyone straddling the OT/IT divide is almost embarrassingly simple: find out the name of your IT person. Treat them like a teammate with real expertise, not a request queue ("not AWS," as Matty puts it) and the rest gets a lot easier.

Download

The Trust Problem Returns

Hannah Foxwell, who has spent over a decade in DevOps and platform engineering, draws a striking parallel to earlier transformations: “It used to be that testers didn’t trust developers and ops didn’t trust testers and there were all these silos. Now we’re putting AI agents in the mix. Can we trust them? Should we trust them?”

This isn’t just déjà vu—it’s a fundamental challenge that resurfaces with every major shift in how we build software. As Robert Werner points out, management had to give up control and push trust to the edges of organizations during the agile transformation. With cloud adoption came self-service and automation. Now, with AI, we’re dealing with non-deterministic black boxes that we need to trust to be “right often enough.”

The Fluency Gap

One of the biggest challenges isn’t the technology itself—it’s the lack of shared understanding. Hannah launched “AI for the Rest of Us,” a community now with over 1,000 members, after realizing that AI fluency is essential for making good decisions about where and how to use these tools.

“I went to a talk at a conference thinking I’d learn about AI in one talk and become an expert by tomorrow,” Hannah recalls. “It just didn’t happen like that. There’s a whole new domain with new vocabulary, new concepts, new techniques.”

The community focuses on making AI accessible without dumbing it down—providing talks and content that explain complex concepts in simple language so more people can participate in the conversation about AI’s role in software development.

The Speed-Responsibility Paradox

The technology is evolving so rapidly that best practices barely have time to solidify before they’re obsolete. Robert describes how hiring strategies at startups are changing every few weeks as new capabilities emerge. “Things that weren’t feasible last week are suddenly possible,” he notes.

But this speed creates a dangerous tension. Organizations are pushing hard for AI adoption while the guardrails, workflows, and cultural practices needed to use it safely are still being figured out. As Matty observes, this leads to perverse incentives—developers required to “use AI” who find ways to tick the box without actually deriving value, just like teams that once added meaningless tests to meet sprint requirements.

Who Owns the Code?

A critical question emerges: if AI generates the code, who owns it? Who’s responsible when something goes wrong?

Hannah frames it in familiar DevOps terms: “Does anybody really want to own a service if they didn’t write it and they don’t understand how it works? It’s the ops challenge again—AI throwing code over the wall to us.”

Robert’s answer is pragmatic and honest: humans will need to take responsibility for validating AI-generated code, even if it’s tedious work most developers won’t enjoy. His company, Leap, is building tools specifically to make that verification process as convenient and enjoyable as possible, because he believes there’s simply no other way to do it safely.

The Documentation Double-Bind

There’s an ironic twist in how AI agents work best: they need excellent documentation. Organizations improving their documentation to support AI-powered development are inadvertently following DevOps best practices that benefit human developers too.

But as Matty discovered building his own project, AI-generated documentation can be dangerously unreliable. The tools will confidently document features that don’t exist, pulling from incomplete PRDs or speculative notes in the codebase. Great documentation trains better agents, but agents shouldn’t write that documentation—creating a challenge that requires human judgment and oversight.

Lessons from Past Transformations

The parallels to earlier shifts are instructive. Hannah remembers enterprise clients who insisted continuous delivery would “never work here.” Now it’s common practice. The same resistance appeared with cloud adoption and agile methodologies.

What worked then still matters now:

Guardrails enable freedom: Constraints and safety nets let people explore confidently Make the right way the easy way: Transformations succeed when good practices are more convenient than bad ones Community and shared learning: Success stories and failures shared openly help everyone navigate change faster Start with good practices: Teams with solid engineering fundamentals—blue-green deployments, A/B testing, safe-to-fail production environments—are better positioned to benefit from AI-assisted development Practical Advice for Explorers

For developers and teams trying to navigate this transformation, Hannah and Robert offer grounded guidance:

Keep your eyes open: Watch for patterns of success and failure. Who’s making this work, and what do they have in common?

Build community: Find or create spaces where people can share honestly about what’s working and what isn’t, without the pressure to pretend everything’s perfect.

Be selective about information sources: With so much noise and hype, focus on quality outlets. Ignore things for a few weeks, and if they keep coming up, that’s when to invest your time.

Practice regularly: The technology evolves so fast that hands-on experience goes stale quickly. Even if it’s not your main job, refresh your skills every few months.

Be specific and constrained: AI coding assistants work best with clear, narrow requests. Frustration comes from asking too much or being too vague.

The Future We’re Building

We’re in the Nokia phone stage of AI-assisted development, as Robert puts it—the technology will look completely different in just a few years. But unlike waiting passively for that future to arrive, developers and teams are actively creating it through the choices they make today about how to integrate these tools.

The question isn’t whether AI will transform software development—it already is. The question is whether we’ll learn from past transformations to build better practices, stronger safety nets, and more trustworthy systems. Or whether we’ll repeat old mistakes at unprecedented speed.

As Hannah emphasizes, having more people with AI fluency means better conversations and better decisions at a pivotal moment in history. The rollercoaster is moving whether we’re ready or not. The best approach is to keep your eyes open, stay connected to community, and remain thoughtfully critical about what works and what doesn’t.

Learn more about Hannah’s work at AI for the Rest of Us. Use code ADO20 for 20% off tickets to their London conference on October 15-16, 2025.

Download

Security: the one topic that’s guaranteed to turn any DevOps conversation into a mix of fear, eye rolls, and nervous laughter. In this episode of Arrested DevOps, Matty welcomes back Kat Cosgrove to talk about the “never not hot” world of security and why it’s always lurking just over your shoulder (like that one compliance auditor who swears they’re just “observing”).

Kat and Matty cover:

Why vulnerabilities never seem to stop showing up in your containers (spoiler: they don’t). How teams can respond without spiraling into full-blown panic. The realities of securing Kubernetes and containerized environments (without pretending there’s a magic “easy button.”) Why security culture matters as much as the tools you’re using.

Along the way, expect the usual mix of snark, sarcasm, and the occasional tangent about how everything in tech eventually becomes a security problem.

If you’ve ever patched the same vulnerability three times in a week, or found yourself yelling at a CVE like it’s a personal enemy, this one’s for you.

Download

We’ve all been there: burning out on volatile tech jobs, tangled in impossible systems, and wondering what our work actually means. On this episode of Arrested DevOps, Matty Stratton sits down with Kat Morgan for a heartfelt, funny, and sharply observant conversation about AI: what it helps with, what it hurts, and how we navigate all of that as humans in tech.

They dive deep into how large language models (LLMs) both assist and frustrate us, the ethics of working with machines trained on the labor of others, and why staying kind—to the robots and to ourselves—might be one of the most important practices we have.

“We actually have to respect our own presence enough to appreciate that what we put out in the world will also change ourselves.” – Kat Morgan

Topics Why strong opinions about AI often miss the nuance Using LLMs to support neurodivergent workflows (executive function as a service!) Treating agents like colleagues and the surprising benefits of that mindset Code hygiene, documentation, and collaborating with AI in GitHub issues Building private, local dev environments to reduce risk and improve trust Ethical tensions: intellectual property, environmental impact, and the AI value chain Why we should be polite to our agents—and what that says about how we treat people Key Takeaways AI isn’t magic, but it can be a helpful colleague. Kat shares how she uses LLMs to stay on task, avoid executive dysfunction, and manage complex projects with greater ease. Good context design matters. When working with AI, things like encapsulated code, clean interfaces, and checklists aren’t just best practices. They’re vital for productive collaboration. Skepticism is healthy. Kat reminds us that while AI can be useful, it also messes up. A lot. And without guardrails and critical thinking, it can become more of a liability than a partner. Build humane systems. From privacy risks to climate concerns, this episode underscores that responsible AI use requires ethical intent, which starts with practitioners.

Download

Matty talks with Andrew Zigler, developer advocate at Mattermost, about what it takes to run a developer community that is open first, and why it's harder than it sounds. Matty says neither of them knew the topic going in, then draws on time at PagerDuty, Chef and Pulumi. The cold open is Andrew: "being default open doesn't mean you have to sacrifice standards or sacrifice productivity or what you're aiming for as a company. It just means that you have to do the work to align people to it."

The Echo Chamber

Andrew says the first hurdle in working default open is the echo chamber feeling: you post things you'd normally keep in closed channels, and either the same few people respond or nobody does, and you can't tell whether the message is landing or being read passively. DevRel also ends up as a counterbalance between what the community thinks of the project and what is happening inside the company. Building trust takes a long time, and the rule is to listen and incorporate the feedback you ask for, because otherwise you lose that trust.

The Gravity of the Company

Matty adds that the company behind a project always has more gravity, since the people paid to work on it attend every roadmap meeting, while volunteers and even people at another company's open source program office can only look in now and then. Andrew agrees that the loudest and most contributory voices are usually paid staff. Andrew's answer is to give other contributors gradients of engagement and a way to validate their experience and reward them, whether with swag, a platform, shared stage time, or simply being heard. People on the edges who never see contributors like themselves celebrated don't find a way in, so part of the job is teaching people to contribute where they are.

Matty compares Chef and Pulumi. At Chef, Matty says, "I work at Chef because I believe in Chef, not the other way around": employees were members of the community first, and community summits had staff and outsiders on equal footing. At Pulumi, when a community event was planned, it was hard to get employees to see that they were part of the community too and to join on a workday. Matty is careful to say it wasn't malicious, and that leadership has to reinforce it, since engineers with deliverables won't otherwise take the day. "No one plans for it to go bad," Andrew says, and adds that this is a universal experience in open source. Andrew suggests sharing the tools too, such as cloud workspaces that let outsiders build the software the way staff do, since internal build systems are where open projects quietly stop being open.

What Can Stay Closed

Matty raises the open roadmap problem: customers can't be named, and a feature may matter because one large customer wants it. Matty notes almost no company would give the community an equal say over the project it stewards. Andrew says "being default open doesn't mean that everything has to be open. It just means that you have to default to being open," and that it's fine to ask at the start whether something needs to be open. The key is to communicate clearly about what isn't, to keep trust. If community-built features make a product sticky in the enterprise, Andrew adds, some of what comes back should go to the community, for meetups, lightning talks and swag, "by sharing the spoils."

Opening Up Advocacy

Matty asks how to open source advocacy itself, since people whose title is developer advocate can't do all of it. Matty describes a friend who asked how engineering blogs work, and the pattern of nothing for three months and then 12 posts in a day, since engineers write when they can. Matty's fix is to have people whose job is content work with subject matter experts. Andrew loves an engineering blog run by engineers, since the community wants to hear from the React developer about a new design library, not executive marketing, and says it needs pairing with a marketing team to tie back to strategy.

Andrew's core idea: "The biggest thing that you can do as a developer advocate is to create more developer advocates," meaning people without the title who have opportunities to engage. Open source communities are seasonal, since people contribute when they have free time, and "you can't control the waves, but you can control what the waves do when they wash up on the shore." Advocates should share strategy and plans, and write retrospectives about conferences, demos and talks, so contributors get excited and come along. Andrew has had contributors ask for feedback on their conference talks, which means trust has been earned and that advocacy created another advocate.

Andrew's example is GitLab's DevRel team, who plan events in the open on GitLab with epics and milestones and post retros with photos, talks and contributors. A contributor in Brussels can see the team is coming in three months and sign up on the issue. Planning for sponsorships, collateral and demos tends to happen invisibly on Slack, Discord or Asana, and fixing that invisibility matters.

Writing Programs and Contact Pages

Matty says a contributor writing program is "so much work" that contacts at other companies who ran one mostly wished they hadn't, since it multiplies content production problems. It doesn't have to be a formal program: signal boost a post about your product, or invite the author to collaborate. Matty also pleads with bloggers to put a way to reach them on their blogs, because Pulumi wanted to syndicate community posts with canonical tags and couldn't find the authors, and some authors turn out to have moved on from the tool years ago, though the post is still good. Matty's own most visited page is an old post about SharePoint 2010 search in a one-way trust, written to document a fix for a team.

Andrew ran a community writing program at Mattermost, which is rewarding for contributors, especially those in emerging tech hubs, and draining for staff, and can drift into a side project that doesn't connect back to company goals. Community members often assume the company won't notice their work, Andrew says, when in fact staff are right on top of anything that comes in and want to lift it up, and helping them get past that feeling builds confidence.

Links Matty's blog post about SharePoint (including broken images!) Community Pulse podcast

Download

Read more of Chelsea Troy's writing here!

Download

Every ADO Cold Open Ever “Episode 0” of ADO “Old Geeks Yell At Cloud” video

Download

Matty talks with Ben Greenberg, who had been head of DevRel at Fuel Labs for about three weeks at the time of recording and also runs a small consultancy, Yalla DevRel. The topic is what to do when you're suddenly in charge of a team, or starting any senior role. Ben had guested before, but that episode was recorded in May and shelved because its social networking content had aged, and Matty says this one is aimed at something timeless. The cold open is Matty on the classic interview question: "What's your biggest weakness, Ben? I work too hard."

Nobody Wants You to Change Everything

Matty's warning for new senior hires: no matter how often people say they want a change agent, "here's the secret: they do not." Ben calls it the hero complex of hiring, the lowercase-m messiah, and describes doing something new in interviews: sharing a real, still-raw failure instead of a humblebrag, on the theory that if Fuel Labs still wanted Ben afterward, the fit would be real. Matty recalls the first manager job at Apartments.com, a role that was half manager and half sysadmin, where Matty arrived fired up about process and after about four weeks realized it was time to stop and listen. Matty's rule: "you have 2 ears and 1 mouth," and "every process, every way of doing things in a company is organizational scar tissue." The likelier explanation for something being done a certain way is that there's a reason, not that nobody has heard of Salesforce.

Ben contrasts the invading colonizer who uproots things with the person who sits with people, listens to their stories and helps shape direction from within, and admits that's hard when you were hired to do things.

The First Weeks

Matty describes starting a role while knowing a new boss would arrive in three months. A coach suggested using the time for discovery so that the new boss could be handed what Matty had learned and a plan, without having made changes yet. Matty's onboarding technique: in every get-to-know-you meeting, mostly about the person and not the job, schedule a follow-up four to six weeks out, when there's enough context for a substantive conversation. Ben adds asking each person who else to meet, which widens the circle quickly, and meeting ecosystem partners and developers who build on the company's infrastructure. Matty recommends The First 90 Days, with the caveat that it reads like Harvard Business Review articles stapled together, and that it helps with figuring out what kind of organization you're in.

Matty also uses a model from an executive coach, Bill Joy, who taught engagement and skill as two axes: a new starter is high engagement and low skill, even a principal engineer or a new CEO. "You could be the new CEO. You are low skill." Activity for its own sake looks busy but doesn't win collaboration, and Ben says DevRel suffers from filling calendars without knowing what moved the needle.

Showing Value

Matty's standing advice is to learn how the company makes money. In DevRel interviews Matty's philosophy is that "if you don't have a way of demonstrating value, a way of demonstrating value will be assigned to you and you won't like it." Take care of the things tied to business outcomes and nobody will question the rest. Matty jokes about wanting a Nicole Forsgren for DevRel. Ben says the same applies to SDK engineers, technical writers and DevOps: do less, more completely and at a higher standard, instead of covering everything.

Ben's Plan

Ben inherited a team of three, dispersed across the Americas, each there about a year, and wants a team "that knows more than you." Ben's first career was as a director at nonprofits, and Ben's earlier stint as a young manager was marked by opinions, talking more than listening and buying into the change agent paradigm, which cost Ben. This time Ben has been listening and taking notes, then drafted a quarterly plan, shared it with Ben's own boss, then the team with an invitation to tear it apart, and scheduled an offsite to build Q1 objectives and key results together. Ben's method is to be a facilitator and consensus builder, and says "ownership is how you create a sense of culture of staying." A key goal is career paths for the team, since nobody had held the role for a while, recognizing what people did in the past year and getting them to where they should be.

Team Lead Is Not a Manager

Matty points to Lindsay Holmwood's post "It's Not a Promotion, It's a Career Change," and tells how a new CTO suggested moving Matty from director to infrastructure architect because technology, not managing people, seemed to be what got Matty out of bed. Matty's conditions were no pay cut and a letter making clear it wasn't a demotion, which Matty says illustrates the problem. Both believe individual contributors should be able to earn more than their managers, and Ben cites Aaron Bassett's talk that promotion shouldn't require becoming a manager. Matty says team lead and people manager are very different jobs: leading an open source project is not performance management, career coaching or time-off requests, and as Ben puts it, "you're never putting an open source contributor on a PIP."

Matty credits Apartments.com for heavy manager training, since many managers were first-timers from internal promotion, and Bill Joy's framing that the hardest transition is the first one, from individual contributor to manager, because you must stop doing what you're used to. Matty also says that leading a DevRel team in data, and not in a space like Kubernetes or infrastructure as code where Matty knows the material, has been easier to do humbly, since "I couldn't get a job on my own team," while still knowing how to do DevRel. Ben calls that humility a good topic on its own.

The First 90 Days "It's not a promotion - it's a career change" (Lindsay Holmwood) "Not All Leaders Are Managers" - (Aaron Bassett)

Download

Matty talks with Jeremy Duvall, founder of Seven Factor Software, a software engineering consultancy in Atlanta, about why DevOps keeps ending up as a department and what to do instead. Jeremy cut teeth at Danger, which built the T-Mobile Sidekick, then worked at Microsoft, and has been doing DevOps for a long time. The episode is part of the show's tenth-year look back, and Matty promises the anniversary episode in a month. The cold open is Jeremy on the Agile and DevOps values: "focus on your people and stop worrying about the stupid shit you use to get things done."

How DevOps Became a Department

Jeremy's first exposure was a DevOps Days in Atlanta where John Willis spoke on burnout, which showed that DevOps wasn't just about playing with Jenkins. Before that, Jeremy says, nobody thought you needed a department to deploy Jenkins servers: two people on a tools team built the machinery the rest of engineering used to ship. The real contribution of the movement was refocusing on the idea that developers are humans. Then, as with big data and digital transformation, big companies took the ideas, put them in a department with pay scales, and turned infrastructure teams into DevOps engineers doing the same things. Jeremy sees platform engineering as "the next logical evolution" of what DevOps should have been.

Matty adds that early DevOps deliberately avoided being prescriptive, with no manifesto, just the CAMS acronym of Culture, Automation, Measurement and Sharing from John Willis and Damon Edwards at the first US DevOpsDays in Mountain View, to which Jez Humble later added Lean, for CALMS. People still have to do work, and automation is where vendors make money, so DevOps drifted toward meaning Jenkins and Puppet. Jeremy compares it to Agile: a manifesto that gave rise to SAFe, which Jeremy calls garbage, and also to good things like Kanban and Lean. Matty adds that "SAFe is how to have Agile but let project managers still have a job."

Measurement and Incentives

Jeremy says the business community got its claws into both movements with Scrum, velocity metrics and somebody-has-to-get-fired accountability, which produces walled gardens, bureaucracy and a pathological culture instead of a generative one. Matty says measurement doesn't equal Taylorism, contrasts Nicole Forsgren's work on developer productivity at GitHub with McKinsey's, and names Freakonomics as the most important DevOps book: "Go learn about incentives and then you will understand DevOps."

Jeremy says what engineers do is hard to measure, so organizations reach for features shipped or hours against velocity points, and "A measurement ceases to be a good measurement when it becomes a target." Jeremy points to the developer productivity work of Abhinav and DX, which focuses on happiness, and cites Antifragile for thinking about teams that survive someone leaving or breaking an arm. Jeremy says Google, Amazon and Facebook get this right, with engineers empowered to deploy and build their own platforms, while Jeremy's retail clients are stuck in a 1990s CEO mindset, with Nordstrom as an example of a real turnaround. Matty adds that Courtney, who led that transformation at Nordstrom, has talked about internal platforms for the enterprise, linked below.

The Frozen Middle

Matty describes hearing at Chef that about 80 percent of CIOs said DevOps transformation was critical but only about 15 percent of enterprises had a plan, and says the C-suite can think big while middle managers whose job is executing one way of measuring will fight a radical change. At PagerDuty, banks had whole teams of incident managers, and they weren't bad people: "I would probably have done the same damn thing."

What Success Looks Like

Jeremy says most of the Fortune 500 now know DevOps is a thing, and successful teams have trust to make decisions and a paved golden road to production, with a platform or DevOps team, whatever it's called, building the frameworks while software engineering teams cross-skilled in things like Terraform get their apps to production without interference. The cloud means developers no longer wait two weeks for a Tomcat server. To avoid repeating the mistake, Jeremy says to avoid commoditization: "everything that's wrong with software engineering today is commoditization and value engineering." Jeremy builds teams with overlapping skills, "I don't want specialists in 2023," and says platform teams are software engineers, "They're not infrastructure people anymore." Matty wraps up with the 2014 episode How to Eff Up DevOps, linked below.

John Willis’s talk at DevOpsDays Atlanta 2016 on Burnout https://platformengineering.org/talks-library/internal-platform-enterprise-courtney-kissler ADO - How to Eff Up Devops with Pete Cheslock, Nathen Harvey, and Randi Harper

Download

OWASP Top 10 Stripe: The developer coefficient (quantifies the cost of bad code to companies to be $59B annually) Facebook: FAUSTA: Scaling Dynamic Analysis with Traffic Generation (how runtime analysis was used at WhatsApp to catch design flaws before they reached production) Dragan Stepanović - Async code reviews are choking your company’s throughput (from LAS 2022, a talk which highlights the systemic problems with developers trying to do manual code reviews of large PRs) AppMap, the runtime analysis company which Brian works for Cloud Native Security with Michael Isbitski ADO Episode

Download

It's a complex world! Matty and Michael Stahnke wax philosophical about whether our systems need to be as complicated as we have made them

Download

Arrested DevOps - The Database: The Elephant in the Room Arrested DevOps - Data! Data! Data! With Francesco Tisiot Arrested DevOps - The New DevOps With Adam Jacob History of databases talk from Matty and Kat Cosgrove

Download

Arrested DevOps - DevOps With Better Marketing with Pete Cheslock Arrested DevOps - Platform Engineering with Daniel Bryant Arrested DevOps - Platforms with Kelsey Hightower and Andrew Clay Shafer Lean Enterprise The Future of Ops Is Platform Engineering Charity’s talk from devopsdays NYC Jess Kerr’s blog that Matt mentioned Cargo Cult Science

Download

https://www.instagram.com/ziggy.odoodle/?hl=en https://twitter.com/opentofuorg https://github.com/opentofu https://linkedin.com/company/opentofuorg https://github.com/opentofu/opentofu

DevOps World is back for 2023, and you won’t want to miss out on this one-of-a-kind event! This year’s program is packed with exclusive insights, immersive workshops, and unparalleled networking opportunities taking place across multiple cities in the US, UK, and Asia. Elevate your DevOps game and register using the following links: NYC area, Chicago, Silicon Valley, Singapore, and London.

Download

Links to Resources Mentioned 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr *The DevOps Handbook The System Initiative Switch: How to Change Things When Change Is Hard

DevOps World is back for 2023, and you won’t want to miss out on this one-of-a-kind event! This year’s program is packed with exclusive insights, immersive workshops, and unparalleled networking opportunities taking place across multiple cities in the US, UK, and Asia. Elevate your DevOps game and register using the following links: NYC area, Chicago, Silicon Valley, Singapore, and London.

Download

The Importance of Your Personal Brand

Whether you’re working for a startup or a corporate giant like Visa, Target, or JP Morgan Chase, your personal brand helps to define your professional identity. This brand is not just about showcasing your GitHub contributions, but about telling your unique story. It’s about how you solved a particular problem or contributed to a project, not just about the technologies you used.

Building Your Brand Story

Building your personal brand starts with self-reflection. Here are three questions to ask yourself:

Who are you professionally? Identify your top three technical specialties, professional specialties, and team contributions.

Who are you personally? Identify three interests and hobbies, your most important beliefs and values, and aspects of your social, family, or community life that you want to connect with people over.

How do you connect with people? Identify shared interests, the advice or information you’re seeking, and what you want to know about other people.

Answering these questions gives you a wealth of material to draw from when telling your story and helps you identify your strengths and areas of expertise.

Show, Don’t Tell

When you’re creating your brand content, remember the old adage: show, don’t tell. Instead of proclaiming yourself a “thought leader,” demonstrate your expertise through your work. Share your accomplishments in a way that highlights how your work benefited others, not just yourself. This approach makes your story more engaging and relatable.

Embrace Vulnerability

Being open about what you don’t know can be a powerful part of your personal brand. It shows that you’re a lifelong learner, open to new ideas and willing to grow. Plus, asking for help or resources can lead to valuable connections and insights.

Pay It Forward

Sharing your knowledge and helping others is a powerful way to build your personal brand in tech. It demonstrates your expertise and your willingness to support your peers. This approach is not about trading favors but about creating a positive ripple effect in your community.

In conclusion, building a personal brand in tech is about more than just showcasing your skills. It’s about telling your story, connecting with others, and contributing to your community. By being authentic, open, and generous, you can create a personal brand that truly stands out.

Links to Resources Mentioned Keep a Brag Book KubeCampus: Free Kubernetes Training Purposeful Personal Branding - Nov 2018 Slides 13-15 have the 3 questions DevOps World is back for 2023, and you won’t want to miss out on this one-of-a-kind event! This year’s program is packed with exclusive insights, immersive workshops, and unparalleled networking opportunities taking place across multiple cities in the US, UK, and Asia. Elevate your DevOps game and register using the following links: NYC area, Chicago, Silicon Valley, Singapore, and London.

Download

“Everything is a Product” - Matty’s talk “More Buzzwords Won’t Help” - Andrew Clay Shafer Telemetry Hub channel on YouTube DevOps World is back for 2023, and you won’t want to miss out on this one-of-a-kind event! This year’s program is packed with exclusive insights, immersive workshops, and unparalleled networking opportunities taking place across multiple cities in the US, UK, and Asia. Elevate your DevOps game and register using the following links: NYC area, Chicago, Silicon Valley, Singapore, and London.

Download

Sysdig 2023 Cloud-Native Security and Usage Report Pushing Left With Tanya Janca (ADO epsiode) Shifting Left Securely (Matt’s talk) DevOps World is back for 2023, and you won’t want to miss out on this one-of-a-kind event! This year’s program is packed with exclusive insights, immersive workshops, and unparalleled networking opportunities taking place across multiple cities in the US, UK, and Asia. Elevate your DevOps game and register using the following links: NYC area, Chicago, Silicon Valley, Singapore, and London.

Download

Pete’s Video Project Pete’s TikTok Want to join a future version of Pete’s videos? Platform Engineering With Daniel Bryant (ADO Episode)

Download

Sonia Gupta and Corey Quinn - Embarrassingly Large Numbers: Salary Negotiation for Human Talking pay in the public square

Download

Kafka Connect tool Metadata parser Francesco’s SOFT blog post

Download

Kafka Connect tool Metadata parser Francesco’s SOFT blog post

Download

ADO Episode - Platforms with Kelsey Hightower and Andrew Clay Shafer Daniel’s Kubecon talk Daniel’s blog/tweet thread the kicked off his interest in Platform Eng Spotify golden paths Crossing the Chasm - Technology Adoption Lifecycle Backstage project Backstage as a service

Download

ADO Episode - Platforms with Kelsey Hightower and Andrew Clay Shafer Daniel’s Kubecon talk Daniel’s blog/tweet thread the kicked off his interest in Platform Eng Spotify golden paths Crossing the Chasm - Technology Adoption Lifecycle Backstage project Backstage as a service

Download

VOID The Verica Open Incident Database (VOID) makes public software-related incident reports available to everyone, increasing understanding of software-based failures in order to make the internet a more resilient and safe place. After scrutinizing nearly 10,000 incidents, one thing is crystal clear: Resilience saves time. Taking the time to understand how to better respond when something green turns red—learning from the people, the processes, and the systems—will make your next incident smoother. 2022 VOID Report “Taylorism is a corporate disease that we haven’t developed a vaccine for yet” - Courtney

Download

VOID The Verica Open Incident Database (VOID) makes public software-related incident reports available to everyone, increasing understanding of software-based failures in order to make the internet a more resilient and safe place. After scrutinizing nearly 10,000 incidents, one thing is crystal clear: Resilience saves time. Taking the time to understand how to better respond when something green turns red—learning from the people, the processes, and the systems—will make your next incident smoother. 2022 VOID Report “Taylorism is a corporate disease that we haven’t developed a vaccine for yet” - Courtney

Download

Jess and Roni talk about what continous feedback: where it came from, what it looks like in the context of a dev proces, and the benefits it can bring to engineers and developers. They also discuss Roni’s observability project, Digma.ai… and his other passion, complicated board games.

Download

Jess and Roni talk about what continous feedback: where it came from, what it looks like in the context of a dev proces, and the benefits it can bring to engineers and developers. They also discuss Roni’s observability project, Digma.ai… and his other passion, complicated board games.

Download

linkedin.com/in/dagnabieda www.themindfuldev.com How Dagna works with her clients https://www.arresteddevops.com/principal-engineer/

Download

Download

Breaking Down Gates with Tim Banks (previous episode with Tim)

Download

Download

You know how so many devops folks are like “lol let me tell you about this time I accidentally took down production”? I would *love* to get to that level of blamelessness and shame-free acceptance with phishing, security misconfigurations, and other such mishaps.

— Kat Sweet (@TheSweetKat) October 25, 2021

If you're in infosec, what are you 5 top priorities for your team right now?

— MattGPT (@mattstratton) October 26, 2021

Download

Download

Melody: melody.dev

Download

Melody: melody.dev

Download

Favorite Episodes Drawing DevOps with Ashton Rodenhiser Multicluster Service Mesh With Phillip Gibson and Annie Wang Brigade With Kent Rancourt Most Popular Episodes Most listened-to episode in 2021 was All Things Docker Second most listened-to episode in 2021 was Foundational Practices With Johan Abildskov Number three was Doing Releases Right With Scott Hain Pet photos! Moxie Nimoy and Ripley

Download

Emily’s book ProAgile Emily’s blog Emily’s github

Approval testing tools mentioned

https://approvaltests.com/ https://github.com/texttest/texttest

Download

Matty’s dog on Twitter Shifting Left Securely (Matty’s talk at devopsdays denver 2017) Steve’s “Collaboration over competition” talk Trivy Checkov from bridgecrew Cosecast Pushing left with Tanya Janca (ADO episode) Cosecast with Tanya Janca We Hack Purple Security Chaos Engineering With Aaron Rinehart (ADO epsiode)

Download

Bridget chats with Kent Rancourt about Brigade.

Download

Emily Freeman, Principal, DevOps Solutions at AWS and Matt have a frank conversation about how DevOps has changed, where it's going, and the merits of the Oxford comma.

Download

Bridget chats with Phillip Gibson and Annie Wang about multicluster service mesh.

Download

"If you invest enough into foundational practices you can ignore them" - this is a heady statement, and special guest Johan Abildskov takes us through a journey to explore what our foundationa

Download

Matt is joined by Ashton Rodenhiser, who has become a fixture at many conferences where she provides graphic recordings of various talks and presentations!

Download

In this episode, Jess talks with guest Cat Swetel about her career, writings, and thoughts on DevOps.

Download

Does tech ask more from its community than other industries? What does it mean to be part of a community and what is expected of us?

Download

Bridget chats with Justin Cormack and Donnie Berkholz of Docker.

Download

Learning, as well as teaching, are both skills. Skills that we can develop with intentionality and practice. Shelby Spees, a Developer Advocate at Honeycomb, shares her insight into this topic.

Download