Overdoing the New
By the time I had started my computer games business in 1994, I had already programmed a commercially published game as an independent contractor working for a local game studio. Actually it was a four-pack of Windows 3.1 games that were sold as a single unit. And I’d worked on a previous game project before that, so in about six months, I had iterated through five unique game projects.
Each time I started a new game, I had the opportunity to improve upon what I’d done before. I’d begin with the code base for an earlier game project, and then I’d make some improvements to the code to create a stronger foundation for the next project.
Additionally, since I didn’t have to reinvent what I’d already done, I could stretch myself by taking on a little more challenge each time. For the first game project I worked on for the local studio, they already had a working prototype running on a Mac, and my job was to port it to Windows. They scrapped that project after a few weeks (for commercial reasons I believe), but the work was basically to translate some pre-existing code from one platform to another. This was my first commercial project ever, so it was great that it was an easy way to get started.
For the first game in the four-pack, however, there was no prototype. I had to code the game from scratch based on a pretty thin design doc (like 1-2 pages). I was assigned a young artist to work with, and that was the extent of our development team. It was a simple shoot-em-up game, so our tiny team was sufficient. I also had enough time to add some extra embellishments of my own, and I believe my improvements made the game a little more fun to play.
With each succeeding game project, I tried to challenge myself a little bit more. The more games I wrote, the more I could lean on previous code I’d already written, often adapting it for similar mechanics in a different game. The more code I could reuse, the more capacity I had for extra embellishments.
For the fourth game in the four-pack, I asked if I could design the game myself, and the company agreed. I kept to the minimalist standards of the four-pack, and I pushed myself to squeeze more out of the little 2D game engine I’d been developing.
By starting with a porting project, in a few iterations I was eventually able to design and code a complete game. I also did the sound effects for it.
But if I’d started with the fifth game project, it would have been too much. And it would have been discouraging too. It was so much nicer to see rapid progress through a series of completed projects, so by the time I was beginning the fifth project, my confidence was sky high. It was just another 20% beyond what I’d done before, so I knew it was achievable.
When I started my computer games business, I wrote a new code base for my first game, and it took about six solid months to develop that game because I put way more into it. Looking back, I think I overextended myself. I tried to squeeze too many new ideas into one project. It would have been better if I’d started with less ambitious project and released and iterated more frequently, like I’d done while working as a contractor. Trying to go too big too soon really slowed me down.
In fact, I made an even bigger mistake by progressing way too quickly into a mega-project that I worked on for years and had to be canceled in the end. Meanwhile, my business was starved of cashflow during that time because I had little to sell, and there was no effort being put into marketing. Going back to smaller projects with more frequent releases – and paying a lot more attention to marketing – turned things around.
Today I’m much better at leveraging the power of incremental improvements. I have a well-developed system that I use for developing and launching new courses. Each time I run through that system, I improve it. I document it more clearly. I add some new ideas, but not too many each run-through. I maintain the parts that are working, and this gives me more capacity to add a little more each time without feeling overwhelmed.
A recurring mistake I’ve made in the past was trying to add too many new ideas to a project. New ideas are way harder to incorporate than re-using previously tested ideas. For me the worst part about trying new ideas is that it’s hard to estimate how long they’ll take. The more new ideas I add to a project, the greater the risk of blowing my intended schedule.
When I’ve tried to overdo the new by incorporating too many new and untested ideas into a project, the project normally doesn’t go well. But when I assemble a project from pieces that are familiar and then add some newness on top of that, my odds of success increase greatly. And I feel more confident too.
Conscious Growth Club is a good example. When I started putting together the initial pieces for this club in 2017, the overall package was new, but I assembled it from pieces rooted in past experience, so it wasn’t overwhelming. I stuck to the core ideas first, and then gradually year by year, we’re adding more to it.
I think of each year in CGC like a new project that builds upon the codebase of the previous year. We maintain what’s working and then explore adding something new – a new feature, a new course, some new experiments, etc. The key is not to try adding too many new ideas all at once, especially if they’re complex ideas.
Consider the CGC member discussion forums. I knew I could manage that because I’d done it before. I’d previously admin’d a sizable public forum for five years, and I had a lot of previous admin and online community experience from years prior. So while we were using new software for the CGC forums, online community management is old hat to me. I was very confident that I could manage that aspect successfully, and I had the necessary mental callouses to prepare me for the experience in a realistic way.
The courses were going to be new, and that part took the longest, but I’d previously had experience with writing (from blogging and a book), product design (from my game development experience), audio (from podcasting), speaking (from six years in Toastmasters), online publishing, and marketing and selling products online. So I had a whole bundle of experiences that gave me a solid codebase to build upon. There was still a lot of newness here, but it wasn’t as daunting as starting from scratch.
For the CGC coaching calls, I had previous one-on-one coaching experience, so it wasn’t too much of a stretch to expand into group coaching calls. It’s basically a series of one-on-one coaching sessions back to back.
Wherever I need to chip away at some of the new areas, I leaned in with practice. My video practice was a bit weak, so I committed to doing a public 30-day challenge to record and publish a new YouTube video each day. I averaged about 30 minutes per day, so that was 15 hours of published video in a month. That gave me sufficient practice to get comfortable with it. I also bought Final Cut Pro and learned it use it for video editing till I grew very comfortable with it. I spent weeks transforming a room of my house into an audio and video recording studio as well. I’ve been using it for years now, but it took a long time to experiment with the lighting and setup till I liked the results.
It was just so crucial to assemble the different parts of CGC from the familiar and not try to squeeze in too many new ideas all at once. Figuring out the new parts always takes longer, but when you do figure them out, you can lock them into your codebase and reuse them efficiently.
Additionally I had to figure out how to launch and promote CGC. I started out very basic. And now each year that we launch, I can do things with a bit more complexity, including advertising. The familiar gets easier, and that frees up capacity to try some new things. I like to incorporate at least one new idea each launch, but if I try to add three or four new ideas, it could become overwhelming to get everything done in time.
Exploring what’s new can be fun and rewarding, but it’s also risky. I’ve paid the price numerous time for trying to be too ambitious with too many new ideas. Every new idea takes a lot of work to figure out, and it’s unpredictable how long it will take precisely because it’s new. A project that tries to incorporate too many new ideas is at great risk of scope creep. If scope creep becomes too much, a project could be at risk of cancellation, or it may begin to feel like a death march.
Think about where it’s important to innovate with a project and where it isn’t. If you want to innovate greatly with the content, it’s probably best to keep the format familiar. If you want to innovate greatly with the format, then you may not innovate as much with the content. If you want to innovate on both sides, look for ways to lean on a tried and tested codebase where possible, so excessive newness doesn’t overburden your project with too much risk.
Exploring the new can be fun and rewarding, but pay attention to the risks. If you’re constantly blowing your intended schedules and dropping projects before they finish, consider whether you’re trying to do too much too soon. Could you scale back to a more reasonable project that can better leverage your existing codebase of knowledge and skills, even if it’s less creative? It’s better to start with a modest success and build upon it with each new iteration than to overwhelm yourself from the start.