Updated: Updated: Strategy
Insanity is doing the same thing over and over again and expecting different results—this quote has been (falsely) attributed to Einstein and many other smart individuals. Nevertheless, it’s sticky and likely contains a grain of truth. It also leads us to two simple choices:
- Don’t expect different results OR
- Don’t ever do the same thing twice
I have found myself quite firmly in the second camp, largely shaped by my professional experience.
Data-Driven Creativity
Two major roles that I held for the first decade of this millennium shaped much of my professional attitude regarding experimentation.
As a mobile ads engineer I learned that being creative and being data-driven are not mutually exclusive but best go hand in hand: creativity gives you ideas for things to try and data tells you how viable these ideas really were. Some of what I considered my best ideas (and filed a patent application for) didn’t deliver the expected results and had to be abandoned. On the upshot many simple ideas were surprisingly successful in improving the mobile browsing experience for Japanese users and the company revenue.
As a practice lead in ThoughtWorks I got very early exposure to the (still widely misunderstood) notion of Agile methods. Behind this major shift in software project management lies the realization that the start of a project is also the time of biggest ignorance. The goal of a project therefore isn’t to mechanically execute to plan but rather to maximize learning early on so you can make a better plan as you go along.
Both experiences led me to a mindset of appreciating experiments as a way to continuous improvement.
Running Experiments
When people hear about experiments they either think about blowing stuff up in chemistry class (where the experiments’ predictability didn’t spoil the excitement) or about start-up companies dreaming up crazy ideas of how they are going to change the world. They might not see a good place for either in the “normal” business world.
Sadly, or perhaps luckily, most experimentation isn’t all that dramatic. It mainly means trying something new and using the results to decide a further course of action. You can experiment with a more efficient route to the office, with a new dinner recipe, or a new vacation destination. The element that distinguishes an experiment from serendipity is that you have a hypothesis that you are looking to verify or falsify based on data that you glean from running the experiment.
Curiously, the lack of a good hypothesis is what makes many so-called Proof-of-Concept exercises not very useful experiments. These activities are intended to succeed, so they’re not verifying a whole lot. I commented in my book that the best experiment is the one with the highest uncertainty (50-50). David Knott also nicely summarized the need for better proof of concepts in his excellent LinkedIn post What C are you trying to P?.
Writing Progression
The absence of work-related travel allowed me to spend more time writing in 2020 (ironically I earned Bonvoy Titanium Status and Singapore Airlines PPS Club status this year without much opportunity to benefit from it). I evolved 37 Things One Architect Knows into The Software Architect Elevator, summarized my experiences and thoughts on defining cloud strategies for customers into my like-titled book Cloud Strategy and started writing about Platform Strategy.
Most people (and many publishers) would not consider writing as something where you experiment a lot. However, self-publishing and social networks have changed the way books are written and in a way that relates closely to my professional attitude. Instead of a “big bang” release, sites like Leanpub encourage authors to release books incrementally. Social networks make it easy for interested readers to follow along and provide feedback. So, you have an ideal platform for some writing experiments.
My books these days follow four distinct stages that are optimized for low cost of early failure and receiving feedback to create a better product:
- Tweets and blog posts are the lowest cost way to gauge reader reaction to ideas and topics. They help me determine “what sticks” and refine half-baked ideas (the blog post on “Explaining Stuff” evolved into a book chapter).
- I publish my books on Leanpub first, starting with about 30% of the anticipated content and adding incrementally. I use mailing lists to solicit more substantive input while rewarding early readers with a heavily discounted price.
- Incremental updates don’t work as well with printed books, so I publish print copies via Kindle Direct after incorporating reader input and having the text professionally copy edited.
- The book may graduate to be published through traditional channels afterwards, most likely with added content and professional illustrations. This is how 37 Things evolved into The Software Architect Elevator published by O’Reilly.
This multi-step process places additional burden on the author (many releases and potential format conversions, e.g. from markdown to asciidoc when publishing) and the reader (downloading updates and re-reading revised or added chapters). However, it leads to a much more satisfying result, which makes it worth the additional effort—hopefully on both sides.
Writing Experiments
This “process” evolved over a series of experiments that are still going. Here is a small sampling of experiments that I ran while authoring my recent books:
Title
“37 Things One Architect Knows About IT Transformation” was a tongue-in-cheek working title that perhaps didn’t help the search engines, but was nevertheless accepted by early readers. The book is packed with metaphors (and The Matrix references) and the one that most stuck in readers’ minds was the Architect Elevator. Hence I renamed the book for the published version (the word “Software” was added to help the search engines – the contents targets a much broader audience than just software architects).
Sketches
I am definitely not an artist. However, I wanted to show readers that my book isn’t a dry, purely technical read, but also has a human and lighthearted side. Readers commented that they enjoyed them, so we included them in the final version, although re-drawn by a professional illustrator. I hired a gifted illustrator to do the sketches in Cloud Strategy.
Diagrams
You’ll notice that Cloud Strategy has many more architecture diagrams than 37 Things. I started adding them both as an aid to the reader but also to help me sharpen my thinking. I was following my own advice on Diagram-driven Design! (that blog post is another example of a chapter that went from stage 1 all the way to stage 4)
Contributors
Cloud Strategy includes three chapters contributed by other authors. They enrich the contents with real-life experiences and diverse viewpoints. Feedback for this experiment has been positive and I continue to include contributed chapters in my upcoming book on Platform Strategy. Editing contributed chapters ended up taking more effort from my side than planned—that was also a finding of the experiment.
Case Studies
All my books are based on real-life experience. To strengthen this aspect, I am working on including real-life case studies into Platform Strategy. Case studies generally require a series of corporate approvals, so this is certainly an experiment!
Twitter Feedback
In the past, I used Twitter mainly to promote my books. For Platform Strategy I have started to solicit direct feedback on some of the core concepts and messages. Not all comments are entirely on topic, but that’s fine because some feedback has already significantly sharpened my thinking.
As I have the ambition to write more, I am sure to come up with new experiments. Aiming for a series or a box set is one of them.
A Baseline You Need
Does experimenting mean you actually never do anything twice? How are you going to get quality and repeatability? As always, there’s an important nuance, or actually two:
- Not everything is suitable to experiments. For example, grammar and spelling are elements that best follow the rules (alas, the US style guides sometimes look like an experiment gone awry—they can’t even agree on whether “about” should be uppercased in titles). The same is true for software development and many other activities.
- Second, you can’t experiment with everything all the time. You need a baseline to compare against to determine whether your experiment yielded positive results. Actually, back in my days as an ads engineer the most competed for resource was “experiment space”, a sufficient slice of user traffic to produce meaningful results. Although not serving millions of requests an hour, writing also requires you to manage your experiment space.
Despite these constraints, I have not yet seen a space where there’s no room for any experiments.
Experimenting Is Learning
Much of what we learn is because we were taught (the boring part) or because we played or experimented with stuff (the exciting part). Learning by teaching often ends early in our lives whereas learning by experimenting continues on. I don’t want to stop learning so I likely also won’t stop experimenting.
Not all people appreciate an attitude of lifelong learning, e.g. this security guard at the Oktoberfest who was not impressed by our experiment to determine how many 1 liter beer mugs one can stack on top of each other. That’s OK—there are two simple solutions. You can have a trusted assistant carry out the experiment (in this case Carlos, who fared a little better than Beaker usually does) or, better yet, you can conduct your experiments in a safe setting. In any case, lack of appreciation should not stop you from always experimenting.
The Results
If you like to see the results of my experiments, you can find all my books on the book page.
I wish everyone a happy and productive 2021!
Make More Impact as an Architect
My book The Software Architect Elevator helps architects and IT professionals play at the intersection of technology, organization, and transformation by sharing the real-life journey of a chief architect. Buy it on Amazon US, Amazon UK, Amazon Europe
