Posts

In 2015, I made $18,000 from a 56-page O’Reilly book titled Migrating to Cloud-Native Application Architectures. Time clocked from the first word typed to publication? 40 Hours. I’m not here to sell you a magic formula. A surface-level analysis might suggest this was nothing but dumb luck. But it would be wrong. Honestly, I never sought out the opportunity to write the book. I did, however, engage in three strategic “luck creating” behaviors that I still continue.

Your technology organization cannot afford unlimited innovation. Dan McKinley coined the term innovation token to model this concept. Every organization gets a fixed supply of approximately three innovation tokens, and it can spend them on anything. As your organization grows in maturity, you might earn a few more tokens. But for the foreseeable future, the supply is fixed. How does this work in practice? Well, let’s start spending tokens: Let’s choose Elixr for our backend services.

In 2008, I believed the only way to save a critical software system was to rewrite it from scratch. I had just been promoted to engineering manager of my team, and that system was our biggest project. And it was in trouble. I knew we had made a lot of mistakes along the way. Now that I was “in charge,” I was going to fix everything. That rewrite almost failed, and I nearly got myself fired.

Today, I’ll teach you how to leverage The Slider Bar Principle to make better software architecture decisions. The Slider Bar Principle teaches us that most software architecture decisions are fuzzy rather than binary. That is, the possible choices lie along a spectrum. Understanding this principle is critical, but it’s only the first step. Using it to guide your decision-making process is the only way it can positively impact your team’s outcomes.

Great software engineering teams recognize the primacy of principles. A few decades ago, everyone wanted to visit Toyota. It had become the canonical example of a great manufacturing company. And Toyota invited everyone to visit, even its competitors. Why? Because Toyota knew that its competitors would do everything they could to duplicate its practices and tools, rather than understanding the principles of continuous learning and improvement. Toyota knew that by the time its competitors successfully duplicated its practices and tools, it would have learned and improved.

What is a great software engineering team? It routinely delivers differentiated value to its customers. It can go fast forever. It can respond to changing market conditions and move in the right direction. It can deliver software that runs on day one and keeps running on day two. Teams like this have many common characteristics, but let’s focus on two: They recognize the primacy of principles. Stephen Covey once said, “there are three constants in life…change, choice, and principles.

I remember sitting in London City Airport at 5:00 AM, watching TV through a coffee-fueled haze as the 2016 U.S. presidential election returns scrolled across the chyron. The impossible was now something I had to accept. A world that I thought I knew. That I thought I understood, was no more. A worldview that I had fortified for fifteen years, in an instant, had disintegrated. A worldview that had been instilled in me by my parents and the church in which I grew up.

It’s Day One of shipping an Atomic Essay every day for 30 consecutive days. Ship 30 for 30 gave us a recommended day one prompt, and I am here for it. So why are we going on this journey in the first place? I really needed a firm kick in the ass to get back into writing. I’ve published dozens of articles. I’ve even published a book! But it’s been a very long time since I described myself as a writer.

This was originally a Twitter thread. I’ve edited it a bit for style and format to make it a bit more friendly as a blog post. I asked my Twitter following to share with me via DM their biggest frustrations with their day-to-day developer experience. I committed to report back with a summary of everyone’s responses. Well, here’s my report! Some of their answers weren’t a surprise. But not all of them!

I’m offering online training in Cloud Native Architecture via O’Reilly’s amazing Safari platform. Several dates still have openings: September 6-7, 2017: 12:00pm - 4:00pm EDT September 13-14, 2017: 12:00pm - 4:00pm EDT October 4-5, 2017: 12:00pm - 4:00pm EDT More dates will be announced soon. Designed for software architects and senior developers working on medium-to-large scale enterprise systems, this two-day, hands-on course will introduce you to the cloud native architectural pattern language and give you practice applying it.