I recently got back from a week-long offsite in Los Angeles, and it was awesome. I love to solve problems and get on a whiteboard, and that’s exactly what you do at an offsite. For whatever reason the experience also got me thinking about my purpose at Group 18. Why am I doing this? How am I making the world better?
One thought that has come back a few times is something like: “to make work fun.”
I mean, it is not fun to lose money. It is not fun to fight your internal systems. It’s not fun to be blind about the data of your own business. People working in environments like that are not flourishing as much as they could. In fact, it can be quite stressful! The founders, owners, and executives of these businesses can get burnt out and disillusioned, and bring that negative energy home.
On the flip side, it is fun to fix all of those problems. To make money. Achieve flow with your systems. Have visibility into data.
It is also fun to make jokes while fixing them, because why not? 🤣 Making Simpsons references during an offsite doesn’t hinder the outcomes!
If I can solve company scaling problems and make people happier while I’m at it, that’s win-win. If people can go home feeling energized for their families and communities and themselves, that’s beautiful.
This is just an early shower thought. Not sure whether I’ll keep this or not, but I enjoyed contemplating a bigger purpose.
In other news, by reader request, there’s now a “buy me a coffee” link at the bottom of each issue of “The Catalyst.” ☕ (scroll down to the end) No pressure, but if these newsletters have made you think, laugh, or sound smarter in a meeting, you can share your gratitude - and I’ll send my appreciation your way 😁
Thanks, Kevin
A Quote
“
What we fear doing most is usually what we most need to do. As I have heard said, a person’s success in life can usually be measured by the number of uncomfortable conversations he or she is willing to have. Resolve to do one thing every day that you fear.
— Tim Ferriss in "The 4-Hour Workweek"
Three Things
1 - 📗 An Immense World This book was a staple of dinner conversations nearly every night while I was reading it. If you wanted to get a better understanding of how the enormous variety of animals across planet Earth get a sense of their surroundings (e.g. electric sense, magnetic, etc.), then you’ll find this book very interesting!
2 - ⌚ Whoop 5.0 I’m a sucker for data, and the latest Whoop bracelet, just announced, adds blood pressure sensing alongside a lot of the normal health and wellness metrics you might get from other devices. If you already wear a Whoop, let me know how you like it!
3 - 🏎️ McMurtry Spéirling at Top Gear This electric luxury car, priced at one million British pounds, or $1.3M USD, goes around the Top Gear test track faster than a Formula 1 car - and looks like a Hot Wheel toy. Top Gear had to weld the water drainage gates on the track closed, lest the suction created by the car yoink them up into the air. The lack of engine noise for something going so fast is something I’m still not used to!
(Enjoy this minute read)
Deep Dive on the Need, Ask, and Deliver Framework
Often I’m sharing concepts here with you that have been written about for decades. It’ll be something I’ve read widely on, have experienced personally, and want to share with you.
But this weekend I was looking through a list of concepts I’d written down - brainstorming possible courses I could teach - and I came across a line that said “Need - Ask - Deliver.”
This is something I’ve never read about and have no book notes on. It came to me as I was diagnosing something during my tenure at Atlassian. We’d run dozens of cross-functional programs across a couple hundred people, and sometimes - often times - things didn’t go according to plan.
Of course, many things can derail a program, but this trio - Need, Ask, and Deliver - became a useful diagnostic for me. Today I want to share the framework with you so you can use it to diagnose your own business.
The Framework
Each name in the framework stands for an abstraction in your business.
Need - What does the business / customer need? Ask - What was asked for? Deliver - What was delivered?
Pretty simple!
In an ideal world, those three things are the same. - You need caffeine. You ask for a hot americano. You receive a hot americano. - A client needs a website update. They submit a ticket for a new hero image. The design team updates the hero image. - Users need password recovery. They request a “Forgot Password” feature. The dev team ships a password reset flow.
It's ideal when all three of these things are the same.
As teams get larger, the needs get bigger in scope, and teams re moving faster, these three things can start to dislocated; the Ask no longer aligns to the Need, and what gets Delivered isn’t what was Asked for.
I bet you can think of a lot of times in your past when the Need, the Ask, and the Delivery were NOT the same thing!
"I asked for roasted chicken!" "Yeah, but the kitchen is spread thin so we delivered chicken nuggets."
This can also go the other way, where Delivery is more than the Need. Imagine a customer that has a small need. The internal team has a pet project they want to push through, so they include more scope than would satisfy the customer. Then the delivery team wants to take the opportunity to fix some technical debt at the same time, so they add more scope to the request.
Do you see how that gets you in trouble? A simple customer request balloons into high scope and long execution times.
When value delivery seems off, teasing apart these three elements is a helpful diagnostic. So how can you start to dive into this?
Be Explicit, and Probe
The absolute best thing you can do as part of your business is to be explicit about each of these three things. Bring the vocabulary into the conversation. If it’s not clear what each element is, you’ll have a very hard time ensuring your teams are delivering value to the customer.
Just ask: - What does the business / customer need? - What was asked for? - What did / will the team deliver?
It sounds easy, but people can obfuscate this! It’s not usually malicious, but if you allow language to be mushy, or you don’t probe for deeper understanding, this can get away from you.
For example, a team presents a scope document to you. You assume it’s what they’ll deliver, but it's actually aspirational; they’re not resourced to deliver it.
Or, a team will proudly present some deliverable. You assume it’s what was asked for, and what the customer needs. Turns out, it’s not what they were asked to build, and even further from what the customer needed. The team is pleased, but the customer is not.
Your job as a leader is to unearth those assumptions by asking clear questions. Don’t allow mush. Ensure things are being clearly documented so you can go back and reference these elements over time.
No mush. Get precise.
While it’s good to be explicit and probe, it’s still reactive, not proactive. Let’s go deeper into the root causes.
I’ll cover five of them quickly: lack of focus, insufficient resourcing, incentive misalignment, unclear responsibility, and agile iteration.
Lack of Focus - I’ve seen departments where the leaders don’t like to cancel work; only add. Instead of focus, you get hundreds of projects. Since the project count and staff count are essentially fixed numbers, the only thing a team can do is reduce the scope of what’s delivered.
Insufficient Resourcing - This is often, but not always, related to lack of focus. If you’ve got so many projects going on that you end up assigning each person to multiple concurrent projects, then very few projects are given the staff they need to deliver the full scope the customer needs.
Incentive Misalignment - Teams are typically rewarded on shipping output (doing stuff). Leaders might say they care about outcomes, yet they don’t do so in practice. This is especially true in a large cross-functional program where many teams are contributing to a big goal. Since accountability is diffuse, you revert to the easier method of assessing output.
Unclear Responsibility - Who is in charge of aligning Needs, Asks, and Delivery? Not only is this framework rarely explicit, but when multiple teams are working together it’s not obvious who is supposed to keep them aligned! Since no one person is in charge of ensuring the Need aligns to Ask and to Delivery, it doesn’t happen.
Agile Iteration - Everyone might intend to deliver what the business needs, but operating in an “agile” environment complicates things. This is because a gap in delivery is intentional in agile; after all, you’re iterating. In practice it’s hard for a leader to differentiate between an expected intermediate gap (fine), and an unexpected final gap (bad).
When all of these factors exist simultaneously even the best teams can find themselves misaligned between Need, Ask, and Delivery. It’s rarely a matter of bad intent. It’s a matter of systemic drift.
If you want to lead well in complex systems, your job is to constantly re-anchor to the business need, clarify the ask, and stay vigilant as delivery progresses.
Consequences of Misalignment
Alright, so we’ve got a framework, and we know the causes. But what’s the cost of getting these elements misaligned?
The biggest problem is that ultimately you don’t build what the customer needs! Over time customers get unhappy, and possibly leave. Your competitors gain an edge. That may seem extreme, but it’s true. It doesn’t happen all at once, but each slip slowly pushes your business in that direction.
Other consequences are: - Lower Trust: Customers stop trusting your company if their needs aren’t delivered. Teams stop trusting each other if delivery falls below the ask. - Waste: When you don’t build what the customer needs, it’s often not helpful and goes in the trash. Many a project has been shelved after delivery because it wasn’t needed. - Burnout: People like making progress and building momentum. When you get alignment wrong momentum slows and people begin to feel a sense of burnout.
Countermeasures
It’s fine and good to have a framework, but how do we put it to work?
Start by reversing the drift. Most dislocations between Need, Ask, and Deliver stem from predictable system flaws. Tackle them head-on: - Ruthlessly prioritize the critical few items that truly matter. - Resource properly. No more spreading people thin across multiple projects. - Tie rewards to business outcomes, not just activity or output. - Assign explicit ownership for aligning Need, Ask, and Deliver across the project lifecycle.
You can also embed this into your team rituals. During retrospectives or milestone reviews, ask three simple questions: - What was the business need? - What did we ask for? - What did we actually deliver?
This practice is even more powerful if you captured these elements during planning, not just after the fact.
And don’t forget psychological safety! Specifically Challenger Safety. Without it your team won’t speak up when they notice gaps. They’ll nod politely while watching misalignment unfold. That’s not a delivery problem. That’s a leadership problem.
How your team acts without Challenger Safety.
Call to Action
This week, pick an important initiative - something your team is delivering or a key customer outcome - and run a quick diagnostic. Explicitly document the Need, the Ask, and what’s being Delivered.
No need to overdo it - jot it in your notebook or sketch it on a whiteboard. The point is to practice seeing Need, Ask, and Deliver as distinct elements.
If you get this alignment right, your customers will notice. Your team will feel the clarity. And you’ll build momentum that compounds.
