Recent thoughts

Shifting Gears: Balancing Introvert and Extrovert Leadership

August 24, 2025

As a design leader, my role lives at the intersection of two opposing forces: externally leading teams and stakeholders while diving deep into uninterrupted strategic work.

I’ve always tested close to the edge of two personality types: ENTJ (extrovert) and INTJ (introvert). Some days, I wake up as the classic ENTJ “commander” archetype who is decisive, outward-facing, energized by conversations and collaboration. Other mornings, my INTJ “strategist” side dominates and I need solitude, focus, and quiet to do my best work.

The work doesn’t wait for my mood, though, and I’ve realized something important: I can’t leave my energy up to chance. I need to be ready to operate in the gear my role demands. Over time, I’ve built personal rituals, frameworks, and techniques to deliberately shift between ENTJ and INTJ gears so that I show up as the leader my team, stakeholders, and company need me to be.

The Ambivert Advantage

Balancing my personality is both a challenge and an opportunity. People tend to see extraversion and introversion as fixed traits, but they’re better understood as energy dynamics:

  • Extroverts recharge through connection and thrive on outward-facing engagement.
  • Introverts recharge through solitude and feel drained by extended social interaction.

I sit close to the middle—what psychologists call an ambivert—which means my energy balance is highly context-dependent. Put me in a creative, collaborative environment, and I’ll lean into my ENTJ side—energized, vocal, and engaged. Drop me into a quiet problem space, and I’ll happily disappear into INTJ deep work for hours.

The upside: I can flex my leadership style to fit the moment. The risk: without managing my energy deliberately, I risk showing up in the wrong gear—pushing for collaboration when I’m drained, or forcing deep work when I’m mentally overloaded.

Recognizing this about my personality was the first step, and took me many years. The next was building a system to choose my gear intentionally. Small adjustments compound; I don’t need perfection, just awareness and the ability to course-correct quickly.

Designing a Weekly Cadence

As silly as it sounds, I plan my week around my energy. The residual effects of COVID have led to many businesses landing on a hybrid work style, with some in-office days and some working from home days. This rhythm suits me well—but it also challenges me to be intentional.

Tuesdays and Thursdays are my anchor days in-office, perfect for stakeholder alignment, team coaching, collaboration-heavy sessions, and high-visibility discussions. On Mondays, Wednesdays and Fridays, the team works from home, giving me space for strategic work, priority-setting, and synthesis.

Essentially, this hybrid model allows me to shift into the right gear to maximize my time and energy around my personality.

Shifting Into ENTJ Gear for Collaboration

My in-office days need to be high-energy, people-first, and outward-facing. The problem is that I often wake up in “INTJ gear” on a Tuesday or Thursday. If I just go with my default state, I risk wasting the day, so I developed a framework to deliberately shift into ENTJ gear.

1. Morning Activation Ritual

Energy sets the tone. This ritual primes my nervous system and shifts me into a forward-moving, engaged ENTJ gear:

  • Hydration: Opinions differ here, but a couple of glasses of water before leaving home makes a surprisingly big difference for me.
  • Movement: My train commute counts as a micro-workout: walking to and from the station gives me movement, regardless of the weather.
  • Mental Jumpstart: On the ride, I cue up high-energy music (good morning Bassdrive.com) or a provocative podcast.
2. Mental Anchoring

Once I’m activated, I set a clear intention for the day. This isn’t abstract—it’s priming my brain to “show up as the leader” before I physically enter the space, and is surprisingly effective:

  • Set Priorities: While I’m riding the train, I write down my top three external priorities for the day—usually important conversations, team coaching moments, or important decisions.
  • Visualize Arrival: I visualize the first 30 minutes of walking into the office: how I want to greet people, where I want to bring energy, and which discussions matter most.
3. Social Warm-Up

Before I arrive at the office, I intentionally initiate one small interaction on Slack:

  • Ping a Peer: Reach out about a topic I want to discuss.
  • Acknowledge Wins: Send a quick note celebrating a recent win.
  • Set Touchpoints: Schedule a quick check-in that creates an early collaboration hook.
4. Structuring the Day for ENTJ Energy

Throughout the day, I protect my energy and presence so I can engage meaningfully in every interaction:

  • Sit where collaboration happens: Even physical placement matters; being near people keeps me externally engaged.
  • Front-load high-impact conversations: I schedule strategic meetings or coaching sessions in the morning, when my energy is highest.
  • Minimize deep-work triggers: I avoid starting the day with systems mapping or strategy docs, as these tasks can instantly shift me back into INTJ gear.

Shifting Into INTJ Gear for Deep Work

Just as I prime ENTJ gear for in-office days, I protect INTJ gear for work-from-home days. Those are my windows for:

  • Long-range strategy: Defining multi-quarter design priorities while adapting to shifting needs and cross-team dependencies.
  • Systems thinking: Refining design processes, frameworks, and scalability models.
  • Reflection and integration: Connecting dots across product, design, and business to inform future decisions.

I treat these days as sacred. Meetings are limited and I carve out large, uninterrupted blocks for deep work.

This separation creates a healthy rhythm: ENTJ days for alignment and influence, INTJ days for strategy and foresight. That balance keeps me effective and energized.

Shifting Smoothly: Picking the Right Gear at the Right Time

Even with the best planning, energy dips are inevitable. Over time, I’ve developed micro-resets I use to stay aligned with the gear I need to be in:

  • Feeling drained midday → Step outside, breathe, and recenter for 10 minutes.
  • Retreating into headphones → Spark a quick casual chat at the coffee machine.
  • Losing focus in ENTJ gear → Re-anchor on the top three priorities for the day.
  • Mental overload in INTJ gear → Take a short walk, clear inputs, and restart the deep-work block.

These small adjustments compound. I don’t need perfection; I just need awareness and the ability to shift gears quickly.

Managing energy deliberately isn’t just a productivity hack; it’s leadership hygiene. My team deserves a leader who’s present, clear, and intentional. Partners need me to show up ready to collaborate, and stakeholders need me to show up prepared to influence and align. And personally, I need space to think deeply and recharge in order to avoid burning out.

By priming my external gear when collaboration matters, and protecting my internal gear when strategy demands focus, I’ve built a sustainable way to lead at scale.

Leadership Isn’t Automatic: Shifting Gears Intentionally

Leadership isn’t about being “on” all the time. It’s about knowing which gear to be in depending on the situation, and developing the tools to shift deliberately. Some days, I’m driving decisions and rallying people around a vision; other days, I’m a strategist, disappearing into thought to design systems and see around corners.

The key: I no longer leave it to chance. I design my environment, my rituals, and my energy so I can meet each day’s demands without burning out or losing clarity. Drive your personality manually—rather than relying on automatic transmission. In a landscape that keeps shifting, intentional beats automatic.

Nothing Works Out of the Box (Good Process Is Built, Not Chosen)

July 31, 2025

If you’ve been in product, design, engineering, or any kind of cross-functional software org long enough, you’ve sat through the meetings. You’ve read the books. You’ve been on the “we’re going full dual-track Agile!” train. Had a brief, chaotic flirtation with Holacracy. Maybe someone dropped the Working Backwards bomb and suddenly there’s a 5-page press release for something no one’s even started sketching yet. And maybe—just maybe—you’re old enough (or perhaps unlucky enough) to have been caught in the sticky, molasses-slow grip of a full-blown waterfall project. God help you.

I’ve used all of them. Loved parts, hated others, quietly sabotaged a few (always with good intent), and mostly just tried to make it all… work. In the end, the only thing that actually works is stitching together the useful bits from each methodology. It’s not elegant, and it has no name—but it’s real.

Agile & Dual-Track Agile – The One That’s Basically Default 

Dual-track is probably the closest thing I have to a default. If someone drops me into a new team and tells me, “Run this thing,” this is where I’ll start. It just makes the most sense in the chaos of modern software.

In theory, it’s about reducing risk. Product and design explore ideas, test rough prototypes, and ideally land on something usable before engineering starts building. That’s the pitch. But in practice, it often feels like a frantic, disconnected rush. Product is iterating mid-sprint. Design’s still making decisions. Dev is waiting for clarity, final designs, contracts to be signed—sometimes just a decision on what we’re even building. You end up with is this awkward in-between phase where everyone’s technically doing their job, but no one’s really aligned.

This is where dual-track agile breaks down if you’re not paying attention. I’ve tracked story points, and I’ve reviewed velocity charts, but even with all that structure, it often feels like we’re guessing. Points are subjective, and velocity numbers can be fragile. When things slip—and they often slip—the real reason is usually that someone didn’t have all the information they needed when they started building.

It works when teams are truly aligned—not just on what we’re building, but why and when. Without that, you get silos. Gaps. Mistrust. And a lot of stressful sprint planning meetings trying to patch over decisions that should’ve been made two weeks ago.

Still, for all its flaws, dual-track is the most adaptable thing I’ve used. It gives product and design space to explore without paralyzing delivery. But alignment isn’t a ceremony—it’s a habit. And if you let it slip, the process won’t save you. It’ll slow you down.

Shape Up – The One I Wanted to Love (But Didn’t) 

I really wanted Shape Up to work. The concept is sharp. You ditch the never-ending backlog, skip the sprint ceremonies, and instead shape real, meaningful work before it ever hits the dev team. You pitch the work, agree on the appetite (time and resources to spend), and the team gets a full six weeks to build it—with no interruptions. And if the work isn’t shaped enough? Then you don’t build it. It’s disciplined. It’s focused. It’s the kind of clarity a lot of agile teams dream about.

We didn’t run it exactly as written, but it sorta, kinda worked for us. Instead of the full 6-week cycles with a 2-week cool-down, we condensed it into 3 + 1. There just wasn’t enough time or space to shape things properly as a team. We were always sprinting into the next thing, still trying to scope or design while development was already ramping up. The pace didn’t leave much room for shaping together. Engineers often didn’t have the context they needed to contribute early. Product was balancing a lot—shipping in parallel while trying to define what came next. The “bets” we placed felt more like best guesses under pressure.

We took the best parts of Shape Up and made it work pretty well for us, but I think we tried to adapt it into an environment that didn’t quite support it yet. The method could work, but it’s demanding. It needs full buy-in, protected time, clear roles, and breathing room to really click—both with the method, and with each other as a team. Without that, it’s hard to get the value it promises.

That said, some of the ideas stuck with me. Shaping with engineers—actually shaping (clarifying requirements, designing together), not just handing off—was a standout.

Working Backwards – The One That’s All About Timing 

This one was… an experience.

I was on a team building a new platform, including mobile apps, hardware, “the cloud.” It was ambitious as hell. So we thought, “Let’s do the Amazon thing. Start with the press release. Nail the vision. Work backwards.” And we did. We wrote a PR for this massive ecosystem—a kind of Alexa-style thing that did everything. It was slick. Inspiring. But ultimately? Kind of useless, because we had no idea how to get from that vision to a working product. It was like advertising your restaurant’s grand opening before you know if you even own a kitchen.

The big unlock came later: the PR/FAQ isn’t meant to be the very first thing you do. It’s not step one. It’s step… four? Five? Somewhere after you’ve done the strategic sticky note dance, mapped your product roadmap, and gotten real alignment on where you’re going and when. Once you have that? Then yeah—write a press release. But not a big bang for the whole future ecosystem. Write one for just the first release—the earliest sign of life in your ecosystem. The thing you can actually build and ship within this timeline, this budget, this team’s capacity. That’s the PR. Then you write another one. And another. And so on.

The FAQ part? Pure gold. Silent reading? Amazing. Everyone drops questions into a shared doc then go through them together—one by one, in real time—and answer them. Carefully. Thoughtfully. Sometimes it takes a couple hours. Sometimes more. That’s okay—that’s the work. What you walk away with is shared clarity and alignment. Not “alignment” as in “we all smiled, nodded, and hoped someone else had it covered.” I mean real, tactical alignment, like “Are we supporting feature X of device Y in V1?” No? Cool. That’s in the FAQ now. We’re done wondering. From there, the team can split off and finally start moving together—this time, with clarity.

Waterfall – The One That’s Not Dead, Just… Taking A Nap 

I’ve done it. Full waterfall. Like, 6-to-12-month-long planning cycles. Requirements docs. Handoff meetings. The whole deal. And you know what? It wasn’t as painful as people make it out to be.

It kind of felt like agile, just stretched out. Design and product still scoped things out ahead. Engineering still waited around. We still had questions we couldn’t answer, and changes midstream still broke everything. But sometimes, waterfall is exactly what you need. When the thing you’re building is expensive, high-stakes, irreversible—like core infrastructure, or data pipelines, or literal hardware—you don’t want to be iterating mid-sprint. You want to plan the hell out of it. Think it through. Know your path before you take the first step.

So no, waterfall isn’t dead. It’s just got a very specific use case now.

So… What’s the Right Way? 

Of course it’s all of them. And none of them.

Here’s what I’ve kept sharpened from the toolbox I’ve built over the years:

  • Start with strategy. I mean shared strategy. Sticky notes. Miro boards. Roadmap themes. Align the team before you start writing anything.
  • Use PR/FAQs at the right time. Don’t try to boil the ocean with one giant doc. Just write the PR for V1. Write FAQs with your team—together, in silence, in Google Docs. It’s awkward, and kind of beautiful.
  • Shape things with engineering. During the discovery sprints, use whatever tools make sense to track engineering time in a way that works alongside velocity charts, or burndowns, or story points if you must—but track it.
  • Deliver with dual-track agile. Let design and product keep running ahead. Let engineering get going on real stuff once the dust settles. Stay a little ahead, but not too far.
  • Go waterfall when the stakes demand it. Bridges. Architectures. Platforms. Things that, if you screw them up, will haunt your roadmap for years. Plan those things like it’s your personal happiness that depends on it. (Because, well, it is.)

Every framework has strengths, and every one of them breaks down somewhere.

The goal isn’t to pick a perfect one—it’s to build something that actually works for your team, your product, and your stage. Process should support good work, not get in the way of it. At the end of the day, the best process is the one your team believes in—and can actually run.

That means adapting. Blending. Adjusting as you go. It’s not always clean, but it’s real. It’s the only way I’ve seen real teams actually get real things done.

What the Nintendo Game Boy Taught Me About Great Product Design

June 30, 2025

When I was a kid, I wanted a Game Boy. Bad.

A lot of my friends had one. They played it on the school bus, at recess, after class, on road trips—it wasn’t just a toy, it was social currency. Owning one meant being part of the conversation. So, naturally, I asked my parents for one. But instead of the beloved Game Boy, my dad got me what he thought was the obvious choice: the Sega Game Gear.

Classic dad move. He was a specs guy, through and through. The kind of guy who read the back of the box and actually cared about things like screen resolution and sound quality. We had a VCR with a remote control when everyone else was still walking up to the TV to hit play, and a 32-inch screen in the 90s—a monster at the time. We were that house.

On paper, the Game Gear looked like the smarter choice. Full-colour backlit screen, better sound, and it came bundled with Sonic the Hedgehog—a game that, by most standards, looked way cooler than Tetris. I even got the “Deluxe Edition” extras: a carrying case, a baseball game, and a giant magnifier attachment to blow up that already-bigger screen. It was peak ‘Sega does what Nintendon’t’ energy—the tagline at the heart of Sega’s North American marketing playbook in the ‘90s. They positioned themselves as the rebellious, high-powered alternative to Nintendo’s clean-cut image. Faster, cooler, louder. The Game Gear was part of that strategy. It screamed performance and flash.

But what Nintendo did—and what Sega didn’t—was understand the tradeoffs that actually mattered.

The Game Gear chewed through batteries like it had a grudge. I’m talking 3 to 4 hours on six AA batteries. That made it effectively a home console with a handle, because taking it anywhere—to school, on the bus, to the park—meant risking a dead device before your first recess.

Although the Game Boy only had a monochrome (green!) screen and basic sound, it ran forever. Four AAs could last you 30 hours which meant it fit into kids’ lives. It was reliable, practical, and it was everywhere. The specs didn’t matter; what mattered was that it worked when and where kids wanted it to. Even the bundled game, Tetris, was genius: simple, accessible, and way easier for new players (and your non-gamer friend) to get into than Sonic or Mario.

How The Right Tradeoffs Made the Game Boy a Legend

What’s wild is that this whole Game Boy vs. Game Gear contrast wasn’t just playing out in store aisles or schoolyards—it was happening inside Nintendo itself. Nintendo had two major internal hardware teams at the time: Research & Development 1 and Research & Development 2, and they operated almost like rival studios under the same roof.

R&D2 was the team behind the Nintendo Entertainment System (NES)—a technical leap forward in home gaming. They chased fidelity, performance, and arcade-level experiences in the living room. They were the ones who made consoles that looked good on spec sheets. That team got to market first and helped Nintendo dominate the home console space in the ‘80s.

R&D1 took a very different approach. They believed in what they called “lateral thinking with withered technology”—a philosophy that prioritized accessible, proven tech used in creative ways over bleeding-edge innovation. Basically, don’t build the flashiest thing—build the right thing. When the handheld space started heating up, R&D1 didn’t rush to outdo the competition. They studied the market, leaned on affordable components, and built the Game Boy to be durable, portable, and practical. It ran on modest hardware—nothing flashy, nothing bleeding-edge—but it was engineered for real life. It wasn’t a powerhouse by any technical standard, but it worked—consistently, portably, and practically. And in the end, that’s what mattered.

Meanwhile, Sega came out swinging with the Game Gear—a bold attempt to show what handheld gaming could look like with no compromises. It had a vibrant colour screen, amazing sound, and enough horsepower to run a scaled-down Sega Master System. It looked and felt cutting-edge—a true tech flex—but all that power came at a cost. The Game Gear was bulky and devoured six AA batteries in just a few hours. Unless you were plugged into a wall or carrying spare batteries like a doomsday prepper, it just wasn’t built for the way kids actually played. It was a marvel in theory—but one that couldn’t even survive a bus ride.

R&D1 didn’t win by winning on paper—they won by winning in the real world.

Even though they weren’t technically first to market with a handheld that supported interchangeable cartridges (that was Milton Bradley’s Microvision, if you’re curious), and even though the Game Boy didn’t “wow” in the spec wars, R&D1 nailed something fundamental: how real kids would actually use their product. They knew kids weren’t playing based on screen resolution; kids were playing in the backseat of cars, in the cafeteria, and under the covers with a flashlight. They needed something that could go anywhere, not just look good in a commercial.

And that philosophy—prioritizing context, constraints, and actual user behavior—is why the Game Boy crushed not just the Game Gear, but pretty much every handheld competitor for the next decade.

Great Design Starts with What You Leave Out

My dad meant well. He wasn’t trying to zig when the world zagged—he genuinely thought he was getting us the best thing. And if you lined them up side by side, he probably was. The Game Gear looked superior in every way except the one thing that mattered most: usability.

It was a classic specs-first decision, and honestly, a very understandable one. He was the kind of guy who paid attention to detail, who appreciated new tech, and who wanted to give us something impressive. But in this case, the context got lost because he was buying a portable system that wasn’t really portable. Not in a kid’s world, anyway. And while I played in my bedroom from time to time (usually plugged into a wall outlet), every other kid at school was swapping Game Boy cartridges on the bus, at recess, and during lunch. They had the less powerful device—but they actually got to use it.

This is exactly what Nintendo’s R&D1 team understood better than anyone. It’s not that they couldn’t match Sega on specs—they probably could’ve. But they knew that chasing raw power would come at the expense of usability, affordability, and battery life. And they made a conscious choice: prioritize the experience, not just the hardware. So instead, they leaned into smart, user-centered tradeoffs. They gave up the better screen, better sound, and horsepower in exchange for something more valuable: battery life, durability, and real-world portability. They didn’t just build a better device—they built a better experience rooted in how kids actually played.

That’s the key: Great design means letting go of what looks good on paper and focusing on what makes something useful, usable, and used. It’s not about maxing out specs—it’s about picking the right constraints and nailing the tradeoffs that matter to your audience. The Kindle isn’t more powerful than an iPad, but it’s better at what its users actually want: reading without distractions. The Switch 2 doesn’t lead on specs, but it leads where it counts: how people actually live and play. Great products succeed not because they do everything, but because they do the right things in the right context.

So whether you’re building hardware, software, or anything in between, stop thinking like a comparison chart. Step outside the conference room. Talk to your users. Watch how they live. You might be falling in love with features no one will ever benefit from.

You might be designing a Game Gear… when the world really needs a Game Boy.

Read more thoughts…