Tools, Not Rules

Over the past couple of years, American Express has gone through a DevOps journey. A transformation that Tim Klever was kind enough to share with us at this year’s Nexus User Conference.  From draconian rules to a state where the company was able to use the right tools to solve problems, there is a lot of interesting insights that we can all learn from. 

Tim shared both failures and successes in automation and tooling; and that’s just the beginning. The journey isn’t over!

Some Background on AmEx and Their Rules

American Express has been around for 170 years, starting as a competitor to the US Postal Service. Over time, they’ve also built a massive catalog of software.

In the beginning, there were rules. Manual reviews and processes would result in forms being sent off to lawyers and approvers. This was

• Slow
• Expensive
• Full of friction

So they brought in a tool—Sonatype! They expected quick success.

At the time – some of their ecosystem wasn’t covered, and getting organic adoption of the tool wasn’t happening as quickly as expected. 

Giving Developers a Second Job Instead of Supporting Them

Next, American Express had to determine why this wasn’t working. Surely, they’ve done all they can. The developers don’t worry enough about security! Why aren’t they helping?

But, when going through conversations like these, Klever and others realized that something was wrong. They found themselves guilty of what he calls “laissez-faire DevOps.” Leadership threw tools at teams but were missing the partnership.

If the developers are brilliant people but still not using the tools they’re given, what’s the problem?

Well, instead of helping, these new tools increased developer cognitive load and gave the dev teams additional work to do while providing no support. They failed to understand the needs of (Read more...)