It’s odd to think that it’s taken 15+ years of “running the show” at various teams to finally figure out what my perspective on my process is. But I think I finally have a label for it: “Inertialess Development”.

Which, sure, isn’t the most elegant phrase. But almost everything in my process has to do with minimizing the impact of change. Whether it’s stuff like describing your high level goals in a single sentence (EA’s “The X” + Simon Sinek’s “Start With Why”) or pushing as much decision-making authority down the hierarchy as possible (David Marquet’s “Turn This Ship Around” along with Daniel Pink’s “Drive”), to prototyping and testing with real users as quickly as possible (Eric Ries’ “The Lean Startup”), everything has to do with being able to adjust your course as you learn.

Most of what I’ve done over the last 15 years has been essentially exploring novel spaces. Medical VR, the early days of App Stores – in both those situations, no one really knew “what worked”, and a lot of elements of development were quite different from the logically adjacent things. App Stores and mobile gamers didn’t behave like console stores or console gamers. Medical VR required different things that traditional VR games.

In both those situations, the most important thing you could do was learn fast. And the best way to learn fast was to try a lot of things, and release as quickly as possible. The best way to do that was to engage everyone on the team – not just in their assigned roles, but to get everyone recruited to think about the product and the users.

We did a lot of testing and data collection. We worked directly with end-users. But we also exerted tremendous experience and judgment, based on those “adjacent” fields that we had expertise in. But I think the most critical thing was that we weren’t bound to a plan.

We had high-level goals. We had a fairly clear understanding of our operating circumstances ($$). But we didn’t have a Profit & Loss to manage. We didn’t have a strict development budget. We didn’t have a timeline to adhere to. Our only goal was to make progress as quickly as possible.

If anyone asked me for a plan, or a prediction, I was clear that I couldn’t and *wouldn’t* provide one. That doing so would be a significant drag on our process, and would create expectations that we explicitly *would not* work to fulfill, because doing so would be explicitly counterproductive to the development process.

My job was to make sure we understood the high level goals. That we pushed our tests to users as fast and cheaply as possible. That we threw away minimal work to minimize negative morale impact.

For building things in novel spaces, I’m totally convinced that if the only skill you & your team has is that you learn faster than anyone else, you will be utterly unbeatable. And the best way to do that is to minimize inertia. Everywhere in the process.

Just saw a post from someone on LinkedIn that said “Nothing is permanent, don’t stress too much about it.” On one hand, it’s nice-sounding advice. Situations change. But it’s also such a privileged statement, and comes from a place where someone doesn’t feel any actual existential threat to their lives that they can just ignore whatever.

Stress out. It’s fine. Sometimes shit is stressful, and it’s correct to stress out about it. And no amount of platitudes will reduce that stress because it’s real and potentially fatal if you ignore it.

Sometimes the only way out is through.

But yeah – the idea that “Nothing is permanent” and therefore okay assumes that your situation doesn’t end in permanent negative consequences, which would be lovely *if true*, but for most people it isn’t.

The reason this bugs me is that like a lot of platitudes, it doesn’t take people who don’t come from privileged backgrounds into account, and allows people to say things like, “Just relax, it’s not permanent,” to dismiss peoples’ real struggles.

I know it’s not the intent, but it is the consequence.

At a previous job, we were building a platform. One of the teams that we were working with was creating a Beat Saber clone and intended to release it on the platform. It was a shameless clone with no meaningful differences, but it would run on our platform, and I guess the idea was that Beat Games, now owned by Facebook, wouldn’t likely ever release Beat Saber on the platform. Still, it would be fun, and the audience for our platform would not just enjoy it, but it would help them.

I talked the higher-ups into killing the project.

Why? Because releasing a clone of an existing game doesn’t just populate our platform with a game that isn’t original, it devalues the entire platform. Yes, Beat Saber is fun. Yes, the clone of Beat Saber was also fun. Yes, there were some minor changes that made it work better with our intended audience. But there were *zero* gameplay changes. There were *zero* significant mechanical changes of any kind.

And if you tolerate this kind of creatively bankrupt project on your platform, you’re saying to creative folks that you don’t care about the integrity of their work, that you don’t have internal creative or ethical standards that define how you work. You tell the creative teams you’re trying to attract that you have no compunction about stealing their creative work and creating something entirely derivative, likely also cannibalizing the market for their original work.

Legal, yes, but ethically bankrupt.

If we believed Beat Saber was the right kind of experience for our platform, it’s *impossible* that Beat Saber, as it existed, with no changes, would be the best possible experience for that audience. Aesthetically, it wasn’t ideal. Mechanically, it was good, but wasn’t ideal, because it wasn’t *designed with the correct goal in mind*. There’s no question that you could make a *better* Beat Saber for the intended audience, but you couldn’t do it by shamelessly ripping off Beat Saber wholesale.

I often tell new game developers to explicitly clone an existing, very simple game that they love, and then change one meaningful part of it and see how that works. It’s a great way to learn the ropes. But that’s a learning exercise – you learn to build by repeating what someone has built. Then you learn to be creative by adding things and changing them. But that’s an *exercise*, and not a cynical cash-grab.

Yes, cloned games are easy and successful. But they come with a cost, and that cost is that people who genuinely value creativity and innovation will be repulsed by that work. If that’s something you’re willing to do, I suppose it’s entirely legal to do so. But you’re telling the world who you are, and the world is listening.

Build original things. Games are too damn hard to make. Life is too damn short. Don’t waste it on derivative bullshit.

Company: How dare you talk about money.
Also Company: Everything we do is 100% driven by money.

If a company doesn’t understand that money is a big part of why people work, then they don’t understand people, and you shouldn’t be working for them.

A company should be paying you what you’re worth. They should be proactive about making sure you’re getting paid fairly if you’re making too little (and not exploiting your lack of aggression and/or awareness). They should be giving you fair raises that outpace inflation.

If you’re an employer, you *need* to be paying people enough that at a minimum, they aren’t worried about money. That is, they shouldn’t worry they’re underpaid. They shouldn’t be under constant pressure to pay the bills. The best amount you can pay them is the amount when they just don’t think about money anymore.

But money is intrinsically a part of work. It is a critical motivating factor – often THE motivating factor for a lot of people, and that’s just reality. It’s not an indictment of their passion for the job or their personal integrity or whatever to talk about money. It’s a necessity.

If your company doesn’t like people talking about money, the thing you should be asking yourself is why? Because you’re worried there’s unfairness in the system? Because you can’t justify the CEO’s 100x multiple on an IC’s salary? Because there’s a huge gender pay disparity? Because some n00b is making 2x what your 10 year vet is making due to circumstance?

Just fix your problems, and let people talk about money if they feel the need to. If you feel a need to enforce secrecy, that should be a big honking red flag to all your employees. And is probably something they should talk to each other about.

But yeah – money’s part of work. Talking about money is part of work. Needing to get paid doesn’t make you a bad employee. If you could work purely out of altruism and love, that’d be great. It also wouldn’t be a *job*.

There are many reasons to stay at a job. But there are also many reasons not to.

I feel like some of them are obvious – your manager’s a jerk, your career path is limited, the work isn’t something you enjoy, etc. But one thing that I think a lot of people miss, because it’s not obvious at all unless you’re doing it, is that if you stay at a job for a long time, you’re going to progress, both in terms of titles and money, very, very slowly.

A friend of mine stayed at their job for something like 8 years. We started at roughly the same experience level. After 8 years, I’d changed jobs 4 times, and gone from an entry level designer to running my own team. My pay had gone up roughly 5x. Theirs had gone up between 1-3% per year, and they’d had a title change maybe once every 3-4 years, going from “entry level” to “senior”.

I’m not being self-aggrandizing or trying to brag, here. The fact is that if I’d stayed at that job, I wouldn’t have gotten anywhere near where I got. Each jump, I got a 20%+ salary increase at minimum, and a title jump + increase in responsibilities.

Yeah, it’s scary. Yeah, it’s sometimes frustrating. Yeah, you need to essentially re-establish your credibility at every job you go to. You need to interview. You need to keep your resume up to date.

Sometimes you leave a job because it’s a dead end. Sometimes it’s a bad fit. Sometimes you get laid off or the company goes under. But sometimes you leave because you can move a hell of a lot faster by doing so.

No manager will ever look out for you the way you will look out for you. And I’m not suggesting you have to be mercenary and self-serving above all else. Far from it. If you change jobs frequently, one of the best tools in your arsenal is for everyone who’s worked with you to LOVE working with you, and want to work with you again.

But one of the biggest reasons I hear people don’t change jobs is that it’s “scary” or it’s “a pain”. But would you do it for a 20% raise? That title change you’ve been wanting for years? I imagine that investment would be worth it. Companies don’t have any loyalty to you. They’ll lay you off in an instant without any regrets if they have to. They aren’t your family.

Treat them like a team. Kill it while you’re there. Watch out for better opportunities. Take them when you can.

I’ve found a weird parallel between how I learn board games and how I do product development. Some people pore over the rulebooks and want to know exactly how everything works. I’ll generally give a rulebook a quick scan, get what I think is the gist of the game, and then dive in.

I’ll often make rule mistakes, miss things, and the session can sometimes be a chaotic mess. For folks who like to have rule precision, it can often be frustrating. My expectation is that the first playthrough will be trash. It’ll be full of errors, the wrong person might win, and there might be a lot of corrections & rule-checking.

Sometimes I’ll do this first playthrough by myself, and soak up all the ways I screw things up.

If I know that the people I’m playing with can’t tolerate a giant mess, I’ll do my best to put in effort to make it right the first time.

But most of the time, I’ll just dive into that first play half-cocked and screw it all up. Why? Because it’s *much* faster to learn that way.

Trying to read rules absent the experience, it’s hard to understand what the rule-writers mean. How am I supposed to understand what this rule means without any context? Without trying to make a decision and all the associated pressures, how do I understand what the bounds are?

I find that I get a lot of pleasure out of diving into that process with a bunch of other people that don’t mind going off not really knowing what we’ll encounter, and who don’t mind throwing out that first game in the name of exploration and discovery.

Sometimes it’ll even be a few turns in, and we’ll just end up tossing out this play, resetting things, and starting over before even finishing, if it’s obvious that things have gone off the rails. And that next playthrough? It’s almost always great, because we know what we’re doing.

Here’s the thing – in my experience, even if you read all the rules – you’ll make fewer mistakes. You’ll start with a better understanding. But you’ll still screw up. You’ll still potentially make fatal errors while playing that will ruin the game. This happens enough of the time that in my experience, going in knowing you’re gonna make a huge mess is *faster* and more efficient. And as long as it’s not going to upset folks (which it has in the past for me, and in those cases it’s a mistake!!) – it can be a great collaborative exploration experience.

I often do this wrong in board games – because there’s only one manual, it’s hard to get everyone to have the same access to the core information. But in product development, that’s a huge part of what I try to do – get everyone as exposed to the rulebook as possible. And then rather than knowing everything before we start, we take a giant flying leap off a cliff together and hope we can build a parachute before we go splat.

it’s a great time. 😀

A bunch of accelerators and mentorship programs rely on volunteer mentors. There are a couple of reasons I hate this:

1.) If you’re a for-profit company benefitting from the value of folks’ knowledge, pay for it. You think that experience isn’t worth any money? You think the mentors will benefit through “exposure”? I get that the draw is supposed to be “leads” for these mentors to get a jump on investing, but that’s like saying artists are fairly compensated through exposure.

2.) It biases the kinds of mentors you get, to those that are financially secure, and likely have *always* been financially secure. Which means your mentors are going to be heavily steeped in survivor bias. But what kind of advice and perspective are most of your people going to encounter? Failure and struggle. And while almost all of the “survivors” encountered failure and struggle and then succeeded, there are *far more* people who encountered failure and struggle and then didn’t. But their advice isn’t less valuable or meaningful, and for a lot of underrepresented communities, probably contains more helpful, more relevant information for their experience – struggles that a lot of homogenous “winners” at startups *literally never experienced*.

I’ve been fortunate enough to work with an accelerator that paid a fair rate for mentors, and would happily do so again. But I’m not interested in donating my time to a for-profit structure that will rely on my good will so they can make money.