The Four AI Archetypes: Finding Your Place on the AI Adoption Curve

The AI landscape is rapidly changing, and as business leaders, so must we. 

Our latest talk breaks down the AI journey into manageable stages:

• Bystander.

• Conversationlist.

• Automator.

• Orchestrator.

Whether you're just starting or looking to revolutionize how your team works, there's a path forward. Learn how to transform fear into action and curiosity into expertise with our step-by-step insights. Listen in and find out where you and your team are on the AI-adoption curve. 

#AILeadership #FutureOfWork #Technology

AI-shortened transcript

Nick: One of the things that we know people are struggling with when it comes to AI—because they're telling us—is that it seems so big, so all-encompassing, that it's really hard to think about from a strategic point of view. What you should be doing, what your team should be doing, what your business should be doing. It’s a bit "jab, jab, right hook," isn’t it?

Matt: Yeah.

Nick: You published a really interesting post on LinkedIn last week that I think gives us a useful framework for thinking about where we are—each of us individually and from a business point of view—on that AI adoption curve. And I thought it would be useful just to talk through those levels and see if we can help some people out.

Matt: Absolutely. I think it’s worth saying, just for context—Nick, you and I have spoken about this a lot—and I want to reiterate a little bit, because I think this is really important. I’m years old now. I’m living through a time where I’m seeing, genuinely, for the first time, a real worry and threat to the way I’ve been able to do my work for such a long time.

You know, I was a developer, I’m a user experience person, I’ve done a lot of product strategy—I’m not a junior person in the digital space at all. But every time I look at LinkedIn, Instagram, TikTok, or Twitter, all I’m seeing again and again are these messages saying AI’s coming. It can take your job, it can do this, that, and the other. And I genuinely think to myself, “Oh my—crikey—how am I going to adapt to this?”

It’s scary, right? I feel fear.

Nick: Yeah.

Leaning Into AI

Matt: And as part of that fear, what I’ve been doing—as you know, what we’ve been doing together actually—is trying to lean into AI. Practical lessons that we, as older statesmen of the digital…

Nick: Some of us older than others, Matt.

Matt: …so that we can start to understand the wheat from the chaff, the signal from the noise. Because it’s not obvious. If you go onto Google or YouTube and ask, “What are the five most important impacts of AI right now?”, you’re going to get videos about "vibe," or how to use this niche tool some dude has vibe-coded—an AI tool that will, say, translate your company accounts. But you know nothing about the provenance regarding security and all that.

There is so much noise about what’s good and bad. It’s really hard to tell the difference. So we’ve been leaning into that from experience. We know how to assess good from bad in terms of…

Nick: Yeah, practical applications.

Matt: …practical application of these things. And what occurred to me was that I haven’t been able to find a very good framework for understanding where I am on my AI adoption journey. For example, if I’m just using ChatGPT to ask it questions—basically like a Google search—what does that mean?

There’s a woman called Allie Miller who’s one of the top voices on AI on LinkedIn. Really great—her webinars are amazing. But her work seems targeted very much to younger enthusiasts—millennials and Gen Zs. I’m a Gen Xer.

Her posts are great, but very much geared toward that audience. So I kept thinking: how do I understand my journey on this? She talks about an “AI-first mentality”—about using AI to change the way you work, not just to use AI. What does that mean?

If I’m using ChatGPT to analyze a spreadsheet and understand sales trends in the US, and ask it how tariffs will affect those sales—that’s still me using the tool to do what I’d normally do manually. I’m saving time, sure. But that’s not AI-first.

AI-first would be: a workflow that sees Donald Trump announce 50% tariffs on steel, then asks: “Do we work in the steel industry?” Yes. “OK, I’ll look at our sales forecast and tell the heads of department what the impact is.” That’s AI-first—it’s proactive, not reactive.

Nick: And it would be running in the background all the time. Not triggered—just alerting you.

Matt: Exactly. So what I’ve been trying to get my head around is: what are the gates or behavioral markers at each stage, so I know I’ve moved from being a basic user to being an AI-first individual?

Nick: Yeah. And it’s not just you, is it? There are lots of people working in companies—doing big work for big clients—who aren’t stringing together no-code tools. It's the complex work of business.

Matt: Right. And that’s what really got me thinking. There are lots of videos about how to use AI as a content accelerator. But there’s not much out there about how to use AI to be a better team leader or line manager. Those are harder use cases. They’re specific to most organizations.

The Four AI Archetypes

Matt: So we’ve got these four archetypes I call AI User Archetypes: Bystanders, Conversationalists, Automators, and Orchestrators.

Nick: OK.

Matt: Originally there were only three—Conversationalist, Automator, and Orchestrator. But I had a conversation with someone on LinkedIn who said, “I’m not interested in AI; it’s not solving any problem for me.” And I realized I’d missed out the archetype I myself had once been—what I call the Bystander.

Nick: Yeah.

1. Bystanders

Matt: At a high level, a Bystander is standing at the edge of the AI revolution, watching from a distance. They’ve heard of AI, maybe tried a chatbot, but it hasn’t stuck. They don’t think it’s relevant to their work. They might think it’s overhyped or unreliable. They feel a mix of curiosity, skepticism, and fear. What they need is clearer use cases—right now, AI feels like it’s for someone else.

2. Conversationalists

Matt: A Conversationalist uses tools like ChatGPT, Claude, Gemini, or Copilot to ask questions, draft emails, brainstorm ideas. It’s one-on-one interactions in a chat window. The AI is a sparring partner or research assistant—it’s not embedded in any workflow.

Nick: Yeah, it’s separate.

Matt: Exactly. And the landscape is muddied—there are ads claiming AI can automate your life, but they’re promising things that ChatGPT alone can’t actually do. So, Conversationalists need to understand that these tools are like a keen but inexperienced junior employee—they might confabulate because they’re trying to give you an answer.

Nick: Yeah. Confidence is misleading—AI seems confident, and we fall for that.

3. Automators

Matt: The next level is Automators—people who design workflows where AI is a step in the process. We recently built one for a hotel chain to generate SOPs from vendor training videos. You use AI to summarize, translate, clean data, or serve as an FAQ bot. It’s not just chat—it’s embedded in tools and flows, often using Copilot Studio, Make.com, or Zapier.

For example: add a line in a Google Sheet to trigger ChatGPT to create a draft invoice in Xero, then alert you via Slack.

Nick: Yeah, that makes sense.

4. Orchestrators

Matt: At the Orchestrator level, you’ve got AI agents working proactively. I have one in my inbox—it watches for action-required emails and adds tasks to my to-do list automatically. It has a prompt like “You are a first-class personal assistant.” It checks email and uses tools to capture the task.

Over time, you build many agents—maybe a coding agent to create tools based on your brief. You’re not doing the work; you’re ensuring it gets done right.

Senior leaders need to move their teams from Bystanders and Conversationalists to Automators and Orchestrators. Because what AI can’t do well—and may never do—is provide the creative spark to ask: why are we doing this? That’s the domain of humans.

Nick: Yes—experience, creativity, empathy. That’s the rarefied space where we create value.

The Future of Work

Matt: There’s worry about what happens to junior roles. Anthropic recently said 50% of junior roles could disappear in the next three years. That’s scary.

Nick: Yeah.

Matt: But I think managing agents, workflows, and automations could create a new area of work. It might not be the same tasks, but new kinds of roles will emerge.

Nick: Agility and hard work will be the differentiators. It’s like writing—yes, AI can write, but thinking is what really matters. If you just use AI to write, you’re the same as everyone else doing that. But if you push harder, you can do more—coding, designing, prototyping. You can go farther, faster.

Matt: Totally agree. There’s this negative vibe-coding label out there. But the people using these tools are learning—just in a different way. They’ll be ahead of us if we don’t adapt. Leaders must remind their teams: if you’re taking 10 days to do something that AI can help someone else do in two hours, you’re falling behind.

Nick: Exactly. If you’re scared, you can run, freeze, or dive in. Freezing is the problem. Knowing where you are in this framework tells you the next step. And moving forward is the only option.

Matt: Couldn’t agree more.

Nick: Cool. Thanks mate. Speak to you again soon.

Matt: Will do. See you later.

AI Chat: “I’ve got a confession to make.”

I tried going AI-first this week. Spoiler: it’s brilliant… until it isn’t.

I sat down with Nick Warren to unpack what happens when you actually try to run your daily workflow through AI.

No filters. No hype. Just two humans navigating hallucinations, rabbit holes, and the occasional win that saves a week’s work.In this chat:

• Why I treat ChatGPT like an overly confident intern (mine’s called Wilson).

• The moment it lied to me about Flask.

• When it builds you a webpage… that looks nothing like your website.

• Why voice input is finally working — and what it means for how we work next.

• And yes, why Git still saves lives.

If you’re serious about working with AI (not just tweeting about it), give this a listen. (We’ll try to improve the audio next time!)

The transcript

Nick: [00:00:00] So Matt, I’ve got a confession to make. You know, last time we recorded, we were talking about AI. But when we finished, we weren’t sure whether or not to post it, because AI is such a big thing and we didn’t reach a ton of conclusions.

It’s not like the usual time we talk where—

Matt: Yeah, that’s right.

Nick: —you’re unloading your wisdom on us. But when we decided we were going to put it out, we decided to just publish the video with the transcript. And I said to you, yeah, that’s great. But I’m going to have to do quite a lot of work on the transcript because—if you’ve ever seen a transcript—from about shifting the default behaviours… And I think, you know—

Matt: Yeah.

Nick: Last time we were talking about how, you know, if you are just starting out, or maybe now you are 10 years old and obviously you’re going to grow up an AI native in the way that my son grew up a digital native. But for the rest of us who are older, or for businesses, one of the key questions we need to ask [00:01:00] ourselves when we’re doing any job—particularly if it’s essentially busy work like that—is: how should I use AI? How can I use AI to get this done quicker and move on with the things I can’t do. Does that ring any bells for you?

Matt: Yeah. Oh, absolutely. Absolutely. Do you know, it’s such an interesting point. Funny enough, yesterday or the day before, I was pulling together a list of use cases—like, how might you use AI to accelerate your daily work life?

I was Googling and going on YouTube saying, “Give me some use cases.” And you know what? There is just so much noise. On YouTube, there is so much. I’m trying to find the most influential people and what they’re saying about how to use AI.

Then there’s [00:02:00] this whole mix between how to use tools like Claude and ChatGPT versus workflow automation and stuff like that. By the end of it, my brain was just like: what the hell?

Where I’ve landed on this is taking an “AI first” approach. Everything I want to do, I’ll try with AI first. If it doesn’t improve things, I stop. If it does, then great.

Nick: Yeah.

Matt: Yesterday I had a list of tasks. One of them was to produce some copy for a welcome screen for a questionnaire survey, and then a thank-you screen. I used ChatGPT—who I’ve named Wilson. I gave him the context and he produced the copy. I added it into the system, reviewed it, moved it forward.

Then I needed to create some content for a web page about AI skills—how we’re using AI, what the skills and capabilities are. I did that too. Then I thought, okay, I’ll get it to look on the web to find out what other pages are like, and not just create the copy but the whole site.

Nick: Ah.

Matt: That wasn’t nearly as successful. [00:04:00] Clearly there’s a challenge in finding the right tool for that. Previously I’d used Vercel’s V0 tool to build web pages. This time I was just using ChatGPT.

Nick: You were generating the HTML, were you?

Matt: Yeah. I said, “This is our current website. Look at the landing pages and create a new one using the AI content.”

It wasn’t even close. It didn’t resemble our existing pages.

Nick: So—

Matt: But that’s good, because I’m understanding the limits.

Nick: Right. Because what we’re really talking about is how we’re pushing AI into the workflow. And that does mean you’re right at the edge of what it can do.

Here’s my prediction: even though AI failed yesterday, right up to the point it failed, it was very confident it could do the job.

Matt: Yeah.

Nick: That’s my experience. When you push it to the limit, it says, “No problem!” And then… you sit there for half an hour.

Matt: I—

Nick: Because it can’t actually cope yet. And sometimes it’s about context length. [00:05:00] That’s what I hit most often.

Matt: Yeah.

Nick: If you’re listening and you’re not sure what context length is: it’s how much data the LLM can process before responding. I might feed it a ton of links and say, “Let’s analyse these web pages.” But sometimes that’s just too much.

Still, I kind of like its unbridled enthusiasm up to a point.

Matt: Yeah.

Nick: And then I tell it to get its act together. Have you seen the thing OpenAI has done—where ChatGPT offers to describe you based on your conversations?

Matt: Oh yeah, I saw that on LinkedIn. Then I tried the prompt myself, and was shocked. The thing is, it feels a lot like reading a horoscope.

Nick: Right. It could apply to anyone.

Matt: Yeah. But then again, people post them on social media like it’s gospel. Did you try it?

Nick: I didn’t post it, but yeah. The prompt just popped up in the app. It basically said, “Want to know what I think of you?”

Matt: Really?

Nick: It was flattering, as you’d expect. But then I asked something more useful: “What should I work on, based on your experience of me over the past year?”

Matt: Right. Okay.

Nick: Because sure, it’s nice being told what you’re good at—but at this stage, I know that. What I want to know is where I can improve. That’s how I framed it.

Matt: That’s interesting, especially when we’re talking about confidence. AI is so confident it can do something—until it can’t. You really have to be on your toes.

For example, this morning I was using Copilot in Visual Studio Code to create a web interface. I used Python, so it picked Flask—a web framework.

It gave me instructions, but told me to run the app using python filename, which is wrong. For Flask you run it using flask run. It told me the wrong thing multiple times.

In the end I corrected it, and it updated the README file accordingly. But the point is: it was so confident.

Unless you know better—unless you know the limitations and hallucinations—you might never question it. [00:09:00] Your ability to use AI effectively is limited by your own knowledge.

Nick: Yeah.

Matt: I’ve had that loads of times, especially with code. It’s only through testing and validating that I’ve caught its mistakes. Maybe that’s less of a thing with content?

Nick: Creating text is what it’s best at—for now. But I’ve seen the same thing happen in code, spinning up a Hugo site, PHP, terminal work—stuff I don’t normally do.

Same thing with Python. There have been times I’ve asked it for something, and because I didn’t know better, I ended up wasting time going down a rabbit hole.

Matt: But that’s the thing. You might waste half an hour, but save yourself a week’s worth of effort overall. So that’s not a bad trade-off.

Nick: I think that’s true—as long as you get somewhere by the end of that half hour. There were times where I didn’t.

One example: we were messing with a Hugo template. Of course, being me, I wanted it to be slightly different from the designer’s version. I kept asking ChatGPT to make changes—“Now do this, now do that”—and eventually it got so mangled that it was easier to start again.

Matt: Yeah. That’s where best practices matter. From a development standpoint, AI is only an accelerator within good process. If it’s changing your code a lot, you need Git.

Nick: Yeah.

Matt: Because asking ChatGPT to undo changes is hard. It doesn’t track what it did well enough to roll things back. But if you’re using Git, you can revert the changes.

A lot of people using AI don’t have that developer background. They don’t know how to make their lives easier in that way.

There’s a bigger conversation here about experienced professionals versus new users, and job loss versus productivity.

There are so many peripheral tasks in every job—software development, writing, UX—that AI doesn’t cover yet. That makes it hard to replace people wholesale.

Nick: Yeah. And on that Hugo project, we did use Git the second time around—because I’d asked those questions. “How could I avoid this problem next time?”

Matt: Right.

Nick: It’s all about building a better process. Having a checklist. Writing it down. Improving it each time you hit a snag.

Eventually it becomes second nature.

One other thing I wanted to tell you—this week I’ve started talking to ChatGPT.

Matt: Really?

Nick: Yeah. You mentioned naming it Wilson. I don’t know if we talked about this before, but I think the big shift will be when we get personal AI—something that really knows us.

But for now, what I’ve been doing is hitting the dictation button on my Mac and speaking my prompts.

Matt: Oh, so you mean speech to text?

Nick: Yeah. I just tap the button, speak what I want, hit enter.

It’s part of smoothing the process. A lot of prompts aren’t programmatic. They’re casual—“I want this, not that.” And I was spending too much time typing. It’s faster to speak.

If you work somewhere you can talk out loud, try it. We’ll all be talking to our computers soon. Better to get used to it.

Matt: You know, that’s so interesting. Years ago, Microsoft did some 3D modelling thing for Xbox. The idea was gestural and voice interfaces would change UX.

In UX theory, major changes come from input shifts—like the mouse and GUI revolutionised computing.

People have talked about voice for years, but it didn’t work well—speech-to-text was rubbish. Not anymore.

Nick: Yeah.

Matt: But the challenge now is the environment. Imagine an office where everyone’s talking to their computer.

Nick: True.

Matt: You’ve got people in meetings, noise bleeding through, noise suppression not working—it’s tricky in enterprise environments.

But like you said, for those who can talk out loud, now’s the time. I hadn’t thought about this in ages, but the dream of natural language input is actually here.

Nick: I got excited about dictation 15 years ago. And again when I was writing novels. But it never worked—detection wasn’t good enough, and I’m a fast typist, so it was easier to type.

Matt: Yeah.

Nick: Now, the detection is much better. And crucially, we’re no longer asking it to create the final output. We’re asking the LLM to interpret what we meant.

Matt: And then generate the final result.

Nick: Exactly. While noise might be an issue for some, I’ve worked in offices where everyone was on the phone. So I think we’ll adapt.

You’ll be shouting to your computer from across the room while making tea: “Hey, do this.”

Matt: And it’s believable. At home, we’ve got an Apple TV and some HomePods. It recognises who’s speaking—my wife, my daughter, me. Shows an icon to indicate who gave the command.

Nick: HomePods.

Matt: That kind of detection is solid now. That’s why AI feels so hard—it’s hard to know how to use it.

Just like with remote work or early websites—people know the potential, but don’t know where to start.

Concrete examples help. Like using voice to get outcomes. Or today—I needed to write a case study for a client. We have a consistent format. I asked ChatGPT to interview me and use my answers to write it.

I didn’t need to write it at all. It just needed to extract info from me and deliver.

Nick: I agree. We ended the last episode saying people should just use it. Hopefully this one gives you another nudge in that direction. Make AI your default.

Matt: Yeah. Ask: how can I use AI to do this job? And if you’re working alone—try talking to your computer.

Nick: One trick is to imagine an eager assistant. How would you explain what you want done? That’s how to think about prompts.

For example, I needed that case study written. An assistant wouldn’t know everything—so I’d ask them to interview me. That’s what you tell AI to do.

Prompt engineering matters too. But if you can get it to ask clarifying questions, that helps.

Two tips: 1) Imagine you’re briefing an assistant. 2) Encourage clarifying questions.

Matt: Great tips.

Nick: One last thing: if you’re just using ChatGPT in a browser, try the app. On my Mac it’s right there at my fingertips.

Matt: Maybe next time we talk prompt engineering.

Nick: Yeah, I agree. It’s the first step toward levelling up—from typing random sentences to getting great results.

Matt: Cool.

Nick: We’ll speak to you next time.

Matt: Yeah, speak to you.

Nick: Thanks mate. Bye now.

How AI is reshaping our work

What’s the real impact of AI on the workforce? Matt Goddard and Nick Warren delve into it, discussing opportunities and challenges as AI reshapes our careers.

As the saying goes, history doesn’t repeat… but it does rhyme!

Watch the video…

Or read the transcript…

Nick: Hey there, friends. I’m Nick Warren, and I’m back with Matt Goddard. You did just say we should label this “Two Old Gits Talk About AI,” but I think we’ve got an interesting perspective. We were young when the last real technological tidal wave came through—specifically, the World Wide Web.

Matt: Yeah.

Nick: I, in particular—and you, to some extent—rode that wave.

Matt: Oh, absolutely.

Nick: We were young, somewhat insulated from the broader effects that hit people who weren’t web-savvy or couldn’t retrain. Whereas now…

Matt: I—

Nick: I won’t say we’re right at the other end of our careers, but…

Matt: What you’re saying is interesting. I’ve just hired a 26-year-old, and I told him AI is going to have a massive impact. It’s either going to improve our efficiencies dramatically, or it’ll start nibbling at our heels on the traditional work we do. We need to get on top of it and understand what’s happening.

Nick: Yeah.

Matt: And because I’m a lot older, I need his unbridled enthusiasm to help me see what I might be missing. A lot of what I see AI do feels like magic.

Nick: Mm-hmm.

Matt: Like we’re in the world of Harry Potter—and I’m here for it. But when I sit down to use it for coding tasks, I think: I know how to code. Why would I tell it to guess what I already know how to do? I can just write it myself and make it exactly right—secure, robust, whatever.

Nick: Hmm.

Matt: I’ve found that AI-generated code might be 60–70% correct. But if I write it, it’s 100% correct because I’m in control of every element. Still, I remember people my age back when the web was emerging saying, “What’s the point of this? I don’t understand it.” And for a long time, the internet was just an add-on to businesses—not the business. Now it’s the default.

Nick: Yeah.

Matt: That’s why I joked about “two old gits” talking about AI—because I can appreciate how amazing these tools are, but I don’t always get it.

Nick: That’s the essence of disruption. It’s Clay Christensen’s idea: the industry being disrupted looks at the new thing and says, “Well, that’s not good enough.” Online shopping used to be poor and insecure. But disruption happens when a new approach is better for the audience than the status quo.

Take me—I haven’t coded in decades. But I was spinning up a Hugo site and used Claude to help me tweak the template. I wouldn’t have attempted that otherwise. That’s the disruptive power right there.

Matt: You’re absolutely right. I’m not some AI techno-bro who thinks AI is the answer to everything. But I’m certain it’s a disruptive force like nothing I’ve seen before. It’s fundamentally changing the way we work and the way businesses operate.

It’s not just about getting rich quick. In the last six months especially, AI tools have shifted from being a quiet productivity boost to being an acknowledged “companion” for delivering work.

It’s like when word processors and spreadsheets became essential office tools. Now, AI is becoming that tool. I don’t even need to open Excel—I can just ask it a question in natural language, like “How many people from the US are in our customer data?” and it answers.

Nick: Yeah.

Matt: It’s more intuitive than I thought it would be. Do you remember early Twitter?

Nick: Mm-hmm.

Matt: It started as status updates—“Matthew Goddard is eating lunch”—but when they removed the prompts, it evolved into a conversation platform. Natural language processing is having the same shift. Before, it was “How old is Judi Dench?” Now it’s “How do I build a willow hurdle?” and it’ll try to work it out with dimensions and all.

Nick: What you’re describing is us getting comfortable using LLMs as search engines—and more. It’s no longer one-off queries, it’s threaded work. We’ve talked before about tools like Make or Gumloop—combining AI with automation to build complex systems.

In content, AI is slightly ahead of where it is with coding. We’re using it to massively increase output. Sure, it can sound average or generic, but the bigger question is: how do you use these tools without losing our voice?

Matt: That’s a really important point. The same is true for coding. When new tech comes along, there’s always a wave of people saying, “Here’s how to get rich using this.” That’s what people are seeing right now—especially developers.

They say, “These so-called vibe programmers don’t understand security.” And that’s valid. You can’t ship vulnerable code. But I’ve also seen AI users evolve. They go from basic “look what I can generate” to learning deeper skills to create secure, robust, and accessible code.

Nick: Mm-hmm.

Matt: That’s the disruption curve. At first, professionals dismiss the early adopters—like how HTML hand-coders sneered at Dreamweaver users back in the day. But over time, those early adopters get better and start doing high-quality work. Eventually, they become the leaders.

Nick: Yeah.

Matt: That shift isn’t coming in five years—it’s happening in months. The change is that fast.

Nick: It’s happening right now. The best quote I’ve seen is: “AI’s not going to take your job. Someone using AI is going to take your job.”

Matt: Yeah.

Nick: I learned that building a business in 1997. You dismiss new tech at your peril. Yes, early AI content can feel average, but the tools are improving fast—look at Claude, look at the latest ChatGPT.

Matt: Totally agree. Back then, we didn’t have the perspective we do now. Now that we’re managing teams, that theoretical 66% reduction in developers has a human face.

Nick: Exactly. One of our responsibilities is to make sure the people we work with understand this shift and are learning the tools. AI makes things easy that weren’t easy before. You can generate 100 blog posts in 10 minutes. But everyone else can too.

The people who succeed will be the ones doing what’s hard. The edge is where the opportunity lies.

Matt: Totally. I was talking to a colleague about how most financial services companies are focused on customer-facing AI, but they’re missing internal tooling. That’s where huge gains are possible—making staff more productive, helping them make better decisions.

And there are two big trends here. First, everyone has access to the same LLMs. So your competitive advantage won’t come from the tool—it’ll come from how you use it. Your domain knowledge, your processes, your curation.

Nick: Yes.

Matt: Second, people with the most experience are best positioned to curate these tools. But that creates a problem: where’s the career path for juniors? If orchestration becomes the key skill, and only seniors can do it, what happens to the next generation?

Nick: Mm-hmm.

Matt: My uncle’s a plumber. Traditionally, you’d pass the business on to an apprentice. But if you build an AI toolset instead, maybe you don’t pass it to a person—you just keep the machine running. If that’s not the case, do we need a guild-like model, where experienced people mentor the next wave?

Nick: I think the people who want to learn will be able to learn better than ever. LLMs make amazing teachers—they focus only on the questions you ask. That’s empowering. But again, it means that motivated self-starters will win.

Matt: Yeah.

Nick: Easy becomes average. To stand out, you still need to do hard things, ask better questions, develop expertise. And for the first time in history, students can go farther, faster. But yes, the old, safe “junior to senior” career ladder may not exist anymore.

Matt: Yeah, and that’s a challenge. It technology creates social mobility—up to a point. You and I have talked about accelerated digital delivery for years. When we started this podcast, we were writing about it back in October 2024. In that article, we laid out the principles: trust, clarity, visibility, and consistency. These are the human elements that allow us to collaborate and communicate well, no matter the delivery method.

Nick: Yeah.

Matt: And of course, you still need skill on top of that. You can have great communication and transparency, but if you’re not good at what you do, you won’t deliver quality results. What’s changed since October is that delivering work doesn’t necessarily mean a team anymore. It can be just you and an LLM working together.

Nick: Yeah.

Matt: But the same principles still apply. You still need trust—that what you get from the LLM is accurate. You need visibility—how did it get to that result? You need consistency—which is tricky because LLMs can give you different answers to the same prompt. And you still need clarity—because a vague prompt gets vague output.

Nick: Yes.

Matt: And even when you’re working solo with an AI, the output still has to be handed over at some point—to a colleague, a client, a user. That chain of delivery still exists. What I find interesting is the space between those tools—the handoffs, the automation, the orchestration. Tools like Make are helpful, but there’s still a lot of friction there.

Nick: Yeah.

Matt: Plus, these tools are all proprietary. OpenAI, Anthropic—they want you to stay inside their ecosystem. So getting LLMs to interact with external APIs or systems is still hard. It’s improving with things like agent design, but it’s early days.

Nick: Yeah.

Matt: Also, let’s not forget—all the code these tools produce is coming from a platform we don’t control. OpenAI, Anthropic… they own the means of your labor. If they retrain their models, your outcomes change.

Nick: Hmm.

Matt: I saw a post—I can’t remember if it was real or an April Fool’s joke—saying you could hire a PhD-level AI software developer for $30,000 a year. Equivalent to five human developers.

Nick: Wow. Okay.

Matt: It’s the same logic that led to outsourcing. But at least back then, you could shop around. Now, if everyone’s using OpenAI’s “PhD dev agent,” and they double the price, you’re stuck.

Nick: Yeah.

Matt: So I’ve been thinking about open-source models—like LLaMA—and whether companies should start building internal capabilities now. Not necessarily retraining their own LLMs, but building tooling around them. That gives you some resilience, some independence.

Nick: Your process, your infrastructure.

Matt: Exactly. Because otherwise, you’re building your business on Amazon’s bookstore again.

Nick: Ha, yeah.

Matt: Do you remember that? Waterstones originally hosted their e-commerce site through Amazon. Someone thought it was a smart move. Cheaper than building their own platform. But then Amazon became the entire market—and Waterstones had no control. It’s the same risk with AI now.

Nick: We need to be anti-fragile. If we want to thrive, we need to build resilience into the system. Anyone listening can probably tell we’re still working this out as we go. But if you haven’t started immersing yourself in this technology yet—start now.

Matt: Yeah.

Nick: Even when it’s not great, even when it’s not as good as you are—you need to see what it can do. I spun up a Docker container the other week to look at something called “Claude Computer Use.”

Matt: Yeah.

Nick: It’s wild. You get a little virtual computer with a browser and Office installed. You give it a task, and it behaves like a human user—browsing, copying, pasting, and editing. It’s nowhere near perfect, but it shows you where the world is heading. I’ll be amazed if this isn’t baked into every OS in a couple of years.

Matt: Oh, absolutely.

Nick: So start now. Everyone’s going to do the easy stuff. If we want to build resilient, future-ready businesses, we’ve got to push further, deeper. Like Wayne Gretzky said—skate to where the puck is going.

Matt: And for people our age, that means letting go of “I can do this better myself.” It doesn’t matter if you can. The point is—this is how work is going to be done now.

Nick: Yeah.

Matt: It’s like using electric power tools. Sure, it’s quaint to do everything with a hand plane and a manual drill, but if you’re a professional, you plug in your tools.

Nick: Yeah.

Matt: We need to get over “it’s not good enough yet.” It’s not perfect now—but this is the worst it’s ever going to be.

Nick: Exactly. Great. So go out and give it a try. Thanks, Matt.

Matt: Thank you.

Discovery, Part II: Understanding your customers

Amazon’s success is built on striving to be  “Earth’s most customer-centric company.”

Let’s start this short article—a follow-up to my first piece on Discovery—with a proposition that seems both painfully obvious and widely ignored:

Companies that give customers what they want tend to grow. Those that don’t… don’t.

Of course, “what they want” is doing a ton of heavy lifting here because customer needs are never just one thing. I may want a new 88-inch 8K TV, but I also want it at a price I can afford from a company I trust.

In other words, customer wants are often a shifting and conflicting balance of priorities and tradeoffs. Getting them right is hard, and that often goes double (or triple) if you are working in digital delivery.

Who are we really designing for?

Let’s imagine that we’re at the start of a typical development project. A client has come to us, concerned that their employees lack engagement, and wants to create a social feed app.

We could just build what they wanted, but as you already know, discovery allows us to dig deeper into the business goals, crystallise the digital goals, review the risks and assumptions (RATS), and agree on the success criteria.

In other words, discovery accelerates digital delivery by ensuring we start in the right direction.

After I talked about the 4 steps of discovery in the previous article, I said this:

Woven through the four steps above is an understanding that every project has different levels of stakeholders with differing priorities, and we only win when they all win.

So, how do we break down these stakeholders? Let’s return to our example of the company whose employees lack engagement.

1. The Client has identified a problem within their organisation. They are the decision-makers purchasing the product, in this case the Head of HR. These are the people who will pay our bills (and return in the future because we did such a stellar job).

2. The Internal Stakeholders are the internal client teams who are using the product we create. In this case, that might revolve around content creation, technical support, or compliance. (If you’ve ever worked on a beautiful website that was a nightmare to update, you know exactly what I mean.)

3. The End Users are the employees who will be interacting with the product on a daily basis. Their engagement (or otherwise) is the basis of our success criteria.

In the previous article, I mentioned the big risk of avoiding discovery, which is that you inevitably overweight the needs of the client. In that example our fictional agency, Done 4U, acquiesced to their client’s desire to “just get on with it”, and missed the opportunity to solve the client's real, underlying problem.

I get it. Pleasing those that hold the purse strings is how we get paid. But what happens when they have jumped to the wrong solution?

To accelerate our digital delivery towards a real solution, we use our discovery process to upend the order above to something much more like this:

1. The End Users.

2. The Internal Stakeholders.

3. The Clients.

Let’s see why.

Are they unengaged, or just buried?

In our example, the Client has noted a “lack of engagement” and jumped to a solution—creating a social company feed that the employees can access on their phones.

Will that work?

Maybe. We’ve worked on similar projects for multinational clients that have hugely increased employee engagement. We could take the Done 4U path and just build it. The Client would be happy and we’d get paid.

But what if it doesn’t work? What if the real problem isn’t a lack of engagement, but a lack of time. If an employee’s work is already taking 110% of their allotted time—we’ve all been there—are they likely to embrace an extra job? Probably not.

An all-too-common pitfall in product development is prioritising the client’s stated needs without validating them against user behaviour. Without asking the End User what they need.

And of course it’s not just the end user. If we are creating a social feed, something has to go in it. The Client may already have a content team (Internal Stakeholders), but what if that group is already at capacity or structured for outbound marketing.

Many of you will have seen ill-considered corporate initiatives that were launched to great fanfare but were ultimately unsustainable. It’s rarely pretty.

This is why discovery must be multi-faceted. It’s not just about fulfilling the Client’s needs but investigating the root causes of their concerns. Are employees disengaged because of poor internal communication? A lack of autonomy? A culture issue?

The right solution can only emerge when these questions are explored upfront.

The obvious truth (but I’ll say it anyway) is that each of our customer groups has overlapping but not always aligned priorities. Neglecting any one of them risks misalignment, poor adoption, and, ultimately, product failure.

We need to bring them together, along with the Business and Digital Goals discovery I talked about in the previous article.

The North Star document: A single source of truth

In the old days, I used to separate the two areas of discovery into two documents:

• Business & Digital Goals

• Customer & User Needs Analysis

But we found that keeping them separate allowed teams to unintentionally (or intentionally) ignore one in favour of the other. By consolidating them into a single North Star document that evolves through the lifetime of the project, teams gain a clear, structured roadmap that ensures all perspectives are accounted for throughout the project.

Also… it’s just easier.

In addition to the Business and Digital Goals covered in the previous article, the North Star document answers three critical questions about each of our customer groups.

The four questions we want to answer in customer discovery

As I’ve said before, Discovery doesn’t have to be this big, overwrought process. For the customers, we are just looking to answer the following for End Users, Internal Stakeholders, and Clients.

1. Who are they? (Personas, roles, behaviors.)

2. What do they want to achieve? (Goals.)

3. What are their pain points? (Challenges they face that the product should solve.)

4. What support do they need? (Features, integrations, usability considerations).

There’s nothing complicated about this. While some agencies will want to run a big research project, in my experience you rarely need to do more than find the different types of customers and talk to them.

Clients are easy to reach because you’re already talking, and they can help you identify and reach out to Internal Stakeholders. Getting to End Users can be a little tougher if it’s a B2C scenario, but if you ask with an open mind, you’ll always find people who are willing to talk.

And it’s amazing how often a single thread from a simple conversation will save you from making a costly mistake or offer an opportunity that no one has thought of. Either way, it can be gold dust considering the relatively minimal effort required.

Which leads me to the MVP question…

Discovery versus the Minimum Viable Product (MVP)

When I’m consulting with other agencies, I occasionally get some pushback that goes something like this:

• What customers say is often different from what they do.

• What customers think they need is often different from what they really need.

• The only way to know for sure is to collect “real” quantitative data.

• Shouldn’t we create a Minimal Viable Product and go from there?

In truth, there’s little to argue with here. There’s (obviously) no better way of measuring the effectiveness of a product or service than by building it… and measuring its effectiveness.

On the other hand, the last decade or so has seen an increasing number of agencies take this truth as tacit permission to avoid doing the fundamentals. You can see why. Working is better than not working. Being paid is better than not being paid. Clients prefer action over discovery. The basic principle of the MVP—let’s create the simplest possible version of our idea and iterate from there—is powerful and seductive.

Then again, even the simplest MVP involves real work—concept development, UI/UX design, coding, quality assurance (QA), and ongoing support. Why wouldn’t you invest a little time to understand your “customers” before you dive in? Even if you factor in the power of AI to speed development,  having a map massively increases your chances of getting where you want to go (and solving real problems).

And solving real problems is what keeps clients or customers coming back. 

Consider Slack. 

Before it became the go-to workplace communication tool, Slack’s creators were working on an online game called Glitch. Although the game ultimately failed due to lack of users, the tool they’d built to improve their internal communication solved a real problem—one that resonated with software teams around the world.

Most of us aren’t lucky enough to be building something for ourselves, but we can all imagine the value of knowing and building the exact thing we want.

That’s the value of discovery.

The lesson from Amazon

I started this article with a mention of Amazon’s mission statement. Here’s the longer version (highlights mine):

Amazon is guided by four principles: customer obsession rather than competitor focus, passion for invention, commitment to operational excellence, and long-term thinking. We strive to be Earth’s most customer-centric company, Earth’s best employer, and Earth’s safest place to work.

You may roll your eyes at some of this, but it’s hard to argue with Amazon’s success or ambition. For hundreds of millions of people, the site is the easiest way to get what they want.

Case in point. Once upon a time, returning an item to Amazon meant packaging it back into the cardboard, taking it to the post office, and paying to send it off. Then, they introduced pre-paid labels you could print and slap on. Today, I just drop my returns into a local shop and wave the barcode on my phone.

Accelerating digital delivery requires that we minimise the amount of time spent sprinting in the wrong direction—and discovery often makes the difference. 

Companies that give customers what they want tend to grow. Those that don’t… don’t.

Which do you want to be?

Bonus: Watch us talk about Discovery-Business Goals

How to Optimise Your Kanban Board (in under 5 minutes)

I’ve mentioned Kanban Board optimisation a number of times in our recent videos, so I’ve put together a quick video to demonstrate what I mean. Sometimes simple changes can make a big difference.

Discovery: The dirty word of digital development

“Andy Dufresne…who crawled through a river of sh** and came out clean on the other side.”—The Shawshank Redemption

In The Shawshank Redemption, Andy Dufresne teaches us that we have to be prepared to get down in the… mud… if we want to come out clean.

That’s how I feel about Discovery—the dirty word of digital development.

I rarely fight as hard for anything as I fight for robust discovery at the start of a project—because it’s here that we learn the most critical thing about our client and their project:

What it is they need.

This might sound uncontroversial—a no-brainer even—but in practice discovery can be a drop-down knuckle fight… with the client on the other side of the ring.

No matter. If we want to accelerate our digital delivery, it’s a fight we have to win.

You can’t always get what you want

The main point of conflict is pretty simple. When a client comes to an agency they almost always know what they want. An app. A cloud service. A website. 

Our painful job—our duty—is to dig past what they want and get to the core of what they need.

And that takes time and effort.

It’s natural for a client to resist this. They’ve done their internal planning and due diligence. They may even have written an RFP. To clients, discovery often looks like an additional cost or pointless delay. 

“We’ve done the discovery for you. The board wants progress. Let’s just get on with it.”

I’ve seen some agencies (and worked on some projects) where the team did just “get on with it”. No discovery beyond the RFP, no investigation or pushback. You want to pay us to build an app? We’ll build you an app.

And six months later there it is… an app that looks fine and works fine… but doesn’t solve the client’s underlying problem.

Because the agency—let’s call them Done 4U— never fully understood the problem. How could they? They never did the work.

Why we’re in the business of solving real problems

Leaving aside the problems of Done 4u’s client, we might think that the agency did okay. They answered an RFP, delivered the project, and got paid. Happy days.

But the client isn’t happy. To them, the project was a bust. How likely are they to come back to Done 4U with the next project?

The answer is obvious.

By surrendering on discovery, Done 4U’s talented team has lost the opportunity to solve the client’s problem, build trust, and open a long-term relationship. 

(If you’ve read the first article in this series—on the principles of accelerated digital delivery—you’ll remember that trust is number one.)

It’s natural for clients to resist discovery, but if we can truly understand the problem, we have the opportunity to consider a range of solutions that might be better, faster, or cheaper.

• Not a new website, but a change to their existing one.

• Not an app on Android and iOS, but a web app to test the proposition.

• Not a bespoke application, but a customised version of an online service.

If you’ve never seen a client’s face when you suggest something that will solve their problem in half the allocated time and budget, I urge you to try it. It’s a special moment— that builds trust and long-term relationships.

Of course, discovery doesn’t always uncover some big unknown opportunity. Very often, we end up doing a version of what the client thought they wanted. But even then, we still move forward with a better understanding of the landscape ahead, of the business goals, success criteria, and risks.

Discovery is about going slow to go fast. So let’s look at how we do it…

The four steps of Discovery

When I start a Discovery process, I’m looking for clarity in four areas. 

1. Business goal (the problem to be solved)

This is mostly what I’ve discussed above: What’s the underlying problem that the business is seeking to solve (or the opportunity they seek to take advantage of). Common business goals include:

• Increasing customer conversions.

• Reducing operational costs.

• Enhancing user engagement.

• Improving efficiency in service delivery.

Clearly defining the business goal ensures that the digital solution we deliver can contribute directly to a measurable business outcome.

2. Digital goal (the solution)

Here we ask a critical question: Is the proposed digital goal the most effective way to achieve the necessary business goal?

If not, we have the opportunity to take a breath and explore different solutions. As an extreme example, a friend who worked for IBM was approached by a Premier League football team that was redeveloping their huge stadium and retail outlets. A big part of the RFP was a digital wayfinding experience (their words) that would guide visitors around the new site. This was certainly a possible solution, but good signage would have likely served far more people at a far lower cost.

The project did not proceed.

3. Risks and assumptions (RATS)

In my experience, few RFPs or clients have truly taken the time to assess the risks of their projects and the reasons they might fail.

This is a critical step, and thinking it through can often open up big questions that no one has considered. For example, I worked with a high-street bank that was developing a service to support small businesses. The RFP laid out the website they wanted, complete with video tutorials that covered all aspects of small business growth.

On its face, this seemed like a sensible opportunity to work on. Small businesses are the beating heart of any economy, and human inertia means that if you capture a company’s banking business early, you are likely to have it for a long time.

And yet, the opportunity was built over a huge and untested assumption… that small business owners would see this big bank as a credible source of startup advice.

When I asked this question in the discovery session, no one had an answer. No one had tested the idea nor surveyed the target audience. To misquote the fantastic movie above: If you build it… no one will come.

Here are some questions worth asking:

• Will customers adopt the new solution?

• Are internal processes equipped to support it?

• What external factors could impact success?

Find your Riskiest Assumptions to Test (the RATS) and test them as part of the discovery process. 

(A simple survey of the bank’s users would have given them the confidence to make the investment, the opportunity to address a perception problem, or the chance to create something that was attractive to the target market.)

4. Success criteria (KPIs)

This is where I see a lot of agencies getting nervous. When we define specific success criteria based on real business numbers, things can seem a lot harder. As a reminder, our notional agency Done 4U could claim success when they delivered on the project. They could add the client logo to their website and create a case study, even though the work did not deliver the result the client wanted. 

Here’s a hard truth: If we want to do great work, we have to put our money where our mouth is and measure our impact.

Measuring success requires well-defined Key Performance Indicators (KPIs) that go beyond general aspirations. Examples include:

• Reducing customer service inquiries by 20%.

• Increasing app conversions by 15%.

• Achieving a 2-second page load time.

Some agencies resist genuine KPIs for understandable reasons. However good your new customer service app is, the client may not get their 20% reduction in support inquiries if they underpromote it or shortchange the hosting. Some things are always outside our control.

But that’s why the whole discovery process is important. We don’t set KPIs with our eyes closed or (this is the classic) take the suspiciously round number that the client is aiming for at face value. We dive deep into our client’s world. We find our RATS and test them. We do discovery. 

Then we set realistic KPIs for the project with our eyes wide open… because later on we’ll want to prove that we delivered a genuine business benefit.

And even if we don’t meet the KPI—which happens sometimes—having a realistic target will tell us if we are heading in the right direction, and help us improve future interventions.

A stake(holder) in the ground

Woven through the four steps above is an understanding that every project has different levels of stakeholders with differing priorities, and we only win when they all win.

In the banking example above, the client wanted to attract new small business customers, but the customers wanted to build a small business. Those goals are related but not the same.

Or take the creation of a Content Management System (CMS).

• The client (marketing or IT leadership) may prioritize integration with existing systems.

• The customer (content creators) requires an intuitive and efficient interface.

• The end-user (website visitors) needs a seamless browsing experience.

Discovery allows us to consider the needs of all stakeholders, ensure that they are aligned, or identify what needs to be done.

If I can’t align the needs of all the stakeholders—like rings on the ring toy above—I won’t proceed with the project.

Discovery is a conversation, not a meeting

Discovery shouldn't be seen as a one-time workshop or a static document that gets dumped in a drawer—but it often is. For some reason, the valuable insights from discovery often get forgotten when the rubber hits the road. Phew, everyone thinks. Now that’s done we can do some actual work.

But that’s not how the best agencies work. Spoiler alert: Things change during projects. Business goals shift. People move on. We learn ever more about our clients.

I’m not saying that we should constantly be moving the goalposts of success, simply that hitting a goal is more like sailing a yacht than driving a car. We know our destination, but to reach it we must take account of the shifting winds and ebbing tides.

At its best, discovery is an ongoing process that:

• Keeps us focused on the right goal.

• Reduces costly project pivots by validating assumptions early.

• Strengthens trust between agencies and clients.

• Identifies new opportunities beyond the initial scope.

The best agencies—and their clients—continue to refine their discovery insights months or even years into a project. It’s not a meeting, it’s an ongoing conversation.

Final thought: Slow down to speed up

Each of these articles is written in service of accelerating your digital delivery practice. On its face, the time we take to do discovery can often seem like slow time—which gives me the opportunity to remind you of the classic bear joke.

Here’s Benedict Cumberbatch in The Imitation Game:

The point, of course, is that we go slow at the start to go much faster later. 

I’ve lost count of how many projects I’ve seen streak away like lightning… racing towards the wrong destination. (I’ve led some of them, and the result is never great.) At best there’s rework and overruns, at worst the project fails.

I solved that, years ago, by getting serious about discovery, and convincing my clients to do the same.

Start slow. Find your bear(ings). Then accelerate away.

Matt

P.S. If you’ve never seen The Shawshank Redemption, do yourself a favor and go watch it.

Bonus: Watch us discuss the way we do Discovery 

Creating the space for your team to focus

It’s circa 2009. I’m a contractor for a major telecoms company, leading one of their smaller development teams.

It’s a normal day until my Boss — the Head of Digital — taps me on the shoulder.

“Matt, would you come into a session with us please?”

“Uh… Sure.” 

I do my best to look relaxed, but my heart rate is climbing. I know that the company isn’t meeting its digital goals. My small team would be an easy target. My heart rate clicks up another notch.

I like this job. I need this job.

When we reach his office, I can see another senior manager inside. There’s nothing normal about this.

“Take a seat,” my Boss says. “We want to talk about what it is you’re doing?”

“Uh, this week’s sprint is to—”

“No.” He leans forward, cutting me off. “We want to know why your team… of five… is outperforming all of our others.”

What I learned from Tim Ferriss

In my article on ownership, I said this about the responsibility of leaders:

If we want our teams to take ownership seriously, we need to give them the time and space to do it. That’s easy to type in an article, of course, but it is infinitely harder to do.

We all know why. The world of work has only gotten louder. When I first read The 4-Hour Work Week by Tim Ferriss, I remember being impressed with—and implementing—his email autoresponder strategy. My responder at the time read something like:

Hi there, 

Thanks for your email. In order to focus on work, I check my emails at 11.30am and 4.30pm. If your message is urgent, please call me on XXXX XXX XXX.

Thanks, Matt.

Twenty years later, the simplicity of this seems almost quaint. Back then, all I had was email and phone. These days, I have email, Slack, Microsoft Teams, LinkedIn, Figma, and Calendar notifications. Many of these involve multiple accounts for different clients.

And yet, the simple premise of Ferriss’s argument holds. If we want to improve our productivity and focus, we need to batch our tasks.

The 2% difference that makes the difference

The two managers study me from across the table, the challenge still hanging in the air.

“We want to know why your team is outperforming all of our others.”

I smile. I can’t help myself as the tension washes out of my body. “Are we? That’s great.” 

My Boss makes a face. “It’s good for you, it’s not so good for everyone else unless we can figure out what you are doing differently.”

I nod. “Okay, tell me what they are doing?”

Over the next few minutes we go over how the other teams operate. It’s standard stuff. Standups. Sprints. All that. In fact, ninety-eight percent of it is exactly what we’re doing in my team.

And yet, the 2% difference stuck out like the crack in a phone screen.

“They have no time to focus,” I say.

How much work can you do in a day?

The answer, of course, is it depends.

In my view, the typical 8-hour day allows for 4.5 hours of focused work, but only if the day is set up correctly. Most people and companies manage far less. Instead of focused work, they peck and scratch at projects between incessant interruptions.

The 2% difference that made all the difference to my team’s performance was simple. I batched as many of the “interruptions” as possible into specific parts of the day.

In recent years, authors like Cal Newport and Nir Eyal have popularised this concept as Timeboxing, but I simply thought of it as clearing the decks so we could do what we were paid to do. Deliver.

The psychological principle behind timeboxing is Implementation Intention. When we set aside specific time to do something, we are far more likely to do it.

How we structure our day to optimise focus

For the teams I lead, the goal is to catch all the communication and interruptions into the morning.

In practice, this batching means:

• 9am-midday: Meetings & Collaboration
  The first few hours of the day are reserved for standups, pull requests, stakeholder discussions, and “office hours”. The goal is to remove blockers and ensure that everyone has everything they need to do their 4-5 hours of focused work.

• 1pm onwards: Focused Work
  Once collaboration is over, leave people alone to do what they need to do. 

That’s it. Like I said, the core of this is very simple. The biggest pushback I get is that this is too simplistic… that life doesn’t really work this way.

And often, those people are right. 

Implementing focus time can be difficult, especially in environments where interruptions are the norm. But this isn’t about slavish adherence. It’s about creating a meaningful default that works to everyone’s benefit, especially the clients’. Yes, sometimes you’ll have to take a call in the afternoon. That’s no reason to be ruled by a tsunami of noise.

Baby steps towards a focused work schedule

Setting up any new behaviour is hard. Here are some simple steps I’ve used to help teams move towards the goal:

1. Educate teams and stakeholders – Communicate the benefits of deep work (for everyone) and set clear expectations so everyone knows where they are.

2. Don’t start focused work until everyone has what they need – Ensure that morning meetings provide all the necessary information to make deep work sessions productive.

3. Use calendar blocking – Set visible “Do Not Disturb” times in team calendars to reinforce focus hours.

4. Encourage ownership – Empower product owners and leadership to shield developers and designers from unnecessary distractions.

5. Be role aware – Some roles are inherently outward-facing and benefit from longer “collaboration windows”. (That’s fine… These are often the roles that protect the core team from endless distractions.)

Don’t just try it. Make it your default.

Based on long experience, here’s what I predict will happen when you try to prioritise time for focused work:

1. It will be hard and you’ll get some grumbling.

2. The team will quickly grow to like it (the clients might take a little longer).

3. You’ll get more done with less stress. You’ll be over the hump.

4. Something will derail the whole endeavour.

5. You’ll be tempted to go back to the way things were (after all, it’s just easier).

That last point is the danger zone because real behaviour change is hard. It’s not about the start — because we all like shiny new things — it’s about getting back on the digital horse when you get knocked off.

I’ve failed at this often. Stuff happens, especially when you are dealing with large, complex projects. I’m often pulled out of focus, but that’s not my default.

My default is space, focus, and delivery. My goal is to have more good days than bad days. Because — trust me — good days compound.

By prioritizing deep work, your team will significantly enhance their productivity and impact. I know that from long experience… and our clients know it too.

Structured focus beats scattered multitasking every day of the week.

Bonus: Watch us discuss these ideas

How To Create Ownership Within Your Team

In this article, I want to ram home the importance of ownership and responsibility for highly-performing development teams. 

We’ve talked about trust as the foundation of accelerated digital delivery, but trust is a byproduct of a consistent, team-wide pattern: Doing what we say we’ll do.

Why it’s always our fault responsibility

Delivering on our promises shouldn’t be a controversial idea, and yet our industry suffers from an epidemic of missed deadlines, stalled projects, and ballooning budgets. Of course, none of these things are ever our fault. It’s other people that are the problem, or poor processes, or constantly changing requirements.  

Sounds familiar, doesn’t it?

I missed many deadlines in my early career. Some were genuinely unavoidable, but many gave me that “bad curry” feeling deep in my belly. Could I have done something differently?

In my later role as a consultant, I’ve worked with numerous struggling development teams. Many are watching helplessly as deadlines whizz by, and often teams stall, often descending into blame and name-calling. “I did my best,” people say, “but I’m not responsible for what happened before/after it left my hands.”

We’ve all heard and we’ve all done it, but here’s the thing: I never hear that from highly-functioning teams or people. They think about the work in a different way.

This entire series is about accelerating delivery, but none of the principles and tactical advice matter unless people take real ownership of the work.

So let’s take five minutes and talk about how you and I can take responsibility to help them do it.

There is no “I” in accelerated digital delivery (uh, what?)

Let’s start with the obvious. In digital development, we are generally paid to do something specific. We’re a team leader, a product owner, a designer, a developer, a UX writer, or whatever. We are valued because of our specialism, our experience, and our ability to execute in that field.

But wait. Our specialism is really only valued in relation to the wider team. In the long run, no one is paid for a specific skill, they are paid because they were part of a group—a team—that delivered something valuable.

No delivery. No jobs.

Common sense? Of course, but then again, I’ve met plenty of otherwise talented people who seem happy to wash their hands of everything outside their area. “I’m not a designer,” they say, “how can I be responsible for good design?”

To be clear, I don’t believe that developers should “do” design any more than designers should “do” development, but 20 years of experience have shown me that caring about the work beyond your silo is highly correlated with excellence.

So how does that “caring” manifest in the real world?

Who’s the real client?

As I’ve said before, the handover is a critical focus of accelerated digital delivery. When we do it well, work flows smoothly through the system, when we don’t, projects stall or go backwards.

To illustrate this, let’s imagine that a “siloed” designer “throws” some wireframes over the wall to development without proper support or documentation. A good developer may be able to do the work, but it won’t be an efficient, accelerated workflow. At best there will be bitty back-and-forth conversations, at worst there will be misunderstandings, rework, and stress.

By contrast, imagine a designer who sees the developer as their client. This designer isn’t just doing a design, they are taking ownership and making sure that their “client” has everything they need to pick up the project and run with it.

Depending on the processes in place, this might include:

• A short handover meeting (that the designer arranges and leads).

• Designs that are signed off by the client (to minimise future changes).

• Wireframes prepared for both desktop and mobile views.

• Copy that’s finalized in collaboration with a content writer.

• Clear documentation and videos explaining the work (and the thinking behind it).

• A follow-up chat to address any issues.

This is a concrete example of “caring beyond your silo”, and works all the way down the line. If the developer is handing the project over to Testing, they should see Testing as their client.

Teams that work this way function smoothly by default. There are always issues to resolve, but they are far fewer because no one is “done” until the next person in line has everything they need.

Some people (diamonds) naturally work this way. They make it their business to understand what the next person needs and deliver it. Others—perhaps the majority—need help to make this step and understand what “done” looks like for them.

And that’s where we (and our processes) come in.

Defining what “done” looks like

If we want people to take ownership seriously, we need to define what that means. In other words, what does “done” look like for each role within the project?

Building on the ideas above, this can be achieved with:

1. Clarity in roles and responsibilities
   Every team member must understand their role in the delivery process, who they are handing off to, and what is required before they can hand it over.

2. Checklists
   These requirements are codified in a checklist that must be completed before the project moves on. (Checklists remain the most undervalued assets when it comes to delivering our work with speed and precision.)

3. Structured handovers
   The baseline for this—believe it or not—is simply that a formal handover actually happens. I’ve been parachuted into teams where there was no handover process, and it was all too obvious in their performance. If you aren’t doing it already, start. Make it a formal process and improve as you go.

… which leads us to another critical aspect of ownership.

There is no “best” way

I’ve been working in digital development for decades, but I’m well past believing that I have the “best” production process. All I can claim is that I have the best so far for my particular teams and their needs.

We don’t carve our processes in stone and demand that others follow them unthinkingly, we write them in digital ink and challenge others to improve them.

Better ideas are everywhere, especially when we break out of our silos and look at what’s working elsewhere. We didn’t always ask our designers to create videos of their user journeys, but an idea sparked by YouTube demos has become a valuable part of our handover process. I can’t remember exactly who suggested it, but it was just as likely to have been a developer or product owner as the designer themselves.

Ownership isn’t just about meeting deadlines and doing good handovers—it’s about continually improving the outcomes for the team and business. 

At least, that’s what I hope for you and your team. Unfortunately, some people struggle to care about what happens outside their silo. What about them?

Square pegs versus round holes

We’re all familiar with the square pegs of the development world. They may be brilliant—although often less so than they believe—but they can’t (or won’t) get with the program.

Whether in nature or digital development, lone wolves rarely survive.

Whether in nature or digital development, lone wolves rarely survive.

Our job, of course, is to help them as much as we can. Mentoring. Clear processes. Warnings when appropriate. If that works, great. If not, we need to consider more radical action.

Great teams are built of great people, great people take ownership of the whole as well as the specific.

It’s often said that one brilliant developer is worth ten mediocre ones, but honestly, I’ve seen it go either way. Brilliance can sometimes struggle to see that there might be a better way, or that someone else might have a useful idea.

I have and want brilliant people in my team, but ownership and teamwork are a baseline if you want to build an accelerated digital delivery practice.

If someone can’t work that way, they are going to be better and happier somewhere else. And so will we.

Actionable steps that strengthen a culture of ownership

Before we finish, let’s just review the actionable steps I take when I’m working with a team that’s struggling with ownership. Here’s a roadmap to turn things around:

1. Name the person with overall responsibility for the final project outcome
   This will be your project lead… the specific person who aligns the team and oversees the steps below.

2. Define the process
   Break your delivery pipeline into clear stages (e.g., Design → Design Handover → Development etc).

3. Assign responsibility for each stage
   Make it clear who owns each step in the process. Define at what point ownership transitions.

4. Create explicit checklists
   Include detailed criteria for what “done” looks like at each stage. Automate these checklists where possible—for example, adding them to your cards on a Trello board.

5. Set Work-in-Progress (WIP) limits
   Avoid overburdening team members by limiting how much work can be in progress at once.

6. Mentor and monitor
   Use the process itself as a tool to mentor team members, showing them how to improve their delivery approach.

Start with yourself

There’s one last thing to talk about, and it’s our responsibility.

If you paused on step 4 above, setting Work-In-Progress limits, you’ll have noticed that it was new to the article. I’d be shirking my responsibility to you if I didn’t touch on that in greater detail.

While it’s lovely to get caught up in fantasies of everyone caring about everyone else and pulling in the same direction, it’s useful to remember that we are all human.

It’s hard to care about anyone else when we are buried under work and stress.

The biggest threat to ownership—and accelerated delivery in general—is too much work in progress. Lean manufacturing has a word for this, Muri, that’s usually translated as “overburden”. Put simply, when there’s too much to do, shortcuts get taken, critical steps get missed, and systems fall apart.

If we want our teams to take ownership seriously, we need to give them the time and space to do it. That’s easy to type in an article of course, but is infinitely harder to do.

What I can confirm, while nursing the scars of long experience, is that the universe will happily reinforce whatever path you choose (or are forced) to take. Too much work will lead to stress, mistakes, and siloed-behaviour as people seek to protect themselves. Rework and missed deadlines will mean more work but less progress.

By contrast, doing less work promotes ownership, teamwork, and adherence to processes that will accelerate your digital delivery.  

If we want others to take wider ownership for the results of the team and business, it’s up to us to take the first step.

Bonus: See us chat about Ownership

Why Clarity is Critical for Accelerated Digital Delivery

True story.

I’m in my office. It’s 10AM Friday, and I’m banging my head against my laptop.

(That’s a metaphor, but it might become true any second now.)

In two days, we’re supposed to push an update live for a major retail client. I’m not running the project, but I’m checking the Kanban board to confirm we’re ready. Go? No go?

And we’re not ready. Not nearly.

The UAT column still has cards on it. Not one, or two, or even ten. Ninety-five unaccepted cards.

I need to talk to the team. Now.

I count to ten… get as far as three… then reach for Slack.

---

From pictures to processes

In the last article, we looked at how visibility accelerates digital delivery. Here’s the crux of it:

Visibility is about making it easy for others to see where we are—by which I mean our status, our work, and our overall progress. When we do this as a team, a lot of good things happen.

Although visibility is (sorry, I can’t help this) easy to see, it’s only ever a snapshot of a moment in time. It’s a picture of the process, not the process itself.

And herein lies the danger.

In almost every business conversation I have (or article I write), I touch on the importance of process. It’s process that drives work through the system. It’s process that governs how fast, efficiently, and accurately we deliver.

But “process” is not a principle. Every team I’ve worked in, whether world-class or amateur-hour, has followed some form of process. Some were friction-free and wonderful; others were the digital equivalent of working with the Sheriff of Nottingham. 

(“Locksley! I'm gonna cut your heart out with a spoon!”)

If great processes drive great results, what drives great processes?

---

10:17AM

I’m talking to two developers on the project. Their response to the 95 cards is a helpless shrug of their shoulders. They did their job by getting their cards to UAT. What happens next isn’t their responsibility.

They're not wrong, but neither is this helping us get back on track. The guy responsible for UAT isn’t in today, but he knew about the deadline. We need to push the update on Sunday because that’s when our client’s (300) retail stores are actually closed.

If we miss this window, we miss a whole week.

Here’s the thing. I trust the team. It doesn’t make sense that they would leave without mentioning 95 untested cards.

Which means that I no longer trust what I’m seeing on the Kanban board. Should we be testing all of these cards? Some of them? None of them?

We have a huge amount of visibility… but zero clarity.

---

Clarity (and the three questions that matter)

Clarity is a critical principle in accelerated digital delivery. If you’ve worked in or with an outstanding team, you’ll know that that can always answer three key questions:

• What needs to be done next?

• How should it be done?

• Who is responsible for doing it?

If you think this sounds simple, you’re right, but it’s also rare, especially end-to-end across a process.

That’s why written processes—checklists and Standard Operating Procedures—can be so valuable. They separate the signal from the noise, lessening our reliance on snatched conversations or half-remembered meetings.

Instead, we have clear, functional steps that relentlessly move our project forward. 

---

10:37AM

I’m getting ready to do something I hate—reaching out to people who should be enjoying a day off.

At the moment, I trust each of them far more than I trust the Kanban board. I’m hoping that the cards are actually done, but are sitting in the wrong column.

In other words, I’m hoping that this is a handover problem… a process problem.

And the irony of that hope isn’t lost on me.

None of these people are responsible for our process. I’m the leader. That’s my job.

I send the message.

---

Focusing clarity where it matters most

World-class businesses are highly functional, creating massive value for their clients or customers.

If your team can answer “the three questions that matter” at every stage, work flows quickly through the system. When they can’t, it stalls, goes missing, gets done twice, or (often worst of all) done poorly. I have a special loathing in my darkest heart for work that needs to be redone. That wrecks project plans, budgets, and confidence in equal measure.

And although the principle of clarity is simple, the reality is that it takes a lot of work—especially if we are talking about complex work like digital development.

In practice, it can help us start if we focus on a few high-risk areas. Here they are:

Meetings

There’s a blizzard of advice on effective meetings, but to my simple mind, it comes down to three things:

•  Know what you need to resolve.

• Get the right people in the “room.”

• Document the decisions, actions, and responsibilities.

That’s it.

Handovers

The gap between one person putting a “project” down and another picking it up may be the single biggest risk to accelerated delivery. A customer mindset is critical here. If the UAT Team (to take a random example) is the developer's “customer,” what should the developer provide? What does the UAT team need to successfully execute their work—every single time? Again, this is simple stuff, but standardising how work gets transferred has saved our team thousands of hours.

Feedback

Many of us suck at giving effective feedback. The gold standard is, of course, fast, specific, and honest. Often, though, what we get is slow, vague, and obfuscating.

It should go without saying that brutal or overly personal feedback rarely helps anyone, but neither does sugar-coating the truth. Great people value good feedback because they want to get better. Make feedback sessions into conversations that produce clear, specific, and documented steps forward. That’s the (functional) reason we’re doing it.

Problems

Things go wrong. Mistakes are made. Clients change their minds (then change them back). That’s life. Problems are rarely a disaster in digital development, but our response can often be the difference between starting to fix things right away or spiraling further downhill.

Here’s the critical thing to remember: The moment of guilt, panic, or frustration after you or a teammate makes a mistake is the moment you’re at the greatest risk of making another. One problem is rarely a disaster, but three or four compounded together are what sinks ships, downs planes, and gets contracts cancelled.

Create a clear process for reporting problems, with explicit protections for the team member reporting the issue. We don’t want people hiding mistakes, we want to know about them and get them fixed. Four questions are useful here to get clarity and move forward:

• What happened?

• Why?

• What do we need to do to fix it?

• How can we prevent it from happening again?

Also—don’t leave struggling teammates in some asynchronous Slack channel waiting for the occasional sad crumb of advice. Jump on a call and actually help them.

---

10:47AM

My phone shivers on the desk in front of me.

It’s Slack—one of our UAT team responding to my questions. A quick message, but more than I have any right to expect on their day off.

I read it; then I reread it to ensure I’m getting it correctly. There’s some confusion in the message, a touch of surprise… but fundamentally it sounds like we’re okay.

The client’s UAT team has already signed off on ninety-three of the cards; the other two are last-minute bugs being worked on today.

The code will ship on Sunday.

“Okay”, I think. “Okay, fine.”

But it’s not fine yet. This was forty minutes of raised blood pressure and low productivity. I still don’t know why ninety-three cards were in the wrong place, or why the reason wasn’t captured and communicated.

There’s no clarity yet, but there will be.

And once I understand the issue, I’ll fix it with clear, functional communication because that’s how we roll. 

In my head—at this moment—I’m a rock star.

Springsteen at Madison Square Garden. 

The Beatles busking on that roof.

And weirdly, because I’m a process nerd, I’m starting to enjoy myself.

---

Building a culture of clarity

Over the next few weeks and months, I plan to write and record specific articles and videos to demonstrate how we deliver clarity in practice—but mostly, this is simple stuff.

• A standard meeting template (with someone responsible for filling it in.)

• A Trello card checklist that must be completed before a handover.

• A clear process for capturing problems (and their solutions).

Clarity may be simple as a principle, but it’s still work. Not just to create the assets you need, but to use them enough that they become second nature to you and your team.

At first glance, functional communication can feel humourless and restraining, but in my experience the opposite is true. Teams that adopt this principle have more fun, less stress, and do better work.

Clarity makes hard work easier. When we do it right, we learn to trust the system and each other. When we don’t, digital development is like trying to do open-heart surgery… with a spoon.

---

Bonus: Watch us discuss clarity

Why visibility is crucial to efficient digital delivery

There’s a secret to accelerated digital delivery that I haven’t discussed much… mostly because it feels too dumb to say out loud.

Here it is: Avoid making big mistakes.

As I said, it sounds dumb… but hear me out. In software development—as in anything—there are two ways to solve problems. As a kid, I learned the “fix it” mindset. When something goes wrong, you do something to solve it—a post-problem remedy of some kind.

I think of post-problem fixes as an old-style manufacturing solution. If a car leaving the production line fails its final inspection, it gets shunted into the “finishing shop”. It may need something as simple as a respray, or it may need stripping back down to the engine.

Either way, there’s going to be a delay, and other “mistakes” are piled up ahead and behind it.

Does any of this sound familiar?

Speaking as someone who witnessed (and caused) a decent number of mistakes in the early part of my career, I believe that struggling projects often replicate this sad story: 

A mistake is caught late, delays production, and must be rectified as quickly as possible because it’s causing knock-on issues with other work.

As I said, avoiding big mistakes is a huge part of bringing your project in on time and budget.  

The question is… how?

In the last article, I wrote about accelerators—reusable components we deploy with 100% confidence. They are a huge help in avoiding mistakes.

But accelerators can’t do it all. Every project involves bespoke thinking, unique design, and custom code. That’s how we solve our clients’ problems. And I love it. Solving unique problems is just about my favourite thing. 

But it’s also where we are most at risk of making a costly mistake, hitting a brick wall, or heading off on a wild goose chase.

To mitigate those risks, we need a different tool from the toolkit. We need to build Visibility into every part of our process.

What is visibility in digital development?

Visibility is about making it easy for everyone to see the wood for the trees. Making it easy for others to see where we are—by which I mean our status, our work, and our overall progress. When we do this as a team a lot of good things happen.

• Status: Is a teammate “at work,” either remotely or at their desk? Are they available, in a meeting, or “asking” not to be disturbed?

• Work: What are they focused on right now?

• Progress: Is their work on schedule, ahead, or falling behind?

Later in the article, I’ll discuss practical ways to ensure visibility, but for now, let’s just focus on the practical benefits.

Visibility Benefit 1:
Mistakes surface early

The earlier we can see a problem, the less chance it has to derail us.

This is not a new idea. The aging car lines mentioned above have long since been replaced by lean manufacturing processes. When a modern Toyota worker spots a problem there’s no waiting or shunting the car off the line, they pull a cord that lights up a big board and gets people moving.

If the problem isn’t resolved within a short time, the whole production line stops. You can see this concept—Jidoka—in the following video:

Problems are resolved right on the line—before they infect multiple vehicles.

Digital development isn’t manufacturing, but we can still benefit from fast problem resolution. But we can’t solve them unless we can see them.

Visibility Benefit 2:
Course corrections happen faster

How often have you done a ton of work only to find that it wasn’t what the client wanted? Like, at all?

I’ve seen this happen with design work, feature development, and even proposal writing. Somewhere between you and the client, the brief got garbled (I’m being kind) and the wrong end of the stick was grabbed and run with.

And it’s not just with clients. As a young project leader, I had team members cheerfully nod at my requests and disappear to do the work. Later on—sometimes days or weeks later on—I’d check on their progress only to discover that they’d completely misunderstood.

(Or had they? As we know… clarity is now one of my key principles for accelerated digital delivery. Perhaps there’s a good reason for that!)

In any case, working on a tangent is another reason why keeping work visible—whether for ourselves or our clients—can save a lot of pain.

If we can check in with each other easily and often, course correction becomes a lot easier.

Visibility Benefit 3:
Smoother resource  allocation 

If one of the team is struggling with a piece of work, either its scope or its volume, I want to know as soon as possible.

If they need advice, we can give it. If they need support, they can have it. If the piece of work needs more bodies, we can get them.

Visibility Benefit 4:
Consistency increases

I’ve known people who deny it, but I believe that visibility taps into a basic truth of human psychology: We behave differently when other people are watching.

The degree of difference may vary from person to person, but broadly speaking, we are designed to care about the opinions of those around us.

This can be extremely useful when we are running a team.

In the Accelerators article, I talked about the huge practical value of checklists and processes. I stand by that, but I also know how many development teams have tried to create standard operating procedures, only to find their use degrade over time… and lead to mistakes and delays.

I feel your pain, so let me suggest that making everyone’s work visible is a big step in the right direction.

When our work is truly available to those around us, when we are working on shared documents (or even shared code), we are far more likely to follow a standard.

And—providing the standard is genuinely good—everyone benefits.

How to make your work visible

As you’ll have noticed, we’re really talking about three directions of visibility here:

1. Our teammates need to know who’s working, and on what.

2. Leaders need to track project progress so that they can deliver support when it’s needed. 

3. Clients need to see that the project is delivering. Regular updates reduce surprises and keep them feeling included in the project’s journey.

The way we deliver visibility will change depending on the audience, but building visibility doesn’t have to be complicated. Here are a few tools and setups that make a difference:

• Availability indicators: Simple tools like Slack status lights signal availability. Remote teams don’t have the benefit of in-office cues, so setting statuses to show availability is essential.

• Scheduled rituals: Remote or not, structured visibility practices like daily standups, weekly updates, project demos, or “show and tell” sessions with stakeholders go a long way to keeping everyone informed.
  For clients, weekly sessions to share what’s been achieved and what’s planned help clients feel engaged without micromanaging every step.

• Shared Tools: Tools like Figma for design or shared project boards in Trello allow the whole team to see and comment on work in real time.
  
  Although some might hesitate, giving clients access to tools like Figma or Miro can streamline feedback and keep alignment on track. Yes, there’s a chance of over-commenting, but more often than not, this access just encourages valuable feedback early on.

• Detailed project tracking on Kanban Boards:  Forget the Backlog/Doing/Done approach, use systems like Trello or Monday.com to represent each stage of development.
  Makes it easy for anyone to see where each task stands. Moving a card along the board is simpler and clearer than updating each card’s status individually.

• Use progress indicators: Many of the tools we use can send out automatic updates when work progresses to the next stages. For example, switching design screens to dev mode in Figma can alert the dev team in Slack, or build processes can send status emails.

All of these ideas can be useful, but—as with any technology—leaders must find the balance between what helps… and what hurts…

Side note: Too much visibility leads to obscurity

We all know the frustration of being copied into endless emails, invited to pointless meetings, or becoming blind to apps that notify us about every little thing.

Sometimes this is because the defaults are just wrong, sometimes it’s about people covering their posteriors… and sometimes it's a sign that our teams lack the confidence (or autonomy) to make their own decisions.

These are all good topics for future articles, but the result is the same.

Too much visibility creates noise.

In my last article, I mentioned the value of setting “smart defaults.” The keyword here is “smart.” Getting visibility right is not about blindly following my advice—or anyone's—it’s about doing what works for your team.

If in doubt, start slow and ask for feedback. It’s okay not to know everything, which leads me to…

The biggest benefit of visibility

As I type these words, I’m feeling on edge.

Soon, I’ll share the first draft of this article with smart people I trust… people who know me well enough not to spare my feelings. So naturally, I’m filled with doubt. Not about the ideas, about the way I’m expressing them. Is the article poorly written? Is it obvious? Is it boring?

Visibility requires vulnerability. Putting your work out there, whether it’s an article, a design, or a piece of code, can feel exposing, especially if things aren’t going well. But if you and your team can learn to live with vulnerability, there’s a huge prize to be won.

When we are open and transparent, others find it easier to be the same with you. The best teams I’ve worked with all share this trait—everyone cares more about being good than being “right.”

There’s a ton of power in saying simple things like “I don’t know,” “What do you think?” or “I need help.” Once you get comfortable with vulnerability, you create a virtuous circle:

• Team mates are more likely to raise issues early, which means…

• Problems and challenges surface sooner, which means…

• Mentors and peers have more time to help, which means…

• Issues get fixed faster, which means…

• There’s less stress (and more progress) within the project, which means…

• Team mates are more likely to raise issues early…

And so on.

We’ve all seen the alternatives: Some teams snipe or bicker. Others—and this is often worse—barely talk at all.

If you can see it, you can solve it

Once you’ve seen the value of working with the door open, it’s hard to unsee. Visibility isn’t just about knowing who’s available or what’s been done. It’s about creating an environment where everyone—from team members to clients—feels informed, aligned, and trusted. 

By contrast, low-visibility projects often generate unforced errors, distrust, misunderstandings, wild tangents, and blame (as things go off the rails).

If you’ve spent any time working in digital development, you’ll have likely witnessed some or each of these things.

None of them are fun or productive.

So let’s stand out. By committing to make our work visible, we build a foundation of trust, a currency that keeps projects moving, builds client confidence, and ultimately leads to more successful and stress-free digital delivery.

Start with your own work, then push out from there.

Bonus: Watch us discuss these ideas

Accelerators: The Fastest Way to “Accelerate” Your Digital Delivery

In the previous article, we explored high-level principles that support accelerated digital delivery—Trust, Clarity, Visibility, and Consistency.

These are all well and good, but for principles to mean anything, they have to make a practical positive difference where the work is done.  (We all know companies that preach one thing but do another, just as we know “principles” that buckle and fail under the pressure of reality.)

So how do we bring a principle—say consistency—to bear on actual work?

I’m glad you asked. 

In this article, I want to zoom way in and show you how we embody the principle of consistency in our development processes.

The method is what we call “Accelerators”... but before we get into those, let’s touch on a problem I see in a lot of development teams (and myself).

Why shiny things can kill your business (my precious)

Humans are wired to pay attention to anything new, but I often feel that developers got a double dose of the shiny distraction gene.

Developers LOVE a new shiny thing—especially if it’s a tool or process.

But this is a big reason why we (and our digital development projects) are so often derailed.

I’ve seen this too many times to count in my career. A development team makes a rational and sensible decision to try something new. The new thing—whatever it is—promises a better result in some meaningful way.

And for a while, it seems to deliver.

But then, problems arise that are both unexpected and inevitable.

Because we don’t know what we don’t know.

In psychology, this is related to the Dunning-Kruger Effect, the (much argued over) idea that humans tend to overestimate their abilities when outside their specific areas of expertise.

I can’t speak to the science, but I know from experience that when I’m faced with something new, I often lack the expertise to recognise my… lack of expertise.

The same is true for development teams who try something new and exciting. Here’s how the cycle plays out in digital delivery:

• When starting something new, your team feels highly confident. The project looks simple at first, fueled by incomplete but compelling online examples. Overconfidence reigns.

• Reality sets in. The task, tool, or system is more complex than initially thought. Unexpected problems and delays arise. Confidence plummets and progress grinds to a crawl.

• Slowly, as they hack away at the problem, the team starts to figure things out. They gain efficiency as they become more familiar with the new tool or system.

• Eventually, after mastering the tools and processes, the team reaches the point where they can make accurate predictions and deliver reliably.

Although I’ve exaggerated the cycle for effect, my guess is that many of you will recognise the stages above in some form. Initial overconfidence leads to disillusionment and, finally, a hard-won victory—but only after losing precious time.

This cycle explains why shiny new things can be so disruptive. 

If we aren’t careful, we end up constantly reinventing the wheel… endlessly revisiting stages one and two.

Zero consistency. Maximum stress.

Not to mention unpredictable timelines and unhappy clients.

So what’s the alternative? How can we set up camp in stage four and live there?

Our answer: Accelerators.

What is an Accelerator?

An Accelerator is anything that allows us to work faster, more consistently, or more reliably. It might be a process, a piece of code, a design pattern, or even a piece of infrastructure. 

An accelerator can be something as simple as a consistent folder structure in your Knowledge Management System, or as complex as a full design system (complete with tokens). 

The key thing is this: Accelerators can be reused across multiple projects.

When we create accelerators, we are codifying our expertise, reducing complexity, and setting smart defaults for ourselves.

We are making our work (and lives) consistently easier.

Ten practical examples of Accelerators at work

Let’s look at some practical examples of Accelerators—big and small—culled from our team.

1. The two-character email address

When I need to type my email address out, I use a two-character code (,e) to trigger a snippet in Alfred.

2. Our Project Delivery checklist

Checklists can accelerate progress by reducing the mental load on your team and ensuring that nothing is overlooked. (If you’ve not read Atul Gawande’s book, The Checklist Manifesto, we highly recommend it.)

Here’s the simple checklist we use to sanity-check whether we should start a new project.

3. Easy email templates embedded in our workflow 

Using Google Docs to write articles makes it easy to embed email templates within our workflow. Once the second draft is done, for example, we send a standard email to our outside reviewers to get feedback. A single click opens an email with the recipients and content prefilled. Paste the link, hit send, and you're done. 

4. A consistent folder structure across all platforms

I loved the practical simplicity behind Tiago Forte’s book,  The PARA Method. Forte argues that we can organise our work, thinking, and lives into four categories: Projects, Areas, Resources, and Archives.

In a world where information is often spread across multiple platforms, having a common structure can hugely increase the speed at which things can be found.

5. Template cards on Trello

Templates allow us to build smart defaults into our systems, releasing us from busy work we must do every time (and avoiding the chance that we’ll miss something important).

6. An “accelerated” desktop

If you know the French phrase, “Mise en place,” (putting in place) you’ll understand how seriously professional chefs take the idea of smart defaults. They know that their best work requires every tool and ingredient to be where they expect it to be at the start of service.

Our Content Strategist uses this one-click shortcut (in Keyboard Maestro) to reset his desktop at the start of every session, arranging apps and Chrome tab groups into specific places… because knowing exactly where things are is a huge accelerator.

7. Our design system in Figma

Figma allows us to reuse our design patterns, literally embedding our expertise and experience into the interactions and code.

8. The standard process we follow to deliver client projects

9. The document we fill out after the Discovery Sprint

Every delivery begins with a Proposition Brief, a standard document that puts us and the client on the same page… literally and metaphorically.

10. And a bonus…

Naturally, as we’ve just started writing articles, we have an article template set up in Google Docs. This will develop over time, but its early existence speaks to something more important than any individual example… our Accelerated mindset.

Building an Accelerated-mindset

It’s probable that none of the examples above surprised you. If you work as a developer, I certainly hope that you already have a documented process, use tools like Figma, and develop reusable code.

If you don’t, start there. (I’ll be writing articles that cover each of these things.)

But assuming you do any or all of the above, I’d like to invite you to think bigger. Reusing email validation code is one thing, but what if we could lift and reuse whole sequences?

Here’s an overview of a login sequence we have reused in numerous apps.

What happens when things HAVE to change?

As you’ll have noticed, our examples above include plenty of recent tools and technologies, so let's address an obvious criticism of the argument I’ve been making.

Yes. Sometimes we have to learn new things. And sometimes, the pain of change will be totally worth it. The question is… when do you want to feel that pain?

I’ll tell you when you shouldn’t want to feel it—when you are working on a client project.

That’s why we never (ever) experiment on Customer Code.

Instead, we rely on our code library, design system, and interaction guides. These tools are built from cumulative knowledge across numerous projects, allowing us to deliver quickly, reliably, and confidently every time.

Accelerators will give you the confidence to move fast without breaking things. That’s what we’re paid for. That’s what builds our business.

And because we can deliver so quickly and efficiently for clients, we have the time to experiment (on non-client) code when the business case arises.

Conclusion: The four BIG benefits of Accelerators

In today’s development landscape, every moment counts. As my friend Don Norman says: “The moment you start a project, you are already behind schedule and over budget”. 

Accelerators don't just speed things up—they improve quality and predictability through:

• Speed: By starting with known, stable assets, you avoid the time sink of creating infrastructure from scratch. For instance, a one-click authentication system can save hours, if not days, of development work.

• Predictability: With accelerators, you know exactly how long tasks will take because you’ve done them before. This predictability is invaluable when creating timelines and managing client expectations.

• Cost-Efficiency: Time saved is money saved. By accelerating the delivery process, you reduce the cost of production and boost profitability per project.

And here’s the final benefit. If you allow accelerators to handle the repetitive tasks, you free yourself and your team to focus on what truly matters—the innovation required to make each specific project the best it could possibly be.

Trust me. Consistent, stress-free delivery is the shiniest thing of all.

Still struggling to deliver apps or digital products on time? Here are the four principles that underpin our success.

Why is digital product development still so hard?

Over the past 20 years, I’ve worked in dozens of development teams and connected with hundreds of developers. By and large, they were smart, motivated people trying their best to deliver high-quality work on time and budget. 

And yet… if you’ve been a product owner or team leader, you’ll likely know the pain and suffering of digital delivery.

Patchy progress. Missed deadlines. Broken features. High-team turnover. Amateur mistakes and misunderstandings. Unchecked feature creep. Stressful meetings. Angry clients. Knock-on effects that (arrggg) force the next project onto the back foot.

Many of these frustrations are burned into developers like a brand… along with sleepless nights and ego depletion. In more extreme cases, entire careers are impacted, not to mention the clients and businesses that rely on the work.

It shouldn’t be this way. We have Lean, Agile, Scrum, Kanban, and hybrid methodologies of every hue. We have tools and processes that our technical forebears could only have dreamt of.

So why does digital product development still feel like juggling smoke?

My answer… and I say this as a 20-year veteran, is that effective digital delivery doesn’t start with tools and methodologies.

At UX Consultancy and Creation On Demand, we’ve built our reputation on four simple principles. There’s nothing radical about them except that they just work. Whether you are an in-house department or a remote team like us, they’ll help you accelerate digital delivery.

But before we look at them, let’s answer an obvious question.

---

Why put principles before processes?

Why principles first? Because they streamline and simplify most of my decision-making. In a market constantly offering new and shiny ideas, principles keep us focused on the fundamentals.

If that new tool or process isn’t helping you do the work that matters most, it shouldn’t matter how shiny it is.

Our principles save time, but be warned—there are no magic bullets here. Nothing I’m about to reveal will stun or surprise you. If anything, your reaction will be muted disappointment. Of course, you’ll think. I know this. Why are you wasting my time, Matt? I’ve got piles of unread emails…

And you’ll be tempted to move to your next internet snack.

But that would be a mistake.

Knowing is not the same as doing. Although you’ll recognize the principles below, the likelihood that you have truly and genuinely internalised them is far smaller. Few development teams have.

As with much of life… it’s not the ideas that matter; it’s the discipline and commitment to follow them through.

---

The four principles we built our house on

In future articles, I’ll explain how we inject these principles into our day-to-day work, but for now, I want to focus on the basics.

Principle 1: Trust

Trust is the single biggest accelerator in our business—perhaps any business. Trust between teammates. Trust between partners. Trust between agencies and their clients. 

Nothing is more important, but there are a couple of real challenges here.

First, you can’t just go out and get some trust. It’s like happiness, a side-effect of other things. This is apparent from our in-house playbook, which lists ten trust-building practices:

1. Valuing long-term relationships. We are in business for the long term and act accordingly.

2. Honesty. We always tell the truth, even if it’s awkward.

3. Honouring our commitments: When we make a promise, we follow through.

4. Admitting when we’re wrong. When we make a mistake, we own it.

5. Clear communication. We are precise in our speech and writing. If we aren’t sure about something, we ask for clarification.

6. Being helpful. Without agenda, we strive to be helpful to our customers and colleagues.

7. Caring. We show we care by being interested in other people. Remembering the little details goes a long way. 

8. Standing up for what’s right. We won’t sacrifice our values for what’s quick and easy (see 1).

9. Transparency. We explain what we’re doing and why—and gladly share our expertise.

10. Being vulnerable. We aren’t superhuman. Sharing our problems or fears isn’t a weakness; it’s a strength—especially when we all help each other.

Working in this way inevitably builds trust, both within the team and with our clients. The practices are simple, but simple is not the same as easy. I’ve worked in enough teams to understand how easy it can be to make a mistake.

• The “white lie” about timings for a stalled project.

• The rushed email that sacrifices accuracy for speed.

• The pressure to “work through the night” (that precedes the inevitable burnout).

Trust is valuable precisely because it is so hard to create. That’s why our three remaining principles are designed to help us earn and deserve it.

Principle 2: Clarity

Although we touched on communication above, Clarity is critical enough to be its own principle. I’ve seen more projects fail due to poor communication than anything else:

• Bad RFPs waste everyone’s time.

• Poor proposals lose bids… or win them (which is often worse)!

• Hurried emails cause confusion.

• Poor mockups require questions and revisions.

• Hiding issues—or ass-covering—wastes everyone’s time.

In future articles, I’ll detail how we build clarity into our tools and processes, but for now, here are the simple guidelines we follow:

• We pay attention to the details.

• We ask clarifying questions.

• We finish our conversations only when we are sure everyone understands.

• We document our meetings.

• We ensure our project documentation is consistent.

The goal here is simple… for everyone to understand exactly what’s been agreed, their role within the project, what’s expected of them, and when.

Again, simple isn’t always the same as easy, but taking the time to be clear avoids all manner of self-inflicted wounds.

Let’s look at another way to make life easier…

Principle 3: Visibility

Digital product development can feel like an iceberg, with 90% of the effort hidden from view on hard drives or cloud servers. If you run a remote team, as we do, it can be harder still to know what’s going on.

And that’s an issue because effective development requires visibility—of people, progress, and problems. As a product owner or team leader, I need to be able to take a quick look around my (virtual) room and see the status of the project. Is everything where I expect it to be? Is something falling behind? Does someone need help?

The gold standard is this: No surprises.

Visibility of progress gives you and the client confidence. But if you can’t have that—we all work in the real world, after all—the next best thing is an early warning if there’s an issue. High visibility of people and their work allows us to course correct when snags occur.

There are numerous ways to increase visibility, from standups to kanban boards. We’ll cover many of these methods in future articles, but at a basic level, we have our team members follow these guidelines.

While working, we will:

• Be present and visible to our colleagues (whether in the room or on Slack).

• Let teammates know if we’re unavailable: in a meeting, on focus time, at lunch, etc.

• Check in often, ensuring that our tasks are properly tracked.

• Attend meetings on time and be ready to focus.

• Surface issues or questions as soon as they arise—no waiting.

Principle 4: Consistency

To state the obvious, it’s no good doing a great job once.

Great teams don’t just deliver; they deliver every time. Day in. Day out. Rain or shine. Relentless performance is a crazy powerful trust generator, and the secret to getting it is really no secret at all.

Consistent teams follow consistent processes, use consistent tools, and act in a (say it with me) consistent way.

It blows my mind that so many companies still develop on an ad-hoc basis. It pains me that so many others do the work to develop a process only to abandon it when things get tough.

I’ll talk about the processes and accelerators we use in future articles, but for now, I want to highlight the critical importance of having a documented way of doing things. For example:

• We don’t develop our wireframes until we know our user stories.

• We don’t map out user stories unless we’ve gone through our Discovery process (step by step) to understand the nuance of what the client is looking for.

True consistency can require real discipline at first, but trust me, it gets easier… and then it becomes your engine of growth.

To be clear, I’m not saying you shouldn’t change or evolve. Quite the opposite. Once you have an agreed standard of work, you have something that can be tested and improved. For example, the process we use to write and publish this article will likely look very different six months from now.

Stick around. Maybe I’ll write an article on it.

---

Putting the pieces together

When you’ve made as many mistakes as I have (and delivered as many projects), it’s hard to ignore the patterns around you—especially this one...

Trust makes every aspect of business easier—and the way to build trust is to consistently and visibly do what you say you are going to do.

See how that works?

There’s nothing radical about our list other than the fact that we live by it, building the principles into our workflows and processes.

But that’s a story for another time.

In the meantime, which of the principles would be easiest for you to improve in your business or team? The first answer is usually clarity or visibility, but your mileage may vary.

---

Bonus: Watch us discuss these ideas

Three +UXC launches Conn3ct

🎉 Big news! We're thrilled to unveil our latest project for Three, Conn3ct! 🚀

Conn3ct is a future thinking #EmployeeExperience platform designed to revolutionize how teams at Three connect and thrive in our ever-evolving world! 🌐🤝

Say goodbye to disconnected teams, and hello to a whole new level of engagement! Conn3ct is more than just an app; it's your team's ultimate companion, seamlessly integrating News, Social features, Recognition, Reward, and real-time notifications. 📰📱✨

Would you like to dive deeper? We'd love to chat with you and explore how our Employee Experience platform can work wonders for your organization.

Let's connect and discuss how we can help you achieve similar amazing results! 📞🌟

100,000 thank yous!

In October 2021, we launched a new Employee Recognition portal for Three called 3Celebrates. It's a tool that allows employees to say thanks and as a way for Three to recognise their employee's milestones.

Since then, we've sent over 100,000 Thank yous, Happy Birthdays and Milestone Celebrations.

UXC are specialists in creating Employee Digital Tools, like 3Celebrates, that help creates an engaged, empowered workforce who communicate, collaborate and deliver business value regardless of location.

Three partners with UXC to build their Retail EmployeeXP App.

Three have selected UXC to design and build a new employee engagement app for their retail staff.

The app will make it easier for retail staff to support their customers by putting all the tools and information they need at their fingertips.

Three chooses UXC to deliver its new recognition system

UXC is very pleased to announce that we have been selected by Three Mobile to provide a brand new system to unify the recognition system between its UK and Ireland operations.

Three select UX Consultancy to deliver their new Intranet

UXC has worked in partnership with Three for the past 6 years to create an employee engagement platform that enables their employees to communicate, collaborate and deliver their business goals regardless of their location. 

We are very excited to continue this work with Three by creating a new best of bread corporate intranet that works seamlessly with their existing employee tools through the employee engagement platform.

Reach TV Selects UX Consultancy to design their new digital streaming platform

UXC is very pleased to announce that we have been selected by Reach TV to design a their new online Digital streaming proposition.

Reach TV’s shares its digital video content to 128 million customers across 1.7k screen in 90 airports across America and is expanding its potential audience with the creation of its new web streaming offering. UXC has been engaged to help ReachTV through a discovery and designs sprint.