Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
LLMs and Generative AI in the enterprise.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
New half-day virtual events with live watch parties worldwide!
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
October 27, 2022
This post is adapted from the 2022 DevOps Enterprise Forum guidance paper Measuring Leadership by Adam Zimman, Lee Barnett, Julia Harrison, Tamara Ledbetter, Dean Leffingwell, Christof Leng, Steven Mayner.
In our last past, we talked about leadership in DevOps. Now let’s look at leadership as it has changed over the generations.
The greatest change with regard to leadership is how and when leaders communicate with those they are leading. The role of a leader is to communicate a vision and goal that aligns followers with the work to be done and to listen to the needs of those doing the work to ensure they have the resources and tools to complete the task.
In 2004, members of Generation Z were under seven years old, or yet to be born, and millennials were primarily still in school. These two cohorts have since entered the workforce, and built careers, and many have become leaders working alongside colleagues of Generation X and baby boomers. They have been the first to grow up in an online and connected world, and, intuitively, their values and expectations are different from those of the generations before them. According to research obtained by the authors of this paper through GWI, 60% of people working in the tech sector now are under the age of thirty-five, and their ways of thinking have been influential in changing the ways people work.
According to research gathered from GWI in 2020 surveying 1.7 million people, a notable difference between younger generations (Generation Z and millennials) and their parents is a greater desire for meaning and purpose in their work. In a market where companies compete for key tech roles, employees want to feel inspired by the organization’s mission and be aligned with its values.
The conscious evolution of organizations from bureaucratic to generative means less reliance on processes, form filing, and leadership sign-offs to get things done. But the risks those processes were designed to manage haven’t gone away.
Source: GWI, 2020.
The requirement is clear: build more features faster and with greater stability. This requirement has prompted a change from the software-development life cycles (SDLC) from as recently as ten years ago. Regardless of the new SDLC chosen, formal leaders’ roles and responsibilities will be impacted.
Older SDLC models, like the Waterfall model, have embedded hierarchies juxtaposed to how successful DevOps teams operate. Collaboration and autonomy are key, communications are made directly to the person who needs the information and not through an organization tree. Decisions are made by the individual closest to the task, or challenge, instead of being deliberated by a change approval board (CAB).
A traditional software development life cycle might have had distinct phases for design or planning; building and testing would take place after a “hand-off” to a QA (quality assurance) team. Now, as we “shift left” and aim to catch errors as early as possible, when they can be resolved with less expense, we have methods such as test-driven development (TDD) and pair programming. However, these are highly dependent on a level of trust and psychological safety in the organization. If a pair of developers are writing code together, including automated tests for that code, they must be trusted to be capable, and they must be motivated and enabled to “do the right thing.” Moreover, if Developer A is about to introduce a costly error, Developer B should feel able to speak up and tell them, regardless of their relative seniority, tenure, membership of a dominant demographic group, or other interpersonal dynamics in the team.
Even in teams that have this capability and culture embedded, it becomes tempting to cut corners when work becomes urgent, and it may not be a conscious choice. Teams often spot potentially serious problems through information sharing, curiosity about each other’s work, and by asking questions—things that might feel like a luxury they can’t afford when put under time pressure. So it’s vital for the team to feel safe to challenge managers and leaders if they’re being pushed to deliver on an accelerated timeline that introduces significantly higher risk than usual. To avoid unacceptable risks, without reverting to bureaucratic methods, we need a culture of trust and safety.
These communication channels and the practices of safety culture have been impacted over the past two years as we all adjusted our behaviors during a global pandemic. Managers that relied on observation or the physical proximity of teams to assign tasks and observe individual contributors were suddenly blind. Teams that had successfully implemented a DevOps model were able to shift more easily. Now, after more than two years of remote working, individual workers are increasingly seeing the “leaders” they follow as the individuals that enable their success. While many managers fill a portion of this role, peers increasingly provide greater impact and more frequent touch points.
Outside of formal leadership roles, some people have an outsized impact on the moods, attitudes, and behaviors of the people around them; we call these people “culture carriers.” Like a carrier of a virus, they infect the people around them, spreading organizational culture.
This impact might be positive or negative—think of the coworker whose bad mood seems to bring everyone down or the person on your team whose presence somehow seems to raise the game of everyone around them.
An intentional culture carrier is someone who chooses to behave in a way that affects the people around them. For example, diversity, equity, and inclusion (DEI) training can highlight small things we do, usually without realizing it, that make people feel included or excluded. By making a conscious effort to behave in ways that include others, a team member can set an example that quickly spreads and becomes “just how we do things around here.” Thankfully, it’s rare to meet someone who uses this power negatively on purpose.
We also meet “accidental” culture carriers—people who bring an infectious energy to a room without meaning to, and often without knowing that they do it or how they do it. But with great power comes great responsibility. Inclusive organizations encourage people to bring their “whole selves” to work, but what if that whole self is unintentionally and frequently bringing down the team’s morale? Given the potential influence of culture carriers, it’s important that managers and leaders support these people in gaining greater awareness and greater control over what could be regarded as a minor superpower.
In our next post, we’ll look at our proposal for a new model.
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.
No comments found
Your email address will not be published.
First Name Last Name
Δ
As we reflect on 2024, we're proud to share a year marked by groundbreaking…
"This feels pointless." "My brain is fried." "Why can't I think straight?" These aren't…
As manufacturers embrace Industry 4.0, many find that implementing new technologies isn't enough to…
I know. You’re thinking I'm talking about Napster, right? Nope. Napster was launched in…