One of my personal delights is to come across new concepts and ideas that advance my professional thinking.

I’m usually suspicious of “form over substance” business books.  I’m attracted to the esoteric, favoring concepts that are meaty and somewhat hard to grasp at first. To me, the really valuable stuff is probably hard.

Two things I discovered in the past year have really got me thinking.

Amazon’s recipe for success is…..API’s?

Amazon’s success is hard to argue with.  Much has been written by the business media about their formula for success, deciphering Amazon’s culture and values such as the 2-pizza rule for organizational design (which I am a believer in, too).

This blog by Steve Yegge takes you much deeper into a seemingly arcane Amazon mandate that might have more to do with Amazon’s success than anything else.  Seriously.

I’ll tease you a bit:

So one day Jeff Bezos issued a mandate. He’s doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion — back around 2002 I think, plus or minus a year — he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.

Before you click away and read it (as you should), it’s written by a technical leader who worked at Amazon for several years before working at Google for several years. He wrote this as an internal memo at Google, trying to explain why Amazon was succeeding where Google was not in the realm of public cloud services.

The gist of the memo was that Jeff Bezos himself was resolute in requiring that every system of theirs must interact with every other system using defined interfaces (API’s).

This is profound because:

1. it meant that each team can operate autonomously of the next, maximizing each team’s agility
2. this forced the creation of a technology services catalog well before Amazon Web Services was ever launched. Amazon was Customer 1.0 of AWS “for real” before anyone else. When AWS launched it was truly prepared to satisfy the needs of its customer base, and has sustained that ability over time

These days, business and IT are inextricably linked. If you can “grok” this article, you’ll be ahead of most in understanding how and why.

Wardley Maps: peeling a very large & useful onion

I’ve been interested in, and performed, strategic planning at times in my career.

However, strategy has gotten a bad reputation, and for good reason. Most of it doesn’t work in leading companies to having success or not.

Like so much innovation, the most interesting innovation I’ve seen about strategy came from an outsider.  Simon Wardley’s experience was not from the strategy industry of consultants, MBA’s etc.  Rather, it was from his functioning (and failing?) as a leader of a technology business.

His “Wardley Maps” resonate with me because they pinpointed why my past work on strategy was flawed in ways that I couldn’t quite articulate at the time.

Here are short and long versions introducing his work:

• Wardley Maps short (19 minutes)
• Wardley Maps long (55 minutes)

Wardley’s work is like peeling an onion. You can explain Wardley Maps succinctly as “value chain meets the dimension of time & evolution”.  But I’ve spent many, many hours with his writings and I still feel like I’m only peeling the outer layers. He writes about gameplay, team behavioral types, and much more.

Grand unification

What’s really interesting is how Steve Yegge’s memo and Wardley’s writings relate to each other.

Warley has written about AWS’ success using Wardley Maps to explain why. You start to understand why Amazon’s “API edict” in Yegge’s memo was so important in unleashing their business agility.  That agility has made it awfully hard for anyone to catch them in e-commerce or cloud computing.

If you’re in the tech industry, I hope you find the time to explore and enjoy these authors as much as I have.