Author: helava

Pain

There’s a bunch of studies about pain that show that the intensity of your recollection of how painful something was isn’t about the maximum pain you felt, it’s about the *last* pain you felt. A surgical procedure that goes on longer, with *higher* maximum pain, is recalled as though it was less painful if a superfluous low-pain thing is added to the end of it.

I’m hearing a lot about folks who were let go from companies after long tenures in terrible ways. Cut off from their communities without a chance to say goodbye or get closure or grieve with friends and teammates.

So add on that low-pain thing at the end. Find the people you want to say goodbye to and say goodbye. Organize a last lunch, or a small get-together. Reminisce and grieve and cry and laugh and whatever. Make that your last memory.

My last three jobs have ended in ways that were painful, and I was never able to get any kind of proper closure. You may want to walk away and never see your team or be in that environment again after having been treated poorly, but you have a choice how to end things for yourself. A little bit of effort to put a nice bow on it, and a great side effect is that your long-term perception of how badly things “actually” ended will be significantly reduced.

Read Only Memory

I picked up a book by Read Only Memory – a beautiful retrospective on the Dreamcast – and it’s a delightful trip down memory lane. The DC remains one of my favorite consoles, and it’s the only “classic” console that I regularly play.

Not only that, but some of my very best friends to this day were from my time working on Seaman, and from a DC-focused online message board from the era.

From that perspective, the Dreamcast has had a surprisingly significant impact on my entire life, and earned a meaningful place in my heart.

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

Vision Pro?

I’m definitely interested in the Vision Pro. And I say that as someone who’s been a VR enthusiast since the Oculus DK2 and someone who spent a few years making a VR product for healthcare, but *not* a fan of Meta and their “leadership” in the space. It’s been great that they put a tremendous amount of money into trying to build out a VR ecosystem, and a lot of absolutely brilliant people have worked under Meta’s umbrella. But Zuckerberg’s obsession with “social” as a driver for *VR* is about as big a mistake as I’ve ever seen at that scale.

I’d love to have seen someone with that kind of $ work on VR as a great “transportative”, isolating experience, which is what VR does extraordinarily well.

While Vision Pro’s price is obviously limiting, it’s clear that this is a “top-down” approach that I think is likely to work. And it’s likely to work because VP offers a competent, usable AR *work* device, where the Quest Pro/2 have been limited by their screen resolution and comfort, and their general … “social-first” approach.

It feels to me like Apple’s approach has been a focus on AR. But instead of getting sucked in to the massive problems that Hololens and Magic Leap and nReal have had trying to make waveguide-based “overlay” tech work, they’ve instead cranked up the resolution and fidelity of pass-through tech… which seems like the correct option to me given the fatal problems of the current crop of AR headsets.

I do *not* think Vision Pro is the thing that will make AR/VR take off like a rocket. There’s a technology limitation that will keep this a niche device for a few generations, IMO, around either “true” AR, or some sort of trickery that lets passthrough-style VR appear invisible. When that happens, AR will instantly become a gajillion-dollar industry faster than anything else, ever. This isn’t that.

But VP is a *huge* step in the right direction if it works as advertised, which, given Apple’s history I presume it will. Which will baffle folks looking at specs and $, and wondering why not Meta Quest Pro?

But the last bit of this puzzle is trust. XR requires a huge amount of environmental and personal data. I *do not want* Meta to have that data about me, because I know it’ll be abused at every opportunity. While all big companies are highly incentivized to utilize that data as much as possible, Apple’s shown a commitment to data privacy that’s well beyond anything their competitors are even willing to talk about.

And this means that once there’s a viable alternative to Meta, I’m going to drop Meta’s products like a hot rock and never look back. And that means as a developer, working on VP is a prospect I’m unlikely to pass up.

Don’t Play Fair

You may see parallels with the modern political landscape, but it’s just as relevant at work.

You can’t beat an effective con(person) by playing fair.

One of the most common questions I get from people who are “stuck” in their career is “when should I leave my job?” and my answer is usually “when you can’t see a way forward.”

And one of the things that people run into sometimes is that they end up in a situation where you’re at odds with someone who’s essentially a charismatic con(person) who’s excellent at managing up. I’ve encountered this multiple times in my career, and the conclusion I’ve come to is that there’s simply no way to win.

You can fight a mediocre con(person) by realizing that part of your job is not just being right, but helping your stakeholders understand that by not just logical but also emotional appeals, etc. etc. But the problem is that a great con(person) is better at doing this, because they can do everything you can, and aren’t constrained by things like integrity or honesty or facts or reality.

You can’t beat that. Don’t try.

I know that sucks to hear, and I’d love to have some sort of playbook to beat them, but I don’t. I’ve tried everything *I* know how, and have lost *every time*. So the advice I can give is just this: There are times in your career where you hit a brick wall. And you can beat your head against it for years and maybe make progress, but at extraordinary cost to you. You feel like you should be able to overcome any obstacle, fight through any bad situation.

But if you can’t see a way forward, it’s time to go. There are times when your progress at a place will come to a complete stop, and there’s simply nothing you can do about it. It sucks, but understanding that and finding a way out is much, much better than fighting an immovable force. And yeah – it sucks. Bad people win. Happens all the time. You need to prioritize what is best for *you*, and that’s often just accepting that if you’re fighting a con(person) and they’d good, and have their hooks in the stakeholders who you need… the way forward is out.

Getting Laid Off

We can all agree at this point that being laid off isn’t a mark of shame or a reflection of your quality, right? Companies making record profits just need to make record-er profits so shareholders can get $$$. It’s a cynical cash grab, and the large companies are all using each other as cover to do it while under the guise of some sort of “market contraction” or some other bullshit.

So if you have been laid off, no, it doesn’t reflect poorly on you. There is literally nothing separating you from someone who didn’t get laid off. It has nothing to do with whether they deserved it, or you didn’t. It’s just arbitrary and capricious.

When you’re applying for your next job, and someone asks you why you’re looking, my recommendation is to not hide that you were laid off. You don’t have to sugar coat it or try to evade the question. Just confront it head on.

If the company you’re interviewing with sees it as a negative, they’re so out of touch that that is in itself a red flag for *you*. But I don’t even think there are companies that are that out of it. They’ll just say, “oh,” and move on. When the folks who interviewed you talk about you later or write notes to the hiring manager, if they mention it at all, it’s definitely not going to be, “The interview went great, they were super smart, really qualified, had great questions for us… but they got laid off from their previous job. Pass.” That’s not happening.

Do not worry about having been laid off. Don’t worry about it when talking about it with your friends, don’t worry about it when interviewing for your next job. It’s just a thing that happened, and these days it could literally have happened to anyone.

Writing Structure?

One of the things I’ve just been beating my head against with this writing project is how to elegantly tie a bunch of things together. Product design is about a lot of things – but a lot of it is centered around finding a “focus” – some clearly defined problem you’re trying to solve. That focus enables two critical things: testing and collaboration.

Testing, because if you know what you’re trying to build, you can ask people whether you’re making progress in the right direction or not. Most product development processes I’ve seen are vague enough that any result can be interpreted as a good result. Which is useless.

Focus also enables everyone to know what they’re supposed to be doing, which is *the* foundation of collaboration. It allows you to distribute authority to people with expertise, rather than keeping all the decision-making in your own head, which inevitably turns you into a bottleneck and a huge point of failure. After all, you’re not an expert on everything.

But then, distributing authority requires a lot of team culture issues to be front of mind. Psychological safety first among them. Ability to communicate clearly. To communicate *intent* in addition to tasks, so that everyone can help reinforce that what you’re doing is aligned with that focus.

It’s kind of a ouroboros in a Gordian knot – everything is interwoven, and trying to explain it in some sort of linear order breaks my head, because I can’t find a way to explain one thing without a bunch of prerequisites, and untangling the web of prerequisites… well, I haven’t found the right sword yet.

I think perhaps one way will be to separate things more, rather than trying to integrate them more. Focus, Team Culture, Leadership (thanks to Eric Nehrlich for reversing my initial order) each being different sections – sort of a progression from the outside in – starting with the customer & what they need, structuring your team in a way that maximizes the experience and strength of the team, and then what your responsibilities are to your team and why your leadership can have a massive impact on all of that jazz.

Which provides some structure to the process. I think even with those things “separated”, I’m going to have some tendrils that tie concepts together across sections (maybe an explicit “prerequisites” block where necessary, or maybe a Jason Shiga-style “choose your own adventure” path through things if you want to follow that concept down a bit deeper. I dunno.

But at least it provides a reasonable starting point.

Musk & Software

Videogames are software. And as critical as engineers are to videogames, if a game team fired most of its designers and artists and said that engineers would constitute the majority of the development team and that all other disciplines were secondary… you’d end up with some terrible videogames.

No disrespect to engineers at all. But just because software is code, software is a creative collaborative multi-disciplinary effort that requires top-level work from ALL disciplines involved working *together* toward a shared vision.

Creating a world where designers, artists, audio folks, producers, project managers, etc. are “second-class” citizens relative to engineers is not how to create great software. I say that with a 20 year history, and at least a few significant successes that illustrate that I know what I’m talking about.

Musk may be smart in some fields, but it’s clear he’s got a 101-level approach to building consumer software, and if I was a Twitter employee, I’d take the severance and GTFO. This is the wrong approach, and since it’s worth calling your shots, it *will not succeed*.