Two years ago, I sat in an OpenShift Container Platform boot camp to better understand container technologies. During our break, the instructor asked if we had read the yellow book, and I wondered what the shuffling around the room meant. Someone had gotten up to the front of the room to pull the book out of their bag. Yeah, Im reading it now.

Good, you should all read this book, the instructor announced. He called it the bible of DevOps. There were nods of approval. Im pretty sure I almost jumped out of my seat. Bible? Before I knew it, training ended, and I had The DevOps Handbook (by Gene Kim, Jez Humble, Patrick Debois, and John Willis) in my hands.

SEE ALSO: Setting up a secure DevOps pipeline in 7 easy steps

In a short amount of time, I came to learn about DevOps and the practices surrounding the core concept that by working together, Developers and Operations teams could drive the delivery of business value through software. I came to understand DevOps as a combination of People, Process, and Technology.

Admittedly it took me quite some time to learn how these three areas played into each other. One challenge was diagnosing the dynamics of a winning team verse a failing team. It often came down to the leadership of the group, and it shaped the teams practices and culture around people, processes, and technology.

Through the opportunities I had to facilitate and work with different teams, I was able to note critical observations and recommendations for improving DevOps practices. In that spirit, here are three lessons learned from the field for leaders on their DevOps journey.

Ive come to realize that things can go very wrong in any endeavor where the outcomes are not clearly defined and prioritized. Artifacts are significant; we produce them in design thinking sessions, feature building, and discovery sessions. Theyve often required outputs for leaders to track KPIs. They live in the form of documents, diagrams and or code. However, these artifacts quickly depreciate in value when teams misunderstand their goals.

The critical point here is not to confuse outcomes with outputs. You shouldnt run a design sprint to produce a backlog for your developers to develop off of; this is an example of focusing on the output. An example of an outcome is having your critical stakeholders, including your developers, understand the problem space to begin developing the solution. If youre running a session or event and have artifacts and checkboxes to produce, thats great. This ensures a role and responsibility to be handled. These responsibilities should be a separate agenda handled by that role.

Teams that align with the same outcome get better value and results. Accelerate is an excellent book that talks about this within organizations adopting DevOps. Targeting outcomes ensures processes involving tech and people align with your business needs.

Safe environments are essential to maintaining the health of your organization. Employees do their best work when they feel empowered. The key takeaway here is maintaining a safe environment for everyone to contribute.

If you are maintaining a healthy team, excellent, you are probably meeting your target outcomes, driving value across the organization or group regularly, and have lessons learned. Great feedback often causes a desire to further improve or experiment with current processes.

If you are struggling with delivering value and meeting your target outcomes, there are few practices to help enable learning from your team, like retrospectives. Dare to Lead is a personal favorite of mine for rumbling with conflicts and complexity within an organization.

Regardless, we can not predict chaos so, within execution cycles, its often necessary to pivot. Changing current outcomes and processes across your organization can be difficult especially concerning team morale and team dynamics. If these changes cause unmet deliverables this also lead to dissatisfaction and blame.

Some indicators of lowered team morale include feelings of frustration that things arent working, push back, and an increase of questions. Here are some tips for pivoting if you are experiencing mid-sprint or mid-execution pivots that are hurting your team:

Maintaining a safe environment will help grow a culture where individuals gain autonomy, allowing value to scale.

SEE ALSO: DevOps report card: Security must be part of the software delivery cycle

Organizations see the need to adapt and innovate to stay competitive and current in their markets. With the increased adoption and emergence of technology (there are 1,200 Cloud Native Computing Foundation projects now, wow!), team members across the organization must understand the technology landscape of your company.

Ensure documentation is current and available regarding the architecture of your application.

If you do not have any architecture diagrams, take the time to work with your team to produce, at a minimum, a big picture diagram that spans across your environments. Present this to your organization and ensure everyone understands how each tool and framework within your environment interacts.

With reference diagrams, your developers can understand the software application and point out any missing details concerning current work in progress. Getting the big picture also allows you to determine better which areas that will most benefit from the adoption of technologies.

Understanding how your tools and technologies benefit your software development life cycle accelerates your software delivery.

And there you have it. Three DevOps lessons learned about People, Process and Technology. Understanding these concepts has made me a better communicator and leader in my teams and projects, I hope it will for you too. If you are looking for more guidance on leading DevOps journeys check out this piece on the 8 habits of successful DevOps team leaders.

See more here:

DevOps lessons learned from the field: People, process and technology - JAXenter