Westrum Breakdown Series: Sharing Risk

DevOps is a culture, not a role or technology. What is culture? Culture may be many things, but we define culture as the practices of the people. In the research of high-performing cultures, some specific traits and behaviors predict high performance. Characteristics and behaviors that nurture high trust and prioritize information flow are critical. 

Through the work of DevOps Research and Assessment (DORA), Nicole Forsgren, and many others, we know that a generative culture as described by Dr. Westrum in A Typology of Organizational Cultures predicts high-performance. This series will break down Westrum’s typology and explain practical actions to improve our culture and outcomes.

Red Flags: Shirking & Narrowing Responsibility

Today, we’re going to dive into a few ways to spread responsibility around and share risks. Before we tap techniques for this generative result, let’s first be sure we know what we want to avoid and why it’s worth our effort.

In a power-oriented culture, responsibilities are avoided or masked. The big bad obvious sign is leaders who take credit for wins and reassign blame to others for failures, often in semi-public settings to aid their power agenda. But it might show up as “Keeping your head down.” or “Flying under the radar.” 

The bureaucratic culture seeks justice in the face of failure. Justice might be delivered in various forms, from reprimands for not following processes to demotion or terminations. We can find the day-to-day signaling in phrases like, “Stay in your lane.”, “That’s above your paygrade.” or “Follow the chain of command.” What’s even more common is an overbearing concern for “stepping on toes.” Just replace “toes” with “eggshells,” and the toxicity is more pronounced. On the development team, it shows up as “That’s my module, why are you making changes?”, “Did you submit a design change approval for that?” and “QA didn’t find the bug. It’s their job to test.” 

A high-performing culture isn’t concerned with personal power, the rules, or proper procedures. Its only focus is the mission. When the mission takes priority, responsibility is embraced and shared alongside the risks. No one fears stepping on toes or others trending on theirs. They’re focused on the mission rather than using every opportunity for political leverage or defense.  

In a generative culture, every miss is a chance to learn and come out even closer to the mission’s objectives. The only response to failure is to create a new hypothesis to test by giving an account of the situation, our actions and analyzing the results.

How To Share Risk and Responsibility

At Merely, we define responsibility as acting on a commitment. It doesn’t mean doing all the work, sole decision-making authority, or being held accountable. For example, we are all responsible for creating a shared understanding of the work in a sprint. We all act on that responsibility by asking questions, sharing what we know, and talking through our uncertainties. It doesn’t matter who will do the work. Our commitment compels us to engage. We look out for each other. 

That is what we mean by sharing responsibility. Here are some ways we can share responsibility and risks. 

Model Shared Risk and Responsibility

More often than not, individuals shy away from or limit their scope of responsibility for safety. We all, especially leaders, must model the change we want to see in the world. We must not demand change with no evidence of safety. The first responsibility we can all embrace is to widen our own and share in the risks faced by the group.  

Here are some scenarios where we can increase our responsibility and share risk.

New Dev in A Dumpster Fire

So, you’re new to the team. About two weeks in, you realize you’ve found yourself smack dab in the middle of a dumpster fire. You’re neck-deep in spaghetti code, kneeling at the altars of God Classes, put to sleep by anemic models, and there’s not a single unit test to be found. 

Oh, deary me, things look bleak. You’ve got a few choices available. You could plan your exit, conform to the dumpster life, rage against the machine, or just do what you do. 

There’s no need to go on a crusade. Just do your test-driven development. Make one slight improvement to each module you touch. Write tests for each bug you fix. Just don’t try to refactor the whole damned thing. Model what you want within what you have to work with today. You don’t need to make the team feel like a failure fighting an impossible battle. Your actions, while restrained, will generate curiosity. 

The Uncooperative Marketing Team

You’re a Product Owner leading the most important new product in the portfolio. You’ve got fantastic retention and conversions from trial to paid customers. You just can’t seem to get the volume of new sign-ups your market can support. Your marketing team keeps targeting what they call decision-makers and buyers rather than your ideal customer. They don’t seem to understand that your customer is empowered to buy or is the person who will be critical to getting a decision-maker to sign off on a long-term contract. 

It’s understandable. The new product’s business model is a significant change for the company. Now, the quarterly review is up, and you’ve got a few choices available. You can evade responsibility for failing to hit your new user goal by throwing the marketing team under the bus. You could focus only on your “product” responsibilities and leave the marketing team to fend for themselves. Or, you can share responsibility and lead the conversation to focus on the mission, increase the free flow of information, and, critically, trust. 

“We’ve done well at converting trial users into paying customers and then retaining them this quarter. The team had to adapt plans quickly several times to hit our targets for these metrics this quarter.” 

“We’ve missed our target for new trial users. As the product owner, I’m responsible for the success of this product. I’ve dropped a big ask on the marketing team and haven’t prepared them well enough to drive new user growth under this novel business model. They’re an amazing team, as shown in their results for the rest of the portfolio. I’m confident we can get back on track next quarter if I get them what they need.”

It doesn’t matter if this isn’t a safe way to approach it. If you’re going to get punished, get punished. That’s what it means to lead. If taking the heat here can lead to the marketing team trusting you a little more, that’s the goal. You might then have the opportunity to invite them to join calls with prospects, customer interviews, and other coworking activities that will allow them to learn in safety. Next quarter, when they nail it, give them all the accolades. 

Create True Cross-Functional Teams

Thanks to the DevOps movement, we’re seeing more cross-functionality between IT Ops and software development. Organizations like IT Revolution have done much to advance DevOps culture. The danger here is in thinking that DevOps is merely a marriage of software engineering and IT operations. 

To maximize agility, we need to also maximize cross functionality on teams. The Scrum Guide says this: 

“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.” [emphasis added]

Elsewhere it mentions that a Scrum Team has all the skills needed to deliver a valuable increment. A feature in a vacuum with no engagement can’t be considered valuable. 

That means the Scrum Team needs marketing. Often this is done by throwing requests over a wall to a centralized marketing team or leaving the Product Owner to manage a separate marketing request. It’s often chaos. I’ve seen the same with UI/UX, product creatives, and other design-oriented needs. 

Marketing is complex work that requires multiple disciplines collaborating. Artists, writers, analysts, buyers, and marketing strategists need to come together. You can’t have all of those on your Scrum Team. The goal is to find something that will work for your organization. Maybe embed a generalist who can launch campaigns solo then refined over time by a hardy centralized team. Our only requirement is a person with the skills to drive engagement with the new feature in an increment whose primary focus is the product.  If you’re a product owner who can do this yourself, take it on. 

You can also drive cross-functionality the other direction:

• Share the responsibility of customer support. Each sprint, one team member, works the customer support queue for an hour a day.
• Share the responsibility of user-empathic QA. Each sprint, one team member, spends half their time doing exploratory testing. 
• Share the responsibility of security. Each sprint, a team member, spends a day or two doing security and penetration testing and remediation. 
• Share the responsibility of content marketing. Each month, one team member contributes content to the pipeline.

Cross-functional teams are the most concrete expression of sharing responsibility and risk. If we have to “throw stuff over the wall” at other teams, we might tempt ourselves into letting go of any responsibility. Even when throwing a task over a wall is appropriate, we must find ways to share responsibility. Even incremental steps are worthwhile in building trust, empathy and increasing the flow of information.

Incentivize The Mission & Generative Behaviors

Managing incentives can be tricky and requires some experimentation and critical review. One of the difficulties in bonus schemes tied to goals or OKRs is a predictable downturn in the aspirational quality of the objectives. This kind of bonus scheme is an incentive to move the goalpost closer consciously or unconsciously. Goals should be attainable but also inspirational and ambitious. At Merely, we don’t have these kinds of incentives. Instead, we reserve 20% of our shares for employees. Equity is a direct stake in the mission and the best way we currently see to keep our goals free of bonus pollution.

Compensation is essential and can provide little boosts, but they are short-lived. The most effective incentives are available every day. That’s immediate positive feedback on generative behaviors and actions in the best interest of the mission.

• “I admire your courage.”
• “You all handled that miss gracefully. And we now have a great plan to address it.”
• “Your experiment was insightful, and our team is going to try it next sprint.”
• “Thanks for saying no to that feature request. It was tough to hear, but staying focused on the mission is more important than short-term gains.”
• “Thanks for cross-training with me. I learned so much about what you do and how actual customers use our software!”

We can all share in the responsibility to focus on the mission and encourage generative behaviors. It’s simple but sometimes easy to miss while we’re in the weeds of creating and delivering products.

Connect with Us

We’d love to hear from you on our social channels. What are some ways you’ve come up with to share responsibility and risk? What happened, and how did it go?

Follow us and tell us all about it!