Not crazy

I was listening to Jenny Wen on Lenny's Podcast and about 8 or 9 minutes in, I got so excited I had to turn it off. Weird, right? But I paused it so I could capture my thoughts and the moment I realized that… I’m not crazy?

Why I’ve felt like an oddball

I’ve bounced between two primary conflicting beliefs over the years:

1. I’m good at this—look, people like me and things I work on are good

2. I’m lucky and/or hiding in places where my bullshit passes

Note: I don’t call this imposter syndrome because A) that’s quite a trope by now, and B) I don’t really believe the second one. (I’m too egotistical for that). But because I’ve never worked in “big tech” or somewhere with a big, well-oiled team, I’ve always been left wondering, “what if…”

Much of my success has come from thinking fast, moving forward, politicking for the right thing, and delivering damn good work in demanding situations. A lot of that happened in the consulting world, which was a great place for me to evolve beyond the often dogmatic world of human-centered design. We built real software with real impact. And in many ways, we did have well-oiled teams, they just didn’t look like the ones being lionized in online product and design circles.

Consulting led me to be a more ruthless, efficiency-seeking pragmatist—cutting out anything that felt like design theater, being more hypothesis-driven, re-using the good parts of process, and looking for any shortcut to impact.

All of which is… good?

Jenny characterized two ways of working she’s seen emerge recently (under the clickbait-y title of the podcast, “The design process is dead”):

1. Supporting the execution (or I’d just say “Delivering”)

2. Creating a vision or direction—for the team to sprint towards

This was my ⚡ moment: this is almost all I’ve done for the last 2-3 years.

Delivering, or “Supporting the execution”

NOTE: I don’t love calling this support, and I think that’s probably why I renamed it delivering. I think this was what I referred to in my own head as ”read and react”, Which, whenever I say it is, when I feel these pains of doubt about, I don’t know the sustainability of it, or the validity of the way I’m doing things. I think the output from this way of working is fine, but it was the lack of a formal process that made it feel slightly off. And it felt like I would have trouble explaining it to my next employer when they ask how I work.

The last year I was BCG, everyone was ChatGPT crazy. It was 2023, after all. I was lucky enough to lead the design and be the pseudo-product-manager for an internal LLM-driven slide building tool called Deckster. (Building decks, get it?)

It was an awesome experience because it was on the cutting edge of building on top of LLMs for an actually valuable use case for a big organization. And it was pretty good! I missed using it when I left. It was better than anything else that was shipping in terms of public products at the time.

But what was most interesting to me, a student of collaboration, was the way our team had to change our ways of working as we built a product like this. It was a big part of the Deckster case study I made when getting my job at Gecko. From that case study, in early 2024:

Things move extremely fast, which broke our “design-test-build” pattern. As ideas came from users, leaders, engineers, and everyone else, [we] had to separate experiments from development tasks. Many items were explored for a day or a week before being tossed or incorporated into the roadmap. Feasbility has never been harder to pin down than when working with generative AI…

This was even before Claude enabled the “cheap execution” that we’ve seen explode over the last few quarters. But the pace of feature development on top of the GPT-4 models was insane at the time. We started doing “product crits” instead of design crits because everyone was bringing new work and experiments for sharing and feedback.

As the designer, you have to be the one to keep it all in your head in order to shape this new thing towards a cohesive product—in real time. That’s never easy, but it feels more under control when there is a more designerly process in place. When you’re doing it live—with the whole team, with senior stakeholders, in 1:1s—you need quick thinking and experience to make decisions snap together into a whole.

Set a direction

I think I (and many designers) have traditionally tried to do this, and even been responsible for it within product teams. But the way in which I’ve approached it has certainly changed.

Last fall I joined the Gecko Manufacturing team as the team was moving from a technical proof of concept system towards deploying with third party operators at forges. I was coming from our flagship field software team with a clear goal to transfer my knowledge into a new team building a new system.

I dove deep into the problem space and hardware/software stack, and without waiting to truly understand everything about it, I took a drastic, scary step: I vibe coded a prototype that overhauled their entire application.

It was not perfect, but it was right enough that the team was able to rally around it, poke holes in it, ask great questions, and make it better than I could. And then we used it to inform the general direction of the app for months after that. But I didn’t revisit it as we made new decisions. I didn’t make v2 or v3 every month. It served its purpose of aligning us at a critical point in time so that we had a shared understanding of what the product could and should be.

In the before times, this type of prototyping was different. It was slower, sure. But it was looked at as a source of truth, which meant it was informed by research. Now it can inform the research. A good prototype was a way to de-risk what was to be built. Now building and shipping is its own de-risking process.

So what?

I don’t know really. I still rely on some tried-and-true human-centered design methods and pull them out of the quiver as needed. But I rarely think about or pitch anyone on anything resembling a double diamond. I am still advocating for more design-forward and user-centered approaches to problems, but my rhetoric has changed.

It’s a very interesting time. And hearing someone else say the things I’ve been feeling on a popular podcast felt like a bit of validation.

What does it mean for what comes next, how the product triad roles converge, or whether or not we’ll all have jobs in a few years? ¯\_(ツ)_/¯

Realizing—and destroying—the value of multi-disciplinary collaboration

I think a lot about collaboration. How to do it. When to do it. And most philosophically, why to do it. A former manager of mine, Greg, once put it so plainly that I immediately fell in love with how he wrote it:

Interdisciplinary collaboration is hard by definition. There will be disagreements about what is important. This is exactly the point.

I’ve reused that line (and line of thinking) a lot over the years, and I feel more strongly about that than ever. I’ve used that to set expectations with teams and colleagues. I’ve used it to comfort myself (or others) after a maybe-too-spirited debate in a meeting. That simple three sentences packs a lot into it.

Interdisciplinary collaboration is hard by definition

“Interdisciplinary” is carrying a lot of weight in this first part. Depending on your experience or perspective, you might not think that it is actually very hard. I used to think of the scope of this for myself as collaborating with engineers and user researchers. Then I added product managers into that mix. But I think that’s a designer’s view of the world—those are the most basic and closely related inputs and outputs to a designer’s work product. And in a more mature team or organization, all of those disciplines are generally rowing in the same direction and have some experience working in those types of product teams, so the collaborative cow paths are pretty well worn.

I’ve learned to expand my definition of “interdisciplinary” to mean basically “everyone with a stake in an effort.” Part of my career maturity has exposed me to working hand in hand with data scientists, architects, strategists, marketers, MBAs, PhDs, 24 year olds, 64 year olds, etc. And in a lot of cases, they weren’t experts in working with designers or engineers—and most importantly, they weren’t experienced in a product-driven style of working. So if we’re not all familiar with the same playbook or principles, how do we get moving and determine some ways of working?

There will be disagreements about what is important.

At BCG, when we are assembling a new team, one excercise we do to establish working norms has a series questions that address preferences like communications (Slack, email, phone, etc.) and feedback style (real-time, scheduled, etc). My favorite one is the spectrum of when to collaborate, and I’m typically the most extreme one at the “Start Together” end of the range.

Why is that? Because I want to be “the collaboration guy”? Not really. I’ve just learned that if we don’t start together, it will lead to misaligned everything. Misaligned priorities, information, schedules—even a misaligned understanding of the problem we’re solving. And if we’re not on the same page, we’re going to have two primary problems: collaborative process and collaborative decision making.

Process is important, but I’m not that designer who pontificates on the elegance of the double diamond, etc. There is no “one true way” that I’m arguing for. I’m just trying to realistically make sure our processes are compatible at a minimum and electric as an aspiration. Figuring out the various inputs and outputs on an interdisciplinary team is hard work, but vital.

But doing that hard work starts to reveal what’s important to different people and disciplines. That lays the ground work for better collaborative decision making. And decision making is where collaboration is tested.

This is exactly the point.

If you’re not arguing, if there isn’t any friction in how you make decisions, if everyone is doing what they’ve always done in their own silo’d disciplines—why are you working together? Are you just coordinating and not collaborating? Boring.

When it comes to decision making, that’s where what’s important is on full display. Timelines, budgets, user needs, business goals, etc. Everyone is representing some subset of priorities when you’re making decisions. They might care about their process, their metrics, their boss, or their users. Now, they might not be saying those things, but it’s baked into their recommendations, questions, and solutions. And that’s OK. Acknowledge those differences and talk about them, not just the solution. It’s easy to try and ignore them, though.

I see these symptoms of ignoring or working around those differences flare up in many teams. These are warning signs that I need to invest more time in our collaborative relationship. Things like:

• You find yourself saying “Why are they asking for that?”

  • This is a great flag that someone doesn’t understand others’ processes, and they are expecting something that will plug into their process.

• You feel a general sense of stay-in-your-lane

  • If someone is asking you “Why are you asking for that?” that probably means that they are unclear about the role you are playing on the team, what your responsibilities are, and how they might overlap with theirs. At worst, they don’t want to let you into their process.

• You’re told that others “can handle it” without you

  • When someone says “We can handle that, we don’t need design for that,” they aren’t acting open to collaboration. There can be many valid reasons, too, but it’s worth interrogating. If this is a constant

If the team is not careful, this is where we can squash the value of interdisciplinary collaboration. There is trap where we collectively gloss over the differences, stay in our own lanes, and then just deliver mediocrity.

But do we need to collaborate?

This all doesn’t even get into the need for collaboration: to solve hard problems. I believe that most regular problems have been solved (at least once), and an existing solution gives us a playbook to follow or at least an example to draw inspiration from. A solution from the real world is a great way to align a team to a vision—“it’s like Github, but for XYZ”—and that not only makes collaboration easier, but it also makes solving the problem easier in a lot of ways.

It is the challenges that need expertise that also need collaboration. You can’t have one without the other. I like to think that the solved problems I mentioned above are also generally single-domain or single-discipline problems. Data scientists have their own set of solved problems, designers have design systems ad nauseam, etc. It’s only when we reach the limits of what can be solved on our own that it gets interesting.

So we identify a new problem and it can’t be solved without bringing in an expert in that thing, and then we need to realize that we haven’t worked with them before, and they probably haven’t worked with us before (or someone like us). This is going to be hard.

But that is exactly the point.