Respect for Production
Respect for production is not about intention or diligence. It’s knowing exactly what is servicing our customers.
Pre-2013 blog archive @davemangot tweet archive
Respect for production is not about intention or diligence. It’s knowing exactly what is servicing our customers.
Don’t ask the computer to change for you. To move quickly and safely, declare your intentions.
Get most of the benefit of a fully staffed team for a fraction of the cost? Looks great on paper.
If maintenance is not part of the lifecycle, it’s repeated project work, and deadly for velocity.
Copilots can locally optimize the system, making everything worse in the process.
It seemed like a good idea in 2001, it wasn’t. It’s an anti-pattern for stability.
We can usually handle more work, with the people we already have.
Automation is not about doing things faster, it’s about shortening feedback loops.
The solution is the easy part, understanding your problem is hard.
Communities of Practice change an organization, not a silo
On the path to take companies to the next level, deploy internal conferences to do the same for engineering
Good leaders enable engineers to feel pride in their work to deliver differentiating results
Feelings are an important part of engineering. But they don’t replace automated tests.
Most developers shouldn’t know or care about the database technologies.
Turn releases into something for Marketing, not Engineering
Trying to close more tickets “doesn’t scale”
If management wants different outcomes, only they can change the system.
Known or unknown, the thing about technical debt that leadership needs to understand.
Agile is not to control, measure, or micromanage teams.
Shifting left is not merely shifting work earlier.
Cost of delay, opportunity costs, etc. are not easily calculated
The cloud isn’t someone elses datacenter but with APIs
Having one group do all the tickets seems like a good solution…
As an engineering leader, avoid ad hoc meetings
When deploying infrastructure, simply costing less can be much, much more
If you’re trying to understand why your SaaS is slow, look for the SRE coders.
Entropy is real. MTBF thinking tries to suppress what is real. DIE instead.
Automation doesn’t replace humans, it enhances them, if we think about it in the right way.
The days of the ivory tower enterprise architect are over. Instead, embrace cultural (architectural) evolution.
Checklists are not just something to be accomplished. Used properly, they allow us to learn more about our systems.
Even with Serverless, one has to obey the cloud provider failure boundaries
When looking to create a more agile business, we can take inspiration from many sources. But ultimately, the problems we need to solve are our own.
If you want your company to be successful, give it something your competitors don’t have. A world class service delivery organization.
With the right culture, companies whose teams hit “singles” consistently will outperform competitors who are overly reliant on the “home run.”
Survival in the digital age requires an emphasis on execution and speed, enabled by a DevOps approach across the business
There are many options for DevOps assessment, the best one also helps your organization get good at delivering software.
When working with companies on cloud migration, rather than focus on tools or technologies, we focus on fundamentals.
Keeping up with growth in an organization is a GOOD problem. Process is a great solution, if done the right way.
There are engineering concepts that are very difficult to quantify. Even if we could, does it make sense to aim for zero?
Many teams in the alternative capital markets space talk about the elements of their culture that enable growth. This “conscious inquiry” approach is well known to high performing teams in the DevO...
Engineers work hard all year. One of the best ways to be a high performer is to remember, downtime.
Attending virtual conferences is a new experience. Presenting a virtual conferences requires a very different approach.
Being a frontline manager requires a careful negotiation between the business and the engineers. If we focus our efforts on needs, we’ll always be doing the right things.
Making data-driven business decisions can change the entire equation.
When taking charge of an organization characterized by chaos, use these principles to help quickly turn the ship get things under control.
When working on multiple projects at once, it is hard to make good progress. If we organize around the value stream, then we can help the work to flow through our system.
Engineering is much more than just writing code – it’s about improving a system. By re-engineering our hiring processes, we can bring much-needed efficiency and results to the system.
Every company may be a software company, but many software companies are now becoming distributed software companies. By adopting an everyone remote culture, we can hire, empower, and enable employ...
In our jobs, it’s not enough to be busy, we need to be productive. By being deliberate about choosing what to work on, we can make real strides for our product, our businesses and ourselves.
Whether and when to deploy on Fridays should be a choice. A conscious one.
If we want teams that are empowered to move quickly and safely, instead of giving them strict instructions on how to perform their jobs, we can make the right way the easy way, and allow the busine...
Part of the responsibility of high-performing Operations teams is to keep the developers moving as fast as possible. Using the Cynefin framework, we have a way of characterizing our initiatives and...
Summary of the overlaps I’ve observed between the DevOps movement and the next generation of Healthtech.
When delivering software to our customers, in any capacity, we’re often faced with a false choice between focusing on stability or speed. With a high performing Operations organization, we can have...
Scrum is not a good fit for SRE teams. Here’s how to be an Agile SRE team.
Gigabit Internet on an OpenBSD firewall with Grafana graphs? Here’s how.
DevOps involveds the entire organization. Not just Dev and Ops
Cross functional teams doesn’t mean everyone eventually does everything. People still have their strengths.
Cross functional teams are a great enabler in DevOps. Why?
Are we losing control of the word DevOps? Is a DevOps engineer a culture engineer?