Dear Dave,

In my last post I wrote about how a vision is a chapter in the story of a product —1 perhaps lofty and intimidating to start, but its helpful to remember that they’re not the final word.

In this much anticipated squeakquel, or second chapter more appropriately, I wanted to go a layer deeper into what makes a vision effective, and some of the tactics I’ve seen work well.

Qualities of a good vision

A good vision is visionary

This may seem painfully obvious, but many visions put forward a vision of the future that’s only a day away. A vision is necessary to change direction, not to define the chapter we’re in today. It couldn’t exist today with the product as-is. It’s not just building new features: a strong vision drives the product in a new direction that will require a meaningful gear shift to achieve. It tells a story about what the product can become for users — solving new problems we didn’t know we could, or in novel and unexpected ways. This matters because a vision needs to be ambitious — otherwise its just an idea, which is always nice, but any product team worth its salt wants its direction to be trailblazing.

It’s evidence-based but highly opinionated

A good vision is grounded in customer research and data. But those things can point us in multiple directions. A strong vision is controversial — other visions are possible, but we choose this one, and the vision articulates why, and persuades you to agree. This matters because a vision is only as good as the evidence that underpins it, and because it’s a stance, by definition, it has to drive towards a single clear path, not describe several options.

It’s concise and memorable

A lot of work goes into a vision, but what you need to consume to get it should be limited and sticky. It should probably, in all seriousness, have a snappy tagline or title people can refer to. It is a simple enough direction to be summarized, even if there’s plenty of content to go through if you want to go deeper. None of this works if the audience can’t hold onto it, and the audience for vision work is likely wide and busy. To be relevant and enduring, the vision has to be easy to describe and recall.

A spectrum of vision artefacts

Next I want to share a non-exhaustive list of common vision artefacts, in no particular order, to show what this blobby-feeling thing actually looks like. All of these can work, and all can fall flat. And often they’re best used in combination with each other.

Prototypes

While visions prototypes increasingly proliferate thanks to our friend AI2, they rarely pass the visionary bar — often falling into the trap of showing a collection of new features we could build, rather than a true direction.

Still, prototypes can be incredibly powerful because they are the epitome of ‘show rather than tell’. They can be highly persuasive for executives, but team members may look at them with skepticism. Voice-over or embedded storytelling is critical to ground everyone in reality with an artefact that looks so real — and to make clear you’re not trying to ship this exactly, but in this direction, which can breed confusion at all levels.

Documents and decks3

There remains a place for tried and true handcrafted words in vision work; this enables you to articulate the principles and frameworks that should drive the chapter ahead in vivid detail, and to get into the evidence behind them. And with agentic design, documents in particular can serve as useful tools to enable AI tools to work towards your vision, too. Words are back in style and more powerful than ever!

But, though they enable you to be precise in theory, words are open to vast interpretation and misunderstanding, by humans and agents. They also frequently require people to read things; some people will do this, but many will not4.

Especially for a vision generated by a UX team, it’s rare that these will do on their own for humans without being accompanied by visuals, but when the narrative is complex, requires technical detail or this is the best approach for your audience, the key element here is to be concise5 and clear, even though the format invites you to do the opposite.

Product vignettes

A version of a deck in practice; by product vignettes, I mean a story told through moments in time in a product. This is particularly useful to convey how product usage could change over time — on day one, the user does X; on day 30, they do Y. This approach is more emotional, leaning into storytelling and showing the role of a product in users’ lives.

Often we use wireframes here or product illustrations rather than real UI, focusing on specific evolutions and how they impact user behaviour.

This is compelling, but risks feeling ‘fluffy’. Technical leaders think it sounds lovely, but don’t know what to make of it in reality; it doesn’t provide as clear or detailed of a path from here to there. This might be intentional, but will mean getting buy-in might take a lot of clarifying around what exactly we’re looking at, and what comes next.

A last word to the wise

An important caveat on all of the above: when I was getting married a good friend gave me the advice that “the seating chart will tell you what to do” — meaning how to arrange your people amongst your tables will become clear as you go.

This struck me as true well beyond this context — your vision work will tell you what to do, i.e. what form your vision should take. First and foremost, go with what you are hearing from the people who will consume it. Treat the vision itself as a product; the people who use it are the ones who will tell you if its working; and as far as the agents who consume it, you’ll need systems to evaluate that yourself!

Either way, the work isn’t done when you share the thing — its how vision becomes reality, whether and how the chapter you’ve written get codified in the experience and influences what comes next.

From gazing into the future, thinking life could be a breeze,

Danielle.

Meet our boss!

In this very special edition of Dear Danielle & Dave & Friends, we sit down with Matt Davey, Chief Experience Officer at 1Password, and the person who has to put up with our antics daily at work.

Matt says the three of us are like “peanut butter, jelly and mustard” (not derogatory?). We think this makes for a pretty great combo — and this conversation will give you a glimpse not only into Matt’s point-of-view, but also into how the three of us lead together.

Matt has led the user experience team for a whopping 14 years. We are both part of the org he’s spent over a decade building alongside cycling through his many eclectic hobbies for much briefer stints, such as printmaking, radio, chocolate-making, 3D printing, biking, and surely many more. He also cohosts 1Password’s security podcast, Random but Memorable, and has his own excellent blog on design & leadership.

Recently Matt went viral on LinkedIn with the AI maturity model he developed to assess UX maturity in the age of AI (which was subsequently expanded by Jakob Nielsen - no big deal). We had a conversation with him about just that, hiring, and much more.

Below is an edited summary of our conversation. This is a longer ep with lots more in the pod, including clues to the blog title, so be sure to listen!

We discuss:

• Why AI has raised the floor of design work without yet raising the ceiling

• The art-to-science hiring philosophy behind our team, and why AI is making the middle of that spectrum fall out

• Why his viral design maturity model isn’t a career ladder

• His long-standing allergy to frameworks, and why he built one anyway

• What it actually takes to lead a team through “full steam ahead” when nobody’s sure the ground will hold

You’ve built our team around the idea of a spectrum, from the art side of design to the science side. How has AI changed that?

I’ve always thought about design as a spectrum — there’s a playful, art-driven end and a more rigorous, science-driven end: the behavioural loops, the IA, the strategic “we’re building this to solve that” side. AI has basically made the middle of that spectrum fall out, because you can now go so much deeper into one side or the other. If you really enjoy the behavioural loop side, nudging users toward something, figuring out the flow of information, you can now do that with quantities of data you’ve never been able to deal with before. And the same is true on the other end — you can lean all the way into becoming a front-end developer while still holding design as a craft. I don’t think you can do both anymore, and honestly, I’m not sure you ever really could.

When I’m hiring, I look for the thing that makes someone’s face light up when they talk about one specific part of the job. I think almost everyone great on our team has one of those things, and we try to give them as many problems shaped like that as we can. Going deeper into AI has mostly just made people go deeper into one area of that spectrum, rather than smoothing everyone into the same shape.

There’s a real risk there too, though — that AI just makes everyone competent at everything and nobody exceptional at anything. How do you coach people to double down on what makes them distinct?

AI has definitely raised the floor. It hasn’t yet raised the ceiling in everyone’s hands. I think where people end up specializing versus smoothing out comes down to expectations. If you care about interaction design and getting something finessed and perfect, and then you go to content design and just accept whatever the model gives you, that’s the split — some people are using it to get better at the ten percent that’s genuinely hard, and some are using it to cover everything at a mediocre level. Both are happening. But the really great work comes from people using it to move that last ten percent, not to try to do it all.

That does mean staying flexible about what you think you’re hiring for. I’ve changed my mind about what we’re looking for more times than I can count, because a great person shows up who lights up over something completely different than the role on paper. You’ll regret filling the hole. You won’t regret hiring someone great, even if they don’t perfectly fit the shape you had in mind.

Your AI design maturity model went viral in design circles. What do you think it was about it that resonated?

Honestly, I almost didn’t post it. I was going to keep it just for us to use as a reference. I ended up sharing it because another VP asked how I was thinking about our AI adoption, and I sketched something rough in FigJam — here’s roughly where we are, here’s where I’d like to be. Having that basis for a conversation, even if the model itself is wrong, turned out to be one of the more useful things I’ve done.

I think it landed because so much of the AI-and-design conversation has been relentlessly negative — “AI can make a rectangle, we’re done,” “PMs can prototype now, that’s us finished.” It’s not nuanced, and it doesn’t give anyone anywhere to stand. The model gave people a place to say, here’s roughly where we are, here’s where we want to go. It resonated because it was a way out of the doom spiral, not because it was right.

Share Dear Danielle and Dave

You’ve said before that you hate frameworks — and yet here you are, having built one. How do you square that?

I really do hate frameworks, if I’m honest. I understand why we need career ladders, why we need some objectivity in measurement. But a sports team is probably the better analogy — you can have the best chess pieces on the board and still lose, because the outcome is judgment, constantly, not just the individual pieces. That’s why the one thing I didn’t want the maturity model to be was a career ladder or an expectation placed on an individual. It’s a level above that. If someone doesn’t do well, it could be the tooling around them, the maturity of the team, the delivery process — none of that is necessarily on the person. Frameworks tend to fail because they assume everyone is in the same place, skilled in different ways but played in exactly the same position.

What’s your advice to leaders trying to convey confidence to their teams right now, when so much is genuinely uncertain?

Part of me wonders if I’m the wrong person to ask, because I probably went into this with something verging on overconfidence. I ran when I probably should have jogged. But I think that’s what the moment required — if the person leading the charge isn’t confident, everyone else just defaults to “this seems bad, let’s avoid it.” We ran an offsite where we asked people to ship something to production, and the wave of emotions in that room was real — panic at eighty percent of the day gone, then euphoria once things started working.

I think the job of a leader here is to have an opinion, grounded in something real, and to actually push forward with it rather than adjusting constantly, because constant adjustment doesn’t build anyone else’s confidence. But I was careful not to turn that into a scoreboard — I originally wanted to track who’d shipped a PR and who hadn’t, and I’m glad I didn’t. Everyone’s learning curve with these tools is different. It’s on leadership to prove the tools are useful and show how, and then get out of the way.

Lightning round

Best leadership advice you’ve ever received?

The problem with getting advice after being in a role this long is that every piece of it was really good for one specific era, one specific scale, and none of it ages well. So the best advice I’ve ever gotten is: start again. Break down your role and rebuild it as often as you need to, because anything you hold onto too tightly slowly deteriorates — a critique format, a team newsletter, anything. Throw out advice the moment it stops working.

Who’s a work bestie who’s helped you along the way?

Our colleague at 1Password Matt O’Leary. He’s an incredible soundboard — optimistic when you need him to be, but never a false positive, so you always know when he actually means it.

Huge thank you to Matt for joining us and sharing some truly wise words; and we’re not just saying that because he is our boss, we swear!

Matt’s building a trivia game called Cloakword, where you’re given an article with the title redacted and have to guess it from the clues. It’s free to play, though he’s kind of hoping it doesn’t go too viral, on account of the API bill.

Dear reader,

We’re heading to a company offsite in a couple of weeks, so we’re taking a wee little break from writing and publishing until we’re back. In the meantime, we’d like to share some of our favourites from the archive, in case you missed them the first time around.

Happy reading! See y’all back here in a couple of weeks!

This one is our absolute favourite and best post by far. Danielle wrote about the difference between speed and momentum — and why momentum, not just speed, is what actually builds trust and buy-in with stakeholders. Danielle will actually be bringing this topic as a workshop to this year's Elevate Festival. If you're in the area, be sure to check it out!

Leading a team through AI change means balancing two audiences: your reports and your fellow leaders above you. Danielle wrote about learning to sit with her own conflicted feelings, and why honesty, transparency, and genuine (not toxic) optimism are what actually help a team find its footing.

There’s been a lot of going on this year in and out of work. It can feel like a lot, overwhelmlly so. Dave wrote about the mindset of breaking problems that seem too large to tackle into smaller chunks so they are more manageable and feel more solvable.

AI has genuinely helped so many of us solve problems in ways we weren’t able to before. But it’s taken something away too — the apprenticeship-style grind that quietly built our judgment. Dave wrote about what that means for the juniors coming up now, and what we owe them.

Brooke came onto our podcast and talked about how change management is the defining challenge in tech. That is especially true now as every company is going through this AI transformation, and many are dealing with the fallout as a result of that. Brooke shared with us the lessons she’s learnt manaing change as a people leader throughout her career.

Tino came to us with something many of us have been observing in this age of AI: AI is making teams skip the alignment work, and the functional culturew we have worked so hard to build as UX leaders, might be part of the problem. Tino shared his thoughts on the root causes and what might leaders do to start addressing the problems.

From practicing “whiz wit” in front of the mirror,

Danielle and Dave

Share Dear Danielle and Dave

Dear Danielle,

Lately I’ve been thinking a lot about the artifacts we make for internal stakeholders, and whether we’re applying the usability rigour we apply to the products we ship to external customers.

Collectively as a product, design and engineering org, we obsess over who our customers are, what they need, what competitive products they already use, and how we can solve their challenges better. We painstakingly test and retest concepts and prototypes to make sure the product is highly usable, study what messages resonate, and partner with our Marketing and GTM friends to devise a plan that makes it all stick in market, all in the hopes of finding that ever-so-elusive product/market fit for new features that propel us to the next level of growth.

Yet we don’t apply that same care when we make artifacts for internal use. Many teams still view artifacts as outputs to send out for people to read, instead of products we ship for people to use. Even the language we use, artifacts, sounds inactive, whereas a product is something someone else has to actually use, and use well, for it to have done its job.

Share Dear Danielle and Dave

Take personas as an example. Everywhere I’ve worked, there are two main “target consumers” for personas. Managers and ICs treat them as a detailed instruction manual, build work off them and rely on them to steer roadmap direction. These folks need the details. Then there’s leadership: the directors and VP-and-above folks who just want the headline. They want a high-level understanding of who these personas are, enough to remember a thing or two and speak to them with confidence. Nothing more, nothing less.

Yet most research teams make one single version, built for one audience’s use case and consumption style. Most personas are incredibly dense infographics with accompanying documents that feel like academic research papers. The usability leaves a lot to be desired.

In many ways, AI has worsened this problem. We can now vibe-code a slide, a doc, a dashboard in the time it used to take to write an outline. That’s been genuinely helpful in so many cases. But most of the people building these things were never trained to think about usability, hierarchy, or who’s actually going to read this and how. With AI, more people can create artifacts faster than ever, but the audience-awareness our job still demands didn’t scale with it.

I’m not advocating for weeks and months of usability research on “onboarding_flow_dashboard_v5_final_final,” or a full-fledged GTM motion so every person in the org can recite the marketing copy. But a version of that thinking, scaled down, would go a long way: who is this actually for, what’s the one thing they need to walk away knowing, is this the right format for how they’ll consume it, and is now the right time to send it or is it competing with six other things in the chaotic land that already is Slack?

We UXers already know how to build something a customer trusts enough to come back to; the people we work with every day should get that same care. Not only does that help differentiate us and highlight our strengths, but being better understood and getting more buy-in also translates to better customer outcomes down the line.

From reading an email that really should be a meeting,

Dave

Dear Dave,

Last week a designer asked me: what makes a good design vision?

This comes up often. “Vision” can feel lofty and intangible, even though developing vision is a standard expectation in senior product roles, hand-in-hand with driving strategy. Still, approaching vision work is daunting: where to begin? What to deliver? To who, by when, who cares?

Templates for this particular task come and go. Most visions take a few tries before reaching a canonical ‘final form’; even then, they fall out of date and get rebuilt anew.

Because a vision is a chapter in the story of a product, not the whole book.

The scale varies —1 a vision might zoom in on one problem, or look across the whole company — but its still a chapter we haven’t gotten to yet; it advocates for a direction to build towards. Once we start doing so, we’re already flipping the pages, wondering what comes next.

Subscribe now

Stay somewhere long enough and you start to see this happening at the organizational level.

At Wealthsimple, I joined at a time when the vision was democratizing wealth through managed investing: diversified ETFs that help you ‘get rich slow’. As the market demanded access to more tools, we expanded into trading and crypto. This wasn’t in chapter one, but the story widened: get rich your way, with a balance of investment types.

While the vision grew, it stayed anchored to a north star: making investing accessible to a new generation, without the barriers of traditional banking. Everything else was iteration.2

Within design, we’re often afforded the opportunity to make visions legible — to do the showing that brings the telling to life. And at our best, we pull vision up ourselves from the customer and product knowledge that shapes all the small decisions we make daily, to form something bigger.

So what makes a good vision isn’t the artefacts — though those are worth plenty, and their quality is a bellwether for the quality of your thinking. Its whether the vision positively shapes how the product is perceived by the real people who use it. The plot moves forward, and the hero — the user — moves with it.

Internally, a good vision goes viral3. People ask for the link. It gets shared in rooms you’re not in. It answers pressing questions about where we’re heading next, and inspires new ones about whats possible after that.

So if a vision is a chapter, it takes some pressure off. You’re not writing the whole book. You’re building on a foundation, with more to come after your part. I’ve worked on many visions, and seen them fail, flourish, and eventually get remixed and rewritten.

The first step is to figure out the shape of the chapter: the piece of the story we need to change now, and why. What new forces are at play in our hero’s world, driving us to need to do something differently?

Define the plot points that matter, with whatever tools are best for the job, within some reasonable constraints on time, and certainly not alone. The form it needs to take to make sense to others — ⚠️ intentional hand-waving ahead ⚠️ — will become clear along the way.

Finally, I will leave you with my personal favourite vision ever articulated4:

This is part 1 of 2; next post I’ll share my perspective on the qualities of an effective vision and some examples of tactics I’ve seen work well in practice.

From scream-singing Unwritten by Natasha Beddingfield, because the rest really is still unwritten(nnnnnn🎶),

Danielle.

In our Dear Danielle & Dave & Friends series, we bring you interviews and letters from leaders in tech, focused on the topic they’d most want to chat about with other leaders.

Meet Jessica Pavia. Jessica leads both UX Research and UX Operations at BMO, where she supports a research team of 25 and an operations team embedded across a broader experience practice of over 110 people inside one of the more regulated, higher-stakes environments out there. Before BMO, she built her career at IBM and helped establish a design research discipline at Loblaw Digital, taught applied research methods at Seneca and Sheridan, and has spent most of her career, by her own account, in the business of patterns, which she traces back to being a kid obsessed with Where’s Waldo.

Jessica came to us with a mandate that’s been following her around for most of her career: “do more with less.” She’s got a lot to say about what that phrase actually means, what it doesn’t, and how she’s learned to translate it into something a team can act on without burning out. Below is an edited summary of our chat.

We discuss:

• Why “do more with less” isn’t a euphemism for working harder, and what it actually asks of a team

• The question she asks before approving any plan: what would you do with half the time?

• Where she’s found the highest-leverage place to cut, and the one thing she’s refused to

• What efficiency looks like in a highly regulated industry

• Why AI only earns a place in her team’s workflow once it’s been tested hard enough to break

You’ve been handed “do more with less” more than once in your career. What does that phrase actually mean to you at this point?

It means be intentional. Every process, every meeting, every investment has to earn its place. I think about this a lot through the lens of my grandmother, who’s Italian. She used to say “meno è più”, which literally means “less is more”. And it took me a long time to understand what she meant by that in a work context, because the blunt interpretation of “do more with less” might be perceived as simply working harder.

So a few years ago, when that mandate came down to my team, I introduced a simple quarterly check-in. Once a quarter, I’d ask researchers about the work they were doing: the types of studies, the volume, how fast things were moving, how many insights were actually driving action downstream. It wasn’t rocket science.

But what emerged wasn’t just the data. It was the story: where teams were thriving, where there was friction, where we had real benchmarks instead of vibes. That’s the difference between doing more with less and just doing more.

How do you actually turn a vague mandate like that into something your team can execute?

I’ve been trained to never measure change without a baseline, so that’s always the first question: where are we starting? A lot of leadership, I think, comes down to storytelling: figuring out what story you want to tell about where your team is creating value, and then finding the data points that support it. If you’re a leader, that might be the story of how your team’s working and where you’re seeing improvement. If you’re an individual contributor, it might be the story of how you refined a process or looked at a problem differently to save time or money.

For example, we focus heavily on removing friction through tooling, but every tool has to earn its place in the stack. We spend real time piloting before we adopt anything, which takes longer than some faster-moving industries might tolerate. What I won’t compromise on is anything that touches risk or customer trust. Those aren’t trade-offs to me. I think of them as foundations.

Banking has a reputation for moving slowly. How has working inside that constraint actually shaped how you think about efficiency?

Honestly, before I joined banking, I heard “banks move slower” a lot, and I was hesitant about it. But I’ve come to see it differently. When you’re helping people manage their money, their security, their future, that’s a real responsibility. (Yes there are) more stakeholders, more approvals, more regulatory considerations. That’s just the nature of the environment, and it’s how you choose to see it. I think about those constraints as a creative challenge. Some of the best work I’ve done, and the best work I’ve seen from my teams, has come out of working inside them.

I say to my team a lot: we move as fast as we can, but with rigour — that doesn’t get compromised.

And practically, there’s a question I ask constantly when someone brings me a research plan or a new workflow: what would you do if you only had half the time? Not because I want people to work faster for its own sake, but because the constraint reveals what actually matters. When everything feels important, it’s hard to know where to focus. I also push my team to bring multiple plans, not just one: show the different costs, the different options, and if we only had one bet, what it would be?

Is AI genuinely buying back capacity for higher-value work on your team, or is it just one more thing to manage?

I’m in the camp that it’s genuinely buying back capacity, with a heavy dose of caution attached. I’ve seen researchers, designers, and operators use it to simplify the repetitive work that doesn’t create much value on its own, which creates more room for the things humans are uniquely good at: critical thinking, judgment, connection. But I’m curious to a fault, so my excitement always comes with caution. I believe in piloting before scaling, and honestly, trying to break a tool before I trust it.

I don’t think of AI as valuable because it’s evolving. I think it’s valuable when it earns its place, the same standard I’d apply to any tool. Where does it actually earn its place in the workflow? Is it enhancing the work or breaking it apart, and how are we testing that?

The goal was never just about doing more. It’s about creating room for the meaningful work, and figuring out how AI can help with that.

Lightning round

Best leadership advice you’ve ever received?

Early in my career, a leader I worked with forwarded me along an invite to a meeting with an executive team. I wasn’t presenting, wasn’t really expected to say anything. But before we went in, she asked me one question: what are you bringing in with you? It reframed accountability and leadership for me completely. The goal was never just to earn a seat at the table. It’s to contribute something meaningful once you’re in it.

Who’s a work bestie who’s helped you along the way?

Christina Cornacchia. We were research leaders together earlier in my career, growing and supporting teams side by side. She has this rare combination of pragmatism and empathy; I could bring her almost anything and she’d cut through the complexity without ever losing sight of the people involved. I joke that she’s on my board of directors for decisions. The higher you go in leadership, the fewer people there are who truly understand the weight of what you’re carrying, and Christina’s one of the people who reminds me I don’t have to figure it out alone.

Huge thank you to Jessica for joining us and for the reminder that “less is more” is a discipline, not a shortcut.

Dear Danielle,

In tech we talk about ownership a lot. You know this as well as I do. We have a dedicated item in our career ladder called “radical ownership,” where folks are assessed on whether they can own initiatives from start to finish, make sound decisions, and ultimately be accountable for the work they lead. It’s often the clearest indicator of how someone’s showing up against the expectations of their role.

However, as we inject more and more AI into our workflows, how far does “radical ownership” extend to your agent’s work too? I’m starting to see individuals and teams lean on AI for their work, then step back from taking full ownership of what the agent actually did. When I talked to them, the argument is always some flavour of “well, I can’t control when an agent drifts,” or “the agent isn’t following my already very detailed instructions.”

I get why people reach for that argument. It’s a lot easier to point the finger at an abstract entity that sometimes seems to have thoughts of its own. (And no, I’m not here to get into AI anthropomorphism or whether we’re approaching AGI or the singularity. That’s a whole other can of worms.)

But my take is that owning an agent’s output doesn’t require predicting its every move. It requires the same thing good management has always required: enough upfront diligence to catch the likely failure modes, and enough review before anything ships to catch the ones you didn’t predict. Guardrails narrow how often drift happens and how much damage it can do when it does. They don’t make an agent’s behaviour fully knowable in advance, and I don’t think anyone should claim otherwise. So if the owner can’t get all the way ahead of an agent’s actions through planning alone, and they won’t always be able to, then the responsibility shifts to putting in guardrails and doing real review of the work before it’s handed off or made available to general access.

Share Dear Danielle and Dave

Many people equate using AI with hiring a bunch of interns, and I think the same metaphor holds here too in the context of ownership and accountability. When interns make mistakes, you don’t throw up your hands and say “well, I guess I can’t control what the intern did.” No. You go talk to their manager, because it’s the manager’s job to own the intern’s output. Because when it comes to interns, more often than not, it’s someone senior who puts their name on it and says “this work is ready to represent us.”

Now I’m mostly talking about internal use cases here, where we build agents to power our own workflows, processes and infrastructure. But I think the argument holds for external use cases too, where the stakes are arguably much higher. And this conversation about accountability and ownership is going to land on UX more and more. When our own teams ship agents into our products and those agents drift, who owns that mistake? I think it’s on us: the team who researched, designed and shipped the thing.

Now, I want to be careful not to conflate accountability with zero tolerance for mistakes. Agent drift happens. Learning to spot it, correct it, and build better instincts around it is part of the job now, the same way learning to review a junior’s first pass was always part of the job. As leaders, we need to create room for that learning to happen, not just demand flawless output from day one. But holding space for the learning curve and holding people accountable aren’t in tension. You can be new to this and still be expected to fully own what you ship, including your agent’s part in it.

Here’s the bottom line I think people need to remember: the agent doesn’t get fired. It doesn’t lose customers. It doesn't sit in the room when our work gets critiqued. Agents don’t lose trust with our stakeholders. We do. They have no stake in the outcome. We do.

Ultimately this is about owning the work, and making sure the outcome puts you and your team in the best light, regardless of who, or what, actually produced it. We as humans simply can’t abdicate that.

From blaming autocorrect for a typo I definitely made myself,

Dave

Dear Dave,

Have I ever introduced you to my dear friend, imposter syndrome?

Even if I haven’t, I assure you, they’ve been in the room in many of our interactions, and in fact are there most of the time. I greet imposter syndrome whenever my thoughts creep towards those perpetual doubts of how did I get here and what do I know and when will they all find out and so on and so forth.

This is a relationship many if not most of us engage with in our work lives, especially leaders, and one that there are many ways to manage — but personally I find acknowledging the feelings as just that (not facts!) helps me keep it at bay.

AI is of course adding a whole new layer to imposter syndrome.

On a recent episode of Work Life, Ify Walker described the idea of the “work twisties” - times where you feel a disconnect between what you know and how to actually do it.

I found this notion really resonant in a moment where a lot of us are feeling some amount of disorientation in response to how AI is coming into our workflows. The ways of doing design and research work that define our craft are changing so immensely that it’s creating a real sense of displacement and disconnect from how to do things we know in our bones how to do.

The way that I’ve always handled my imposter syndrome is by naming it. It doesn’t mean I don’t hear the voice everyday, but I have built an accepting relationship with it, and I do my best to focus on the real data before me, namely how I show up, get the work done everyday, and the positive outcomes that drives consistently.

In the interview, Ify describes a similar practice for approaching her work twisties: making a list of fact vs. story. What’s true, and what’s the narrative on top that’s twisting the facts and making things hard to approach?

That won't work for everyone. Having these insecurities is fairly universal; facing them is highly personal work. And certainly naming the twisties won’t make them go away; mine are still very much in the room as I write this.

But it helps me tell the difference between "I don't know how to do this yet" and "I was never any good at this," which feels like an important distinction right now, when so much of what we know how to do is changing shape.

Imposter syndrome and I go way back. The work twisties are new to me, but I have a feeling we’ll be getting to know each other well.

From never having been able to do a cartwheel but trying anyway,

Danielle.

Dear Danielle,

I got some amazing news last week that absolutely made my day: a mentee of mine finally landed a job after months of searching and interviewing!! (LFG!!) It was truly blood, sweat and tears.

They landed an entry level position at a large Canadian company. It’s not their dream job per se, but it sounded like a great opportunity for someone who’s been trying to break into the industry. As we have received many questions on this, getting the foot in the door is often the hardest part for junior designers and researchers.

At the same time, I can’t help but wonder (and worry) how well my mentee is going to be supported by their new team, new manager and the larger org. Especially as UX continues to face the onslaught of AI mandates and the pressure to demonstrate the impact of such tools as an industry.

But zooming out, the larger picture I worry about more is how tempted, or even forced, the new UXer cohorts are going to be to take shortcuts.

I’ve written about this before: AI is giving researchers at all levels something we’ve been asking for for years. By offloading many tasks like tagging, synthesis and analysis, either partially or completely to AI, we now have more time to think. More time to be strategic. More time to actually influence the things we’ve always said we wanted to influence. Many of us would agree it’s truly been a gift.

But gaining something usually means giving something up too, whether we notice it happening or not. The work many of us have been able to offload to AI, we can offload because we already built the judgement and deep intuition to assess whether the output is any good. That judgement was honed through the slow, unglamorous work of sitting with transcripts, tagging themes, writing and rewriting the insights until 5pm on a Friday.

What I worry about now is that a lot of that unglamorous work, the work that quietly built our judgement, has disappeared from the career path entirely under the pressure of speed. And our juniors may be paying for it without knowing what they’re missing.

I’m reminded of my first years as a junior research analyst. I remember the specific feeling of being handed a stack of raw transcripts with no shortcut through them, and how much of a slog it was: reading through every sentence, highlighting key phrases, grouping them into themes. At the time I didn’t know I was building anything. It just felt like the job. It was the job! Today’s junior researcher is far more likely to be handed an AI-generated synthesis and asked to sanity-check it. Faster, yes. But they’re starting one step removed from the thing that actually taught me how to trust my own read on a transcript. They’re evaluating a conclusion instead of arriving at one.

What’s essentially happening is the apprenticeship model that quietly trained a generation of senior UXers is collapsing, and I don’t think many of us in more senior positions are being honest about what that means, or what we owe.

So what do we do as leaders? I don’t think the answer is to stop using AI. But I do think it means something changes for those of us who have already built the thing AI is now doing. If the messy work no longer happens naturally, we as leaders have to build and facilitate an environment to make it happen deliberately. Give the junior designers a bit more time to wireframe instead of jumping straight into AI prototyping. Pull a junior researcher into an actual synthesis session led by a senior UXR. Let them sit (or perhaps even force them to sit) with the ambiguity before the machine resolves it. Give them work AI could do, but don’t always let it.

I keep thinking about what it took to build the judgment I now get to use all day, and I’m not sure I would have built it any other way. My mentee starts their new job in a couple of weeks, genuinely thrilled, and so am I for them. I just can’t shake the question of whether the version of this job they’re walking into still has room to build what I built. And if it doesn’t, what our responsibility is to make that room ourselves.

From teaching my 8 y/o how to do proper push-ups so she can start building the reps,

Dave

In our Dear Danielle & Dave & Friends series, we bring you interviews and letters from leaders in tech, focused on the topic they’d most want to chat about with other leaders.

Meet Konstantino (Tino) Kapetaneas. Tino is Director of Product Design & Research at Flipp, where he’s led and grown the function for nearly eight years, building the UX research practice from scratch, scaling a 27-person team, and helping evolve the company’s product from a single app to a multi-product ecosystem. Before Flipp, he cut his teeth on the agency side in digital health, doing formative work with patient advocacy groups that, by his own account, set the direction for everything that followed. Dave and Tino are also old colleagues; and if you’re wondering whether they’re real-life besties, Tino’s official position is that he can neither confirm nor deny this. Tino has previously written for us and we were very excited to have him on the pod!

Tino came to us with something that’s been eating at him: AI is making teams skip the alignment work, and we’re starting to pay for it. Below is an edited summary.

We discuss:

• Why AI-enabled speed is surfacing alignment problems that were always there

• What happens when four stakeholders ship four competing prototypes before anyone’s written a brief

• The case for participatory design process — and why designers’ instinct to protect their territory is working against them

• Why functional culture, as we’ve built it, might be part of the problem

• What the design brief is doing now that the PRD used to do

You came in with a pretty strong take. What’s prompting it?

A few things. The first is kind of funny. We just did a company offsite with a Dragon’s Den–style pitching competition: use AI to build a new retailer brand from scratch, in 90 minutes. My team — people who’d never worked together before — came out with a deck, a valuation, a pitch to investors, and a theoretically functional prototype. We won.

Here’s the insane part. I won the pitching competition not really knowing what my business was all about or how I was going to run it. I don’t know the first thing about how to run the business I pitched. And I think that kind of underscores what we’re seeing with a lot of the outputs coming through AI-enabled workflows right now.

The second example is less simulated. I was part of a project recently where, at the very early stages, four different stakeholders had each built their own prototype. Nobody asked them to. None were made by designers. There was no product brief. That was how the project started.

What I found really interesting about that early stage was how difficult it was to decide what to do next. What were we evaluating these outputs against? What problems were we trying to solve? How would we know if we were going to be successful? And ultimately, the only way out of that stage — where you have four or more competing ideas, all high-fidelity, all very convincing — was to defer to the loudest or highest-paid voice in the room.

That’s a problem we’ve all struggled with throughout our careers. But with AI, it’s becoming way more common.

Is this AI breaking the process, or exposing what was already broken?

Both, I think. On one hand, I’m concerned about the dysfunction being cultivated as a consequence of this technology. At the same time, it does start to poke holes in the old guard — how we used to operate. And some of those holes were always there.

Take something small: have you ever had a PM request a Figma licence and quietly bristled at it? I say this facetiously, but I think designers can be sort of gatekeepy. Is that conducive to creating the best work possible? Probably not. And now that AI is giving product managers and engineers capabilities they didn’t have before, they’re looking over their shoulder at designers thinking: do I still need these people? The best way to counter that is to stop protecting the territory and start participating in a collective process.

So how do you coach your team through this?

The first thing I’d say is that what teams are experiencing right now, a lot of the time, is a vacuum of leadership. I don’t mean that to be extreme. I just mean that when everyone’s looking over their shoulder wondering if they can trust the person next to them, that’s often a consequence of there not being clear guidance about what to do in an ambiguous transformation moment. And you can point up to the executive layer and blame them — a lot of people do, and I struggle with it myself sometimes — or you can choose to find a path in the chaos and work with your peers to make progress along it.

More crafts-oriented people — designers and researchers especially — can be uncomfortable stepping into that leadership role. So a lot of what I coach my team on is: how do you label and manage uncertainty, and how do you step into that role even when your title doesn’t call for it? Go build relationships with the directors in other functions. That might seem like overreach, but sometimes you need to go up the influence chain before you can move anything laterally.

The other thing: write the brief. We’re seeing a world right now with less and less upfront documentation — no PRDs, no requirements, just outputs. So some of my team is picking up that slack. They’re writing UX briefs, articulating the problem, scoping what’s possible. Not because it’s a designer’s job, but because someone has to create something that people can align to. Even if it’s incomplete. Even if it’s imperfect. Just something to anchor to.

What’s the bigger structural shift you’re pointing at?

This is the uncomfortable part. I think horizontal functional leadership — the investment we’ve made in building functional teams, functional culture, functional identity — is going to have a hard time over the next five to ten years.

I pride myself on the product design and research culture I’ve helped cultivate at Flipp. And that’s a selfish viewpoint. Because what it also does is reinforce silos, even when we’re trying not to. And I think the next leg of our evolution is going to force us to come to terms with that.

In practice, what that looks like at the individual level: stop designing in a silo. Invite your PM and your engineers into your design critiques. Not just other designers. Yes, you’ll have untrained voices in the room — that’s uncomfortable. But that’s also how you build a joint culture around making products. The best teams I’ve ever been on worked that way: T-shaped people, a lot of trust, a lot of improvisation. You were playing jazz. And misalignment doesn’t just create dysfunctional teams — it ships to the products themselves.

Lightning round

Best leadership advice you’ve ever received?

Not from anyone who told me directly — I’m going to be lame and quote Steve Jobs. There’s a video from the early nineties where he talks about how the best managers come from craft experience. They need to know how to make things. They need to be great executors first, because the people working with them want to learn — and you can only teach what you know how to do.

That’s how I’ve built my people leadership layer. Great craftspeople first. The behaviours follow from that.

Who’s a work bestie who’s helped you along the way?

I have to give Dave a quick credit — he’s been incredibly supportive of my personal fitness journey, and I’ve built habits from time spent with him in the gym that I’ll carry the rest of my life. Outside of that: a product director peer at Flipp who’s just gone on maternity leave. She’s been a huge advocate for good product operations, standardised documentation, better roadmap practices. I don’t think I’d be nearly as involved in cross-company operations without the doors she helped me walk through. Genuinely grateful for that partnership.

Plugs

Tino just pre-launched his first home-built SaaS product: Acorn Pad, a privacy-focused digital note-taking app he built himself using AI. There is a floating teal squirrel. We enthusiastically recommend checking it out.

Huge thank you to Tino for joining us, and for articulating something many of us have been feeling but not quite naming.

Tino is based in Toronto and is indeed Dave’s gym buddy. You can find him on LinkedIn.

Dear Dave,

Recently I reconnected with a former colleague (hi Jeff!), and we got to talking about ambition.

I was reminded through our conversation about the early days of building my design skillset. I worked at a company where designers were expected to own everything from discovery through execution alongside developers, without support from specialized roles like researchers, content designers or ops. This was a great place to be when I was learning because it helped me grow in lots of different directions, and figure out what I wanted to do - and what I didn’t.

One such example was struggling over making an icon of an awning sufficiently ‘whimsical’, feedback that kept me up at night unsure how I could achieve that. I managed to get the awning right - and learned that an icon designer, I was not.

That was painful. But it was also instructive.

Knowing what I didn’t want to do helped me understand the kind of designer I wanted to be. And when I was given the chance to lean into the research and strategy work I loved, it was deeply affirming to be celebrated and encouraged for those skills.

Subscribe now

We tend to think of ambition as wanting something grand. But ambition can just be wanting something different. Ambition can be wanting to find a role that’s just right for you, that enables you to thrive and do your best work. Not to always get it right, and certainly not to always know what you are doing - but to love the work you do.

When I meet with people on my team for the first time, I like to ask them, what gives you energy? (Or using more vivid language borrowed from another former colleague - hi Polly! - ‘what fuels your fire?’) And what takes it away?

We often think of career growth in terms of promotions and salary. These things are very real, and very important. But the happiest people I know in their work are the people who made decisions to work places that embrace who they are, and where the work feels good day-to-day, because it’s aligned to how they work best.

I know this moment in the industry feels disempowering for a lot of us in UX, and with good reason. And: operating from that feeling of disempowerment creates poor conditions for doing your best work.

I still think about that awning. Not because I ever got good at making icons whimsical (or at all), but because of what the many, many hours I spent on it taught me about who I am as a designer, and who I’m not. When all was said and done and my icon made it into production, I knew something more about who I was and who I wanted to be.

I think that’s what ambition actually looks like much of the time. Not a big plan. Just paying attention to how you feel in your work, and redirecting your energy where you thrive.

From beneath a whimsical awning,

Danielle.

Share

Dear Danielle,

Bear with me as I talk about sports for a second.

On one of the recent episodes of “Dear Hank and John” (which as you know is the name inspo for our blog!), John shared the latest news on AFC Wimbledon (an English Football League One team where John is a minor investor).

They just wrapped up their season and barely staved off relegation. Now their focus during the offseason is to figure out how to do better next season (for us Raptors fans, this sounds painfully familiar).

AFC Wimbledon is a small market team, so they don’t have all the money in the world to acquire big-name players and improve the caliber of the team overnight. They recognize they have to work hard at developing the talent they already have to get better. John said something on the podcast that really stuck with me: “We can’t buy stars, so we have to make them.”

Deep down, I think what John is getting at is something most leaders know but struggle to practice: we need to have the patience to develop the talent we already have and see that through.

We’re wired for instant results. This is especially true in tech, where we move at breakneck speed so we can get to our next set of milestones and sprint towards the next one even faster. Now supercharged with AI, there’s seemingly “no excuse” to be slow. You wrote about all of this in your very insightful piece on drawing the distinction between speed and momentum.

The interesting irony in all of this is that our obsession with speed doesn’t give people enough room to show us what they’re truly capable of. We hire someone, put them on a team, and start the clock. But how focused their product area is, how collaborative their stakeholders are, how stable the org structure is when they join, how different the culture and ways of working are from wherever they came from — all of these things massively affect how quickly someone finds their footing. It takes a lot of luck for all of that to line up perfectly out of the gate.

Share

And that’s what makes stars — not talent alone, but leaders with the awareness to recognize that someone is struggling because of their environment, not their abilities. Yes, there are expectations for them to adapt, especially the more senior they are, but sometimes they just need a bit more patience and grace to succeed.

We don’t always hire instant stars on our teams. But in the cases where we gave someone more runway — moved them to a different product area, worked with them to find a more focused assignment, paired them with a stakeholder who had the bandwidth to collaborate — I’ve watched those same people become some of the strongest contributors on the team.

I don’t have a formula for how much patience is enough. Three months probably isn’t. A year with no signs of progress probably is too long. The answer, as with most things in leadership, lives in the uncomfortable middle.

What I do believe is that we can do better as an industry. The tech industry loves the narrative of the overnight success, the 10x hire, the person who walks in and immediately transforms the team. Those people exist, but they’re the exception, not the rule. And building a team strategy around exceptions is how you end up constantly hiring, constantly churning, and never actually building the institutional knowledge and trust that makes a team greater than the sum of its parts.

So we can all be a little more patient, a little more curious about what’s going on beneath the surface, and a lot more intentional about creating the conditions for people to succeed before we decide they can’t.

That’s the AFC Wimbledon lesson. You can’t always buy the star player. But more often than not the star player is already on your roster. You just need to invest the time to make them.

From explaining the offside rule to my kids for the hundredth time,

Dave

This week’s letter is brought to you by our brilliant colleague . Kate is Director, Culture & Organizational Initiatives at 1Password; in other words, she makes our work great to do everyday. Before moving into employee experience, she has a background in sales and customer success, and is a card-carrying Theatre Kid.

Dear Danielle and Dave,

I’ve been belting out show tunes since I could speak. I got an acting degree, wildly expensive headshots, an agent, and then made a genuine attempt to “make it.”

What followed was a humbling education in what making it actually required. (There was also a year as a Disney birthday party princess. Separate letter.) (Editor’s note: WE NEED THIS LETTER!)

Subscribe now

By 23, I’d made peace with the pivot, landed my first corporate job as a Business Development Representative, and discovered something unexpected: everything translated. It turned out that reading a room, holding attention when the energy shifts, and showing up composed when you’re not were not only stage skills, but enormously useful in meetings, presentations, and cross-functional conversations.

That translated skill set became the foundation of a decade of career growth.

It also, somewhere along the way, became the whole story I told about myself.

I leaned into it, and it worked. I built things. I read rooms very well. I got promoted — a few times. I got good at being good at work; and more than that, I understood why I was good at it. I began to know my competitive edge; what I didn’t notice yet was that I was also starting to become it.

There’s a difference between being good at something and that thing being the only role you can play. Knowing I could read a room and show up prepared stopped being a skill I had and started being who I was.

It showed up in small ways I didn’t clock until I started looking back. I almost never said “I’m not sure” in a meeting. I rarely let people see me working something out in real time. If I didn’t have a fully-formed answer, I’d hold the question until I did.

Being polished became non-negotiable, not because anyone asked for it, but because I’d stopped being able to separate the skill from the person doing it.

I’m eleven years into my corporate career, and I’m reflecting on what kinds of skills are actually required for the leadership level I’m now at. Realizing that skills are, in fact, just skills has been a reminder that growing as a leader involves pausing to ask what each skill is in service of. The most interesting leadership work, I’m slowly learning, starts when you let people see more than the finished version.

My identity is bigger than any one thing I’ve refined over the past decade, and so is the work.

Somewhere between the birthday parties and the corporate offsites I’ve learned a lot, but many parts of me are still in rehearsal. As we know in the theatre world, that’s where all the real work happens.

From a retired birthday party princess,

Kate

Share

Subscribe to Kate’s substack for more of her writing. 💙

Dear Dave,

A few weeks ago I wrote about speed vs momentum and the perceived perils of process in tech. We do not trust the process. We often loathe it, in fact. The process slows us down and must be disrupted! (Cue pitchforks.)

I also wrote a while back about solving problems in our AI solutions-focused era, noting that:

“The design process has always been adaptable done right — grabbing the pieces we need, leaving behind the ones we don’t, moving at the speed demanded by the problem at hand.”

As you can likely glean, I am something of a process nerd. I love seeing how people adapt and remix processes to solve problems in new ways and pull humans together to do hard things well. There’s delight in the “product-y” way of looking at the world — always looking for opportunities to shift left, try things differently, and see what learning comes out, not just in what we ship, but how we ship it.

I’ve always been conscious of the Feelings process can inspire in others — whether negative (“boo meetings!”), unproductive (“more meetings!”), or dismissive (“don’t talk to me about meetings!”).

But process is how things happen. It reflects the deeply human nature of product work: the thinking, the doing, the dot-connecting we do together as a team to make something other humans find genuinely useful.

And lately I’ve noticed a fascinating development: suddenly, everyone seems to care about it.

Subscribe now

Specifically, there’s a new emphasis on process improvement through AI — in particular, a fixation on personal software, tools you build for yourself at work whose only purpose is making you happier and more efficient. We are being more prescriptive about process than we’ve been since the days of waterfall and scrum, and the prescription is simple: use AI.

Dave recently wrote about AI learning and development, and I’d add: it’s a marvel how much space we’re being afforded to learn these tools on the job, often without any specific metric besides usage (yet).

It’s a curious phenomenon, and one many find rightly frustrating. Adopt AI tools — why? For what? We might respond: tell me what problem you think this can solve, and let’s see whether it actually makes sense.

But tucked inside even a blunt mandate is an invitation: to look at how we work, interrogate the defaults, and ask whether what we’ve been doing is the best way to do it. That’s what I’m embracing — the focus not only on building, but on how we build.

Process, at its best, is just that question, made repeatable.

From shuddering at a distant memory of the job title “Scrum Master,”
Danielle

Share

Dear Danielle,

I own an EV that can self-drive, and I love it.

I didn’t always. In fact, I was pretty skeptical of the technology. I’ve always considered myself a skilled driver, certainly better than most.

But honestly, safety wasn’t the deeper issue for me. I’m far from a gearhead, but I’ve always enjoyed driving. I’ve owned a car for as long as I can remember, and there is something freeing about rolling down the window, going at a speed that’s just dangerous enough, sometimes lost in thought while listening to my favourite tunes. Cliché, I know, but there is something romantic about it. Driving has always felt like one of those rare adult activities where you are fully in command. It’s a small, daily act of mastery.

So no, it wasn’t just safety. I was worried about what I’d lose. That if I started outsourcing what I’d practiced for decades to a machine, I’d stop being good at it. That I’d become a passive passenger in an experience that used to be mine.

I think a lot of us are sitting in that exact same seat right now with AI at work.

We all have skills we’ve built over years, sometimes decades. And for many of us, those skills aren’t just things we do — they’re who we are. “UX Researcher” and “Product Designer” aren’t just titles, they’re our identities. So when we’re asked to hand over part of our craft to a machine, it feels like more than a workflow change. It can feel like giving away a piece of ourselves.

And the fear isn’t irrational. There’s a real use-it-or-lose-it tension here that I don’t think we talk about enough. If a researcher stops doing synthesis because an AI handles it, can they still call synthesis a skill? If a designer stops building from scratch because they’re iterating on AI-generated prototypes, does their craft atrophy? The muscle memory, the intuition, the hard-won instincts that come from doing the work — they’re how we became who we are professionally.

So I get the resistance. I really do.

But here’s what surprised me about my car.

When I finally started using the self-driving feature, I realized I’d been so focused on what I might lose that I’d completely failed to consider what I could gain. Driving demands enormous cognitive load. Your brain is constantly processing road signs, traffic lights, other vehicles, pedestrians, construction zones. You’re scanning for danger all the time. It’s exhausting in a way you stop noticing because you’ve been doing it your whole life.

By letting the car take over, especially on long highway drives, I got some of that capacity back. I started actually listening to podcasts instead of half-hearing them. I had deeper conversations with others in the car instead of giving them the distracted quarter-attention that driving allows. Sometimes I just sat there and thought. The irony is that the thing I was afraid of losing — that feeling of freedom on the open road — I actually found more of once I stopped white-knuckling the wheel.

Share

So I think our relationship with AI at work can follow the same arc. But only if we’re honest about what it actually costs — and deliberate about what we do with what it gives back.

Sometimes, I still have to intervene with my EV. The technology isn’t perfect. It gets confused by construction zones, hesitates at unusual intersections, occasionally does something that makes my stomach drop. But each time I take the wheel back, I become more cognizant of exactly where the machine’s judgment ends and mine begins. The imperfections end up drawing a sharper line around what actually requires a human. And that clarity is harder to develop when you’re doing all the driving yourself, because everything felt equally mine.

I wonder if the same might be true for our craft. Maybe researchers who let AI handle the templating and transcript processing don’t lose their synthesis muscle — maybe they develop a sharper sense of where synthesis actually matters, because the machine shows them exactly where it can’t do what they do. The imperfections become a mirror for your own expertise.

Because the hardest part of all of this isn’t learning the tools. It’s grieving the version of yourself that was defined by work you’re now being asked to let go of.

Instead of turning me into a passenger, the self-driving car turned me into a different kind of driver — one who’s learning, through every glitch and hesitation, exactly when to take the wheel and when to let go.

The mastery shifts. It doesn’t disappear.

From writing this in the car while the robot car is driving,

Dave

Meet Brooke Sykes. Brooke's career started in academia before pivoting into policy research with the Ontario government, and then into tech at Mozilla in 2022, where she now manages a user research team. She came to us with change management on her mind, and we got into the often underrecognized emotional side of navigating change. Below is an edited summary.

We discuss:

• Why change management is the defining challenge of this moment in tech

• The gap between a mandate and a strategy your team can actually use

• What researchers’ instinct for scepticism looks like when you point it at AI

• Why not having a playbook might be the most honest thing a leader can offer

• The emotional dimension of change that tends to get skipped over

You chose change management as your topic. Why is it top of mind right now?

I think it’s really the defining challenge of the moment that we’re in in tech. With change brought about by AI, but even in the last few years — teams contracting, layoffs happening — people are grappling with those changes.

And specifically right now, the change management involved in taking a mandate like use more AI on your team. We have more AI tools available. They can unlock really great things. But translating that mandate into actual change that people on my team can adopt, can feel good about — things can get really, really fuzzy in there.

So how have you approached it?

I try to be really transparent — share whatever information I get about what the expectations are across the org, and then get the team’s input. Really have an open discussion: how are you feeling? It’s okay to have questions and doubts. We can learn about this together.

And one of the things that has come back to me a lot as a leader is that you don’t need to have all the answers. I’ve really tried to communicate that we are figuring this out together. Nobody really has it figured out at this point.

What are the most common pitfalls you see in communicating change?

One is the emotional dimension. Change isn’t just a new tool or operational. It’s the people behind it. A lot of our professional identities are bound up in our expertise — and right now, some of that expertise needs to be expanded and rebuilt. That can be tricky.

The other one is that gap between a mandate and a strategy that the team can actually employ. Even well-intentioned mandates can stall if there’s no clear strategy: what tools, how do I use this, how do I still verify the work? That’s the messy thing we’re working out right now.

Researchers tend to be skeptical by default. What does that look like when you point it at AI?

With researchers, the default stance is one of skepticism, critical thinking: can I trust it? Is it good quality? And if you throw in a black-box AI technology, all sorts of spidey senses go off.

And I think that’s okay to have those questions. My team asks really smart questions — some that give me pause and make me think more even about the technology.

When we mapped out our research process to figure out where AI might fit, it became clear that some folks weren’t really thinking about it as I use AI for this or that. They were already embedding it into their entire day — using it as a thought partner, asking it to poke holes in their work, doing a first pass of synthesis and then asking an LLM to check what they might have missed.

So there isn’t one way to use it. And how you match the different ways of using AI to the context you’re in — level of risk, timeline, what the stakeholders need — that’s where the judgment comes in. I first thought I’d create some kind of model everyone could adopt. I’m less and less thinking that’s possible. It’s more about understanding the technology and the contextual constraints and making a really good decision.

What about harder changes — personnel changes, layoffs?

Even when a few people are let go, it’s emotional. It’s okay to feel sad about it, and to give people time to process it. Sometimes we’re losing people who are friends, or part of our work community. It can bring up job security anxiety: why them? Am I next?

I try to share information as soon as I get it — whatever I’m able to share, I pass it down so folks hear it directly, and don’t have to fill gaps of information with assumptions.

And it impacts people in different ways. I’ve always been touched when people have reached out to me too — acknowledged that even though I hold a leadership position, it’s impacted me as well.

Is there a playbook for any of this?

I wish there was a playbook for everything. But admitting when you don’t know the answer — I think that can go a long way in building trust with the team.

I think that was part of my trepidation stepping into a leadership role: people are going to turn to me and want answers. But getting really comfortable with nobody does — saying, I don’t have all the answers, we can figure this out together — has felt right. We’re going through this together.

Lightning round:

Best leadership advice you’ve ever received?

That you don’t need to have all the answers. You just need to know how to find them.

A previous boss of mine had this really effective approach — she’d put some of my questions back on me. Not just what do you think we should do, but: what would success look like in this scenario? What are our options for getting there? What do we want to try next? When I later took a coaching workshop, I recognized that framework immediately.

Now I try to resist the temptation to jump straight into problem solving. Somebody on your team asks a question and you want to say, well, I think you should do this. But sometimes I’ll take a beat and say: what would success look like here? Let’s talk through the options and land on something together.

Who’s a work bestie who’s helped you along the way?

I feel lucky that I’ve had a work bestie at pretty much every job. What they give you is someone to celebrate the wins with, but also to talk about the challenges — the highs and lows. Just having a trusted person who’s there for both has been really important.

(Brooke ultimately gave a shout-out to Eric Pang, who she described as a sweetheart, a talented designer, and someone who is always down to chat through a work challenge. This was very wholesome.)

Anything you’d like to plug?

Brooke and her team are hiring a Senior User Researcher at Mozilla in Canada.

Huge thank you to Brooke for joining us and for making us feel considerably better about the fact that we also don’t have it all figured out.

Brooke is based in Toronto, has been to Amsterdam and recommends it enthusiastically, and has many work besties. You can find her on LinkedIn.

Hi there! 👋

If you’re reading this, you might be totally new to the world of UX, currently trying to break in and find your footing, or earlier in your career. We wrote this FAQ for folks like yourself! We get a lot of questions from new UXers and from those who are looking to chat whenever we are hiring, but we don’t always have time to hop on a call and answer them. This FAQ addresses the most common questions we get from new (and less new) folks in the industry.

Is there a question missing here? Drop us a note at deardanielledave@gmail.com, and we’ll email you if we add an answer!

Can I talk to you directly instead?

We wish we had time to grab coffee (virtual or IRL) with everyone that reaches out to us, but we don’t, especially in our efforts to have a strong work/life balance. We built this document as a way to protect our time while still answering your questions.

As noted above, if a question is missing, you can submit it to us, and if we find that the best way to answer that question is by having a coffee, we’ll reach out to you accordingly!

Breaking into UX

How do I get my first role in UX?

It’s important to start out by saying that everyone’s journey into UX is different — your path won’t look exactly like ours or anyone else’s, and that’s a great thing! There is lots of room for you to forge your own unique path into this industry.

Here’s a brief history of how we got into UX:

• Danielle: I got my first formal role in UX working in a tiny startup (less than 6 employees) while I was doing the Master’s of Information program at University of Toronto. I was able to get an internship as a UX Designer there which was a great learning experience. The start-up was associated with the university and I knew the founder through my courses, which helped me get my foot in the door. Before that, I also started building my portfolio via my course work, creating UX case studies out of some of my previous work experience, and volunteering* at Civic Tech Toronto. Towards the end of my Master’s degree, I got a contract role as a UX Designer at Freshbooks, which I was able to convert to a full-time role after 6 months.

• Dave: I didn’t get into what many consider traditional UX until much later in my career. I started working in more traditional market research as a research analyst at AC Nielsen coming out of my MBA, then moved over to General Mills leading consumer insights work on some household name brands. Both were great learning experiences in their own right - Nielsen as a consulting agency helped me hone client management skills and gave me solid foundational quant research and analytical chops. My time at General Mills taught me how to manage a large research budget and manage research vendors. My first exposure to “true” UX is when I started working for Flipp. There I stood up the UX research team, also ended up leading PM, CX and Product Analytics for a spell towards the end of my tenure there.

*Volunteer projects does not mean working for for-profit start-ups for free; this means working with interdisciplinary teams such as at Civic Tech Toronto on projects focused on causes you believe in, where everyone is volunteering, and you can build meaningful relationships through the collaboration.

It’s really not easy to find that first role. It will take time, sometimes lots of time. We empathize with anyone looking to break in — we know it’s really difficult. Oftentimes these things come down to luck and circumstance.

Now we absolutely recognize telling someone to “bank on luck” isn’t exactly the most actionable advice. What you can do though is to maximize your luck by trying the following:

• Build your network: This does not mean reaching out to people you don’t know on LinkedIn or by email; but instead trying to build meaningful relationships with people in the industry. E.g. through coursework, mentorship programs, volunteer projects*, meet-ups, etc.

• Find a mentor: Finding a senior designer or UXR who has been in the industry for a number of years can go a long way. They can be a source of great advice, information and inspiration, can provide interview tips and be someone to check in with regularly when you get stuck.

• Build your skills/knowledge: Learn from others, leverage resources online, read articles, take free courses, etc.! Get the foundations down so you’re set up to start applying them.

• Volunteer / do pro-bono work: when you are just starting out and have little to no professional experience, volunteering your skills to do some pro-bono work for your local barber shop, restaurant or make a website for someone in your network can be a great way to hone your skills, get feedback and build your portfolio and reputation!

• Build your portfolio: Start to practice your UX chops by building a portfolio based on projects from courses, previous work, volunteer projects, etc. This will help you practice and give you something to get some feedback on. It’s now easier than ever to create great looking portfolios with the help of vibe-coding tools!

  • A note on portfolios for UXRs: it’s less common for UXRs to have portfolios compared to designers, but it’s not unheard of and we’ve seen some great UXR portfolios. It really does help you stand out if you can put together something that’s thoughtful.

• Think about places that need a new UXer, and focus on finding those roles: This may mean that your dream company isn’t the place where you start out. Places that need new UXers might be…

  • Really big, e.g. banks, enterprise software, government: These may be places with really large UX teams with many senior or lead level UXers keen for the opportunity to mentor new UXers as they level up their management skills.

  • Really small, e.g. teeny tiny startups, non-profits, small businesses with no UX: These may be places that otherwise wouldn’t be able to hire a UX person, who can give you a ton of autonomy to learn, grow and develop your own processes.

• ….or, transition from another role: Or, consider a role (perhaps your current role) in a company that has a UX team, or that doesn’t have one yet (until you came along!), where you can aim to transition internally. This career path happens a lot more than you think! It takes time but you will learn a ton along the way.

• Weigh experience over pay*: Not every job is going to pay great. In fact, most junior roles don’t, especially in today’s market. So don’t put too much weight on the salary. Instead, weigh towards the experience you are going to gain, the type of company & team you’ll get to be on, and the type of projects you’ll get to work on. Those experiences will pay dividends down the road, and you’ll get your chance for a bigger paycheque.

  • *Not everyone is in a position to do this; as with everything in this list, disregard if its not right for you. There’s no single path or thing to do to get your first role.

Alongside all of the above: be patient/kind to yourself in the process: This is hard. Show yourself lots of self-care and compassion through this process! And remember you are not alone. Connect with peers, classmates or colleagues looking alongside you and learn from each other alongside supporting each other - it makes a world of difference.

Do I need to get a degree in order to break into UX?

Nope! There are so many paths to a role in UX. A lot of people don’t come into the industry with a “traditional” UX education; there are so many other types of education or experience that are relevant. If you think you might want a degree, see the answer above. If that doesn’t seem right for you, research other peoples’ paths into UX for inspiration, and forge your own!

As hiring managers, we generally place more emphasis on real world, practical experience over education. Not to say education isn’t important, but you can only get so far with classroom theory. Even if you end up pursuing some sort of UX degree or education, it’s still good to try to get some hands-on experience (see answer re: volunteer and pro-bono work).

What are salaries like in UX?

Really varied, and it depends a lot on context, location, experience, and more.

User Interviews publishes a UX Salary Report every year. It’s a solid point of reference and should give you a good general sense for what averages look like in the industry. If you want specifics, or hone in on particular roles or companies, talk to different people, and in particular, look to build relationships with people at a similar level to you or one level above (e.g. if you are breaking in, reach out to some Junior Researchers/Designers) who you can talk with candidly about salaries so you can build your baseline.

Is 1Password hiring?

If we are at the moment, it will be listed here: https://jobs.ashbyhq.com/1password

For Danielle: Do you recommend the University of Toronto iSchool User Experience Design program?

I (Danielle) had a really great experience at the iSchool, and that experience was definitely a big boon for me as I got started in the industry. So generally I recommend it, but it’s not for everyone — and again, everyone has a different path into UX! Doing a master’s degree is by no means a prerequisite. Also keep in mind: the program has changed significantly since I graduated. Reach out to a more recent graduate to get an idea of what its like now.

So, is it right for you? Only you can figure that out! But based on my experience, I think it’s particularly good if:

• You enjoy learning in an academic university setting. This may seem obvious but I really enjoyed my undergraduate university experience, so going back for a Master’s degree was a good fit for me. There were still essays, late nights studying, dense readings, and lots of time spent on theory rather than practice — all that fun stuff. If you don’t find that stuff fun and are looking for a more purely practical learning experience, this program may not be your best option.

• You have an idea of what you want to get out of the program. Again, maybe seems obvious! But if you just generally want to build UX skills, there are a lot of ways to do that besides doing a costly (both in terms of time/expenses) university degree. This program works particularly well if you go into it intentionally aiming, for example, to do research in a particular area of interest, or to gain practical experience while studying in an academic setting.

  • For myself, going into the iSchool, I knew I wanted to get practical experience to put on my resume, so it was important to me to secure a summer internship, and to do the Capstone course in my second year where I could embed and do a project in an organisation.

Ultimately, with any learning opportunity, you get out of it what you put in! So just doing a program to get a job at the end of it, while an extremely reasonable and fair goal and likely ultimately everyone’s ideal end state in pursuing an education of any kind, is making a big investment towards an end that’s not guaranteed.

So while that may be the end goal, when considering doing UX education, focus on evaluating the program for yourself as an individual. You can come up with criteria that make sense for you — for example:

• Teaching style: the kind of teaching you’ll receive from the program and whether that’s compatible with the way you like to learn

• Practical opportunities: the opportunities to gain industry experience (e.g. capstone courses, internships, practicums, etc.) and how they align to what you’re looking for

• Expertise: the people teaching and whether they’re people you’d want to learn from

• …and more! Use AI!

Portfolios & Interviews

What do hiring managers look for when evaluating portfolios?

Every hiring manager evaluates portfolios a bit differently, but here’s a general framework for the kinds of things we tend to look at. Think of these less as a checklist and more as lenses we’re looking through as we review your work. Keep in mind too that the degree to which we expect you to demonstrate these skills based on the level of job you are applying for.

1. Craft - How strong is the design execution?

This is the one people tend to think about first, and for good reason — it’s often the first thing we notice. We’re looking at your visual design, interaction design, and overall polish. Does the work demonstrate a strong sense of hierarchy? Are the flows usable and well-considered? Have you thought through different states and edge cases? Ultimately, does the work feel thoughtful and well-made? Craft signals that you care about the details, and that you have the skills to follow through on your ideas.

2. Product Thinking - How well do you understand the problem and shape the right solution?

Great-looking work only gets you so far — we also want to see how you think. How did you frame the problem? What tradeoffs did you navigate, and why did you make the decisions you made? Can you clearly connect user needs to product outcomes? Did you celebrate the right metric, or did you optimize for something that looks good on paper but doesn’t actually move the needle for users? This is where we get a sense of your judgment, and judgment is one of the hardest things to teach.

3. Journey & Systems Thinking - Can you think beyond a single screen?

A single screen can look beautiful, but users don’t experience products one screen at a time. We’re looking at whether you can design coherent experiences across steps, states, and connected parts of a product. Do you understand user journeys and information architecture? Can you zoom out and consider how your piece fits into the broader system? This is especially important as you grow in your career — the ability to think in systems is what separates good designers from great ones.

4. Agentic Building - Can you move work forward through prototyping, building, and iteration?

This is an increasingly important one. We want to see that you can actively use prototypes, AI tools, code, or whatever else is at your disposal to explore ideas, test them, and create momentum. It’s less about which specific tools you use and more about the mindset — are you someone who builds to learn, or do you wait for permission to move forward? Showing that you can get scrappy and make things real, even rough versions, goes a long way.

5. Storytelling - Can you bring it all together?

This is the thread that ties everything else together. A portfolio isn’t just a collection of work — it’s a narrative. We’re looking at whether you can present your process and outcomes in a way that’s compelling, clear, and engaging. Can you walk us through your thinking in a way that makes sense? Do we come away understanding not just what you did, but why it mattered? Strong storytelling shows that you can communicate your work effectively, which is a skill you’ll use every single day on the job.

How do I build a portfolio for UX/UX Research when I’m just breaking in and don’t have any formal work experience yet?

It’s totally okay if the projects on your initial portfolio aren’t from paid work — honestly, we expect that when we’re reviewing portfolios from people just starting out. What we’re looking for is evidence that you can think through a problem and apply the UX process, regardless of where that work happened. So get creative with it!

A few ideas for where to pull from: school projects are a natural starting point, especially if you can frame them as proper case studies rather than just assignments. If you’re currently working in a non-UX role, try applying the UX process to something at your job — maybe there’s an internal tool that’s painful to use, or a customer-facing flow that could be better. Volunteering experiences and meet-ups are another great source of real, collaborative project work. And don’t underestimate personal projects — pick something you’re genuinely interested in or a problem you’ve personally experienced, and work through it. Some of the most memorable portfolio pieces we’ve seen have come from someone scratching their own itch.

The key with all of these is to show your process, not just the final output. Walk us through how you identified the problem, what you did to understand it, the decisions you made along the way, and what you learned. That’s what makes a portfolio compelling, not whether the project came from a Fortune 500 company.

When in doubt, Google around for portfolio inspiration from other UXers — there’s a ton of great examples out there to learn from.

What differentiates a UX Design portfolio from a UX Research portfolio?

There are lots of ways to incorporate both skills into your portfolio, but the basic difference is that a design portfolio will focus on the design process, thinking and output in the presentation of projects, whereas a research portfolio will focus on the research process, thinking and research impact on the product.

True, they’re often really similar processes, ideally happening at once! But it’s about where you focus the narrative.

In a UX Design portfolio, you might show a problem statement, describe your design process, some findings from evaluative research, and showcase your designs with a focus on iterations in the process resulting from user insights.

In a research portfolio, you might show something really similar, but you may focus more on your research planning, recruitment, synthesis process, how you shared the insight, and how the insights influenced product decisions.

Both stories are similar — it’s more about the emphasis! A design portfolio might more so emphasize design iterations based on insights, whereas a research portfolio might more so emphasize communication of the research insights.

No silver bullet solution, lots of different ways to do this (the theme of this doc)!

What format should my portfolio be in?

Do what’s best for you. What will be simplest to update over time and iterate upon? Will you rely more on copy to tell your story, or images?

Build it yourself, use a template, use Figma, use Google Slides, use Notion… do what makes sense for you! It’s more about the content, storytelling and polish than the format you choose. We have hired candidates with all kinds of portfolio formats.

That said, the most common format and medium we see are personal websites (that include both work and a little about themselves) and Figma (again, people often include a bit of personal side there). There’s a lot of upside to a personal website, so if pressed to give a recommendation, that’s where we’d land. It’s a great way to showcase your work and its impact, gives you a natural reason to reflect regularly, and a place to iterate and update over time. A website also affords you the opportunity to demonstrate your AI skillset highly tangibly.

Also, please don’t password protect your website or otherwise. It’s a point of friction for the hiring team. Unless you worked on some state secrets (which you probably shouldn’t include on a website anyway), there’s no good reason to gate your portfolio.

What can I do to make my portfolio stand out? What are elements of a great portfolio?

Whatever your UX discipline, here are some tips:

• Strong communication/storytelling: Be really clear and concise. No matter your focus in UX, communication is a core skill of your role. Being able to tell the story of your work and who you are will always make you stand out.

  • Edit, edit, edit! Do you need every screen from that prototype? Always ask yourself: what can I take out to tell my story more clearly, for someone who has 1 minute to read this?

• Visual polish: Passing that 5 second test where everything looks polished and clean will help you stand out. This doesn’t mean your portfolio design has to be wildly innovative, though that’s great if it’s your thing — just that it needs to be simple and consistent, just like the kind of design work you’ll be working on as a UXer.

• Usability/accessibility: Similarly, the portfolio should be usable and accessible itself. This will be core to your work, so make sure your portfolio reflects it.

• Bring yourself to it: Show us who you are and what makes you awesome. You’re so much more than your credentials. Bring some of that you to your portfolio.

What tools do I need to know how to use? How important is it to know how to use AI tools?

Let’s break this down by discipline.

For Designers: Figma is a must-have. It’s the industry standard and you should be comfortable working in it. Beyond that, the tooling landscape is shifting fast — designers are increasingly becoming builders, not just people who hand off mockups. Getting proficient with vibe-coding tools like Cursor and Claude Code is becoming a real differentiator. You don’t need to be a software engineer, but being someone who can prototype with code, build functional things, and move work forward without waiting for a developer? That’s increasingly valuable.

For UX Researchers: It’s good to know your way around tools like UserTesting, Dovetail, Maze, Qualtrics, and similar platforms — but honestly, none of them are that hard to pick up if you haven’t used them before. What’s becoming more important is knowing how to work with AI. The frontier models — Claude, GPT, Gemini — are becoming part of the research toolkit. Knowing how to prompt effectively is table stakes at this point. Beyond that, learn how to work these tools into your research process: using them to help with synthesis, summarization, and analysis. But equally important is knowing how to spot when the output isn’t quite right. AI can get you 80% of the way there fast, but that last 20% — the judgment call on whether something is actually accurate and meaningful — is still very much your job.

For everyone: The tools will keep changing. What matters most is building a mindset of curiosity and adaptability around new tools rather than chasing mastery of any one specific platform. The best UXers we’ve worked with aren’t necessarily the ones who know the most tools — they’re the ones who pick up new ones quickly and figure out how to make them useful.

Dear Dave,

Offsites: a time of joyful reunions, breathless height comparisons, and, reliably, bone-deep exhaustion.

When we bring our team together for Real Life Zoom, it can be deeply valuable — but it requires a hefty dose of intentionality. The difference between time well spent together and time just… spent together is the effort behind the scenes to design a purposeful experience.

Recently, our Experience, Design and Research team had our offsite in Toronto (remember? you were there!). We split our time carefully between lightning talks, open reflection on burnout and ways of working, social time, and, of course, hacking with AI. We wanted our team to have the opportunity to learn together and ship real product changes.

A few years ago at our last departmental offsite, we ran a design hackathon where the team went deep on solutions to problems they cared about; this was greatly rewarding, though those great ideas didn’t come to life.

This time, our hackathon was literal: the team vibe-coded real, shippable solutions to UX debt — tangible things built together, focused on visual bugs and design system updates rather than blue-sky design work.

This was, frankly, not easy in multiple ways. Getting our codebase up and running took significant time and tedious troubleshooting. The exercise sparked honest but difficult conversations about how quickly our roles are changing. And once things were running, actually getting solutions built properly was a hurdle in itself — designing with AI is fundamentally imprecise, yet we’d taken on precise design work.

Subscribe now

It wasn’t perfect. But along the way, something wonderful started happening that could only happen in person. As teammates pushed through the challenges of setting up the production environment on their own devices, they’d shout with glee once things clicked — and the whole room would erupt in applause. When people hit walls, peers jumped up to help. We demoed small wins and cheered each other on. We went on a hero’s journey together, reaching a triumphant climax by overcoming challenges we didn’t think we could, together.

That’s not to say we ended the week on a freeze frame of happy AI adoption. We didn’t. The challenges of the hackathon reflect real, ongoing barriers for our team. And just as important as the hackathon was the time we spent talking honestly about burnout, AI anxiety, and disillusionment — alongside the time we spent simply being together, connecting on a human level.

The difference between a good offsite and a great offsite is purpose. Knowing why we’re all here — why it’s worth the time away from family and life outside work to be together in person. Right now, for design and research teams, that means creating space for AI experimentation together alongside genuine, honest conversation about how our roles are evolving that make us feel less alone and, importantly, more confident in how we move ahead.

All that, of course, and good food.

From organizing my closet full of offsite swag,
Danielle.

Dear Danielle,

As with New Year’s resolutions, we work with our teams to develop their growth plans at the start of every year, based on feedback they received at the end of the previous year, coupled with their interest, passion and growth ambitions.

In the check-ins that follow, I consistently hear the same frustrations; some flavour of “Sorry, I just haven’t had time to make progress on my growth plans.”

I empathize. Things are just so busy. Between the projects, the meetings about the projects, the meetings to debrief the meetings about the projects, and the extracurriculars and side projects that folks inevitably sign up for — it’s easy for growth plans to become an afterthought.

But I also know that a lot of growth plans are poorly designed from the get-go. Many people find it difficult to make time for their growth plans because they’re designed as a separate entity to their day-to-day, and there’s little synergy between how they might make progress on their growth plans and their day-to-day job.

In other words, often growth plans weren’t set up for success in the first place.

So I’m proposing we rethink growth plans as part of your job so that you make progress on them as you do your work.

A helpful framework I’ve been using with my team is the 70/20/10 rule: 70% of the learning should be done on the job and as part of your job, by doing, experimenting and being hands-on. 20% is learning through others - your peers, mentors, your network. Then the last 10% through study - conferences, books, online courses, webinar. I see most people have it reversed where 70% of their growth plan comes from study, and that’s why it’s so hard to find time.

Subscribe now

AI learning and development is a prime example of this. Many people approach AI learning as this massive endeavour that they feel they must carve out a huge chunk of time in their day or week to tackle. They feel this imposter syndrome where they feel like they aren’t expert enough at prompting to use Claude Chat proficiently, or they aren’t “dev enough” to navigate Cursor. So much time is spent on watching YouTube tutorials, reading up articles, researching the best way to approach learning AI.

Instead, the learning should be baked into the day-to-day. Start with smaller tasks and experiments. For researchers, that means using LLMs to help you draft research briefs and discussion guides. For designers, that could look like getting comfortable with prompting in Figma Make and asking it to recreate a screen in your product. Repeat these behaviours and tasks to understand what AI does well, learn and iterate. Once you feel more comfortable, graduate to the more complex tasks. For example, for researchers, build custom agents to help you automate repeatable tasks in your entire research flows. For designers, build an MCP for your design system and connect it to your vibe coding tool so the vibe-coded prototypes look and feel more consistent.

At the end of the day, when it comes to AI learning and development, as Nike guides us, “Just Do It!”. Because the truth is, no one really knows what they are doing when it comes to AI. But you can become more proficient at it by getting hands on with it. Sometimes, it is ok to build the plane as you fly it.

From trying to retrain a rogue AI agent,

Dave

Dear Dave,

Category: things tech workers reliably hate.

My guesses given this Family Feud would include: meetings, process, planning — the harbingers of building slow. AI is in; process is decidedly out, in favour of compressing as much as possible so we start at the end with the finished product and work backwards where we need to. Even the good old double diamond of design has become a dirty duo (say that five times fast).

But while AI has smushed the double diamond into a thin line, disdain for process is nothing new. The perils of moving slow have always been a concern in software development, and with good reason — the slower we are to get work in front of customers, the riskier it becomes. Over-investing up front in something people don’t value is wasteful and demoralizing.

What I’ve always noticed in conversations about speed, though, is that everyone has a different framework for what fast and slow actually mean. Where one person thinks two weeks is a compressed timeline, another thinks it’s far too long. We all look at the same project and see different scope. A designer sees information architecture foundations crumbling beneath the surface. A researcher sees a gap between the feature and the problem. An engineer sees technical gotchas. A PM sees an urgent customer escalation that needed to be resolved yesterday. So we debate scope, agree on a timeline, and everyone goes off to do their part.

Then comes the doing — and this is where things get lost.

There’s an update here or there, chatter among the working team. But for leaders and stakeholders, questions start surfacing quickly: What’s happening? What’s taking so long? What are people actually doing? Planning software provides answers, but in my experience they’re nearly always oblique — missing some layer of detail that someone needs, frustrating everyone in one way or another. These tools make work legible to the business, but they don’t tell its story.

Share

This brings me to a distinction I come back to constantly in coaching: speed vs. momentum.

Speed is quantitative — the hours, days, weeks, or months it took to do the thing. Momentum is qualitative — how it felt while we were doing it. Did it feel like consistent forward movement? Did we learn from customers and the team along the way? Did stakeholders feel like they were part of the journey, or did the work just... appear one day?

The good news: momentum is entirely within our control. And it’s not about big, packaged updates. It’s the active Slack channel. The small win shared mid-sprint. The quick check-in with a stakeholder — not a formal update, but a genuine question or a focused ask for feedback. It’s showing how decisions are evolving, not just announcing where they landed.

Momentum is deeply undervalued. We focus on hitting the big deadline and sharing updates at milestones, rather than involving curious stakeholders along the way. This instinct is pragmatic (updates take time!) and, perhaps tacitly, defensive — we want to build conviction before exposing work to a wider, more senior, scarier audience. But the cost of that approach is that stakeholders experience the work as opaque, which breeds the very anxiety and scrutiny we were trying to avoid.

The instinct to keep momentum going is one of the clearest things I pattern-match in high performers. They recognize that bringing people along isn’t just about maintaining buy-in — it actively makes the work better. It treats stakeholders and customers as true partners, not a box to tick.

At a time when AI is compressing timelines and raising the bar for what “fast” means, momentum matters more, not less. When the output is faster, the journey becomes a differentiator. Teams that move quickly and bring people with them won’t just ship more — they’ll build the trust and alignment that lets them keep shipping.

Speed gets you to the finish line. Momentum makes people want to run the next race with you.

From being flattened beneath the double diamond,

Danielle.