Skip to main content
  1. Posts/

Shared Focus - Using The First Way with DevOps

·366 words·2 mins
Chris Ayers
Author
Chris Ayers
I am a father, nerd, gamer, and speaker.
Table of Contents

A common issue I see when discussing DevOps with teams or organizations is the presence of Organizational Silos. Organizational Silos are made up of all types of people. Sometimes its a job type, like developers, qa, or infrastructure. Sometimes its a department, like accounting, or hr. Whatever the composition of these silos, they usually impact organizational performance and the ability to deliver value to end users.

This happens over time, with members of the silo identifying with each other, viewing those not in the silos as outsiders. Depending on the business, the silos can lose trust in the business overall and tighten ranks around their silo. The silos can turn into walled fortresses. When the silos get in the way, the silos are more focused on their own success than the success of the organization.

This can also happen with leaders. Leaders trying to turn their areas into fiefdoms. Leaders concerned about their power, responsibilities, or bragging rights. Either way, like the silos, situations like this can lead to groups concerned about their success, instead of the success of the organization.

Common Goals
#

To really succeed, to improve and to grow as an organization, everyone needs to share some common goals and shared focus across the organization. How do we bring value to users? Sure, Dept A can release X feature or function, but if it depends on Dept B to work, it brings no value. If developers can write lots of code, does that benefit the user if it isn’t tested? If that code doesn’t have resources to run on? If you’re writing code no-one wants? Or systems are built and configured but there’s nothing to run.

When everyone is working towards common goals and have a shared focus, the whole is greater than the sum of the parts. I was introduced to some of these ideas as “The First Way”. I read about this in “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” by Gene Kim and “The DevOps Handbook”. The ways were also in a blog by Gene Kim called “The Three Ways”. If you haven’t read either of these books, please go read The Phoenix Project.

Related

How Do You Boil the Ocean?

·329 words·2 mins
This is a phrase I end up using a lot while talking with clients. I used to use a different phrase about elephants but moved away from that language to be more respectful. Let’s start with what it means, at least in the context I use it, and why this phrase is so useful when talking about Devops. The Meaning # I’ve seen and heard a few meanings and usages of the phrase, “Boil(ing) the Ocean”. I’ve heard many negative contexts like: to undertake an impossible task or project. I usually use it in this context, Here is a big task with lots to do, how do you get started and make progress?

Snake Oil DevOps - BEWARE!

·442 words·3 mins
As a DevOps Consultant a lot of what I do is spent on People and Processes. If you remember the definition of DevOps that I love is from Donovan Brown, “DevOps is the union of People, Processes, and Products to continuously deliver value to our end users”. I want to keep reiterating this, continuously deliver value to our end users. I bring this up because my job as a DevOps Consultant is to delivering value to my end users. But not all of us do. My amazing coworker (@_s_hari) and I have discussions about this quite a bit. As far as I know, he coined the term and gave me his blessing to blog about it.

What is DevOps?

·230 words·2 mins
What Isn’t DevOps? # Before I define DevOps, let’s get started with what DevOps isn’t. DevOps isn’t just a title, or a guy, or a department. DevOps isn’t just automating everying, and isn’t just logging everything. DevOps isn’t dozens of alerts every day, and isn’t an on-call rotation. DevOps isn’t agile or small releases. DevOps is a mindset.

Some Tools to Help Present Git

·416 words·2 mins
I’m presenting soon on Advanced Git. I feel a lot of Developers and DevOps engineers know enough git to the job, but sometimes that’s it. I want to help people be more comfortable with the git command-line, and help alleviate some fear or hesitation in dealing with git edge cases. While researching things, I came across a few neat tools I’m using to help describe things.

Dependency Injection, Architecture, and Testing

This blog was posted as part of the Third Annual C# Advent. Make sure to check out everyone else’s work when you’re done here Dependency Injection, or DI, is a Software Architecture Design Pattern. DI is something that comes up during discussions on SOLID, IoC (Inversion of Control), testing, and refactoring. I want to speak on each of these briefly because DI touches all of these. But before I really dive into things, I want to define what a dependency is. A dependency is any object that another object requires. So all of those classes, services, and libraries that we use to build our applications are dependencies.