Quotes About Collaboration

Most people in a company, frankly, are not going to understand how communities are built and operate, but many people in the community aren't going to understand the dynamics of how that company operates.

Anything worth doing transcends borders.

You can't help someone get up a hill without getting closer to the top yourself.

A great team doesn't mean that they had the smartest people. What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists.

The only thing more dangerous than a developer is a developer conspiring with Security.

we're hearing more lately: something called "DevOps." Maybe everyone attending this party is a form of DevOps, but I suspect it's something much more than that. It's Product Management, Development, IT Operations, and even Information Security all working together and supporting one another.

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.

What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists.

What these organizations have in common is a high-trust culture that enables all departments to work together effectively, where all work is transparently prioritized and there is sufficient slack in the system to allow high-priority work to be completed quickly. This is, in part, enabled by automated self-service platforms that build quality into the products everyone is building.

A firm-wide, shared source code repository is one of the most powerful mechanisms used to integrate local discoveries across the entire organization.

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.

Patty thinks for a moment, "It's strange. Even though we have so much data on projects, changes, and tickets, we've never organized and linked them all together this way before.

Creating and prioritizing work inside a department is hard. Managing work among departments must be at least ten times more difficult.

Imagine a world where product owners, Development, QA, IT Operations, and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds. By working toward a common goal, they enable the fast flow of planned work into production (e.g., performing tens, hundreds, or even thousands of code deploys per day), while achieving world-class stability, reliability, availability, and security.

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.

Another benefit of having Development and Operations using a shared tool is a unified backlog, where everyone prioritizes improvement projects from a global perspective, selecting

Erik described the relationship between a CEO and a CIO as a dysfunctional marriage. That both sides feel powerless and held hostage by the other.

This is the reality of operating complex systems; no single person can see the whole system and understand how all the pieces fit together.

we are not talking to one another about what changes we're planning or implementing. This is not acceptable.

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

Solving any complex business problem requires teamwork, and teamwork requires trust.

should be as easy as writing one line of code to create a new metric that shows up in a common dashboard where everyone in the value stream can see it.

all team members as well as passers-by can see the latest information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on. This

As has been proven time and again, the further the distance between the person doing the work (i.e., the change implementer) and the person deciding to do the work (i.e., the change authorizer), the worse the outcome.