Category: Leadership

Big Dreams Bad Ideas

I’m not great at mentoring entry-level folks.

This is something that I wouldn’t have expected – I was an entry-level person once, right? Should be straightforward.

But I think the weird thing is that while the advice I have for folks is often quite simple – focus on one major idea, reduce risk wherever possible, make something much smaller than you expect and only add complexity once that simple thing is working – implementing that and understanding its value requires a *significant* amount of the kind of context that you only get from shipping games.

Every young game dev I’ve talked to has huge dreams. They want to make big, complex, ambitious things. But even moderately sized things blow up into incomprehensible complexity so fast that it becomes really difficult to learn anything from the experience other than “something somewhere went wrong.” By keeping things small & focused, you can understand the parameters of the thing you’re building, and iterate with a much better understanding of what’s actually happening.

Basically, by keeping things small & comprehensible, you’re going to learn much faster than by trying to wrangle three interconnected new systems where changing one variable in one place completely changes the behavior of the all three systems simultaneously.

The reason I’ve tried for years to get this across to new devs is that if you can get to this point quicker, you’ll learn faster. Which is beneficial, right?

But I think to some degree, learning that interconnected systems explode into incomprehensible complexity is one of those things that human brains aren’t wired to naturally understand, and new devs maybe need to crash into that wall headfirst a few times before they even understand there’s a wall there. Telling someone they need to do things a certain way to avoid crashing into a wall they can’t see… doesn’t work.

So yeah. My point, I guess, is that if you’re a moderately experienced dev who’s smashed into that wall a few times & thinks, “There must be a better way of doing this!” There is! Hit me up. I’d love to help you figure it out. gamedev

Start Small

If I could get across only one thing to most folks building brand new products, it’d be this: Start small.

It’s not a simple thing to do. To start building something small means deeply understanding the problem you’re trying to solve. You have to know what’s important to end users and what isn’t. What you need in your product that will make a difference in their lives, vs. what is nice to have. You can’t get caught up in your own ego, and your desire to make something you’re proud of, happy with, or is a full realization of whatever dream it is you have.

You have to be ruthless. You have to cut away everything that it’s vital to the core of what you’re trying to build. This is where a lot of people trying to do “MVP” make mistakes. You cannot cut away what people need. You can’t deliver a shitty version of the whole product. You need to deliver the *smallest possible thing* that *does what a user needs*. It doesn’t have to be pretty, or easy to use (unless those are rare parts of the core concept). It doesn’t have to scale or be reliable. It doesn’t have to have social invites or animated buttons.

It doesn’t have to be the whole idea. Especially for games.

But it has to have that kernel of the thing you’re trying to pitch to folks. And it has to be good enough that you can understand when you see someone use it if it’s working. So while it can be busted, it can’t be *too* busted. While it can be ugly, it can’t be too ugly. And all of that is context-dependent on what you’re building and who your users are.

But the smaller you start, the more understandable your problem is. The more understandable the user’s response will be. The more you can shrink the number of variables involved, the more you can understand the variables you kept. Every system explodes exponentially with each new variable. Too many, and even if you’re getting data, that data will be incomprehensibly complex. If you can get your thing down to *one* new thing, you’ll be able to understand the impact of that one thing. Two, maybe. Three, forget about it.

Small. Build small. Pare down your idea until it’s almost nothing. Then you’re in the right ballpark.

How to Get Better at Public Speaking & Having Difficult Conversations

One thing that’s come up in discussions with a handful of folks recently has been about presentations & talks with folks in various awkward/difficult situations. And I’m not going to pretend that I’m any good at any of this, so I hope this doesn’t come off like, “I’m awesome at this s**t, learn from me:” – more, “I’ve had some experience with this s**t, and I’ve at least shaved the most awful edges off, here’s how:”

Practice.

I know, right? Seems crazy. But over the last 3.5 years, I’ve now given probably hundreds of presentations – many are just little weekly updates, some were talks about the company’s philosophy, some were attempts at motivation – they’ve run the gamut. And I think consistently, everyone underestimates how much preparation goes into these things.

For the most part, preparing for a significant (and new) 30 minute talk in front of a team takes me about 8 hours. I’ll make a Keynote presentation as a way of “thinking it out”. Usually this comes with at least a little bit of structure – how to reinforce a point I want to drive home. What kind of visual “language” will help reinforce it, and be memorable. The slides start off all text, and over the course of development, I’ll try to replace as much text with images as possible – in part because text sucks for presentations, in part because the presence of text encourages you to just read your slides, and in part because the images just look better & are stickier.

But the whole time, every iteration (of which there are usually dozens), I’ll “walk through” the presentation, and try to think about what I’d say. I don’t generate a “script” – I think part of trying to be engaging is reacting to things, and being spontaneous. But it’s spontaneity within a structure which is provided by the slides, so you don’t forget the things you’re trying to get across.

So (hopefully) the end result feels “off the cuff”, because a lot of the actual content is improvised on the spot. But the main points are not. The overall flow is not. This goes for presentations to large groups, and it also applies just as much to difficult conversations with individuals, though those don’t usually involve a Keynote presentation.

One thing to note – I think the bulk of the “work” building presentations is figuring out the correct order for content. Getting the ideas in the right order can have a huge impact on how it’s all ingested by the viewer, and having a flow to your presentation that makes sense takes a lot of iteration and practice.

If you’re going to have a difficult conversation with someone in a work environment, HAVE NOTES. Practice. If you need to, practice WITH SOMEONE ELSE (if they’re in the position where you can talk to them about the issue you’re having with whoever). These conversations are always insanely difficult, and it’s very difficult to get your points across in a clear, coherent, and memorable way if you do it all off the cuff. The other person’s reaction and emotions will pull you WAY off your “plan” – but having a plan means you have something to come back to. Practicing with someone else means you can anticipate some of the things that won’t go to plan and have another plan.

Anyway – the point of this is that for me, the way I got through these things – presentations, difficult conversations, etc. – is practice. Is planning. Is preparation. Is iteration. A 30 minute presentation may feel like it doesn’t require much forethought, but if you’re talking to a team of fifty people, consider what that costs to the company in time and money, and then invest the time preparing accordingly to make it worth their while.

Pain is the Mind-Killer

I got a terrible case of plantar fasciitis a few days ago. Standing up felt like someone was stabbing a ragged knife deep into my heel, and every step was blinding agony. Even lying down off my foot, the base level of constant pain kept it constantly in the foreground of my mind. Stretching, shoe inserts, and painkillers have made things better, fortunately, but one thing I observed was that over the course of the last 36 hours, my worldview shrank considerably.

That is, so much of my mental attention was focused on the pain, and trying to avoid it, mitigate it, whatever, I literally couldn’t pay attention to anything else. I couldn’t read things and understand them properly. I couldn’t make plans. I couldn’t respond with thought and consideration when someone asked me a question. I don’t think it’s an exaggeration to say that something like 80% of my conscious mental bandwidth was thinking about pain 100% of the time.

I am lucky in that I’m not in chronic pain. This was a temporary condition and appears to be improving. I feel like my worldview is opening back up. I don’t know what it’s like to live with chronic pain, but it felt like the world “closed up” in my mind.

The other parallel I have is with learning new things. When I first went to a trackday, I couldn’t “see” the track. I was laser-focused on whatever was right in front of me, because everything was happening at speeds I’d never dealt with before. As I got more comfortable, I could then begin to better see other cars, further down the track, etc. But at the very start, if you’d asked me what kind of car was right in front of me, I don’t think I could have answered you correctly because so much of my mind was occupied by “WTF is even happening???” It was like that with the pain. All I could focus on was what was literally right in front of me, and even then, just barely.

I don’t have any deep insight here, other than I hope to be able to be more forgiving and thoughtful when people who are experiencing this sort of thing need accommodations in the future – not just for the pain, but the impact it has on ones’ ability to interact with literally everything else.

One Tool to Make User Testing Actually Work

Call your shots.

I say this over and over. Every time I say it, it’s because I see someone rationalizing away some result that they didn’t want with the explanation that, “No one could have predicted this,” or something like that. And it’s frustrating, because every time I’ve seen some leader say, “No one could have predicted this,” there’s a bunch of people on the team – boots on the ground – that are like, “We *did* predict this. We told you exactly this would happen.”

And yet, because no one put it in writing, no one planted their flag in the ground, the leadership goes, “Yep. Our decision process was correct, we’re smart, but there was no way to see this thing coming.”

Without things in writing, it’s easy to handwave them away. It’s a gut-level reaction, and something that a lot of people consider positive, because it’s a way to “not dwell on the past” and “move forward”. But it’s also a really spectacular way of *not learning*.

So for me, when faced with a fork in the road – some decision that either I need to make and be accountable for, or a decision someone else needs to make & is asking for my input – I write it down. I say what I think will happen and why. I try to imagine what will happen if they do something else, and describe that as well. I talk about the circumstances, my assumptions, and what kinds of things would change the outcome. And I give it to them in writing.

It doesn’t magically fix things. Your boss (or whoever) will still handwave things away. They will still say “No one could have predicted…” even after you remind them of this thing that you wrote and sent them *before* the decision was made. You will need to remind them of this in a graceful way that absolutely is not, “See, I told you so!” But you want to be firm and say, “This is what I predicted, this is what happened, here’s why when we come to this kind of crossroads again, I’d love to help you understand the potential outcomes.”

It’s a slow process. But this does make progress. It helps build your credibility. It takes time, it’ll be frustrating. But it’s also so much better than hearing the folks in charge behave as though this information never existed, and it’s the only way I’ve found to actually make positive change.

Sometimes you’ll be wrong. Own it. But always call your shots.

What Work Looks Like

When I left my last job, I thought, “Boy, I’m glad I’m not going to have to figure out what ‘work’ looks like after the pandemic.” But I’ve now got a potential opportunity, and have to actually at least give this some serious thought.

For me, there are a few things that I’m certain of:

* It’s not going to be 40-hrs a week in an office. Never. No chance.
* It has to provide enough flexibility that anyone can go pick up their kids at school, or attend whatever events they need to.
* Periodic in-person time together, and the riffing on ideas that comes from that, is an important part of the early phase of product development.

So no daily commute. Maybe one weekly. Probably not folks who are spread across the countries & time zones, at least not yet. Some overlapping guaranteed hours, but with the goal of providing a lot of flexibility.

For me, the thing I *love* about work is bouncing ideas around and seeing them get better. Creating memories with people I enjoy spending time with. The satisfaction of seeing the business engine start to crank, and seeing players enjoy what we’re building.

I think that for me, work is likely “nearby enough to meet once or twice a week, but mostly remote”. I don’t yet know the details of what that means, but what are your thoughts? I know a lot of folks who’ve gone fully remote and love it. Thoughts? Would you ever consider even partially co-located work at this point?

Startup Advice

Running a #startup for the first time? Here’s a few bits of unsolicited advice from someone who’s been there a few times. Most of this is relevant to software development – there are some things that can be different working with hardware or other things with longer lead/iteration times.

1.) Secrecy doesn’t matter. Until your product is successful, it’s not worth it for anyone to care about it. If you’re pre-product/market fit, you shouldn’t hesitate to tell anyone you think can help you what your idea is. Don’t bother with NDAs. Don’t bother with patents. Nothing will protect you better than speed. Secrecy and speed work against each other.

2.) Don’t worry about competitors. You may hear of someone doing something that on paper sounds exactly like what you’re doing. That’s fine. It’s easy to get scared off of a concept when this happens, because you’re worried about losing first-mover advantage. But in most things, first-mover advantage doesn’t actually exist. And literally everything I’ve ever worked on – someone’s out there trying to do something similar. But it’s never *the same*, because no one has the experience and perspective that you do, so if you’re trying to solve someone’s problem, you’ll do it in a different way than anyone else. And those differences are what will differentiate your product, not the high-level thing that your product is doing. So if you’re working on a tool that auto-annotates meetings and follows up with important tasks, and you hear someone else working on something that sounds similar – don’t sweat it. Your products will almost certainly be totally different, and prioritize different things.

3.) No, really – don’t worry about competitors. Early on, some folks do a lot of “competitive research” to figure out the features your product needs to have before launch. If you’re doing this, you’ve already lost, because you’ll always be months, if not years behind the competition. All you need to do is focus on the problem you are trying to solve for a particular audience, and understand what that specific, small audience needs to have a great experience. Stuff that already exists that you can see in your competitors’ products? They’re basically “solved problems”. If you’re building something new, you have “unsolved problems” that you absolutely need to address first.

4.) This is the tough one, because very few people know how to do it correctly. But prototype fast, and test with real users as soon as you humanly can. And I don’t mean “build a shitty version of your thing” or “build something janky and busted that doesn’t do the right thing.” Building a honest-to-goodness minimum viable product that will *answer the questions you need answered* about whether you’re building something someone desperately needs – that’s a very tough challenge, and it’s *very* specific to your product, what you know about your audience, and what you don’t. There is no boilerplate answer for “what features are necessary for an MVP” that you can steal from someone who’s done this before. It requires deeply understanding your potential audience, and deeply understanding what you’re trying to do, and then finding out what you don’t know in order of “biggest risk” on down.

In addition to the base complexity of trying to understand what a real MVP should contain, you’re also fighting everyone’s existing process, training, and how they evaluate whether something is “good” or not. By most metrics, MVPs will be “bad” products. They shouldn’t be robust. They shouldn’t be pretty. They shouldn’t scale. (Of course, those statements can be wrong if your product specifically is focused on one of those areas, and for some reason that’s the thing you need to get answers about.)

Great artists are great because they make great art. Great engineers are great because they write great code. By whatever definition great is in your field. But a great MVP is evaluated by if you’re getting great, actionable, understandable *information* from your target audience. The information doesn’t even need to be *positive* for your MVP to be doing a great job. If you are learning things you didn’t know before, and couldn’t have known before, then your MVP is doing a great job!

It’s a way of thinking of greatness that is surprisingly counterintuitive, because you will feel bad about showing it to people (because it’s not “great work” by a traditional definition) and you will often feel bad about the data you get back (which is that your first iterations of your MVP are showing that users are NOT responding to your product the way you thought they would).

But imagine if you’d spent three years working on that product, and *then* users didn’t respond the way you thought they would. Then your company would be dead. So if you’re learning, and creating actionable data, and gaining a better understanding of your audience and product, the MVP is doing its job.

Learning fast is 100% of a startup’s job in the early days. Every decision you make as a #leader should be geared toward maximizing how fast you can learn. Usually that means maximizing iteration speed and minimizing risk (which can mean building infrastructure that doesn’t feel like “product” at first!), so that you can learn quickly.

If you’re doing this for the first time, and this all sounds wrong to you, DM me. Let’s talk. Because *so* many startups make the same mistakes – they keep things under wraps. They spend years building before showing anything to anyone. They trust their own judgment and insight. And then they launch and are dead in months.

There is no more expensive and wasteful mistake than building the wrong thing. Learning fast with real users is the absolute best way to make sure that doesn’t happen. It may be the only way.

Leadership & Counterintuitiveness

When you’re in a position of leadership, there are a lot of things that feel counterintuitive. A lot of your “natural” responses will be wrong.

When something goes wrong, you may get upset, frustrated, or angry. This was “fine” when you were an IC, but *fatal* when you’re a leader. This trains people to not tell you when things go wrong, and every single time it happens it will have ripple effects that will last for years.

Take a breath. You don’t need to solve this instantly. If you need to, try, “Thank you for telling me this. Give me a second to digest things before we move forward,” then take a walk around the block, or scream into a pillow behind closed doors, or whatever. But your public-facing response, and your response to the person who told you whatever catastrophic news is positive, grateful, constructive. Because you *want* people to come to you with bad news, from small bad news to company-destroying catastrophic news. And if they’re scared of your response, they’ll hide bad news from you until it’s too late. So even if you can’t do it in “real-time”, ask for a moment to process things, go freak out in private, and then come back ready to solve problems.

This is hard to do. You will fail at it, and freak out in public. That’s alright. It happens. But do your best to keep your responses in check, because this is genuinely one of the most important things you can do as a leader – be open and positive and constructive when you get terrible, terrible news from your team.

This doesn’t mean you can’t hold people to account. It just means that you do it *after* you’ve addressed the immediate crisis. Because often the problem isn’t quite where you think it is, and the problem is rarely with the messenger.

So yeah – that’s the big one, but the obvious one. For one that’s weirder and less obvious (and will make you a bit paranoid until you learn to live with it)…

When you tell jokes, people laugh. This is feedback that tells you you’re funny! People like you! You should tell more jokes!

But laughter is sometimes a genuine response to humor… and sometimes it’s a social signal that you’re in the in-crowd. Yeah – people are laughing not (just, maybe?) because you’re funny, but because you have *power*. And it’s really easy to overlook this, because it *feels* good. People listen to you. They pay attention. Because you have good ideas, and are charismatic… and(or?) you have power.

You feel validated in speaking up, because people listen. They respond. They laugh. So you speak up more. You interject. The feedback encourages you to do more.

But a lot of this feedback is social validation of your *power*, not (just?) the quality of your ideas or humor.

What do you do about that? Nothing. Just keep it in mind. Question whether you need to talk or not. Whether the positive feedback you’re getting is because your ideas are good, or because you happen to be up in the hierarchy. If that’s all you do, you’ll do a better job than most.

Good Managers, Bad Managers

One thing that I’ve found over the years is that almost all good managers I’ve worked for or with, didn’t learn from good managers. They learned how to be good managers by having bad managers.

While it’s easy to understand how being managed by someone awful would teach you what you don’t want to do when you have the chance to manage others, it’s a little un-obvious why having great managers wouldn’t teach you the things you *want* to do when you have a chance to manage others.

The main problem is that when you’ve been managed by great people, you don’t get yelled at. You never feel what it’s like to be humiliated in public. You get a chance for your career to develop, and you often don’t feel the unjustness of being passed over for something you genuinely deserve. There’s a lot of things like that. When you’re managed by someone good, these things happen, and they feel natural. They often don’t feel like someone’s put in a ton of work to make those things happen. You don’t see the effort they put in to remain calm, to ask “why” instead of lashing out, to build structures that are fair and responsible and foster growth.

And so when someone who’s never had a bad manager then gets a chance to manage folks, they can be frustrated when things go wrong and lash out. Why did (underling) screw up?!? Why weren’t they paying attention?!?! And while there are some folks who are observant enough to have understood that a great manager walked them through some of *their* mistakes, I’ve found that a lot of folks don’t understand the work that made their experience great.

So they respond with emotion. They nitpick. They think career progression “just happens”. They promise their managers work that their team is underequipped to do. They manage up, because that’s what got them here, and they didn’t see the work that was required to manage down.

Someone who had a terrible boss? Well, some of them get into power and say, “My turn.” Those – those are the absolute worst. But they’re also obvious. Having a bad manager who only ever had good managers? They can be *super confusing*, because their behavior makes almost no sense. They seem to want the right things, but are just incapable of actually doing them.

This pattern has been so consistent for me that I hesitate to hire someone who *hasn’t* had a garbage manager at some point in their career. And I don’t honestly know if I’ve ever worked (above OR below) a great manager who didn’t have someone looming in their past that they didn’t like.

What’s your experience been?

teamwork management

Inclusivity

Every society that becomes more inclusive becomes better at stuff.

It’s not rocket science. The more people you empower, the more likely you are to find brilliance. If you exclude women, you cut 50%+ of the population, lowering your odds to find brilliance. If you make your workplace hostile to people of color, queer folks, etc., you dramatically lower your odds to find brilliance.

It doesn’t even really matter *how* you define brilliance, unless to you, brilliance is literally homogeneity. Your odds get way worse. If you’re a company trying to live on the cutting edge of anything, where the number of people who can make outsized impacts is already relatively limited? You’re *dead*.

Globally, look at all the repressive regimes across the world that exclude huge swaths of their populations. How many are leaders in innovation? None.

So if your company isn’t providing opportunities at ALL levels for everyone to be engaged and contribute and lead, you’re trashing your opportunity to be the best organization you can be.

There are tons of *other* reasons that building a representative/diverse/welcoming/inclusive organization matters. But if you want a simple argument? It’s just a numbers game.

Every person you exclude is an advantage you’re handing your competition.