Category: Leadership

No One Has It All

No one has it all. Everything costs something.

A lot of hustle-culture lifestyle business nonsense shows people driving fancy cars, being influential, spending time in beautiful places, blah blah blah. And a big part of what draws people to entrepreneurship is this idea that they too can be rich, powerful, and control their own destiny.

Most of that is bullshit.

It’s easy to forget that everything *costs* something. Building a startup consumed everything about my life for years other than it, and the time I carved out for family. And at the end of it, it cost me another five years in therapy and waking nightmares and cPTSD, and a handful of relationships I once valued. It gave me a certain level of financial independence, which is a massive visible positive (and which I never, ever take for granted), but on balance, I’d trade the latter to get rid of the former, which I know may seem weird to folks who didn’t go through it. And that’s all invisible to people. What is visible is the “success”. No one sees the cost. This is true for almost any level of any type of success.

You look at folks like Elon Musk – he’s got the adoring throngs of sycophants, and more money than … well, almost anyone else in the world. But what did it cost him? He doesn’t have great relationships (if any at all) with his children or spouses, he doesn’t have any relationships to anyone who isn’t so far up his butt that he can maintain any connection to reality. Is that a trade you’d make? I wouldn’t.

You know the kinds of folks at work who will stab their co-workers in the back and get promoted. You know the folks who work 20-hour days at the cost of their health and their marriage.

Maybe you look around and think, “How is it that this is all I’ve managed to achieve when others have done so much more?” And sometimes, yeah – you hit a rough patch and don’t make a ton of progress. But I think more often than not, what you’ll find is that the people who achieved that thing you call success were willing to pay a price that you *weren’t willing to pay*. And while hustle-culture bros will tell you you’ve gotta learn to pay that price, I have a different message for you:

Knowing what your boundaries are is more valuable than almost anything else in the world. Understanding what you will not do and why, and having the integrity to live up to those values? Yeah, it will often cost you. But in the long run, knowing who you are, and what you believe in is a really difficult, often very expensive thing to learn. That’s *character*. That’s *integrity*. That’s your *soul*.

Don’t trade it for anything.

Writing a Thing

Last year, when Eric Nehrlich was writing his (excellent) book You Have a Choice, we buddied up to be “accountability partners”. I started out wanting to write about my perspective on product development and team leadership, but I beat my head against it for a month before giving up. There was too much, it was too interconnected, and I couldn’t figure out how to make it all sensible. I ended up writing my little resume booklet.

I thought this year, I’d revise that booklet into something better – but I bounced off of that, too, because while it’s not perfect, it actually says everything I need it to say. I’m sure parts of it could be clearer, it could use a real example resume that goes from being bad to good, etc. But all the knowledge I wanted to get into it? It’s in there already. So I keep rewriting little bits of it, but I go back and re-read them, and they’re maybe marginally punchier, but there’s no new knowledge in there. So it got to feeling like I was running on a treadmill for no reason.

Tonight, my subconscious finally solved the first problem, after a year of working on it. I always feel like these answers emerge like a submarine breaking through the water’s surface or something. But it hit me:

For how to communicate ideas to a team well, read Simon Sinek’s Start With Why. Or better yet, just watch his YouTube video about The Golden Circle. It’s everything great in the book without the fluff.

For how to incentivize and structure a team & peoples’ responsibility, and how to think about motivation, read Daniel Pink’s Drive. There’s an RSA Animate thing about that book, but I found it worth actually reading the whole thing.

For how to lead a team in a really interesting way, and to harness everyone’s complete potential, read L. David Marquet’s Turn This Ship Around. The entire book is essential reading for anyone in a position of power, and it will totally discombobulate your concept of what a leader’s real role is.

Those books are not exactly my worldview, but much like the current version of my resume book, they’re also “close enough”, and the things I’d have to add to that are mostly practical examples of how to put this stuff into practice in reality.

So now that I’ve completely buried the lede, the point is this:

Those books exist. They describe most of my perspective on team leadership and product development. But there is something that I’ve found that isn’t in those books, that was spawned by my specific experience, and is deeply fundamental to how I now think about product development and communication. And I think if you’ve followed my posts on LinkedIn for a bit, this next section will be really obvious.

The book I’m gonna start working on now I think will be called Anima. The subtitle will be something like “How to solve every single problem with your product in one sentence.”

Maybe that’s too hoity-toity. I dunno. But that was the submarine that emerged from the deep. I can offload all the team leadership & most of the communication stuff onto those other books. They’re “good enough”, and unless I can contribute something substantial and worthwhile, you should just read those. The thing that I can contribute is this.

One sentence.

It’s a way to think deeply about every single bit of your product. It’s your North Star. It’s the sword you use to hack away the unnecessary parts. It’s how you empower everyone on your team.

And yeah, I know – grandiose claims. Sounds delusional. But the number of times over the years that it’s helped – and the number of times I’ve resisted doing it and failed, only to realize that not doing this process is *why* it failed – I think this is something that is uncommon in product development. And it’s uncommon in team leadership. And most important of all, I think when people think about giving a team responsibility and autonomy, this is the missing link – you can’t give people responsibility and autonomy without *understanding*, and *so frequently* when I talk to folks who are having team leadership/communication/product problems, it all comes back to this issue. That most people, most of the time, hand wave away a lot of uncertainty and lack of clarity, but that uncertainty/lack of clarity causes communication problems, prevents people from acting with autonomy, creates bottlenecks, etc. etc. etc.

So yeah. The one thing I want to communicate, it turns out, is the concept of “one thing”, and how you can totally supercharge everything you do in a startup or product development process by figuring out how to communicate what you’re doing to your customers and your team in one sentence.

Why I Can’t Be a Fractional Product Person

Over the years, the idea of a part time product-person role has come up. A fractional CPO, or something of that ilk. I have friends (and family) doing fractional CTO work, and that’s always seemed sensible to me. I *want* a fractional CPO position to work, because that’s the kind of work I’d love to be looking for.

But I’d never, ever hire a fractional CPO, and I’d recommend that you don’t, either.

I get why you’d want someone in that role. There’s some sort of limited-domain or limited-size product knowledge that you don’t have, and an injection of experience could make a huge difference. Your company is otherwise good, and the person leading the product charge currently can do *most* of the job, they just can’t quite do all of it.

But here’s the problem: The product is the business.

Yeah, you can make similar arguments that the tech stack/process is the business, or marketing is the business, or whatever. But I’m a product guy, so for me, the product is the thing. And it’s not just my bias. I think that your product is so central that the decisions you make around product will bleed out into everything else, and everything else about your company will similarly bleed into your product.

The problem with a fractional CPO is simple: They will never endure the full pain of their decisions.

Product pain comes in many forms. A consultant can be very good at solving short-term pain. But the problem is that many solutions to short-term pain cause long-term pain. And if your consultant isn’t around for the long term, they don’t consider that pain to the degree that they should.

That’s it. That’s the whole problem. But it’s unsolvable. Because no amount of intellectualizing or rationalizing how you’re anticipating that long term pain is the same as knowing that it will one day punch you in the face at the worst possible moment. Even full-time folks often make this mistake. But fractional product people are heavily incentivized *to make this exact mistake*, and because of that, they will – consciously or otherwise.

This is the central bit of your business, and an absolutely critical thing to get right. If you are having product problems, you need *full time*, heavily invested people who can fix those problems. If you can’t afford to hire a full-spectrum product person with the expertise you need, you are failing to hire one of the single most critical roles for your business, and your chances of failure will skyrocket.

I know it seems like a fractional CPO can be that boost of product knowledge you need. It means you don’t have to expand at a time when expansion is scary and expensive. But it is a bad investment. It will always be a bad investment, and the problem is that it will seem good until it catastrophically fails. Please don’t do it. You need a full-time product-focused person with the necessary expertise as a central role in your company.

Loyalty

Stopped by GDC for a few minutes this year, and one thing that was a stark contrast to when I regularly attended a few years ago was that the amount of company swag that people were wearing was 10% or less of what it was in the past.

Teams used to wear their company stuff loud & proud. I’m curious if the change is because everyone’s now unemployed, or they realize that companies aren’t their friends no matter how positively they feel about them in the moment, or both.

Probably a mix of all three. It’s a hard lesson to learn. Be loyal to people who treat you with respect. Never spend your loyalty on a company – it’ll never, ever be returned in kind.

Friends Are Terrible Co-Founders

With all the layoffs, there are going to be a lot of folks who decide that this is their chance to take a swing at being an #entrepreneur and forming a #startup. If that’s you, fantastic. Here’s the single most important piece of advice I can give you:

When you look for a #cofounder (and you should), you want to find someone whose skills *complement* yours that you HAVE WORKED WITH in STRESSFUL SITUATIONS before.

It’s tempting to start a company with people you like. I get it. But here’s the catch: if you haven’t worked with your friend & potential co-founder before, you don’t actually know what they’re like when stuff goes crazy at work. And in startups, things will be crazy all the time.

I founded a company with someone I’d lived with for a few years before. I knew them as someone who was smart, considerate, gentle, empathic, and reliable. What I discovered was instead that they were self-centered, egotistic, a terrible, borderline abusive manager, and so catastrophically flaky they any time something exploded and got genuinely difficult, the only thing I could rely on them for was to not be there when we should have been working on things together.

Starting a company with someone isn’t like being friends. It’s like being the ne plus ultra of coworkers – a comparison I like a lot more than the common “it’s like being married”. It’s not like being married. It’s like being tied together hanging off a bridge with anvils around both of your ankles. You need to work together under intense and constant pressure or you’re both screwed.

So look around. That person who was there with you when you had an impossible deadline to meet? The one who you always turn to when you have problems? The quiet person that folks often overlook who does all the actual hard shit? These are the kinds of people you want to be thinking about, not the office entertainer/fun person that everyone thinks is hilarious.

Your co-founders should come from the strongest, most effective of your work relationships. Most startups fail. And they fail for all kinds of reasons. But the most common reason I’ve seen is that co-founder relationships fall apart. Friends become bitter enemies. It’s happened to me, and it’s happened to a lot of people I know. The co-founder relationships that are most likely to succeed are the ones forged under the shared pressure of having worked together in difficult circumstances.

One Great Idea, Steal Everything Else

There’s gonna be a lot of #startups in the wake of all the recent #layoffs. The most valuable advice I can give is around really understanding that people want what you are trying to build. And that’s a long, complicated discussion. The tl;dr there is you need to validate with real users that there is actual demand for your product. Nothing else you do is more important than that, and everything you do is meaningless if you get that wrong.

BUT. That’s a long discussion. Here’s a shorter one, and it’s the 2nd-most valuable piece of advice I have.

Keep your product focused around one simple idea, and rip off everything else you can directly from other products.

Yeah, I know – this sounds like I’m telling you to just blatantly copy everything other than your core idea from other folks.

I am.

No, I’m not telling you to *ship* something that’s ripped off entirely from other sources.

Here’s the thing – you want to minimize the number of variables that you’re working with. Everything you don’t know explodes your risk exponentially. So there’s some part of your product that you can’t know – that’s the brand new thing you’re doing. Almost everything else you can likely crib from something that’s already established. And rather than innovate on it, I’m telling you to just ape it directly.

Why?

Because it minimizes risk. Let’s say you want to have a character in a side-scrolling platformer jump. Make them jump exactly like Mario. Same height, same timing, same forward distance, same air control, etc. etc. etc. Because that becomes 20 variables that you don’t need to worry about, and more importantly, you know it will feel right to your audience, because it is familiar.

Now, as you focus on your one really new idea, you’ll find that it naturally bleeds out into other things. Maybe your “new idea” is to have a game where a character can dash. That dash will affect the jump. When can it happen? How far does it travel? How does it change animations? Level layouts?

Because it interacts with jumping, it will change jumping. And as you tweak the new thing, you’ll find that you will likely also tweak the “stolen” bits. And you’ll do that enough that the starting point (Mario) will be totally unrecognizable by the end.

But if you had to tweak all the elements of dashing with all the elements of jumping and it was all unknown, you’d have a problem with hundreds of variables, none of which were set in stone when you started. This huge complexity with no constraints leads to chaos.

So start by eliminating all the variables you can by taking things that already exist and doing exactly that. Then as your new stuff comes online, experiment and evolve all the systems that you ripped off, and they’ll evolve into something new, but starting from a point where the results are known, and feel good to the end user.

By the end, you’ll have spent all your time focusing on the new thing, and by limiting complexity, you’ll actually be able to finish & ship.

Two Steps to Building Better Products

Had a fun conversation with a friend this morning, and it was sort of weirdly illuminating for me. My #productdevelopment process basically breaks down into two pretty simple concepts that are *incredibly* difficult to actually execute:

1.) Know what you’re trying to do. That is, you have to be super specific and use very precise language to articulate the one big idea that you’re building your product around. Every entrepreneur can describe their product *generally*, but I find very, very few who can do it with exacting precision. Who is your market? What problem is this solving? What is the benefit to the user? If you can do this in one crisp sentence, you’re way, way ahead of the game. But the funny thing? It’s actually less about knowing what you’re doing – most people can understand that. It’s almost entirely so you can understand what you are *not* doing, which is a boundary that a lot of entrepreneurs actually never quite figure out. Which leads to scope creep, bloat, and eventual death.

2.) In traditional product development, you might do some testing, but basically, you’re going to bundle up a bunch of stuff, release it at some point, and then either succeed or fail. For me, the goal of everything I do is “How do I disassemble that one giant ball of risk, and try to mitigate every individual piece of it as early and cheaply as possible?”

That’s it. If you want to reverse engineer almost anything I’d say about product development, it’s “Do you understand what you are trying to do, and how to make good decisions about whether or not to do something?” and “How do I make this less risky and learn earlier?”

Now, while they’re simple concepts, doing them in effective, meaningful ways is an incredibly complicated, nuanced, and product/context-specific challenge that’s new and difficult and surprising every single time.

“This Team is Great!”

Whenever I’m on a team, I think, “Man, this team is *great*. So many wonderful world-class people!” Even when there are problem folks. No team is perfect, but I’ve had a lot of really deeply pleasurable working experiences, and at almost every job, I’ve ended up making a few lasting friends.

And while I’m normally not a super outgoingly optimistic guy, I think whenever I hear, “This team is the best I’ve ever worked with!” or “This is the best team in the world!” there’s part of me that thinks, “Look, not every team is the best, how good could this one be? It’s clearly not the best in the world,” but a much bigger part of me is really happy for them.

Because a lot of teams are great. A lot of *people* are great to work with. And when you find them, they’re so joyous and uplifting and pleasurable and energizing to be around that yeah, it feels like you really can’t get any better than that.

But that comes with a downside – if this team is this good, will I ever have an experience like this again? Sometimes that can trap you in a situation that is no longer the right one for you. But the answer is, “look around”. Look at all the folks touting how wonderful their teams are. They’re *right*. They’re *all* right.

So when your team, or your circumstance, *isn’t* right for you, it’s okay to move on. It’s okay to leave a great team of (probably mostly) great people in search of the next thing for you. And you’re *probably* going to love the team you move to, and will one day think, “This is the best team I’ve ever worked with.”

New can be scary. For those of us who are socially a bit on the reserved side, it can be a really big challenge. But I think if you look out there among your peers, you’ll find a lot of people have found jobs with *wonderful* teams and excellent coworkers.

When one day you decide you need to make the leap, you almost certainly will, too.

The Obvious Solutions

In sixth grade, I watched a show on PBS about MIT’s 2.007 robot competition, and I knew that was what I was going to try do in college.

I wanted the challenge of solving some problem, building a machine to do it, and compete using both my wits and my engineering skill. And in 1997, I got to take the class and live out a childhood dream.

I love building things with my hands. I don’t do it as often as I’d like these days, but I find that that’s when I feel like my mind and body are fully engaged. Part of the challenge is figuring out the rules – what to build, and then executing in real time during the competition.

The year I took the class, the design of the competition… was terrible.

The goal was to get balls into your bin. They fell from a “waterfall” mechanism that triggered a few moments after the competition. There was a ramp from the starting position near the waterfall and your bin down to a central arena where the balls would land.

The problem with the rules is that there was one very clear, very obvious solution. An arm that would extend and redirect the balls directly into your bin was the clear answer, and the winner would simply be the person who built the fastest, most robust arm that couldn’t be deflected out of position.

That was it. The best strategy by far required zero human interaction – in fact, human interaction would make it *worse*. If you wanted to build the most robust arm, that’d take all your material and space. You’d build the strongest, fastest arm you could, and hope that you could beat everyone else to the punch. If someone built a stronger, faster arm, you were screwed, but here’s the thing – if you built *literally anything else* you were even more screwed.

I didn’t build an arm.

I decided that even though the rules had a clear solution, this isn’t what I wanted out of the competition. I wanted to build an RC robot that relied on my control, that gave me options and flexibility, where I could construct a strategy on the fly and do interesting things. So I built a little bulldozer thing with skids and wheels that could Hoover up balls into a front cage, dump them into a hopper in the back, and then the hopper could extend up from the central arena and dump balls into the bin. I could theoretically use the extending hopper to also block anyone else from dumping balls into the bin. It was really maneuverable and quite fast. I practiced any strategy I could think of over and over again.

But I knew that if I went up against even a marginally competent extending arm, I’d lose.

I don’t have strong memories of the competition or its results. I think the winner in the end was an extending arm. As for me, despite hours and hours of practice, the thing that undid me in the end was a small screw protruded from the bottom of the machine, and in what felt like one-in-a-zillion odds, when I turned off the ramp into the central arena one round, that screw caught on the ramp and “beached” the machine.

I was proud of that machine, though. Aside from the protruding screw, a mistake that was easily fixable with iteration, it was a fairly robust, well-built, flexible machine. It did what I’d hoped it would do, and I got to play the competition the way I wanted to.

And I think that there are really strong parallels to my professional career.

When I look at mobile gaming, there are lots of people who “build the arm”. They look at the current winning strategy, and think they can build the best arm.

I *hate* building arms. I’ve never done it. I’ve never believed that the next hit looks exactly like an iteration of the last hit. I’ve never wanted to work on solved problems. My focus has always been on making things that are flexible, and “broad” re: strategic options, and have attempted to wield that breadth in interesting ways.

And it’s weird – until this afternoon, I never realized *how* strong the parallel was between my experience with 2.007 and the rest of my career.

But I think that “strategic weirdness” is why I love working with a broad range of multidisciplinary people. It’s why I love working on new things. It’s why I hate the kind of “iterate until optimal” business model of highly derivative games.

Back at a job long ago, we made a bingo game, under some amount of pressure from the company that’d acquired our team. The obvious thing they wanted us to do was ape the leading bingo game, and they’d market it aggressively and hope to do something. I kept kicking the can down the road, until one day we figured out how to do something interesting with powerups in bingo, where teams could collectively bring powerups to the game, and trigger them in fun, synergistic ways.

It was a system that created a huge potential for interesting gameplay, because it wasn’t just about *your* powerups and what they’d do for your cards, it was what you could do for the *other* players on your team. It made bingo a wild cooperative team game, and the results were delightful.

The game didn’t succeed in the end. I believe it still could have, given the “possibility space” of the system we’d created. The company basically said, “Welp, dislodging players from (whatever game was winning the bingo category at the time) is too expensive.” And while I think we’d have gotten to a point where we’d have a better game and those costs would have come down, they decided to pull the plug (there’s a lot I’d say here about judgment and necessary courage, but…)

But to me, the point is that fighting the winning bingo game with a clone of the winning bingo game was a sure fire recipe for disaster. It’d have been trying to “build a better arm” when the arm you’re fighting has 100x your budget, 100x your size & weight, and is *already deployed*.

We didn’t have an option to build a better arm. We could only build something new. And I think there are some situations and companies that are foundationally only about “building arms”. They’re not for me, and never will be.

Work is many things, and depending on circumstance, you can’t always think this way. What I have is a luxury. But work, to me, is about the joy of creation, and building things with other people. The most joy comes not from building arms, but from building new weird shit with strategic breadth and the possibility of wielding that breadth in shocking and interesting ways.

And it’s weird that I’d already known that back in 1997 when building a robot for a class.

 

Hiring Fields You Don’t Understand

How do you go about hiring a game development team, if you have no experience with #gamedev?

I’ve seen MANY companies over the years, be scammed – sometimes out of *millions* of dollars, because they hired a development team that promised things that they weren’t equipped to deliver. And it’s not just game developers – on one project years ago, before I’d joined the team, they hired a team of “experienced Hollywood writers” to write the script for the game.

The work they turned in nine months later was a failure in so many different ways, it’s almost hard to know where to begin. The writing was awful, juvenile crap. It wasn’t suitable for the targeted rating of the game. It was full of racism, homophobia, and otherwise wildly inappropriate content. But it was also completely unsuitable for a game where the player-character *is the player* and doesn’t have a prescribed personality.

We had to scramble to rewrite as much as we could in the six months we had left. I ended up redoing three characters *from scratch* in that time, writing *all* their dialogue while ALSO implementing the script into game logic. It was bananas, and if we didn’t have a team of dedicated, excellent developers fixing the problems, that game would never have shipped.

But other projects? I’ve seen “devs for hire” claim experience they simply don’t have. They’d say one thing that was technically true-ish, but where the text implied something that was explicitly untrue.

And it sucks to see companies invest their valuable time and resources into a team that’s essentially scamming them.

But how do you keep that from happening, when you’re trying to hire for a discipline you *don’t understand*?

I think the best way to think of it is “How do you buy a house?” Sure, there are some folks who will buy a place with no inspection and no contingencies, and hope for the best. Some get lucky, some get very, very screwed.

But most people who have a finite amount of money and care about risk get inspections. And they have contingencies. So if you’re looking to hire a dev studio, you have to find someone with knowledge to vet that team.

I don’t know of anyone who provides that service.

But on a project a while back, I had questions about the dev team – the project wasn’t working, and the claims they were making were raising the rest of the team’s suspicions. So I did a deep dive just into their website and their LinkedIn profiles. At first blush, things looked okayish. A sort of B-grade team with experience.

As I looked closer, though, cracks started to appear. Yes, they worked on that game & have a credit on it, but as part of the IT staff. And yet that person is the “Creative Director” here. Is that fatal? No – not by any means. But as I went further, it turned out everyone’s titles and experience were … illusions. And once I realized this, it became clear what the right questions to ask were, and the whole house of cards came falling down…

Why didn’t the project work? Why were the dev team’s answers to the rest of the company’s questions so evasive? Why did things they said with certainty and confidence make no sense?

That ability to say things definitively had snowed the inexperienced entrepreneurs who’d hired them. They used a bunch of fripperous bullshit jargon to make arguments from authority to justify their awful decision-making, but those arguments fell apart the moment they encountered someone (me) with actual experience.

So, I guess my point is this, and when I started writing this post, I had no idea where it was going:

If you want a “house inspection” when you’re hiring a dev team, hire me to do it. It’ll cost you a thousand bucks, and I’ll spend a day looking into the team’s experience and bona fides. I’ve had 20 years in games, led and built multiple successful teams, and while my background is primarily in game design, I’ve worked with every stripe of game developer at every scale out there.

I’ll tell you whether the team is what they say they are, what experience they *actually* have to back it up, whether what they’re proposing makes sense, and whether you should actually work with them, or find other teams to interview.

The worst thing about this: I was thinking of two specific situations, and only later realized that two OTHER specific situations could be described exactly this way, but were even worse, I’d just blocked them from my mind at the time.

This happens a LOT. Seriously, if you need someone to validate a dev, I have even more experience than I think at finding bullshit artists, apparently.