Quotes About Operations

you definitely need to know about constraints because you need to increase flow. Right now, nothing is more important." Erik assumes a lecturing voice as he starts, "You say you learned about plant operations management when you were in business school. I hope as part of your curriculum, you read The Goal by Dr. Eli Goldratt. If you don't have a copy anymore, get another one.

One goal is that our tooling reinforces that Development and Operations not only have shared goals but have a common backlog of work, ideally stored in a common work system and using a shared vocabulary, so that work can be prioritized globally.

four types of work: business projects, it Operations projects, changes, and unplanned work.

In our world, Development and IT Operations are adversaries; testing and Infosec activities happen only at the end of a project, too late to correct any problems found; and almost any critical activity requires too much manual effort and too many handoffs, leaving us to always be waiting.

Instead of IT Operations doing manual work that comes from work tickets, it enables developer productivity through APIs and self-serviced platforms that create environments, test and deploy code, monitor and display production telemetry, and so forth.

One is that it matters. it is not just a department that I can delegate away. it is smack in the middle of every major company effort we have and is critical to almost every aspect of daily operations.

Frequently, Development will take responsibility for responding to changes in the market, deploying features and changes into production as quickly as possible. IT Operations will take responsibility for providing customers with IT service that is stable, reliable, and secure, making it difficult or even impossible for anyone to introduce production changes that could jeopardize production. Configured this way, Development and IT Operations have diametrically opposed goals and incentives.

In the technology value stream, we optimize for downstream work centers by designing for operations, where operational non-functional requirements (e.g., architecture, performance, stability, testability, configurability, and security) are prioritized as highly as user features.

the architecture that our services operate within dictates how we test and deploy our code. This

However, for decades we have ended up with silos of information, where Development only creates logging events that are interesting to developers, and Operations only monitors whether the environments are up or down. As

The principles of Flow, which accelerate the delivery of work from Development to Operations to our customers The principles of Feedback, which enable us to create ever safer systems of work The principles of Continual Learning and Experimentation foster a high-trust culture and a scientific approach to organizational improvement risk-taking as part of our daily work

Dr. Eliyahu M. Goldratt, who created the Theory of Constraints, showed us how any improvements made anywhere besides the bottleneck are an illusion. Astonishing, but true! Any improvement made after the bottleneck is useless, because it will always remain starved, waiting for work from the bottleneck. And any improvements made before the bottleneck merely results in more inventory piling up at the bottleneck.

In Operations, we may deal with this problem with the following rule of thumb: When something goes wrong in production, we just reboot the server. If that doesn't work, reboot the server next to it. If that doesn't work, reboot all the servers. If that doesn't work, blame the developers, they're always causing outages.

By doing this, Development and Operations may end up creating a shared work queue, instead of each silo using a different one (e.g., Development uses JIRA while Operations uses ServiceNow). A significant benefit of this is that when production incidents

One of the key lessons in Lean is that in order to shrink lead times and increase quality, we must strive to continually shrink batch sizes. The theoretical lower limit for batch size is single-piece flow, where each operation is performed one unit at a time.

the four types of work: business projects, it Operations projects, changes, and unplanned work.

delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.

As Damon Edwards observed, "Without these self-service Operations platforms, the cloud is just Expensive Hosting 2.0.

CIO stands for "Career Is Over." And VPs of IT Operations don't last much longer.

For example, high performance with a functional-oriented and centralized Operations group is possible, as long as service teams get what they need from Operations reliably and quickly (ideally on demand) and vice-versa. Many

Was there an outage I didn't respond to quickly enough? As an IT Operations guy, the career-ending outage is the joke my peers and I tell one another daily.

As part of the First Way, you must gain a true understanding of the business system that it operates in.

Situations like this only reinforce my deep suspicion of developers: They're often carelessly breaking things and then disappearing, leaving Operations to clean up the mess. The only thing more dangerous than a developer is a developer conspiring with Security. The two working together gives us means, motive, and opportunity.

Your job as vp of it Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure it service.