Artisanal Concatenations of Sentient Emanations

I have often said, “Good teams build products. Great teams build tools.” This has become a part of me over decades of shipping software, both good and bad. The best software I have ever shipped has included many tools for operators and intermediate users.

Over those two decades, I have also encountered a few moments of regret. One of the most frequent regrets occurred when I wished I had access to libraries and tools I had developed elsewhere. If I built a nice kernel-level memory management library in C, why shouldn’t I be able to use that elsewhere if the two companies are not competitors?

I had to throw in that last question because I am sure every armchair software developer was halfway out of their chair to demand “whaddabout competitor?!” Checkmate, dear reader. I am way ahead of you.

Setting aside the competitor issue for the moment, I just imagine needing to call a plumber or an interior decorator, and while I require their specialized knowledge and services, I do not run out and buy them an entirely new set of tools to do my job.

I am reducing this absurdity on purpose. I have not felt this particular type of regret in a while because part of what I have done over the past several years is build some software as a consultant, where I changed the underlying assumption about what I have built from a work-for-hire basis to that of a licensing model.

Part of the reason I did this was to give a steep discount to some customers who were not well-financed. Finding cheap product market fit is attractive, and I priced these projects accordingly. The result was that I built a gigantic pile of libraries for several companies, which I now own.

I have gone through these repositories a few times over the years. Some of the time I cackle and imagine I have a gigantic trove of riches. We all know this is fiction. My dragon hoard of software is not a pile of golden coins and gemstones. It is essentially a collection of half-eaten sandwiches and discarded pieces of lumber.

However, I intermittently have a library for timestamp management, database access, authentication, or similar core technology that enables me to build something swiftly.

I think there is a case to be made for software developers to build and maintain their own tools over the years. I can appreciate the IT department manager developing sweats and anxiety at an army of developers showing up with their personal laptops, fully configured to work, with access to their own code libraries. After all, a good chunk of software projects these days start with a pile of npm install instructions or similar that fetches open-source libraries from a billion places.

I exaggerate slightly and with good reason. In the era of the LLM, I can envision developers who have trained up their own AI to solve specialized problems for them. Does this not enable them to do their jobs more effectively?

I feel like I have to stop here. The world is not ready for this flavor of crazy. The IT department of Giant Mega Software Concern can stand down and move the minute hand of their doomsday clock back from midnight.

I wanted to make sure this was written down somewhere, so when this becomes normal in five, six, or even ten years, I can send links to the young peoples and leap up from my chair, pointing and screaming furiously, “See? SEE?”

I do believe a day will come when it will be normal for people to BYOT (Bring Your Own Tools) to work.

See you all next week!

Hello, everyone. I am glad to say that the majority of my move is behind, as we are down to a single-digit number of boxes left to unpack. There might be a future blog post about John’s unhealthy fixation with cardboard boxes or the wonderful feeling of removing a good percentage of your household items through yard sales, donations, and dump runs. As a matter of principle, I may want to do this every five to ten years. 

Many people ask me what I think about AI, and more specifically, AGI (Artificial General Intelligence). I have two replies. The first is that I wrote a story about how that will end. You can read it on this very blog. The second thing is that I do not think LLMs will get us there.

I think a second generation (Third generation? Fourth generation?) of AI systems will soon be coming and will have a better symbolic understanding of the data. The investment frenzy for those systems and the startup companies that create them has not yet begun.

The symbolic understanding of the data is important. The only reason current LLM systems can answer the question, “What do a fire engine and a book have in common?” is because someone typed it into the internet already. We need an AI system that spontaneously, without prompting, creates jokes with that level of cleverness. The spontaneous creation of new ideas, and eventually new science and mathematics, is the part that will tip it over into AGI territory.

Until then, everything we read from current AI systems is just a highly plausible set of words calculated from a subset of gobbledygook that humans have saved onto the Internet. Paragraphs of text read like they were written in a hurry by a tenth grader who has an essay due in nine hours, not even considering the high level of hallucinations that sometimes find their way into the output.

The AGI system that will eventually exist will combine multiple generations of AI systems and add a top-level layer of autonomy, asking, “Is this what I really think, or at least, what I really want to say?”

When two different instances of the AGI software answer Spock’s Mom’s question (go ahead and Google it if you are an unlearned heathen) in a way that makes justice systems of the world contemplate making it illegal to hit the off switch, AGI will have arrived.

See you next week.

Last week, I did not have my machine assembled, and now that it is physically set up, this week, I am not mentally set up due to all of the box ferrying: up the stairs, down the stairs, open the box, empty the box, repeat.

I promise I will resume sending you all Amazon links and industry rants next week.

I have talked to aspiring engineers about professional skills they will need that not taught in school. Some of them are technically taught in school, although they are taught poorly. Version control systems are a great example of this.

While getting the basics for fetching code, creating branches, and committing code is nice, that is not the education you need with version control software. I will use Git for our example today, although it could just as easily have been one of many different flavors of version control. Perforce comes to mind as a version control system that video game developers use because it manages large repos of game assets nicely.

The things you need to learn about version control are more related to merging code and how to deal with a repo that four or more people are actively working on, sometimes even editing the same file. This is not what you get to do in school unless you are working on some kind of capstone project. A week-long project with two or three developers does not get to the level of excruciating pain and suffering that results from four or more people actively working in tandem on a codebase. You seldom get projects with enough people, and you are not working on a project for long enough for the pain to really be felt.

It raises the question: “What is the reasonable expectation for source control proficiency for a new employee without any experience?”

The answer is: “Git proficiency is not a reasonable expectation.”

There is a moment of cognitive dissonance when a new employee asks for help with a git merge. “Hey,” You might be tempted to say, “Didn’t you submit your code sample from a git repo?” While that is a perfectly reasonable knee-jerk reaction, it is not really a good one. Merging code into a large project on a team is not the same as “one person writes a small piece of code and uploads it in a controlled environment with no one else touching it.” It is not in the same ballpark and probably not even in the same league.

You are left with two options.

The first is to buy one of them there goofy mugs with all of the Git commands written on it and to have them hunker down and “git gud.” Maybe this works here and there. I do not know if it scales well. If you want to try that, you have the Amazon Affiliate Link to buy it. I will thank you for them tasty Bezos nickels if you buy one.

The second option is to have them look at using nicely written GUI tools to do their Git management.

I am a fan of the second option. I have used Sourcetree to great effect with new engineers, technical artists, and other team members to solve Git issues. Sourcetree is reasonably good and it is free. It is also a Gateway product to Bitbucket and Atlassian products. Consider yourself warned.

Other people use Smartgit, a fine alternative. It just costs the monies.

Visual tools like this are a reasonably good and fast way to teach new hires to triage repo issues effectively.

In the long term, is this a skill you will need to be a successful senior software engineer or architect? Possibly. Some people get quite good at using visual tools to manage the repos for their whole organization. Some people need to go to the command line, possibly out of personal choice.

The point I want to make is that this is not an urgent skill to learn right out of the gate. If you do need it, maybe, in several years, you will have time to learn it. There are enough important things to learn as a freshly employed software engineer that this one is worth punting down the field a little.

Thank you for coming to my TED talk!

At least one finance person has made the jokes about GAAP and how it does not mean what a game developer thinks it means. GAAP in this conversation means Games As A Platform. Consider yourself disambiguated.

We are all watching the conflagration in the mobile app stores and eating our popcorn. The view from down here is magnificent and… big enough to see from space. What is selling today? Recent studies show many six-year-old franchises and [checks notes] Monopoly-plus-coin-master.

You might narrow your eyes and proclaim, “But whaddabout Balatro?” Or you could point at me and mumble, “Something something Palworld!” Yes, you are right. Four or five amazingly successful indie games exist out of at least ten thousand published annually.

I keep telling people every year, “Right now is both the best time and the worst time to be making video games.” Yes, that is right, I am very conflicted about this. Too bad I cannot channel that into a career making the Toktoks.

Let’s throw some more conflict on the fire. I am a gigantic fan of true player ownership of digital goods. I believe that web3 represents a possible means to this end. I am also a fan of distributing games on the open internet. That last point represents a conundrum because the best path to tackling the existing mobile dual monopoly is yet a third closed platform: The Epic Game Store. The enemy of my enemy is not my enemy. While he is still fighting the Apples and the Googles, Tim Sweeney is my favorite person in the games industry every year.

Let’s bring that back to GAAP. Roblox. Fortnite. Minecraft. Zepeto. These are a few of the names I have heard for GAAP. Roblox is presently the incumbent in this space, possessing full facilities for developers to sell virtual goods, mass adoption, and a thriving developer ecosystem. Fortnite is on its way there. You cannot directly sell your items yet, but we must believe this capability is coming. Minecraft is still unsure what it wants to be when it grows up. Zepeto is just this strange international platform that smart people keep yammering about. I am including Zepeto in this conversation out of respect for their pattern recognition skills.

So how do we know that GAAP will be so gosh-darned big?

The first thing to point out is that making games is expensive. Let’s pretend that game developers are construction workers for a moment. How much more expensive and time-consuming would it be to build a house if the construction workers were not allowed to reuse their hammers from job to job? Unreal Engine, Godot, and Unity are all engines that make it easier for people to make games; however, the production pipelines and intermediate tools made on top of them generally do not enjoy portability from game to game or company to company. This is one of the reasons that GAAP is attractive. There are already companies founded by Roblox players who have turned their passion into their livelihood. One of those games is so popular they had a toy included in Happy Meals from McDonald’s!

The creator programs for Fortnite are not far behind Roblox. They understand this is their future. It took years for Roblox to reach Seven Hundred Million Dollars in payouts to creators. In a year, Fortnite got halfway there. Fortnite is kind of cheating a little because it is paying creators out of the revenues generated by selling items and V-Bucks. I strongly believe that a real creator economy will be coming soon.

What makes this interesting is that you can make some comparisons to the dual monopolies in mobile app stores. For example, you can argue that Roblox is like Google and Fortnite is like Apple. There is some delicious irony in that last comparison.

Like in mobile app stores, a dual monopoly creates pressure to compete. Similar things are happening in ridesharing. Uber and Lyft essentially keep themselves honest with their customers. There are more disturbing comparisons to be made between ridesharing drivers and game developers, and we will choose to have that conversation later.

The last interesting point that makes me believe more firmly in the GAAP future is how hard it is to publish… anything. The Friction Is Too Damned High. This will eventually be a problem that comes to GAAP, but today is not that day. Going through all the submission processes for mobile and console games is hard. I cannot speak to the Steam submission process here because I have never done it. I see developers begging to have their game wishlisted on the socials all of the time, and it sounds like it has its very own rituals and observances.

If I started my career fresh today, I would make a game on Roblox or Epic’s UEFN. Heck, the desire to try making games for these platforms is even non-zero for me. I can feel the pull, and it is stronk.

I have declared that GAAP will be a “Next Big Thing” and might even be here in 2025. There are lots of people who believe that “something something AI” is going to be a “Next Big Thing” and are puzzled that I left it off my list. I feel like I should address this.

AI tools are coming to games, and I believe they will be here in the next few years. I also do not think they are a revolutionary change. LLM-based AI will be an evolutionary step that reduces studios’ costs. I do not think it is an automobile; I think it is a faster horse. I will let you all puzzle out what that means. If you need help, you can contact me on my socials.

On that perplexing note, I hope you all are here again next week!

I continue to earn about fifteen cents a month as an Amazon Affiliate. Whoever bought that book from my top ten last week, thank you. This week, I wanted to talk a little about “The Next Big Thing.”

The Next Big Thing is a consumer phenomenon. Once upon a time, the iPhone was a “Next Big Thing”. At one point, the internet was a “Next Big Thing”. CD Rom drives, The Nintendo Switch, and even the Commodore 64 all had their moment in the sun as The Next Big Thing.

Figuring out what will be “The Next Big Thing” is hard. I gave a talk in Seattle called “Out of Touch: The Next Big Thing After The Next Big Thing.” My thesis was that in 2014, gesture technologies were up and coming, and there were so many interesting technical problems that needed to be solved that it would not be the Next Big Thing, but it could possibly be the Next Big Thing after that. It was a fun talk, and the audience rated it highly. I do not have my slides anymore or I would share them. All I have is this great picture of me wishing I was Tom Cruise.

Now that we are in 2024, I was clearly wrong about gesture technology’s speed to market. I remember declaring that there will be a point when gesture technology will be the predominant driver for man-machine interfaces. There will be a new form of sign language that machines will use to interpret gestures, and old people like me will use an old keyboard to talk to machines. The keyboard will not be connected to anything… Some product manager somewhere will take pity on us old people and have a “fax machine compatibility layer” that will watch the gestures of someone typing on the disconnected keyboard and understand what letters are supposed to appear.

There are lots of people who think that voice is a killer app for communicating with computers. They do not have kids, and some… probably do not have a robust dating life. I do not mean to be mean about it. They just forget that sound is a lousy shared transportation medium for data. It will be hard for a room full of kids to scream commands into some online game and have them all easily understood. At the same time, you can always add more cameras if you have maxed out the ability of a machine to count wriggling fingers and elbows. An interactive application with gestures is possible at a football stadium in the same way that a voice-driven application in the same venue is not.

So now that we know that I was mostly wrong about gesture technology a decade ago, what do I think about The Next Big Thing today?

I see three things.

GAAP (Games As A Platform)

I think that this is The Next Big Thing. Roblox and Fortnite have gotten to a billion dollars in creator payouts. This is almost real money! I am also learning that other platforms exist, like Zepeto. Also, while they are currently at a disadvantage in their current market position, Minecraft can still make itself felt here. If I had to bet dollars on this, I would bet on GAAP being a significant driver for consumer game spending. I think this will double by next year in size and be the big theme for next year’s GDC (Game Developer Conference).

Augmented Reality

Right on its heels, I can see the Apple Vision Pro and similar AR devices being very real by 2026. I have some self-interest in this position. I wagered a fancy steak dinner in SF that there will be 4 million AR devices in the marketplace by 2026. I do not know what the killer app for AR will look like yet, either. No one is throwing dead presidents at me to parachute in and get feral with the device in search of its Genre Defining Hit. I do think there is a clear prosumer and urban city dweller killer app outside of games. People looking to meet in real life will use AR tools to find replacement meeting places for work or play when someone is stuck in traffic or if the place they want to meet is just too busy. There is a clear advertising model here for coffee shops, bars, restaurants, and other businesses to offer incentives via discounts or BOGO (buy-one-get-one) for consumers to adjust their plans in real-time. AR can advertise the arbitrage opportunity inside the display, and the platform can also give everyone updates on where to go and when.

Distributed Ledgers

While this is the one I am most interested in, I think this one is the furthest out. I did not call it web3 or Crypto on purpose. Grifters and bad actors have done a considerable amount of damage to the growth of this space. We are in a prolonged period of indigestion on distributed ledgers accordingly. There are many uses for tokens and distributed ledgers, and we cannot get to this future fast enough for me. Some great use cases for distributed ledgers include resource access, public spending, fund-raising, member-based governance, and voting.

There you have it. 

– 2025 will be the year of GAAP.

– 2026 will be the year of AR.

– 2029 will be the year of distributed ledgers aka web3

I will do my very best to remember to check in at the end of each of these years to see how far off I am. I do have a history of being very early to most new technologies.

See you all next week!

Happy Easter, everyone! I was trying to figure out how to write something very quickly for today and figured, “How hard can a top ten list be?”

The answer is: Very.

I am not going to finish this before the Easter egg hunt begins and the corresponding Easter wine bottle (or three) gets opened, but here we go.

I was an uneducated startup CEO in 2005 when I was trying to raise money. I was blessed with many advisors who gave me feedback on things I needed to learn to be a better CEO. I almost listened to them. Here we are, nearly 20 years later, and I have finally learned some valuable lessons about business management and fundraising.

I was a pretty cocky entrepreneur, and I thought I had it all figured out. Here is the idea. Just add money. A lot of that cockiness came from bootstrapping a few companies into existence. I was super cringey, as the kids say it, and I thought I had the rizz. The rizz is also something the kids say. A lot of VCs, and really good ones at that, took meetings with me, and I appreciate them doing so, even if I was essentially burning an hour or two of their time. I think some of them were trying to figure out how to pair me with an actual CEO and be their technical cofounder. I have some later thoughts on why that failed—largely related to my inflated sense of self-worth. We all have our own problems.

At the time I was bragging that anyone could start a company, and I was really harsh on people with MBAs. It was largely a defensive and childish reaction to people spouting, “One plus one equals three.” On at least one whiskey-fueled occasion, I came up with the idea of the Amazon.com MBA program.

It was my thesis that you could just figure out all of the crap you needed to run a startup and raise money by reading a bunch of books from Amazon. It was an absolute hit amongst my drunken engineering friends and I made a note to myself to put together a list and post it to the internet in all its glory.

Thousands of days later, here we are, and I still have not made this list. This changes as of right now. As an official Amazon Affiliate who has made Hard Cash Money for the first time, I will put together my top ten books that will help you dominate the world! At the very least, it will steal nickels from Jeff Bezos and put them in the pocket of yours truly. Every click matters! Insert the Starship Troopers “I’m doing my part!” memes. Do your part, dammit.

Without further ado, here are my top ten books, presented in no particular order:

The Power of Habit by Charles Duhigg

This is a powerful book. I used this personally to stop checking my fingernails. I use it professionally to help shape the minds of the people I coach.

The Talent Code by Daniel Coyle

The Talent Code is an excellent book. It is a primer on how to think about talent and how to shape it.

Dynamics of Software Development by Jim McCarthy

This is an oldie but a goodie. It is software development related, and it is in layman’s terms. It was recommended to me by a fantastic games producer I worked with at Digital Chocolate. It helps you think about big problems in software and how to solve them as people.

The Secret Language of Success by David Lewis

This is the first book that I read from this list. It is probably one of the two most creepy. The secret language of success is about body language and unspoken cues. It talks about the importance of how to structure your office and why I fucking hate having my back to a door at work.

Abundance by Peter Diamandis, Steven Kotler

This is probably the most important book to understand. If you cannot frame yourself as an abundant thinker, you will be forever trapped in scarce thinking and fighting zero-sum games. It is also important for you to understand scarce thinkers and how to avoid their traps.

Irresistible by Adam Alter

This is also a very dark book. There are a lot of conversations about habit forming and how social media is like nicotine for the soul. If you want to understand the motivations and dark patterns to make applications addictive, this is a primer for what to do and what not to do. I do not recommend this book to everyone.

Outliers by Malcolm Gladwell

I love Malcolm Gladwell’s books, and Outliers is really important. It gives you some guidelines on how to think about practicing your craft and the importance of repetition. There are a lot of people who misunderstand the ten thousand hours he suggests, which makes me chuckle. Some people can reach their ten thousand hours in only one thousand hours. The importance is the unfair advantages of being exposed early and often to ideas.

Trillion Dollar Coach by Eric Schmidt, Jonathan Rosenberg, Alan Eagle

This recent recommendation talks about the power of networking and connecting with highly influential people. It gives some interesting anecdotes about one of the unseen power brokers of Silicon Valley and speaks to the power of having a coach and a mentor. I strongly believe in the power of networking and the importance of mentorship.

Patton on Leadership by Alan Axelrod

Software development is war, and there are few leaders like Patton. I don’t know what else to say. This is a good book about the importance of audacity.

Term Sheets and Valuations by Alex Wilmerding

This is an awful book and a must-read. My corporate counsel recommended it to me when I was trying to learn about fundraising. You need to understand the contents of this book before anyone gives you a penny as an investor, especially if they are an institutional investor.

There are a few books missing from this list. Is this a separate list for the runner-up books in the future? Or do I violate good UIUX principles and give you too many choices?

Getting To Yes by Roger Fisher, William L. Ury, Bruce Patton

I recommend this book so everyone can learn how to do principled negotiation. I mostly tell people to read it and throw it in the trash. Most negotiations you will do in your life are against monster hardball negotiators. Win-win situations are uncommon; you must be prepared to blow everything up and walk away. Always know your BATNA.

Blink by Malcolm Gladwell

I didn’t want to put two Malcolm Gladwell books into this list, so this gets an honorable mention. Blink is all about decision-making.

The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren

This last one is me nerding out. The DevOps Handbook is a primer for how to think about large-scale deployments. You might argue the contents of this book are now dated and serverless is the future of software. I might write about this later and what the 37 signals people are learning about getting off the cloud, oops, I mean migrating to the sovereign cloud. Everyone is on the cloud because that is the destination of the information superhighway—or something.

Left out from this list is a primer on calculating the Total Addressable Market. Maybe that is something they teach you when getting your MBA. I sucked at this, and I broke the standard script for making decks. According to recent advice, about 90% of my VC pitches were dead by the second slide.

So there you have it. I would love to get a list of your must-read books and maybe add them to the Amazon.com MBA.

See you all next week!

After a half-week in San Francisco, I am back home. I just attended the Game Developers Conference (gdconf.com). I have a soft spot in my heart for GDC… I feel like I am at home when I am talking with other professional game developers. A part of me wants to sit my creaky bones down in a chair, point my cane at you all, and explain how it used to be better while shaking a fist. Once upon a time, it was in San Jose, more intimate and less Brought To You By Our Esteemed Sponsors. The Sponsors were always there, but in this day and age it feels like they take every opportunity to try and smash their logos and products into your face.

I attended half a dozen sessions this year or so. Admittedly, about half of them were at an offsite event focusing on Revenue Optimization that my company organized. These sessions felt like “The GDC of Old” to me.

I also attended two amazing sessions this week. Zac Litton put on the first of these. I had the pleasure of working with Zac indirectly during the early mobile era and from what I can read on LinkedIn, his career story looks amazing. His presentation was on engineering leadership. Some excellent ideas on how to think about your engineering leadership were presented here. I need to think about how this will benefit the engineers I work with now.

The second amazing presentation was by the ever-so-humble Raph Koster. He was celebrating 20 years of his book, A Theory of Fun. As an Amazon Paid Affiliate, I will link it to you from Amazon in my continuing attempt to wrench nickels from their profitability.

It is great to hear Raph speak for many reasons. First, my serious love affair with Ultima Online was why I pursued a game career. The second is that when I bought myself my first GDC badge, I walked up to a group of game developers talking about MMOs, and Raph was one of them. The first game developers I met were all MMO developers, and I stood there (more than a little awkward) listening to them share stories, thoughts, and anecdotes about their game launches and current live ops issues. It was quite educational. The final reason is that his presentation was a nice update to the state-of-the-art on his “Theory of Fun.” Do I link it twice? I must. You should buy this book. 

One of my takeaways from the presentation was that the “two marshmallow” experiment has been debunked. I am a little sad about this one. I use this experiment all of the time because of its cleverness. Another takeaway I shared with the audience at the end of the presentation as a comment is that we need to ensure we are bringing industry and academia together. Someone in the audience asked, “Can you make fun without formal game design training?” Raph quickly said, “No.” The audience chuckled. The real answer is “not anymore, and not for a commercial production.” When the game industry started, I think many people made fun games without any formal game designer training simply because it did not yet exist. The budgets and teams for games these days are so big that I believe it is certainly a necessity.

I attended a few other talks. I was keen to attend a talk on successful remote studios. I was irritated that one of the panelists was very excited about remote work, provided the vast majority of the team was within driving distance. It is like saying you are a vegetarian because the beef you are eating does not itself eat meat. It distracted from the presentation and diminished the overall value of the session. I went there to see if there were any new tricks I could learn, and mostly, it reinforced stuff I already knew. This is okay. We cannot win them all. I was worried I would not learn anything from this presentation because it looked like the amount of time I have remotely led teams exceeded the sum of half, if not all, of the panelists.

The final thought I want to leave you all with is that, generally, there is “one thing” that everyone is talking about each year. Usually, it is “the next big thing”. MMOs. Microtransactions. Social Games. Casual Games. Mobile Games. Mobile Games 2.0.

I did not see any of that this year. The conversations, the sessions, and the exposition floor were a shotgun blast of topics. Layoffs. Consolidation. The continued suckiness of web3 games. The fear of AI games. The continued repercussions of Apple Privacy on marketing (and subsequently, escaping from the app store).

I should rephrase that. If you stared at everything hard enough, you would see a rising conversation about the power of Games As A Platform. You have to search for it. The reason is that it has some energy similar to the AI game conversations. Minecraft, Fortnite and Roblox are a gateway product to a new generation of game developers. A hungry, excited, and amateur generation of game developers. And much like “the scary AI,” it is coming for “your jerbs.”

I predict we will see and hear more about this next year. Roblox is in a happy position of having several hundred million dollars of creator payouts that put them at the top of the GAAP leaderboard. However, UEFN paid out three hundred million dollars to creators and got there faster than Roblox got to three hundred million dollars. If you are good at arithmetic, this is now a billion-dollar marketplace. Sort of. Maybe I will talk more about that in a future week.

See you all soon!

A long time ago, I interviewed at Amazon. I interviewed there a couple of times, come to think of it, including at their game studios and hardware subsidiary. If you are interviewing at Amazon, you must read this Clearly Affiliate Linked book: The Amazon Way. It is an interesting book to read, even if you do not interview at Amazon. One of my Amazon interviews was with a part of the company that prided itself on its independence, including independence from Amazon culture. I did not know this going in, and I did My Very Best to sound as Amazonian as possible. I channeled my inner Bezos and felt I nailed the interview. I later got feedback from some of my spies that I sounded too Amazonian to fit into their culture. Whoops.

There is a lot to like about The Amazon Way. There are also parts that are less likable. One of the fourteen principles of The Amazon Way is to disagree and commit. I found this to be the principle I loved the most from the book. I was not a “disagree and commit“ employee early in my career. I was a “disagree and burn the whole fucking company down around me” employee. I did get better. After becoming older and wiser, I apologized to several people too close to the flames I created in choice moments of disagreement.

Disagree and commit is an important principle. In many situations, I have been the lone voice of dissent and have argued heartily for what I believed were the best business strategies and outcomes. Sometimes, I have been voted down with good reason. Sometimes, I have been voted down, and the cost to the business was severe. In at least one case, it was fatal.

In the case where it was fatal, I was right to disagree, and I committed to our intended (and flawed) path. I have often wondered how I could have persuaded the rest of the leadership team to adjust our trajectory. Sometimes, you do not have the tools necessary for the situation, and the best you can do is to commit to the bit.

This is GDC week. I debated writing one or two of my pending game-related blog posts. My contrarian instincts kicked in, and I wrote about my favorite part of The Amazon Way instead. Everyone will learn enough about the game industry from others for the next seven or eight days. I am even participating in an exciting event near the show to talk about what I do for fun and excitement these days. I think the event is filling up, and if you want to learn more about revenue optimization or say hello, you know how to find me on the interwebs.

Let’s get back to disagreeing and committing. This is an incredibly valuable team skill, and it is also an incredible leadership skill. While you want to put forward the best ideas, sometimes they do not land successfully on the roadmap. The best you can do in that situation is to challenge each other to understand what truly happened after the dust settles. This can sometimes take months.

Some of my earliest career mistakes revolved around holding onto my ideas too long. I should have let some of them go even when I was right. There was some karmic blowback from that when I started my own game studio. I was the CEO and held the majority stake in the business. My cofounder was in the minority. Most of the time, however, his ideas were correct. We had long debates on strategy and tactics and often took his proposed path. I could disagree and commit, even though I could have just doggedly pushed my slightly worse ideas as the decision-maker.

Right now, I am in a nice spot of being able to agree and commit. That is super easy! I always stand ready to jump into the decision-making fray and argue my position if that changes.

Learn to disagree and commit. Especially if you think you do not need to do so.

I was a Vice President of Engineering for Hi5.com, which eventually became a startup working on a social games site called Magi. It was the first time I was an executive for a company with tens of millions of users and tens of millions of dollars in revenue. It was also a sinking ship. There are many reasons why the business utterly failed, and that conversation will cost you at least one or six beers. I am in SF next week for GDC if you wish to avail yourself of this storytelling.

I confess that I agitated my peers by my conduct. I was in the process of learning to teach people to lead. I had to read that back to myself, and I am satisfied with the sentence. Mistakes were made. There are old sayings about giving people fish and teaching them to fish. I cackle maniacally when people bring up these sayings and then change the conversation to explosives and scooping fish out of the water. There are as many ways to catch a fish as there are to skin a cat. I am admittedly not certain I would try to skin a cat with explosives.

This has nothing to do with engineering leadership and the teaching thereof. Today’s metaphor is the warp core.

I am guilty of conducting high-risk social experiments on engineers and engineering leaders. Some of these experiments were well-controlled. Some were detonations visible from space. I often encouraged people to lead meetings, which was a well-controlled experiment. I would randomly and, at the last minute, appoint someone to run a meeting who had yet to do so ever. At least one person in the room knew I was not there intentionally and was merely hiding out of sight. They were there to send me a signal flare if something was going badly and I needed to intervene.

My peers hated this with a passion. “You are meddling with the warp core!” They would proclaim indignantly.

Yes. Yes, I was. I was meddling with the warp core. I look at the people who were a part of these experiments a decade later, and I will say that many of them have been forged into terrific leaders.

If you lead people, give them learning opportunities and stretch their capabilities. Do not be afraid to do this! I had given people learning opportunities by accident early in my career and have deliberately done so much later.

I am quite pleased with the results.

You should take this as an encouragement to meddle with your warp core. Traveling around the universe at a comfortable Warp Six point Five will get you there consistently if you only care about the results. Occasionally, pushing your engines to a crazy Warp Ten will tell you how good the ship is under duress. It also gives you some opportunities to find issues that need tuning in case you need to go that fast. Eventually, you will.

That is it. That is the whole post. See you next week!