When the Business Partners with Tech and They Do a Dojo

The following is an excerpt from a presentation by Aimee Bechtle, senior manager of next-generation infrastructure, and John Schmidt, director of product management at Capital One, titled “When the Business Partners with Tech and They Do a Dojo.”

You can watch the video of the presentation, which was originally delivered at the 2018 DevOps Enterprise Summit in London.

Aimee Betchle

A few years ago, Capital One embarked on a technology transformation. We started to adopt agile DevOps in the cloud. We are embracing open source, microservices architecture, RESTful APIs, and security is always a top priority.

This is a relative emotional depiction of John and me in the organization.

As you can see, there are several layers and complexity, and I’m amazed that John and I ever found each other. But when we did, we formed a partnership to help his team start their DevOps transformation.

In early 2017, my vice president sponsored the initiation of a DevOps acceleration service where we would provide DevOps engineers to the application teams to help them adopt continuous integration, continuous delivery, continuous operations in the cloud.

I’m leading this new service and been asked to help drive this transformation. I ask myself every day, as a change agent, “How can I support a DevOps transformation in an organization of this size and complexity?”

What I’m hoping today is that as we share our story about our partnership, you will take away some of those tidbits and nuggets.

Leading this acceleration service, our motto was ‘no fear releases.’

I have a new team, a new service, but I don’t have any customers yet. I had to go out and start talking to my tech colleagues to get some business.

I was surprised when I started talking to them that I was hearing,

“We don’t have time right now,”

“You’re going to have to talk to our product owner,”

“That’s up to our product owner.”

I was taken back that I kept being told repeatedly I needed to talk to the product owner.

I understand now that we’re all in on DevOps. We’re sharing a backlog, the DevOps engineers and the software engineers. The product owner is prioritizing the backlog. Having to weigh the priority of the functional requirements versus the non-functional. I had this new insight, but I also had a really narrow focus. I wasn’t looking at the people outside of my line of sight. I had to do something that was not instinctive to me, talk to the product owners and talk to the business.

I shared my insight about the product owners with my director at the time, who then arranged for me to brief the product manager’s forum that John was still leading. I prepared this great deck, filled with facts from the 2016 State of DevOps Report. I was discussing the benefits of DevOps, the service, and how my team was going to help bring humane IT to these software engineering teams.

I was surprised after briefing these product managers that I received silence and glazed over looks. There was one person though, who was listening and smiling and speaking up and asking questions. That was John.

John and I begin talking and getting to know each other, and I learn that John was facing some challenges that had not yet been solved for.

For example, the team that was working on this particular platform was well established to deliver, and extremely skilled. It was a very advanced engineering investment, but it still took three weeks at best to get a line of code from dev into production.

At this point, I want to commend John. I think it’s really hard to recognize and admit that you have anti-patterns and that it’s even harder to do something about them. That’s what he did.

Unfortunately, my presentation wasn’t what did it. What I learned was that John had visited the Target dojo.

They stood up a large facility and ran multiple teams through to help with their cultural transformation to a tech company. There, he learned about the benefits of that model and of the dojo. I had also been practicing a modified form of dojo when I was in shared solutions engineering in Card Tech, so I was also aware of those benefits. We agreed that that was a model that we wanted to experiment with for his teams and for my acceleration service moving forward. It was fascinating to see that this type of model and what it can do for a team and the whole team learning model.

Now that I’ve run several of these, I believe the dojo is the fastest and most effective way to adapt a team to an engineering culture and build accelerated expertise and DevOps in the cloud. I mentioned that our motto for the acceleration service was ‘no fear releases,’ and now our motto is ‘no fear change.’

After John and I agreed, he formed a product leadership team comprised of the product owner, the scrum master, and the tech lead. They sat together every day. We just got dev and ops sitting together, my mind is blown that now we have tech and the business sitting together! I spent about three weeks meeting and planning with them. We planned with two teams, two web APIs, 9 to 10 engineers, which is about the max that you want to go. Then this team worked together for quite a few months.

They were co-located. They had some, but limited, DevOps skills. We scoped out a six-week challenge to help upscale them to adopt CICD pipeline for different APIs that supported a federated code contribution model, where they would have multiple teams contributing code that had to be integrated into the application, and executing the same test code in both pipelines.

I had never done this model before. I was trying everything to get this plan in place but my anxiety went up. John saw that and instead of quelling it, we embraced it. John looked at me and he said: “It’s going to be messy.”

I just heard Chris Hill talk about psychological safety and when he said that I knew what that meant. John and I were creating a psychologically safe environment in which this team could transform.

This is our journey map.

We spent about nine weeks together. The first three preparing.

It was an emotional journey, and I want to highlight the two dips because these are two very important points that are probably going to be experienced with every transformation. They are points where you can either stop and quit, or decide to move forward. They’re very important points in which, as leadership, you need to decide what you want to do and if you’re going to push forward, that you’re critical in that pivot.

This particular team had been working together for quite a while, so their tech lead knew them very well. That first week after we kicked off, Week 0, the anxiety was high. They were uncomfortable. They felt exposed. They were being asked to learn skills that they had never done before.

And they were asking, “why are we doing this? It’s not broken. It was working.”

Their tech lead just looked at them and said, “You know what? It’s a leap of faith.” That’s what this team needed to hear in order to get the pivot, and we got the pivot. Then they went over the hump and they said “Ok, we got it now, we’re good. I want to get back to code and business as usual.” So, we said, “No. You’re going to meet the challenge.” And they did. By the end of the six weeks, they had reduced what was about three weeks of testing to three hours.

Afterward, I interviewed John for a blog post and he had these wise words, “I don’t think there’s any other way we could’ve gotten there. The team is truly set up for long-term success. Even now just over a year after we completed the dojo, that acceleration has only continued. It wasn’t just getting the pipeline running. It was also changing their skillset, mindset, and culture. It was a behavior change.”

We moved on. I went on to do a couple more dojos. I had some great new skills with the product owner and the tech lead. John moved onto a machine learning and data science space within our organization and started to observe some of the same challenges.

The slight difference with his team now, was that we had some fantastically brilliant people. Data scientists with some really strong technical skills, but fairly limited engineering experience and almost no DevOps experience. We’re facing a pretty steep hill. So, he thought, ‘You know what? I’m going to go see what Aimee is doing.’

We said, let’s do another dojo.

John called me and starting last November, I met with another new product leadership team comprised of the scrum master or the tech lead and the product owner. We scoped out a new challenge. This was a sharp contrast to the first team that we had worked with. It was still two teams, there was a data modeling team, and a platform engineering team for the data models. Still about 9 to 10 engineers. They were brand new, never worked together before. They were distributed across multiple locations. They had no DevOps skills and they had a pretty steep challenge with trying to adopt the CICD pipeline for a couple different machine learning models into a container orchestration in the cloud.

Because of the steep hill, we scope out a ten-week challenge. We co-located into an offsite facility. But, my team had never done DevOps for machine learning or data science. These guys had never done DevOps. It was scary. We were afraid, to be honest, and our anxiety went up. Once again, John said.

“It’s going to be messy.”

Here’s a 10-week journey map.

We hit the same first dip, what I called the ‘fear dip.’ Now, do you think if we’d said to a bunch of data scientists ‘it’s a leap of faith,’ that would have gone over well? No, we had to look at who this team was and call in the big guns. We called in an agile coach. We ran an anonymous survey and we did what was called a ‘mind mining,’ where we wanted to understand what they were thinking and what they were feeling, so we could address them.

• We had a half day of talking about what the results were of that survey.
• We started implementing team building exercises each week.
• We established norm to values with this.
• We created a psychologically safe environment.

We got through the pivot.

Then they doubled down and they started flying to learn DevOps.

I want to highlight again…

What worked for the first team to pivot, wouldn’t have worked for the second.

As a leader who wants to influence these teams, we have to understand how that team thinks, what their values and beliefs are, and adapt our approach to support them, not the other way around. Otherwise, they’re not going to listen.

As you can see, there’s a similar pattern with two dips and what I call the “Dojo Mojo Dips.” Usually, the first dip is a, “can we do this?” dip and the second one is, “When can we just get back to code and business as usual?” But, that’s not what we want. We want to commit to at least six weeks when we try to do this because it takes at least six weeks to adopt a new habit. There’s a lot of studies on this.

Even after the six weeks are over, in order to sustain this change, it will take repeated practice and continued commitment from both the business and tech. Today those teams that had their DevOps journey jump-started by the dojo and by John, are experiencing continued success. That dojo model has proved it can produce faster-lasting results even when teams have different skills, technologies, and needs.

A few things we wanted to summarize are

1. The team was able to create several reusable building blocks that will fundamentally change their ability to innovate. By ‘innovate,’ we mean test, develop new types of features, get them out into production, into the world, and get feedback from reality if these things are really resonating.
2. There’s something I like to call the ‘oops tax,’ where sometimes you might be able to get everyone together, get some temporary speed, get something in market. Then inevitably technical debt or other problems creep up and you start crashing. But with this foundational stability, safety, and resiliency of the two platforms we’ve really facilitated ongoing acceleration. We’ve had a very smooth acceleration curve.
3. Finally, the speed is real. The ability to go from weeks or in the case of these machine learning models, a very uncertain multi-month journey, to being able to get new code out there in hours, has been fantastic.

Now we want to provide you with some insight into how the business thinks.

John Schmidt

I want to start off with a quick review of what I consider to be somewhat of an ancient secret, if you want to motivate someone, you need to really understand what’s going on in their motivational framework.

Generally speaking, my perspective is most people want to be a happy camper.

In order to be a happy camper, they want to avoid bears and they want to find picnic baskets. Now, I grew up in Canada. Bear safety is an important life skill to learn at a young age. In the picnic baskets, you can imagine whatever you want, it could be intrinsic, extrinsic motivators. I personally would love to find a nice bottle of scotch and maybe an internet connection in my picnic basket. Either way, those are the two major things that you’ll need to tune into if you want to influence them.

However, it turns out, the way our brains are wired, bears are much more persuasive than picnic baskets. This may sound obvious but it’s actually something that I forget myself in many cases. I get in front of someone and I’m really excited to tell them all the benefits of this great idea I have, only to realize later that I completely neglected to address the bear in the room. Because bears are so much more persuasive than picnic baskets, it almost doesn’t matter how many awesome picnic baskets you put in front of the person you’re trying to convince. The bear will outweigh them all.

Now, I don’t necessarily know what all of your business and product management partners might be worried about, but I can definitely share with you a little bit about my bear. For that, I want to introduce the Angry Bag of Money.

That’s my bear. To me, this is what it feels like when I’ve succeeded in getting investment support. We have a good set of value hypothesis, the senior executives that are investing in us feel great, but I don’t feel like we’re not making progress fast enough. Maybe our options are too constrained, maybe we have really painful bottlenecks that are causing increasingly painful trade-off battles. Or there’s that background fear that competitors and disruptors are going to get there better or faster than us. It feels like the money has done its job. It’s there, it’s sitting on the table, and it has this look and it’s staring at me and saying, “Hey I showed up. I’m here to support you. Why can’t you go faster?”

Here’s the thing,

• Does the angry bag of money care if your code is in a Docker container? No.
• Does the angry bag of money care if they use Jenkins or Circle CI? No.
• Does it care if on Monday morning the release is out there, but it meant everyone worked all weekend and there were sever rollbacks? No.

What does the angry bag of money care about?

• Does it care about getting value to the business and to the market faster? Absolutely.
• Does it care about fast feedback from that customer and the ability to revert to previous no good state faster? Yes.

A lot of the benefits of DevOps often get framed or explained in terms of speed, but speed minus safety equals crash. While the notion of speed sounds cool, if speed isn’t paired with an appropriate amount of safety, it will inevitably lead to a crash.

When Aimee said to me early on, “no fear releases” it really resonated with me, because I thought that was key. Having that element of safety is essential for being able to go fast at a sustainable pace.

- About The Authors

IT Revolution

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.

Follow IT Revolution on Social Media

• 
• 
•